Title: RE: [ebxml-iic] Deployment profile template for CPA v2.0 comments
Thanks Sacha:
That is good input, we'll need to use it in a deployment template - maybe can we talk about this at our next meeting Aug 8th?
Also: what do you mean by "no use of CPA" in (b) ? (isn't one needed in general to communicate agreement? Or else what is used?)
>b)
>ebXML CPA management seems to become a major topic. A pattern I see sofar >is:
>o no use of CPA's.
Cheers,
Jacques
-----Original Message-----
From: Sacha Schlegel [mailto:]
Sent: Tuesday, August 02, 2005 12:02 PM
To: iic
Subject: [ebxml-iic] Deployment profile template for CPA v2.0 comments
Hi IIC
I think a Deployment profile for ebXML CPA will be very helpful for
ebXML endusers who are using CPA's. I think any help for ebXML endusers
how to deal with CPAs is helpful ...
MSH's are taking on the responsibility for ebMS, hence the ebXML MS
software enables security, reliable messaging, and non-repudiation. So
what ebXML enduser are left with is how to deal with CPA's ... and that
is no easy task.
On another note we already experience CPA interpretation
incompatiblities. Eg one system respects certain elements/attributes
whereas the other system does not respect them. An enduser wants to
create one CPA and then be assured that this CPA works on all CPA
supported MSH's. So some form of CPA interoperablity requirements just
seems to be just be ahead of us.
Further, it would be nice to also have a documnet which the software
vendors have to fill out, which exactly indicates which CPA
elements/attributes/combinations a software implementation supports or
not.
Some comments here:
a)
maybe add to the profile whether the enduser wants to use the underlying
collaborative business process (egBP). As we know the Service and
Actions (the CollaborationRole elements) are derived from the ebBP, but
we lost the choreography information in the CPA.
We also know that the primary job of an MSH is to handle the ebXML
Messages on a messaging level. It is very well possible to require an
additional software which deals with the underlying ebBP. Eg a tool
which either enforces or simply monitors that the message flows
correspond to the underlying ebBP. Such an additional software component
would deal with the ebBP signals.
In case people want to support the underlying ebBP this would make them
aware that their target ebXML software must support ebBP's in some form.
This also plays into point b) below in that regard that if the
underlying ebBP changes the CPA's have to be changed to reflect the new
underlying ebBP's.
b)
ebXML CPA management seems to become a major topic. A pattern I see
sofar is:
o no use of CPA's.
o in a hub-spoke scenario, the hub takes on the responsiblity to manage
the CPA's.
So in a deployment profile we could identify if a party takes on the
responsiblity to manage the CPA's for the community. In a hub and spoke
environment this is typically the hub. In a mesh-net kind of enviornment
it could well be a 3rd party not engaged in the business at all but
simply provide CPA services to the community.
What does CPA management include?
o create CPA's
o update CPA's
o distribute CPA's to the 2 trading partners referenced in the CPA.
o store CPA's (eg in an ebXML registry/repository with a standardized
user authenticated interface to query and retrieve them).
o notification that a CPA has changed.
o manage to have smooth transition between 2 CPA's (no hickups during
CPA changes).
o provide means that parties can make changes to the CPA.
In the case, that a party takes on the responsiblity to manage CPA's ...
the trading partner may have a much much simpler CPA deployment
requirement. Potentially all information they need to provide are:
o party name with routing id's
o remote party this CPA is created for (for mesh scenario)
o selection of supported underlying ebBPs (choose from a list, maybe hub
dicates the services)
o role they are playing in the collaborations (omitted in the hub-spoke
scenario as the hub know which roles s/he plays)
o transport protocol (http or smtp, maybe dictated by hub)
o endpoint address
o certificates for security
so the shortest possible list:
o party name and routing Id
o endpoint address
o certifciates (if any use of scurity)
In a hub-spoke environment, the hub pretty much dictates the security
settings.
In a mesh environment, the community may define a default security
setting. Obviously an open community allows each trading partners to
choose how they feel they have to setup the environment.
To summaries point b): Make sure the user knows in what sort of
enviromnent s/he will operate and if someone, who is responsible to
manage CPA's.
c) 3.3.1, page 15, Certificates
Maybe set in the deployment profile whether self signed certificates are
allowed or not. If not and in a hub-spoke environment, list of hubs
trusted certificate authorities. So the spoke knows from where to get a
signed certificate.
d) 3.3.1, page 16, DeliveryChannels, Tranports, Document Exchanges.
A note I made for myself: ... maybe use a bottom up approach.
It depends a little if a CPA skeleton is generated from one or more
ebBP's. If not, a CPA is done by hand.
Eg list the messages (the actions) first. Then list services and assign
the actions to the service. Next provide a delivery channel, transport
and document exchange. Then assign the actions to the delivery channels.
Guess it depends on the role of the deployment profile to list and
introduce the required elements and attributs or whether it also
provides to "howto create" a new CPA.
e) 3.4.1, p. 18
I think a place to put a short summary of the underlying business
process would not hurt.
f) 3.4.1, p 19
Business Transaction Characteristics. An interesting element ;) What
does it mean to have tp:isConfidential set to "transient" but we have no
SSL for the HTTP protocol? Or tp:isConfidential set to "none" but we
have DigitalEnvelope set in the Sender or Receiver Bindings?
-> general comment: in the ebMS profile you had places to reference
interoperablity tests. Maybe add a place to tools to validate the
integrity of a CPA.
g) 3.5.1, p21
MessagingCharacteristics: syncReplyMode
When using an ebBP implementation, we have the ebBP signals along the
MSH singals and the business document repsones. This may be a challenge
for the synchronouse reply mode.
... I keep thinking that such a profile can also be used for parties to
shop for the right ebMS, ebBP software. eg we require these
funtionalities ... does the software vendor provide them?
h) 3.6.1, p 24 off topic
Receiver Binding - Reliable Messaging.
I have not come across the reason why the Retries, and RetryInteval are
useful for the receiver. Is it used to potentially calculate the time
when I no longer can expect the message? Probably in combination with
the "TimeToPerform" in the Business Transaction Characteristics element.
Without the ebBP (the knowledge when which action has to occur, eg
action a after action b, so we can start the timer for action a after
having received or sent action b), we would not know when the time
starts though.
k) 3.7.1 Transport Sender - Server security - ClientSecurityDetailsRef
... is used to list all trusted certificate authorities which a signed
client certificate must be signed by.
l) 4.1 Maybe add if CPP's are required for the case of CPA generation
from two CPP's.
m) 4.3 When using ebBP, it seems there is a certain interest in
specifing the legal context of the ebBP business signals. The ebBP
singals can a) be used for technical state alignment or b) also for
legal business related matters.
Regards
Sacha
---------------------------------------------------------------------
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
