[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: message routing
+1
This is most certainly application level routing. It
requires digging into (and hence knowledge about) the payload
which is clearly not the MSH's concern (endpoint or intermediary).
Cheers,
Chris
Martin W Sachs wrote:
>
> David,
>
> "Invoices greater
> than a certain value are routed to one location and less than that value to
> another."
>
> This is definitely an application matter. It is highly application
> dependent and not something
> that the message service or other component of middleware can accomplish
> without digging into the payload and understanding the application
> semantics.
>
> However, the CPPA and BP team have to look at this use case if it is a
> realistic one. It is not clear to me that the CPPA endpoint definitions
> allow this case. Nor is it clear to me that the BPSS covers this case
> since, as I understand it, the business transaction can have only one
> response message and has no means of specifying alternative delivery
> channels for the same message.
>
> 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
> *************************************************************************************
>
> "Burdett, David" <david.burdett@commerceone.com> on 07/27/2001 08:21:34 PM
>
> To: Martin W Sachs/Watson/IBM@IBMUS
> cc: Dale Moberg <dmoberg@cyclonecommerce.com>,
> ebxml-cppa@lists.oasis-open.org
> Subject: RE: message routing
>
> Marty ...
>
> >>>Yes [using data in the payload for routing], but to be strenuously
> avoided (see my previous posting).<<<
> I totally agree, but the use case I had in mind would be Invoices greater
> than a certain value are routed to one location and less than that value to
> another. It's weird and you could argue it's an application responsibility
> but then what customers want to do is sometimes weird.
>
> >>>There is nothing in the MSG spec that gives permission to use
> refToMessageId in appication-level messages at all. In order to use
> refToMessage ID to assist routing of application-level responses, the
> specification needs to state that in a reply message, refToMessageId
> contains the message Id of the message that is being replied to.<<<
> Hmmm! The spec says RefToMessageId ... "MUST contain the MessageId value of
> an earlier ebXML Message to which this message relates". My interpretation
> was that this allowed (but didn't restrict) the message to referencing an
> earlier message that is being replied to. I think this is another point
> that
> needs clarification in version 1.1 ...
>
> >>>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<<<
> The role element in the Manifest element IS only related to packaging. The
> only other reference to role in the spec is lines 762-4 which say ...
> "Note:
> In the context of an ebXML business process model, an action equates to the
> lowest possible role based activity in the [ebBPSS] (requesting or
> responding role) and a service is a set of related actions for an
> authorized
> role within a party." This is making reference to the Authorized role.
>
> David
> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Wednesday, July 25, 2001 9:30 PM
> To: Burdett, David
> Cc: Dale Moberg; ebxml-cppa@lists.oasis-open.org
> Subject: RE: message routing
>
> My replies further embedded below
>
> 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
> ****************************************************************************
>
> *********
>
> "Burdett, David" <david.burdett@commerceone.com> on 07/25/2001 03:55:34 PM
>
> To: Martin W Sachs/Watson/IBM@IBMUS, Dale Moberg
> <dmoberg@cyclonecommerce.com>
> cc: ebxml-cppa@lists.oasis-open.org
> Subject: RE: message routing
>
> Marty
>
> See comments inline.
>
> David
>
> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Friday, July 20, 2001 11:41 AM
> To: Dale Moberg
> Cc: ebxml-cppa@lists.oasis-open.org
> Subject: RE: message routing
>
> 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
> >>>I agree. You also might need to include:
> 1. The business process that the message is part of
> MWS: Yes, that's an additional level in the hierarchy that Arvola is
> looking for.
>
> 2. Anything specifically agreed in the CPA
> MWS: Yes, if we can identify additional entities.
>
> 3. Data included in the payload (not ideal but sometimes necessary!)
> MWS: Yes, but to be strenuously avoided (see my previous posting).
> Looking into the payload is forced on a system when the message header
> doesn't contain the right elements. In the tpaML OBI prototype we had to
> dig the purchase order number out of the payload because there was no
> standardized header that included a conversation ID. The ebXML message
> service is supposed to enable us to avoid doing things like that by
> including the right generalized elements in the header.
> <<<
> 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.
> >>>I don't understand why. Can you explain?<<<
> MWS: There is nothing in the MSG spec that gives permission to use
> refToMessageId in appication-level messages at all. In order to use
> refToMessage ID to assist routing of application-level responses, the
> specification needs
> to state that in a reply message, refToMessageId contains the message Id of
> the message that is being
> replied to.
>
> 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.
> >>>Agreed<<<
>
> 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.
> >>>There certainly has to be agreement between the parties on what data
> goes
> in the header. I also agree that this information "could" go in the CPA.
> However this suggests that at the extreme, each company is going to sit
> down
> with every other company they do business with to work out what this data
> will be. I don't think this scales.
> MWS: Of course it doesn't scale. Our teams are supposed to be defining a
> messaging service that contains sufficient routing elements to cover
> any application structure we can think of. Once two parties agree on which
> BPSS instance document describes their collaborative process, the routing
> elements are defined in that document and no further agreement is needed.
> We thought that service and action are sufficient but that seems to be not
> the
> case and we have to work on ways of generalizing from the two levels to
> more
> than two. As long as all the levels are in the BPSS instance document, the
> routing agreement is implicit and the installation tools do the rest.
>
> A more likely approach would be for
> companies to agree to define the headers according to some community
> standard (e.g. RosettaNet) which makes the addition of new links to new
> parties much easier to do. If this happens, then the need for bespoke
> definitions to go in the headers of messages is significantly reduced. If
> it
> is needed, then there are extension mechanisms in the ebXML Messaging
> Service spec that allow it. It also means that we do not need to define it
> ... either in the ebXML Messaging Header or the CPA.<<<
> MWS: As long as you don't care whether members of your community can
> interoperate with members of mine. ebXML has a goal of universal
> interoperability.
> Let's not lose sight of that goal.
>
> 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.
> MWS: The appropriate places in the CPA already point to the appropriate
> places in the Proces Specification document.
>
> 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 is one way of doing it but can be overkill in some circumstances.
> <<<
> MWS: Replying here would only reiterate what I said above and in the
> previous
> posting.
>
> This part is mostly performed by the CPA installation
> tool
> >>>If you have one ;)<<<
> MWS: True. If I have an IBM 650 with only a few thousand words on its
> random
> access drum memory and a 1955-style assembler, ebXML won't help me much.
> For 2001, you want to argue about whether a CPA installation tool that
> helps both sides reach compatibility is better or worse, simpler or more
> comple, etc., than a tool into which each party has to type its
> configuration
> information and hope that the two match.
> , of course, when it digests the CPA and builds the control block
> (database row, perhaps) that manages the information flow related to that
> CPA.
> >>>Marty. You seem to be suggesting that companies adopt a specific
> technology solution. Why?<<<
>
> MWS: I am saying that automated tools are a well developed technology
> and one that doesn't require everyone to use the same one. I am not going
> to rehash the arguments that a standardized agreement language benefits
> interoperability for everyone.
>
> 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:
> h
> Multiparty choreography (BPSS may have taken care of this one)
>
> 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.
> >>>This assumes that all the parties need to understand the complete
> business process.
> MWS: That is precisely the question. Once you talk about a multiparty
> CPA, you have to answer all those questions. With tpaML, we decided to
> practice crawling before
> trying to walk. ebXML did the same thing for version 1.0. My point here
> was only that
> I didn't want the discussion to confuse routing at the destination with
> multilateral
> CPAs. They are completely disjoint sets ofproblems.
>
> I don't think this is always the case. If I am a bank and
> make payments when requested. All I need to know is that the request is
> valid. I don't need to know anything about the business process which is
> being followed. If the bank does, then we are changing the way business
> happens now.<<<
>
> 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.
>
> 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.
>
> 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
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-cppa-request@lists.oasis-open.org
begin:vcard n:Ferris;Christopher tel;cell:508-667-0402 tel;work:781-442-3063 x-mozilla-html:FALSE org:Sun Microsystems, Inc;XTC Advanced Development adr:;;;;;; version:2.1 email;internet:chris.ferris@east.sun.com title:Sr. Staff Engineer fn:Christopher Ferris end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC