[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [ebBP] 11/11/2004: Alignment with CPPA and ebBP
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]