[Fwd: [ebxml-bp] [ebBP] 11/11/2004: Alignment with CPPA and ebBP]

["Monica J. Martin" <Monica.Martin@Sun.COM>]

See per discussion today.

Monica J. Martin wrote:

> In our Friday, 12 November discussion, our goal will be to start to 
> address some of the alignment issues between CPPA and ebBP (and 
> hopefully help with coordination with ebMS) [1].   We wish to discuss 
> and verify association of the business level description of process 
> and relate it to the technical messaging protocol and security details 
> that are needed for full configuration of the interfaces of the 
> business participants.
>
> Here is a starting list with some details (sorry I didn't save the 
> email references but can resurrect them if need be). Thanks.
>
> 1. Roles
> a. ebMS required Service and Action and BPSS has Role. ebMS added Role 
> values to its header, and CPPA had to struggle to say how values from 
> BPSS mapped into ebMS values. See also Service. In ebMS v2.0, it 
> states, "In the context of an ebXML business process model, an action 
> equates to the lowest possible role based activity in the Business 
> Process [ebBPSS] (requesting or responding role) and a service is a 
> set of related actions for an authorized role within a party."
> b. How do we handle more than one CollaborationRole in the CPA? In an 
> ebXML message, there are the CPA ID, conversation ID, Service name and 
> the Action name. How do you assign an incoming ebXML message to the 
> correct business process (CollaborationRole) within the CPA? 
> [Schlegel]  If the CPA is based on the ebBP, it must have the 
> ActionContext element. Should a CPA be rejected which has non unique 
> (non unique per CPA) Service elements in it? [see also 'Action and 
> action context']
> 2. Action and action context
> a. ebXML Action is similar ot WSDL operation concept. An exception is 
> that a WSDL operation with a 'request-response' MEP (WSDL v1.1) has 
> only one name. [A function would have one name embracing both its 
> input parameters as well as its return values.] For ebXML, two Action 
> values are associated with that WSDL v1.1 'request-response' MEP. If 
> this is allowed, it could make the monitoring mapping from ebMS back 
> to BPSS more dependent on using information about the document exchanged.
> If a BPSS is used in conjunction with a CPP, the BusinessDocument 
> element can provide additional information about what documents are 
> exchanged in the BusinessTransactionActivity. There is still some 
> question about whether mentioning syntactical details about a document 
> in BPSS impedes reusability by violating its abstraction level. (This 
> may have been addressed by using our variable construct). If so, 
> probably CPP and CPA should have better provisions for documenting 
> (under SimplePackage or elsewhere) information needed in a 
> collaboration agreement. For example, information about context has 
> been suggested as something we should make room for or, more grandly, 
> a whole recipe for constructing the document/businesspayload from bits 
> and pieces of schema. [Moberg]
>
> 3. Service
> a. CPPA can map to several Services. Therefore, can a single BPSS 
> instance contain several Services (in the context of what ebMS 
> understands Service)? [3] Currently, CPPA maps a Service to 
> ProcessSpecification/@uuid (restricted to one service). 
> OperationMapping should change this between CPPA and ebBP.  An ebMS 
> Service/Action defines the specific Service. [4] Need to explore 
> design patterns for distributed processes to clarify. We need to 
> handle multi-party BPSS instances that have multiple services. This 
> could affect any resolution on Schema #7 for ProcessSpecification and 
> ProcessSpecificationType. b. What information items contain Service 
> values in a BPSS instance (OperationMapping is an example). Dale 
> provided a detailed account for operations and their relationship with 
> CPPA (see [5]).
> c. Payload services: ebMS v3.0 is targeting payload services. How does 
> this affect any validation parameters in ebBP and/or CPPA? The 
> extensibility of these services poses a problem of how to document 
> these extensions for use with CPPA [Moberg].
> 4. Other
> a. HasLegalIntent attribute: In later versions, we may wish to discuss 
> making whether HasLegalIntent attribute and other BT characteristics 
> are negotiable (This has been currently slated for post-v1.0 CPPA 
> negotiation specification work). However, this attribute specifically 
> has not been discussed in that work).
> b. MSI-BSI Questions: Need to compile first. We could start with Sacha 
> Schlegel's question on Business Service Interface or Handler last week 
> to ebBP team (See: 
> http://www.oasis-open.org/archives/ebxml-bp/200411/msg00030.html). 
> Requires ebMS collaboration as well. [1]
> c. Clearer definition of differences of message vs. business 
> acknowledgements (affects ebMS, CPPA and ebBP).
>
>
> [1] I've been in contact with Ian Jones to accomplish this for eMS as 
> well.
> [2] Mapping has been questioned between action and action context in 
> the <ThisPartyActionBinding> (Note, some v2.1 CPPA changes are under 
> consideration). Why does this not map to an identifier rather than a 
> name (for reference purposes). Steve Capell suggested CPPA have a 
> namespace declaration that defines the namespace of the BPSS instance. 
> He also recommended a QName although this does not find favor in W3C 
> (and Dale also questioned the use of qname).
> [3] Does ebMS wish to update its concept of "Service" to align better 
> with WSDL or retain a  generalized "Service" concept with WSDL as just 
> one specialization? [4] An ebMS Service/Action is generally viewed as 
> a package or class and action as a function or method. So the 
> combination labels a specific source/sink of a data stream in a way.  
> The sender pushing a stream towards some data sink on the receiver 
> side - the action is semantically more on the side of the sender than 
> a label for the process. Service actually could map to portType while 
> action maps to operation (somewhat). [Moberg]
>
> [5] From Dale Moberg, 24 September 2004 (see: 
> http://www.oasis-open.org/archives/ebxml-bp/200409/msg00090.html)
> ==============
> The server receiver only needs to indicate the “interface” aspects of 
> WSDL. These aspects are found within the wsdl:portType (v1.1) (or 
> wsdl:Interface v2.0), its included wsdl:operations and referenced 
> wsdl:message, wsdl:type, or wsdl:part elements (the precise elements 
> needed differ in WSDL versions). For each /ActionBinding/, the 
> interface’s operation needs to be identified. The 
> */WSDLOperation/@operationRef /*uses a URI-Reference to identify the 
> operation. This reference is constructed by appending a fragment 
> identifier to the targetNamespace URI. The fragment is constructed 
> using a syntax similar to that of XPointer that is documented in 
> [AppendixC WSDL 2.0 Core].
>
> For example, if the */WSDLOperation /*contains
> <tp:DocExchange docExchangeId="docExchangeA1">
> <tp:WSReceiverBinding version="2.1">
> <tp:WSDLOperation version="1.1" 
> operationRef="http://hello.org/hello1#operation(Hello/sayHello)" >
> <wsdl:definitions xmlns:tns="http://hello.org/hello1"; 
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
> targetNamespace="http://hello.org/hello1"; name="HelloWorld">
> <types/>
> <message name="Hello">
> <part name="String_1" type="xsd:string"/>
> </message>
> <wsdl:portType name="Hello">
> <operation name="sayHello" parameterOrder="String_1">
> <input message="tns:Hello"/>
> </operation>
> </wsdl:portType>
> </wsdl:definitions>
> </tp:WSDLOperation>
> </tp:WSReceiverBinding>
> </tp:DocExchange>
>
> then the URI-Reference
> http://hello.org/hello1#operation(Hello/sayHello 
> <http://hello.org/hello1#operation%28Hello/sayHello>)
> would select the wsdl:operation that has been previously referred to 
> in a */ServiceBinding /*
> *//*
>
> One problem has been that picking out what is relevant in the 
> operation varies depending on whether the DocExchange aspect of the 
> DeliveryChannel is in a CanSend, a CanReceive, or a nested 
> CanReceive/CanSend context. ebXML has chosen to have a separate 
> configuration for each message sent and received. That is, there are 
> separably configurable "sides" for each message sent. Each sent 
> message is considered an Action. For WS, an operation can span several 
> ebXML actions. In addition, fault messages are defined that can be 
> sent instead of a message or in reaction to a message. That means that 
> for WS MEPs beyond the In-Only and Out-Only, there really needs to be 
> something that points to the "part" of the operation that is being 
> configured. To do this, additional URI-References are required that 
> point to the input, output or fault messages that make up the ebXML 
> Action.
>
> <tp:ServiceBinding>
> <tp:Service>urn:w3c:wsd:hello</tp:Service>
> <tp:CanReceive>
> <tp:ThisPartyActionBinding id="companyA_TPAB2" action="OneWay" 
> packageId="PlainSOAP">
> <tp:BusinessTransactionCharacteristics 
> isNonRepudiationRequired="false" 
> isNonRepudiationReceiptRequired="false" isConfidential="none" 
> isAuthenticated="none"
> isTamperProof="none" isAuthorizationRequired="false"/>
> <tp:ChannelId>ChannelA1</tp:ChannelId>
> </tp:ThisPartyActionBinding>
> </tp:CanReceive>
> </tp:ServiceBinding>
>
> Unfortunately, inputs and outputs don't have names in WSDL so the 
> previous way of referring does not work. In WSDL 1.1, the input and 
> output references a message, so message references works for this 
> version. For WSDL 2.0, however, the message construct is removed, and 
> the corresponding link to the type is made using the value of an 
> attribute named "element"-- the value is the qname of the globally 
> declared element.
>
> Since CPPA and BPSS have the same granularity of its basic Actions, 
> (the parts of the BT) something like the above apparatus will be 
> needed in our BPSS 2.0 OperationMapping construct....In generating a 
> CPP when given a BPSS instance that contains OperationMapping 
> elements, the CPP can derive from the BPSS instance the precise 
> details needed in the WSDLOperation section of its configuration for a 
> Delivery Channel.
>
> ==================================================================================================== 
>
>
> CPPA to ebBP mapping provided by Dale Moberg, 11 August 2004 
> (http://www.oasis-open.org/archives/ebxml-bp/200408/msg00016.html)
>
> CPPA BPSS
> ======= =====
>
> * /CPP/CollaborationRole/ProcessSpecification/@name 
> /ProcessSpecification/@name
>
> [Discussion:
> Nagahashi: I believe this name attribute is of different nature than 
> other name/nameID attributes. ProcessSpecification is the root element 
> of BPSS and it doesn't have nameID attribute. This name attribute is 
> not used for reference purposes. We won't make it optional. It would 
> be safe to drop this from the list.
>
> Moberg: This name attribute is not used for reference purposes either 
> within BPSS or within CPPA. But for some reason, it is "imported" by 
> CPPA when BPSS is used. This may be an option to mapping to Service.
> /CPP/CollaborationRole/ProcessSpecification/@uuid 
> /ProcessSpecification/@uuid
>
> /CPP/CollaborationRole/ServiceBinding/Service /ProcessSpecification/@uuid
>
> [This was the alignment made of CPPA 2.0 and BPSS 1.01. It is subject 
> to renegotiation.]
>
> * /CPP/CollaborationRole/Role/@name Selected from //Role/@name
>
> [The specific xpath to the Role in the BPSS is indicated by a href,
> which uses a fragment identifier to reference the Role element by its 
> id.]
>
> 1/2 * /CPP/CollaborationRole/ServiceBinding/Can[Send|Receive]
> /ThisPartyActionBinding/@action Can take value from BPSS (see note) or 
> can use an agreed upon value.
>
> [CPPA spec notes: When business transactions are not reused in 
> different contexts, it is recommended that the names of the requesting 
> business activity and responding business activity be used as action 
> names.]
>
> /CPP/CollaborationRole/ServiceBinding/Can[Send|Receive]
> /ThisPartyActionBinding/ActionContext No specific reference to an 
> information item (container element).
>
> * /CPP/CollaborationRole/ServiceBinding/Can[Send|Receive]/
> ThisPartyActionBinding/ActionContext/@binaryCollaboration Corresponds 
> with value of BinaryCollaboration@name
>
> [In 2.0, this will need to be generalized to reference 
> BinaryCollaboartion,
> MultipartyCollaboration or BusinessCollaboration.]
>
> * /CPP/CollaborationRole/ServiceBinding/Can[Send|Receive]/
> ThisPartyActionBinding/ActionContext/
> CollaborationActivity/[CollaborationActivity...]/@name Matches the 
> value of BPSS //CollaborationActivity@name.
>
> [These Collaboration activity children are used to select nested BCs.]
>
> * /CPP/CollaborationRole/ServiceBinding/Can[Send|Receive]
> /ThisPartyActionBinding/ActionContext/@businessTransactionActivity 
> Matches the value of BPSS //BusinessTransactionActivity/@name
>
> /CPP/CollaborationRole/ServiceBinding/Can[Send|Receive]
> /ThisPartyActionBinding/ActionContext/@requestOrResponseAction Fixed 
> enumeration.
>
> [Aligned with whether the action is a requesting or responding 
> activity, but nothing is referenced in the BPSS instance directly.]
>
> Also, .in the CPPA, .the */BusinessTransactionCharacteristics 
> /*element has the following attributes:
>
> · an IMPLIED isNonRepudiationRequired attribute,
>
> · an IMPLIED isNonRepudiationReceiptRequired attribute,
>
> · an IMPLIED */isConfidential /*attribute,
>
> · an IMPLIED */isAuthenticated/* attribute,
>
> · an IMPLIED isAuthorizationRequired attribute,
>
> · an IMPLIED */isTamperProof/* attribute,
>
> · an IMPLIED isIntelligibleCheckRequired attribute,
>
> · an IMPLIED timeToAcknowledgeReceipt attribute,
>
> · an IMPLIED timeToAcknowledgeAcceptance attribute,
>
> · an IMPLIED */timeToPerform/* attribute,
>
> · an IMPLIED */retryCount/* attribute.
>
> ·
>
> These attributes allow parameters specified at the 
> /Process-Specification/ level to be overridden. If one of these 
> attributes is not specified, the corresponding default value should be 
> obtained from the /Process-Specification /document
>
>
>
>
>