OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC