[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RM Use Cases
Hello all: please find below some RM use cases (co-written by Fujitsu & Savvion), for your review... Jacques
Three use cases can be independently used
to demo Reliable Messaging:
Use Case A: demonstrates "guaranteed delivery" (resending a failed
message)
Use Case B: demonstrates elimination of duplicates (idempotency)
Use Case C: demonstrates handling of a failed Ack (combines A & B)
Terminology:
MSH means Messaging Service Handler. (impements ebXML TR&P)
1. Use Case A: Resending a Reliable Message not well received.
------------------------------------------------------
Context:
Track #1 of demo draft, purchase order exchange.
Description:
as Case title says.
Steps:
- Buyer App: sends a "reliable" PO.
- Buyer MSH: sets header field (DeliverySemantics = "OnceAndOnlyOnce")
and generates a SequenceNumber=1.
- Seller MSH: does not receive it because of sub-transport failure,
or because of a host failure. (See suggestion for practical simulation
below).
- Buyer MSH: does not receive the expected Ack (MSH-level) .
- Buyer MSH: After the timeout has expired, resends exactly same PO.
- Seller MSH: receives the PO, sends back the Ack, and transfers PO to
SellerApp.
Buyer App Buyer MSH Seller MSH Seller App
PO |------------> |-------------- PO------* (no PO)
at timeout:
PO |------------> |------------- PO------------>|--------> PO
|<-----ebXML Ack--------------|
POAccept |<------ |<----------- PO Accept ----- | <------ PO Accept
|------ ebXML Ack------------>|
2. Use Case B: Elimination of Reliable Message duplicate.
------------------------------------------------------
Context:
Track #1 of demo draft, purchase order exchange.
Description:
as Case title says.
Steps:
- Buyer App: sends a "reliable" PO..
- Buyer MSH: sets header field (DeliverySemantics = "OnceAndOnlyOnce")
and generates a SequenceNumber=1 (or increment if not the first).
- Seller MSH: receives it and passes it to the SellerApp, and sends
back an Ack to BuyerMSH.
- Seller MSH: Because of a sub-transport problem or a Buyer MSH problem,
receives again the same message. (See suggestion for practical
simulation below).
- Seller MSH: sends back an Ack to BuyerMSH, detects duplicate
(SeqNumber is
same as previous one), discards message (does not pass it to Seller
App).
Buyer App Buyer MSH Seller MSH Seller App
PO |------------> |------------- PO-----------> |--------> PO
|<-----ebXML Ack--------------|
*----- PO------------> |(duplicate)
|<-----ebXML Ack--------------|
POAccept |<------ |<-------------- PO Accept ---| <------ PO Accept
|------ ebXML Ack------------>|
3. Use Case C: Failed Acknowledgement for a reliable message.
------------------------------------------------------
Context:
Track #1 of demo draft, purchase order exchange.
Description:
A reliable Message is well received, but its Ack is not well transmitted
back
to sender. The sender resends the message after timeout. The seller
detects
a duplicate and ignore the repeated message. This is a combo of Case A &
Case B.
Steps:
- Buyer App: sends a "reliable" PO.
- Buyer MSH: sets header field (DeliverySemantics = "Once AndOnlyOnce")
and generates a SequenceNumber=1 (or increment if not the first).
- Seller MSH: receives it and passes it to the SellerApp, and sends
back an Ack to BuyerMSH.
- [Seller App: is in the process of preparing a PO Acceptance]
- Buyer MSH: Because of a sub-transport problem or a Seller MSH problem,
does not receive the Ack. (See suggestion for practical simulation
below).
- Buyer MSH: After the timeout has expired, resends exactly same PO.
- Seller MSH: receives the PO, sends back an Ack to BuyerMSH
- Seller MSH: detects duplicate (SeqNumber is same or smaller than
previous one),
discards message (does not pass it to Seller App).
Variant:
- the PO acceptance could be sent and received by Buyer even before
timeout
of intial PO expires.
Buyer App Buyer MSH Seller MSH Seller App
PO |------------> |------------- PO-------------> |--------> PO
*--ebXML Ack------------|
at timeout:
PO |------------> |------------- PO-------------> |(duplicate)
|<-----ebXML Ack----------------|
POAccept |<------ |<-------------- PO Accept -----| <------ PO Accept
|------ ebXML Ack-------------->|
4. Demo Implementation Notes
-------------------------------
4.1- Note that the MSH sender of a reliable message is supposed
to store the message until an Ack is received
(and resend it if needed, transparently to the App layer).
As the next Application message can be sent without waiting
for the Ack of the previous one,
it is expected that several messages need to be stored.
This results from lifting the "blocking" constraint
(lines 123-125 in v0.080 should be removed.):
"Service and the Sender's Messaging Service will not
initiate a new message transmission until a current
message transmission has been correctly received."
However, in the context of the demo, we should not have to deal with
several concurrent msg_sendings/msg_acks. So one message at most
would need be stored at any time, for each connection (pair sender-receiver).
4.2- How to simulate the "failures": two solutions:
(a) The Seller MSH has a configuration parameter that will make it NOT
send an Ack for a received reliable message (just once) (supports
Case C), or ignore a received appmessage (just one) (supports Case A).
The Buyer MSH has a configuration parameter that will make it resend
twice the next app message (supports Case B).
(b) We can use one of the candidate Hubs, to simulate sub-transport
problems.
As we understand, Viquity's Hub is a router that is transparent to
MSH layer: it generates no Ack, makes no changes to routing header
fields, just transfers any message.
The only "ebXML intelligence" this Hub has, as an exception to its
dumbness (no offense Philippe),
is that there is a DUNS field somewhere in the header that it can read
to decide of which URL to send it next.
It does not fall into the category described in Phase 2 (section 4)
of the RM spec, so is not involved at all in the Reliability mechanism.
Such a Hub really is part of the "sub-transport"
layer, and we can use it to simulate network problems,
and reliable exchanges between two end points. We can demonstrate:
- Use Case A: by intercepting and deleting a PO message at Hub level.
- Use Case B: by resending a PO message at Hub level.
- Use Case C: by intercepting and deleting an Ack message at Hub level.
Here, we would act manually at Hub level, selecting messages based on
their origin-destination, and showing the audience what kind of
"trouble" we simulate.
(To check with Philippe on detailed procedure.)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC