[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Propsals from Shan Harter
Ian:
Interesting use case. My comments:
First a few comments on conformance to ebMS2:
(a)- there are several Acks going on, yet there is no apparent use of the Reliability feature (e.g. no AckRequested element, but introduction of header extension (non normative):
<eb:QualityofServiceInfo eb:deliverySemantics="OnceAndOnlyOnce"/>
(b)- the Acknowledgement element does not contain RefToMessageID (not conforming). Instead, the Response message presents itself as an (empty) business message that is referring to the previous one, and just acting as an business-level Ack - see the "Upload / Response" [Service/Action] message. The contained Ack element seems to be just as a way to distinguish from error cases.
General comments:
(c)- these acks and other Receipts (see the "Download/CompleteRequest" and "Download/CompleteResponse" messages) are driven at application level. With Reliable messaging, they should not have to. Unless some business receipt is needed.
(d)- The scenario is indeed a case of Push-and-Pull MEP, although not the most straightforward: one where there may be many responses. The pulling demonstrated here is a 2-step pull, with step1 to get a list of DocumentIDs ("Directory/Request"), step2 to fetch each Doc individually ("Download/Request") all this implemented outside ebMS2 because it does not support queuing/pulling. (It seems that it is the best alternative.)
(e)- We can speculate that users would not need to do this with ebMS3: the "Server" would just post 1 by 1 all its response docs, each as a separate message. The Client MSH would then either pull these 1 by 1, but not based on DocumentID (nor on messageID), just FIFO. This is not even a case for pull-by-messageID, since once posted by the Server app, there is no rationale for pulling the responses based on messageID (the client can't make the association messageID-documentID).
(f)- Talking of support for such a Push-and-(multiple)Pull MEP: at MSH level, the correlation between all these responses and the initial request, would only appear via RefToMessageId. Although we might make the case that the client MSH has the ability to selectively pull (based on RefToMessageId ) these responses from Server (e.g. to satisfy a "GetResponseFrom" API call from its app) I would not go there: I believe it is again up to the queuing at Client MSH to support such API calls. Does not have to translate into selective pulling between MSHs.
So I see this use case as indeed a good case for Pulling (here, Push-and-Pull MEP), the "Server" being only able to respond to protocol requests. I think a lot of what the use case is implementing on top of ebMS2 can be supported by ebMS3.
Jacques
-----Original Message-----
From: ian.c.jones@bt.com [mailto:ian.c.jones@bt.com]
Sent: Tuesday, August 16, 2005 8:18 AM
To: ebxml-msg@lists.oasis-open.org
Cc: shan.harter@systrendsinternational.com
Subject: [ebxml-msg] Propsals from Shan Harter
Team,
below is an e-mail submitted by Shan Hartner with the attachements removed and plced directly on our repository with the links at the bottm of the e-mail. This should make it easier for everyones e-mail servers/slow links as the attachments would total about 900K.
Sorry, I have been a little slow passing this out due circumstances beyond my control. Speak to you tomorrow - the meeting notice will follow shortly.
<quote>
Ian,
In the Word attached document, I am submitting it for community use and adoption as the group sees fit.
You will see that the act of utilizing the MSH is completed with action verbs such as:
Upload
Directory
Download
Profile
Notices
EBTStatus
Session
See page 21.
This document is not 100% complete, but with it and the use cases you'll get a clear definition.
I have also attached some use cases.
In the Pull-MODULE-MOU.pdf, the following is supported/addressed by the attached document
1. Is supported
2.1. Is supported (the queue or Sending MSH is in a server role providing the receiving MSH data to be retrieved)
2.2. Supported
2.3. Supported (manual CPA)
3.1. Supported
3.2. Supported
3.3. Supported - this is covered by a directory request. See 7.2.2 Directory Request Message,
7.2.2.2 Payload Requirements and 7.2.3 Directory Response Message and a few others.
3.4. Supported
4.1. Supported, with ack receipt
4.2. Supported, with ack receipt
5.1. see delivery status... and others...
5.2. believe we do this as well...
Attached is also an example log showing how a sending MSH (thin client) would act if it was sending and receiving from a "provider" (server) MSH.
Regards,
Shan
Shan Harter
VP of Project Services
PEBS, Inc.
Tempe Arizona, 85284
ph: 480-756-6777 Ext 205,
fax: 480-756-9755, cell: 602-821-2951
http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/14065/ebXML%20Use%20Cases.doc
http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/14066/ebXMLClientReceivingMSHExample.txt <http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/14066/ebXMLClientReceivingMSHExample.txt>
http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/14067/ebMSH-Hub-Spoke-Transport.doc <http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/14067/ebMSH-Hub-Spoke-Transport.doc>
Regards,
Ian Jones
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]