RE: [ebxml-iic] Deployment profile template for CPA v2.0 comments

[Sacha Schlegel <sschlegel@cyclonecommerce.com>]

Hi Jacques

I am refering to the open source ebMS implementation Hermes which does
not use a CPA (per now) but a config file.

Unfortunately I have not gone through an Interop to see other ebMS
implementations. What I heard from the 2004 Drummond testing was that
the parties did not exchange a CPA but referred to the test setups.
Unfortuantely I have no information how parties exchanged the agreement
in the ETSI interops.

You are right, I should not have listed the "no use of CPA's". It seems
the way to go, to get the CPA between two parties and then distribute
the CPA to each party to configure their MSH's.

We can discuss on August 8th.

Sacha

On Tue, 2005-08-02 at 22:12 -0700, Jacques Durand wrote:
> 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:sschlegel@cyclonecommerce.com]  
> 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 
>