[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: message routing
My turn;-)
Please see my comments below.
Cheers,
Chris
Martin W Sachs wrote:
>
> Dale,
>
> First, I would like to separate routing from multiparty.
>
> ROUTING
>
> The routing issues exist at the message service handlers at the From and To
> party. It has become clear that single conversationId, Service, and Action
> elements are not necessarily sufficient and that refToMessageId is not
> precisely enough defined in the message service spec at this time to be
> able to rely on it as a routing element. CPAId is also an element in the
> routing matter. Role should also be useful but it isn't clear that the Role
> element in the message service spec is directly related to authorized role
> in the BPSS spec since it seems to be tied into packaging. There have also
> been suggestions that 2 levels of service and action are not necessarily
> sufficient although I am not sure that the use of conversationId and CPAId
> were taken into account. The routing subject needs a lot more attention.
I agree that it deserves attention, the larger question in my mind is what
manner of attention?
In general, I concur with Marty's observations above. The unfortunate
aspect we have at present is the common-law marriage of CPA and MSH. While
on the one hand, we were attempting to align these specifications as best
we could, on the other hand, we were trying very hard to preserve their
independence from one another so that each could be considered valuable
on its own. This was the case for all of the ebXML specifications to
a certain extent.
The combination of CPAId (hence the actual CPA or some manifestation
of the information that is defined by a CPA), ConversationId (which
identifies for the runtime state regarding the exchange of messages
that are related in a way that is described by the CPA and BPSS (or
some other description of the choreography), Service and Action
are all useful and in many ways necessary for "routing".
I will grant that for some simple exchanges, a BPSS description
is overkill. Something like a WSDL description may be more than
adequate. However, WSDL is lacking in some aspects that are covered
in the CPA which I and hopefully others think important.
>
> Regarding your fourth paragraph. I definitely agree that the routing
> issues are on the private side (between MSH and application) but there is
> also the question of each party understanding what routing information it
> has to place in the message header to enable correct routing to take place
> at the destination. That does have CPA implications in that something may
> have to appear in the CPA to enable each party to understand the other
> party's needs. Perhaps that information is really in the Process
> Specification document but there are places in the CPA that have to point
> to the appropriate places in the Process Specification document.
Agreed.
>
> I think that the above paragraph already says it but just to make it
> perfectly clear regarding your last sentence: The combination of CPA and
> Process Specification document definitely applies to the contracts between
> MSHs and applications because that's how Service and Action are defined and
> tells the middleware what to send to the MSH to put in the Service and
> Action elements. This part is mostly performed by the CPA installation
> tool, of course, when it digests the CPA and builds the control block
> (database row, perhaps) that manages the information flow related to that
> CPA.
Agreed.
>
> MULTILATERAL CPAs
>
> In IBM Research, we deferred multilateral tpaML when we realized that there
> were major matters whose solutions would delay the basics. Problems we ran
> into included:
>
> Multiparty choreography (BPSS may have taken care of this one)
Possibly, but I don't believe that they gave it all the attention
that it really needs. What they did IMHO amounts to a placeholder
for dealing with multiparty choreographies in the next round.
Karsten, please correct me if I have mis-characterized this.
>
> Conversation state tracking across parties: To first order, each party
> needs a view to the message exchanges among all the parties in order to
> properly track the state of the conversation. A has to know about the
> messages between B and C to understand the current state. It wasn't
> clear how to do this without introducing yet more messages to exchange
> state information or if we could simply things by deciding that C does
> not have to know everything about what A and B are doing.
Yeah, this is where things get tricky!
>
> Are there things going on between B and C that A isn't supposed to know
> about even though there is a CPA among the three of them? Are there
> things in the CPA that relate to matters between B and C that A
> shouldn't even see in the CPA?
>
> Are there new security issues with more than two parties?
>
> We didn't give up on these problems. It was more of a case of crawling
> before walking before running. So yes, at least in my mind, leaving
> multiparty CPAs out of scope for version 1 was a matter of not having
> enough time to work the problem than because of any principle. We have
> seen the result of Core Components perhaps being too ambitious.
Agreed! ;-)
>
> Regards,
> Marty
>
> *************************************************************************************
>
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287; IBM tie line 863-7287
> Notes address: Martin W Sachs/Watson/IBM
> Internet address: mwsachs @ us.ibm.com
> *************************************************************************************
>
> Dale Moberg <dmoberg@cyclonecommerce.com> on 07/20/2001 11:56:41 AM
>
> To: Martin W Sachs/Watson/IBM@IBMUS, ebxml-cppa@lists.oasis-open.org
> cc:
> Subject: RE: message routing
>
> Marty and Prasad,
>
> It would be useful to assemble some examples/scenarios/etc
> that show why conversationId, service, and action
> (and I would add Role in there to the mix) fail to capture
> what needs to be asserted about multilateral conversations/flows.
> I suspect that it is true, but we are saying that there is something
> not expressible by means of certain semantic elements, so
> we need to be able to show and agree upon some of what is being
> left out.
>
> There was general agreement for v1.0 that multilateral CPAs
> were not in scope, but, as I recall,
> it was more because there wasn't
> enough time to sort all the issues out
> than a highly principled omission!
>
> I think we are also going to need to revisit terminology,
> because the tag "Service" has gotten just too tangled
> up now to use. For example, (referring to the
> recent PIP threads), talking about the
> selling service or buying service is semantically like
> what had previously been called the role in a BP.
> [I had always thought that the cluster part ("3A" )of a PIP
> designation was like a service (which I construed
> as a bundle of "actions"), whereas the "4" in 3A4 was
> like the Action designator. Returning the POAck
> was the Action that was the business level Response
> to the PO (3A4), which was the Request. But that
> might have been entirely my own picture!] And this is
> still while thinking about conversations, and
> before we even get to the web "services" turf!
>
> Finally, I think the concern with what information
> is needed for "routing" to the "application"
> (and the related process, which is receiving payload(s)
> from the application and knowing how to
> send it off), are basically kinds of information
> that pertain to the "private intranet side of
> integration" and not to the secure packaged
> transport or public side of integration. This information
> is important for the configuration of a MSH on its
> "application" interfacing sides, but is not clearly
> something that is needed for a CPA when understood
> as an agreement on those factors needed to
> exchange business data interoperably. We have
> always had a tension in deciding how much
> of this information to capture in CPPs or a CPA.
> One place to start in rethinking this issue is
> what capabilities are being advertized when the
> "service" , "action" and "role" fields are included
> in a CPP? For example, for a recipient,
> are we saying anything more than
> we can handle the incoming payload so that
> the output response payload(s) can eventually be
> made available back to the sender (or to other
> interested parties in the multilateral case)?
> Similar issues can be posed about what is
> being claimed within the CPA context. The
> point is that the CPA pertains mostly to the contract
> among/between MSHs, and not to
> contracts between MSHs and "applications".
>
> -----Original Message-----
> From: Martin W Sachs
> Sent: Fri 7/20/2001 7:07 AM
> To: ebxml-cppa@lists.oasis-open.org
> Cc:
> Subject: message routing
>
> FYI
>
> ************************************************************************
> *************
>
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287; IBM tie line 863-7287
> Notes address: Martin W Sachs/Watson/IBM
> Internet address: mwsachs @ us.ibm.com
>
> ************************************************************************
> *************
> ---------------------- Forwarded by Martin W Sachs/Watson/IBM on
> 07/20/2001
> 10:06 AM ---------------------------
>
> Prasad Yendluri <pyendluri@webmethods.com> on 07/19/2001
> 03:58:18 PM
>
> To: Scott Hinkelman/Austin/IBM@IBMUS
> cc: Arvola Chan <arvola@tibco.com>, Martin W
> Sachs/Watson/IBM@IBMUS,
> David Fischer <david@drummondgroup.com>, Burdett David
> <david.burdett@commerceone.com>, ebXML Msg
> <ebxml-msg@lists.oasis-open.org>, Pete Wenzel
> <Pete.Wenzel@RosettaNet.org>
> Subject: Re: PIP IDs
>
> Folks,
>
> I think I agree with Scott, Arvola and Marty :). Bottomline is,
> the current
> model based
> on the ConversationId, Service and Action is too inadequate to
> represent an
> arbitrarily
> large "conversation", that is potentially "multilateral" (as
> opposed to the
> current
> bilateral) and consists of >= 1 sub bilateral business
> processes.
>
> I think this would be one of important pieces of work for the
> next version
> of the MS
> spec. We need to come up with a more comprehensive, generic,
> robust and
> extensible model
> of a "conversation", that identifies a specific exchange
> belonging to a
> "conversation", a
> business process instance within, the specific action with that
> process,
> the originating
> and receiving parties, the originating and receiving service
> entities etc.
>
> Regards, Prasad
>
> -------- Original Message --------
> Subject: Re: PIP IDs
> Date: Thu, 19 Jul 2001 11:41:19 -0700
> From: Scott Hinkelman <srh@us.ibm.com>
> To: Arvola Chan <arvola@tibco.com>
> CC: Martin W Sachs <mwsachs@us.ibm.com>,David Fischer
> <david@drummondgroup.com>,Burdett
> David <david.burdett@commerceone.com>,ebXML Msg
> <ebxml-msg@lists.oasis-open.org>,Pete
> Wenzel <Pete.Wenzel@RosettaNet.org>
>
> >From the RosettaNet point of view, it will be desirable if we
> can have
> distinct Service, PIP (equivalently BPSS Business Transaction),
> and action
> elements in the message header.
>
> Again, my view on this is to define a Qualified Invocation
> sequence
> generically with an arbitrary number of tags, and
> drop the tag names "Service" and "Action". Just as ebXML Message
> Service
> defines a SOAP+Attachments Profile,
> RosettaNet would define an ebXML Message Service Profile, which
> would
> contain mapping to its PIP,etc,etc, (its invocation
> qualification).
>
> Scott Hinkelman, Senior Software Engineer
> XML Industry Enablement
> IBM e-business Standards Strategy
> 512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
> srh@us.ibm.com, Fax: 512-838-1074
>
> Arvola Chan <arvola@tibco.com> on 07/19/2001 09:03:32 AM
>
> To: Martin W Sachs/Watson/IBM@IBMUS, David Fischer
> <david@drummondgroup.com>
> cc: Burdett David <david.burdett@commerceone.com>, ebXML Msg
> <ebxml-msg@lists.oasis-open.org>, Pete Wenzel
> <Pete.Wenzel@RosettaNet.org>
> Subject: Re: PIP IDs
>
> Marty,
>
> Up to now, RosettaNet PIPs are either request-response
> (two-actions) or
> notification (one-action) style business processes. Earlier
> versions of
> PIP 3A4 are an exception in the sense that PIP 3A4 covers
> Create Purchase
> Order (request-response), Change Purchase Order
> (request-response) and
> Cancel Purchase Order (request-response) interactions.
> Recently, PIP 3A4
> has been split into 3A4 (Create Purchase Order), 3A8 (Change
> Purchase
> Order), and 3A9 (Cancel Purchase Order) in order to achieve
> some degree of
> uniformity across PIPs (I believe). Therefore, I think it is
> reasonable to
> equate existing RosettaNet PIPs with BPSS Business
> Transactions.
>
> In the RosettaNet message header, there are separate elements
> to identify
> the PIP ID, the PIP action and the Service. Multiple PIPs may
> be
> implemented by the same service, e.g., there may be a Buyer
> service
> implementing PIPs 3A4, 3A8, 3A9 from the buyer perspective, and
> a Seller
> service implementing the same PIPs from the seller perspective.
>
> I don't think we should equate PIP ID with Service and action
> with "the
> particular business transaction within the PIP". Otherwise, we
> will not be
> able to capture the role information, e.g., the ability to
> distinguish a
> Buyer Service from a Seller Service, and a request action from a
> response
> action.
>
> From the RosettaNet point of view, it will be desirable if we
> can have
> distinct Service, PIP (equivalently BPSS Business Transaction),
> and action
> elements in the message header. Alternatively, we can use the
> Service
> element to capture role information (e.g., Buyer vs Seller), and
> use the
> Action element to capture the PIP ID. Whether we are dealing
> with a
> request action or a response action will have to be inferred
> from the
> Service element.
>
> Regards,
> -Arvola
>
> Arvola Chan (arvola@tibco.com)
> TIBCO Software (on loan to RosettaNet)
> +1-650-846-5046 (US-Pacific)
>
> ----- Original Message -----
> From: "Martin W Sachs" <mwsachs@us.ibm.com>
> To: "David Fischer" <david@drummondgroup.com>
> Cc: "Burdett, David" <david.burdett@commerceone.com>; "ebXML
> Msg" <
> ebxml-msg@lists.oasis-open.org>
> Sent: Thursday, July 19, 2001 8:07 AM
> Subject: Re: PIP IDs
>
> In my opinion it makes more sense for Service to point to the
> PIP ID and
> action to point to the particular business transaction within
> the PIP. In
> other words one execution of a PIP is a conversation. I believe
> that some
> of the PIPs include multiple business transactions.
>
> Regards,
> Marty
>
> ************************************************************************
> *************
>
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287; IBM tie line 863-7287
> Notes address: Martin W Sachs/Watson/IBM
> Internet address: mwsachs @ us.ibm.com
>
> ************************************************************************
> *************
>
> David Fischer <david@drummondgroup.com> on 07/19/2001 10:45:54
> AM
>
> To: "Burdett, David" <david.burdett@commerceone.com>
> cc: ebXML Msg <ebxml-msg@lists.oasis-open.org>
> Subject: PIP IDs
>
> David, in the F2F you mentioned the need for a new element to
> contain
> industry specific business process identifiers such as a
> RosettaNet PIP
> identifier. Could this be done with Service/Action where the
> Service would
> be something like RNet and the Action something like PIP3A1
> (Request
> Quote)?
>
> <eb:Service>urn:services:RNet</eb:Service>
> <eb:Action>PIP3A1</eb:Action>
>
> Regards,
>
> David Fischer
> Drummond Group.
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single
> word
> "unsubscribe" in the body to:
> ebxml-cppa-request@lists.oasis-open.org
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-cppa-request@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC