[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:
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? |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]