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


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
	

winmail.dat



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


Powered by eList eXpress LLC