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

[Martin Sachs <msachs@cyclonecommerce.com>]

Sacha's posting to the IIC list will be of interest to the CPPA TC.

Regards,
Marty
>Mailing-List: contact ebxml-iic-help@lists.oasis-open.org; run by ezmlm
>X-No-Archive: yes
>List-Post: <mailto:ebxml-iic@lists.oasis-open.org>
>List-Help: <mailto:ebxml-iic-help@lists.oasis-open.org>
>List-Unsubscribe: <mailto:ebxml-iic-unsubscribe@lists.oasis-open.org>
>List-Subscribe: <mailto:ebxml-iic-subscribe@lists.oasis-open.org>
>Delivered-To: mailing list ebxml-iic@lists.oasis-open.org
>From: Sacha Schlegel <sschlegel@cyclonecommerce.com>
>To: iic <ebxml-iic@lists.oasis-open.org>
>Date: Tue, 02 Aug 2005 12:01:53 -0700
>X-Mailer: Evolution 2.2.2
>X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on
>         hermes.oasis-open.org
>X-Spam-Status: No, hits=0.0 required=7.0 tests=none autolearn=no version=2.64
>X-Spam-Level:
>Subject: [ebxml-iic] Deployment profile template for CPA v2.0 comments
>X-pstn-levels:     (S:99.90000/99.90000 R:95.9108 P:95.9108 M:97.0232 
>C:98.7678 )
>X-pstn-settings: 3 (1.0000:1.0000) s gt3 gt2 gt1 r p m c
>X-pstn-addresses: from <sschlegel@cyclonecommerce.com> [db-null]
>X-OriginalArrivalTime: 02 Aug 2005 19:02:32.0675 (UTC) 
>FILETIME=[BCB35330:01C59794]
>
>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

*************************************
Martin Sachs
standards architect
Cyclone Commerce
msachs@cyclonecommerce.com