- From: Krishna Sankar <ksankar@cisco.com>
- Date: Mon, 22 Jul 2002 22:11:05 -0700
- To: <www-ws-cg@w3.org>
Chris, I was talking more about a prescriptive document defining the MEPs not a descriptive one. If different layers refer to an MEP, we need to have crisp, clear, concise and interoperable "stuff" like naming schemes, message ids, referable some state information (like Stage 2 in a req-response MEP) et al. The WSA Usage scenarios do consist of the common choreographies and message patterns. But the scenarios describe things, we cannot make things out of a scenario. We should be able to make it a prescriptive document by adding unique ids to each scenario, eliminating duplicates, naming the messages in each choreography, and developing a schema. Then specifications like WSDL can unambiguously refer to an MEP or part of an MEP. One of the crisp definitions of MEPs can be found in RosettaNet. They clearly define the message, choreography et al and one can clearly refer to the parts - like first interaction of PIP3A4, which is send a PO, from a buyer to a supplier. We, actually, can abstract one step up and define a 4 message choreography and call it Request-Accept-Dance MEP. Then we can inherit the MEP to PIP3A4 and add the domain specific messages, making the Purchase Order choreography. To postulate further, if we had defined the Request-Accept-Dance MEP, the RN would have had to only define the domain specific messages ! Any MSH which implements the MEP would then be able to handle RN messages. BTW, if we also add how sessions and context would be handled in the MEP, then we achieve uniformity and interoperability between domains. Correlation ID and similar artifacts would become part of the MEP and away from the domain. Again, this would be a hierarchy of MEPs, similar to OO with multiple inheritance. In this utopian scenario, we have achieved transport and protocol independence at the upper layers while keeping interoperability, uniformity and pluggability at the lower layers. For example one can truly achieve the OrderSend business process with RN/SOAP/http and use RN/SMTP at the other end without missing a beat - all in the MEPs ! May be I am rambling, who knows. Anyway, my 0.02$ cheers | -----Original Message----- | From: www-ws-cg-request@w3.org | [mailto:www-ws-cg-request@w3.org] On Behalf Of Christopher B Ferris | Sent: Monday, July 22, 2002 7:27 PM | To: Krishna Sankar; www-ws-cg@w3.org | Subject: RE: Message exchange patterns document | | | | | I think that you will find that the Usage Scenarios doc [1] | makes a valiant | attempt | at trying to articulate thes layers. | | Cheers, | | Christopher Ferris | Architect, Emerging e-business Industry Architecture | email: chrisfer@us.ibm.com | phone: +1 508 234 3624 | | [1] | http://www.w3.org/2002/ws/arch/2/07/16-ws-arch-scenarios/ws-a | rch-scenarios.html | | | | | | "Krishna Sankar" | | <ksankar@cisco.co To: | <www-ws-cg@w3.org> | | m> cc: | | Sent by: Subject: RE: | Message exchange patterns document | www-ws-cg-request | | @w3.org | | | | | | 07/22/2002 03:58 | | PM | | | | | | | | | | Philippe, | | Exactly. IMHO, the cohesiveness and coherence | between the | "layers" when talking about MEPs is what this document | should achieve. | SOAP,WSDL, orchastrators et al could be talking about the same MEP or | different MEPs at different layers or (the most common | scenario) would | be aggregation of lower layer MEPs at higher layer. In any case, well | defined MEPs at various layers, in a common shared document | would help. | | cheers | | | -----Original Message----- | | From: www-ws-cg-request@w3.org | | [mailto:www-ws-cg-request@w3.org] On Behalf Of Philippe Le Hegaret | | Sent: Monday, July 22, 2002 12:02 PM | | To: Hugo Haas | | Cc: www-ws-cg@w3.org | | Subject: Re: Message exchange patterns document | | | | | | | | On Mon, 2002-07-22 at 13:59, Hugo Haas wrote: | | > | | > As per my action item, I have started a document about message | | > exchange patterns whose goals are (from the abstract): | | > | | > * explain how to document a MEP. | | > * list the MEPs developed within the Web Services Activity. | | > * eliminate discrepancies. | | > | | > The document is available at: | | > | | > http://www.w3.org/2002/ws/cg/2/07/meps.html | | > | | > Message exchange patterns have a role in SOAP, WSDL, and | | are likely to | | > come to play in other places (e.g. conversation, choreography). | | > | | > I think that the XML Protocol Working Group and the Web Services | | > Description Working Group should come in agreement about | | using a same | | > concept and way to describe MEPs, and that the Web Services | | > Architecture Working Group should look into generalizing MEPs. | | | | After some readings on SOAP, WSDL, and other languages | MEPs, I wonder | | how useful it would be to have a common document for them. | | SOAP works at | | the protocol level, WSDL works at the message level, and | | choreographic | | languages work at the web service level. You can hardly | compare them. | | MEPs are more horizontal than vertical imho. | | | | Philippe | | | | | | | | | | | | | | |
Received on Tuesday, 23 July 2002 01:12:07 UTC