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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-tp message

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


Subject: Re: TP Spec interpretation



David,

I am going to give you an initial answer, below, but this may need some
more iterations.  I am copying the old and new trading-partners lists on
this reply since I think that this is a generally interesting question.
Note also that this question may really be for Karsten Riemer and the BP
team. I have also copied Karsten on this reply.

First, the service definition itself is in the Process Specification
document, i.e. the XML collaboration description derived from the BPSS.
Since the Process Specification document is defined in terms of roles
rather than specific parties, Visa could certainly define the service only
once.  However if that service is to be embedded in a larger business
process, it would have to be imported into the Process Specification
document for each using process. To me that looks like a natural use of
namespaces. I don't know if the BPSS provides for that kind of modularity.

As to the CPP and CPA, remember that each CPP is specific to one party and
each CPA is specific to one pair of parties. Indeed, within a single
CollaborationRole element, a single Process Specification document is
referenced and single role is defined relative to that Process
Specification document.  However multiple CollaborationRole elements can be
supplied either to define more than one role or to permit reference to more
than one Process Specification document. Note, however, that the payment
process were defined by a separate Process Specification document alongside
of the one defining the larger business process, there would be no way of
specifying the choreography (of the whole business process including the
payment process) across the two Process Specification documents.  If the
choreography of the payment process relative to the larger business process
can be left to the private processes at the parties, than this should also
work.

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 06/01/2001 08:53:11 PM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:
Subject:  TP Spec interpretation



Marty

I'd appreciate it if you could help clarify one aspect of the CPP/CPA spec.
Specifically, we are debating whether you can use the same service more
than
once in different business processes. For example you could imagine a
Payment Authority (e.g Visa) that offers a Payment Authorization service
that accepts a payment request and returns a payment response that conforms
to some part of the IFX spec. This could be used in many different
processes
to make a payment, e.g. to pay an invoice, to get foreign exchange, etc. It
would be really good if Visa could just define the service once and then
everyone could use it in whatever business process they wanted to.

Our reading of the CPP/CPA spec is that in a Collaboration Role there can
only be one Service associated with Specification (ie a Business Process)
and a role (ignoring load balancing, etc). Is that your understanding too?

Best wishes.

David

Solution Strategy, Commerce One
4400 Rosewood Drive, Pleasanton, CA 94588, USA
Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704
mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com






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

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC