OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ebxml-msg] about async responses


Title: about async responses
Jeff:
looks fine in general, with some minor comments:
 
- In (b), nothing actually requires the bundling of the RM Reply
to use the business response message (PO Ack ) that matches the request (PO) to be acknowledged.
An implementation of RMP is unlikely to be able to enforce this (the async business response being submitted
as a separate reliable request, the RMP has no knowledge of this correlation).
I see this bundling as something that will rather be driven by run-time contingencies: any reliable message submitted
the other side, is fair game for bundling... and if none is sent at the moment, the RMP may decide to just send
a separate callback message (as in (a)) after a while.
 
- in all your exchanges below,  you give the same "reply pattern" to both the PO message and the PO Ack message.
It does not have to be that way: the pattern used  from A to B does not have to be same as from B to A.
 
Cheers,
 
Jacques
-----Original Message-----
From: Jeff Turpin [mailto:jturpin@cyclonecommerce.com]
Sent: Wednesday, September 08, 2004 9:29 AM
To: Jacques Durand; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] about async responses

I would like to summarize where I think we are in terms of the use of WS-Reliablility for the ebMS Request-Response MEP (Async). I typed this up rather quickly so I apologize if my mock diagram is confusing. In addition I feel it will be necessary to keep the ebXML MessageId and RefToMessageId elements to allow for correlation of Async Request-Response messages.

 

ebMS Request-Response MEP (Async):

 

      COMPANY_A                                                                                                                            COMPANY_B

 

SOAP One-way MEP: Payload (PO BOD, etc.) ------à S-RMP.Submit -------à R-RMP.Deliver -----à Payload(PO BOD, etc.)

SOAP One-way MEP: Payload (PO Ack BOD, etc.) ß------------ R-RMP.Deliver <---------- S-RMP.Submit ß------------- Payload(PO Ack BOD, etc.)

 

RM-Reply options:

 

a.       Callback RM-Reply:

 

SOAP One-way MEP: Payload (PO BOD, etc.) ------à S-RMP.Submit ---------à R-RMP.Deliver -----à Payload(PO BOD, etc.)

SOAP One-way MEP: S-RMP  ß------------------------------------ R-RMP(RM-Reply(Ack or Fault))

 

SOAP One-way MEP: Payload (PO Ack BOD, etc.) ß------------ R-RMP.Deliver <------------- S-RMP.Submit ß------------- Payload(PO Ack BOD, etc.)

SOAP One-way MEP: R-RMP(RM-Reply(Ack or Fault)) ----------------------------------à S-RMP

 

b.       Callback RM-Reply(Bundled):

 

SOAP One-way MEP: Payload (PO BOD, etc.) ------à S-RMP.Submit   +   R-RMP.Deliver -----à Payload(PO BOD, etc.)

 

SOAP One-way MEP: Payload (PO Ack BOD, etc.) ß------------ R-RMP.Deliver ß------------- (Payload + RM-Reply) S-RMP.Submit ß------------- Payload(PO Ack BOD, etc.)

SOAP One-way MEP: R-RMP(RM-Reply(Ack or Fault)) ----------------------------------à S-RMP

 

c.       Poll RM-Reply:

 

SOAP One-way MEP: Payload (PO BOD, etc.) ------à S-RMP.Submit   +   R-RMP.Deliver -----à Payload(PO BOD, etc.)

SOAP One-way MEP: S-RMP(RM-PollRequest) ----------------------------------à R-RMP

            Or

SOAP Request-Response MEP: S-RMP(RM-PollRequest) ----------------------------------à R-RMP

 

SOAP One-way MEP: S-RMP  ß------------------------------------ R-RMP(RM-Reply(Ack or Fault))

            Or

SOAP Request-Response MEP: S-RMP  ß------------------------------------ R-RMP(RM-Reply(Ack or Fault) – Sent in SOAP Response)

 

SOAP One-way MEP: Payload (PO Ack BOD, etc.) ß------------ R-RMP.Deliver <------------- S-RMP.Submit ß------------- Payload(PO Ack BOD, etc.)

SOAP One-way MEP: R-RMP <--------------------------------- S-RMP(RM-PollRequest)

            Or

SOAP Request-Response MEP: R-RMP <--------------------------------- S-RMP(RM-PollRequest)

 

SOAP One-way MEP: R-RMP(RM-Reply(Ack or Fault))  ----------------------------------à S-RMP

            Or

SOAP Request-Response MEP: R-RMP(RM-Reply(Ack or Fault) – Sent in SOAP Response)  ----------------------------------à S-RMP

 

 

 

 

 

 

 


From: Jacques Durand [mailto:JDurand@us.fujitsu.com]
Sent: Wednesday, September 01, 2004 10:54 AM
To: 'ebxml-msg@lists.oasis-open.org'
Subject: [ebxml-msg] about async responses

 

 

Precision on how reliable async "responses" could be handled:

First a reminder that ebMS Request-response MEP was implicit in ebMS 2.0 with reftomessageid,
and additionally for synchronous case, with SyncReplyMode.

Assuming a more explicit notion of ebMS Request-response:
When asynchronous, such an ebMS-level MEP does not necessarily map to a single SOAP Request-response MEP instance (the HTTP binding of which is - though not necessarily - commonly defined as an HTTP Request-response).

An asynchronous ebMS Request-response does not have to involve WS-R Deliver+Respond.
these two messages do not have to appear as a pair Request / Response at RMP level:
they may be handled as two unrelated SOAP messages (submitted to RMP via "Submit" operation), and therefore subject to same WS-Reliability handling (same RM features).

(They could map to - for example - two SOAP One-way MEP instances.)

This of course does not hold for synchronous ebMS Request-responses, but then their likely binding to
an underlying synchronous protocol will not require the same handling of reliability for Responses.

Jacques

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]