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: Draft of Requirements for Intermediary Support for discussion.


Title: RE: PIP IDs
David Burdett has given his permission to repost his
suggested requirements for support of intermediaries
using CPP and CPA profile exchanges. I have
edited out some no longer relevant pieces
of the thread that this came from (with
David's permission), and think that
we should take this as input to our
future work on multiparty cpas as well
as on intermediary support.
 
I will be commenting on these requirements
in a separate message later on this week.
 
 
Dale Moberg
-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Monday, July 30, 2001 5:10 PM
To: Dale Moberg; Martin W Sachs
Cc: Arvola Chan; David Fischer; ebXML Msg; Pete Wenzel
Subject: RE: PIP IDs

Dale
 
Here is my first cut of the requirements for CPPA that are needed to support intermediaries. It suggests the development of several different types of CPA/CPP ...
1. Transport CPP. This specifies the MSH parameter values that can be applied to the exchange of messages that are independent of the business process, business transaction or the needs of an individual party. A typical use of his would be by a Community of users that agreed to exchange all messages in one (or a few different) ways.
2. Business Process CPP, Specifies a way of exchanging data/documents/messages that meets the needs of a specific business process or business transaction. The CPP should omit any data that is specific to any transport or communications protocol. (Is this WSFL?). A typical use of this would be a standards group that wanted to define some standard business processes that they had developed, or a Community of Users that had identified the subset of standard transactions that they would use.
3. An Endpoint CPP, that identified a series of URLs and Security data that could belonged to a Party to which messages could be sent
4. A Community CPA. This would be a combination of Transport and Business Process CPAs which represented the standard way by which members of that Community would carry out its business. It would omit any specific Party information (e.g. URLs or security information)
5. A Party CPP that:
  a) Referenced Transport CPPs, Business Process CPPs, and/or Community CPAs and EndPoint CPPs. The EndPoint CPPs could apply to either:
     i) all interactions with the Party, or
     ii) one or more combinations of Transport CPPs, Business Process CPPs ro Community CPAs
6. A Party-to-Party CPA.. This could either:
  a) Reference a Community CPA, excluding any Business Processes/Transactions they did not support, and:
     i) add EndPoint CPP information that applies to all Business Processes/Transactions, which could be over-ridden by
     ii) adding EndPoint CPP information that applied to individual Business Processes/Transactions, or ...
  b) Create a one-off CPA that included Transport and Businss Process level data as well as URL and security data as currently defined.
 
Intermediaries could then use these CPAs/CPPs as follows:
1. The CPAId in the Message Header would reference a Community CPP or a Party-to-Party CPA
2. The CPA Id in the Via element would reference an individual EndPoint CPP (or part of a CPP) and optionally a Transport CPP to identify where messages should be sent to.
 
I am not sure if these ideas are completely baked, but hopefully we can start a useful discussion.
 
David


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


Powered by eList eXpress LLC