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: PIP IDs


David,
>The key point is that I think we should allow any or all of these to be
used
and not dictate to an implementation what is required. The consequence of
this is, IMO, that we need to keep these elements separate in the header so
that you can easily choose which ones to use.

I agree, and...

Sounds like a SOAP Bubble to me !   Exactly the same concept.

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



"Burdett, David" <david.burdett@commerceone.com> on 07/19/2001 12:30:21 PM

To:   Martin W Sachs/Watson/IBM@IBMUS, Scott Hinkelman/Austin/IBM@IBMUS
cc:   Arvola Chan <arvola@tibco.com>, David Fischer
      <david@drummondgroup.com>, ebXML Msg
      <ebxml-msg@lists.oasis-open.org>, Pete Wenzel
      <Pete.Wenzel@RosettaNet.org>, ebxml-cppa@lists.oasis-open.org
Subject:  RE: PIP IDs



Marty

You make good points, I can see how any combination of the following could
**potentially** be used for routing purposes:
* From Party
* To Party
* Service
* Action
* CPAId (header)
* RefToMessageId
* CPAId (Via)

... and probably more.

For example at its simplest you could base your routing just on "To Party",
e.g. everything for IBM goes to the same URL. At the other extreme, you
might have to look into the payload to work out where to send the message,
although I don't think this is a good idea.

The key point is that I think we should allow any or all of these to be
used
and not dictate to an implementation what is required. The consequence of
this is, IMO, that we need to keep these elements separate in the header so
that you can easily choose which ones to use.

For example you could combine To Party, Service and Action into a single
URI
for the "to" such as
urn:party:xyzco:service:supplierordermgmt:action:neworder but then you are
forcing single end-point based routing.

Thoughts?

David

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Thursday, July 19, 2001 12:11 PM
To: Scott Hinkelman
Cc: Arvola Chan; David Fischer; Burdett, David; ebXML Msg; Pete Wenzel;
ebxml-cppa@lists.oasis-open.org
Subject: Re: PIP IDs



Yes, an arbitrary hierarchy of elements might solve some of the routing
problems we have been turning up.  However it has to be designed in such a
way that each party to a CPA understands the other party's hieararchy.  In
other words, both parties must agree to the meaning of each element and the
hierarchy has to be expressable both in the message header and in the CPA.
I don't think this is a problem; it is a piece of work to do. I  believe
that the authorized roles and refToMessageId will also have to be part of
that routing information as mentioned in prior postings.

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
****************************************************************************

*********



Scott Hinkelman
07/19/2001 02:41 PM

To:   Arvola Chan <arvola@tibco.com>
cc:   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>
From: Scott Hinkelman/Austin/IBM@IBMUS
Subject:  Re: PIP IDs  (Document link: Martin W. Sachs)

>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-msg-request@lists.oasis-open.org








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


Powered by eList eXpress LLC