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