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] | [List Home]


Subject: NDD, negotiation/instatntiation, CPA template update


Hello,
 
I have been working on the CPA generation topic a bit more.
Attached ZIP contain three NDDs: 
1) instantiating a CPA between two partners
2) instantiating a WSDL between two partners
3) instantiating two CPAs between three partners
 
The NDD expresses which partner provides which parameters.
The NDD references template that are to be instantiated.
The instantiation is based on "parameter" documents, which each partner needs to provide. Examples added.
The results of applying the parameters to the templates, according to the NDD, is added for illustration.
 
The data were generated automatically and once I get the chance to clean up the scripts / stylesheets  used I will post them too.
 
The next step is define an exchange protocol for initiating negotiation, (requesting and) submitting parameters, and distributing the results.  The protocol can have multiple transport bindings, including ebMS, Web Services and others.
The NDD format can also be enhanced in various ways.
 
Comments are welcome ..
 
Kind regards,
 
Pim
 

 

From: Pim van der Eijk [mailto:pim.vandereijk@oasis-open.org]
Sent: 22 June 2006 14:00
To: 'OASIS ebXML CPPA TC'
Subject: RE: [ebxml-cppa] Agenda for OASIS ebXML CPPA teleconference June 23, 2006 at 8 AM PDT (NDD,CPA services)

 
Hello Dale,
 
Two comments, one short and one longer:
1) I sent a message on defaulting for more attributes, which seems a separate topic:
http://lists.oasis-open.org/archives/ebxml-cppa/200606/msg00009.html
It's not very important though ..
 
2) On the topic of negotiation services I can report on some work I've done, based on the NDD concept described in http://www.oasis-open.org/committees/download.php/10193/Negotiation.req.06Mar02.pdf which you've pointed me too.  Below is some status information on that. I'd be interested in learning from the experts on the TC if you think this is going in the right direction.
 
My scope is (for practical reasons) limited to cases where, when working from a CPA template:
- any subtree that can be instantiated in the result CPA can only be set by one partner.
- there are no co-constraints on values of a parameter and values of any other parameters, whether supplied by the same partner or by other others.
- all constraints can be checked on parameter input.
This excludes some possible scenarios but covers many common uses of ebXML.
 
Basically, the idea is to have a very simple XML representation of the NDD concept. It names a template and provides a set of pairs of named parameters and XPath expression. See the attached "simple.ndd.xml" sample. 
 
Partners then need to supply a simple XML document with values.  Values can be atomic (text content or attribute values) or complete sub-structures (like a KeyInfo XML substructure). See the attached "simple.A.parameters.xml" and "simple.B.parameters.xml" samples.
 
With these limitations, there would be no need for a complex dialog of proposal/counter-proposals. Once all partners supply their parameters, the resulting CPA should be technically acceptable (it may stil be rejected for business reasons).
 
I wrote an XSLT based "compiler" which takes an NDD document and a CPA template, and generates, for each partner, a second (third .. n-th) XSLT-bsed "compiler", which in turn takes an XML parameter document and yields an instantiated CPA document by transformation.  A sample generated stylehsheet which instantiates the template with B's parameters is "cpa-example-2_0b.simple.B.xsl". When all partners have supplied their parameters, the transformation for each partner can be run as a pipeline in arbitrary order to generate the instantiated CPA. Sample "cpa-example-2_0b.simple.cpa2.xml" attached.
 
Questions/comments/thoughts:
[1] The template would be a complete CPA, so there is no separate CPA template schema and no need for changes to the CPA schema.  This is good, I think. The tp:Start and tp:End could be in the past and one or both PartyIds could be bogus. They would be set to their desired values by specifying them in the NDD and submitting them as parameter values.
 
[2] In the simplest case only one partner supplies parameters, and the other partner information is fully specificied.  The operation could then be implementable as a simple Request (parameters and value) Response (resulting CPA) operation.  However, it seems to me as if in practice at least @tp:cpaid, tp:Start and tp:End would always need to be set for each new CPA dynamically, i.e. not in the template. 
The start may have to be at least some working days after the CPA is configured to allow partners to configure other systems than the ebXML message handlers. If that is true, there will always be more than one partner supplying parameter values.  But if one partner e.g. "B" runs the CPA process, it could still retrieve its own parameters dynamically when A submits its CPA request, and send the combined resulting CPA back immediately.
 
[3] As for services, it seems to be there are two separate cases: 
1: A process for arriving at a uniquely identified, shared knowledge of a set of technical parameters and services to support construction of that set of parameters. I.e. a CpaId identifying a CPA XML document (or equivalent other representation of those parameters). This is what CPA formation/negotiation and this this message are about.
2: Service management functions:  request a partner to deploy a service (by CpaId), notifications of deploying a service (CpaId), notification of temporary unavailability of a service (CpaId, SuspendAt, ResumeAt), notification of premature termination of a service (CpaId, Date). 
Is this a useful distinction?
 
[4] Apart from generating a CPA from a template, in practice partners will often want to generate a CPA from a previously agreed CPA.  Suppose the URL of a partner's ebXML gateway changes, or a certificate expires. The amount of human intervention / supervision would be much lower than for a new business partner, perhaps it could be fully automated.  The process would be to:
-  Send messages to partners with as parameters the OldCpaId and the changed information. An NDD could be used to define which parameters can be changed in this way. Difference with working from a template are that only the changed information needs to be supplied, not all parameters. 
CPA is identified by NewCpaId.
-  Partner sends notification to partners that services NewCpaId is available, requests partners to deploy service NewCpaId at their end, and (optionally, if before the tp:End in OldCpa) notifies partners that OldCpaId will be shut down (after some transation period in which OldCpaId and NewCpaId are both available).  
The Certificate Exchange Message covers a special instance of this?
 
[5] Validity of supplied parameters will be done by the ebXML software that loads the configured CPAs.
But the NDD could mention additional constraints on the values (e.g. a list of alternatives). The run-time should check these when parameters are supplied.  My "compilers" don't have that capability yet, still working on that ..
 
[6] The mechanism could easily be generalized. It could reference more than one CPA template, so partners can configure multiple CPAs in one process. The only requirement is for the template to be a well-formed XML document.  It could also be an XML schema, ebBP process, WSDL .. The service management service messages could then be about multiple new/old CpaIds.  The mechanism could also be generalized to more than three or more partners ..
 
Pim
 


From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: 21 June 2006 19:23
To: OASIS ebXML CPPA TC
Subject: [ebxml-cppa] Agenda for OASIS ebXML CPPA teleconference June 23, 2006 at 8 AM PDT

NEW numbers!!!

 

866 383 5205

732 694 1566 (for international callers)

 

144286# is the conference participant pin

 

Agenda

 

1. Flattening discussion continues

 

a. Reuse proposals from PIM discussion, adding an ID to MessagingCharacteristics and BusinessTransactionCharacteristics. Where to put the attribute of type IDREF to reference these? Where in the hierarchy to allow the MessagingCharacteristics and BusinessTransactionCharacteristics elements.

 

b. Adding xinclude?

 

c. ebMS 3.0 Pmode values, news?

 

d. Progress on schema modifications for flattening.

 

2. Cardinality revisited on ProcessSpecification, Role and Service.

 

3. Followup on negotiation services and wsdl approach?

 

 

Samples.zip



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