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: RE: [ebxml-cppa] Agenda for OASIS ebXML CPPA teleconference June 23, 2006 at 8 AM PDT (NDD,CPA services)


Hello David,
 
What you describe is generating the CPA at the client side and resubmitting it to the server.  That is possible, but then the CPA template publisher needs to compare the submitted CPA and the template to find out what changes the client submitted.  Since templates are a mechanism for the "server" to indicate that some parts of the CPA are not modifiable ("take it or leave it") by the "client", this would give them less control. 
 
A browser interface is still possible when the client submits the parameter values and the CPA is generated at the server. This assumes the server can generate the response CPA and decide on approval automatically. It would be a "binding" of the abstract protocol discussed in my message. Other bindings for this process could be SOAP/WSDL-based (Dale posted some initial XSDs/WSDLs some time ago) or ebXML messages. The Web Service/ebXML binding is more suitable for CPA renewals/modifications, where there is an existing B2B message channel that can be used and the messages may be generated by an automated process rather than a human operating a Web browser interface. The browser binding would be very suitable for generating a first CPA between two partners.   
 
Pim
 


From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: 22 June 2006 19:13
To: Pim van der Eijk
Cc: 'OASIS ebXML CPPA TC'
Subject: RE: [ebxml-cppa] Agenda for OASIS ebXML CPPA teleconference June 23, 2006 at 8 AM PDT (NDD,CPA services)

Pim,
 
I'm very much in favour of this approach.
 
I also believe that the future is a CPA template that is then pluggable with the particulars for party A and party B.
 
Another variation on this then becomes instead of using the xslt - you can create a Web form and use AJAX / JavaScript techniques to do the cutting and pasting "inside" the DOM and then publish the CPA via the "submit".
 
This way partners could cut and paste their certificate and simply type in their URL reference and other details.  You can then auto-create the NDD for them too if necessary.
 
The form layout would be something like:
 
 Select CPA template: < drop list >   --- notes: JavaScript will load template into DOM)
 
 Enter your email address: < text line >
 
 Paste your certificate here: < text area box>  --- notes: exported cert as ASCII text
 
 Enter your secure endpoint URL: < text line >
 
 Select retry count : < number >
 
 Click here to build your CPA : [ Submit ] 
 
--- notes: JavaScript does update to DOM with values and then outputs XML via http to registry, email address(es), etc for review and confirmation...
 

DW


-------- Original Message --------
Subject: RE: [ebxml-cppa] Agenda for OASIS ebXML CPPA teleconference
June 23, 2006 at 8 AM PDT (NDD,CPA services)
From: "Pim van der Eijk" <pim.vandereijk@oasis-open.org>
Date: Thu, June 22, 2006 8:00 am
To: "'OASIS ebXML CPPA TC'" <ebxml-cppa@lists.oasis-open.org>

 
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?


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


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