[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: message routing
Marty,
I am not sure I agree with the statement that:
>
> 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.
>
In mqany situations the legacy (i.e. the code that implements the
functionality)
is really blind on respect to the context in which it is used (and this in
order
to use it in many contexts, potentially).
So, routing decisions based on information contained in the payload may be
highly
apreciated.
/stefano
> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: 30 July 2001 04:54
> To: Burdett, David
> Cc: Dale Moberg; ebxml-cppa@lists.oasis-open.org
> Subject: RE: message routing
>
>
>
> 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
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC