[ebxml-cppa] CPP/A 10/14/2005: Starting Comments on v2.1 Working CPP/ADraft (updated)

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

mm2: See at end of this email a few comments. Thanks.

> mm1: Through page 50.....editorial are marked as such. More may 
> follow. Thanks.
> [start1]
> Section 7.3:
> May wish to consider reference to CPA profile in IIC deployment 
> template - indicative of idea of CPA template
>
> Section 7.5
> EDITORIAL: You specify middleware. As we discussed in ebBP, this may 
> be services, gateway, etc. Suggest more generic language.
>
> Section 8.4.4
> EDITORIAL: With the updates in ebBP, may wish to call consider updates 
> similar to signals: ProcessSpecificationInfo (particularly if you are 
> generalizing).
>
> Section 8.4.4.2
> EDITORIAL:
> Change from: NOTE: The ebXML Business Process specifications with a 
> 1.*  major version have a version indicating the version of the 
> Process-Specification document; in major version 2, the 
> specificationVersion attribute indicates the version of  the 
> Process-Specification document. An instanceVersion is added to track 
> versioning of specific business process descriptions.
> Change to: NOTE: The ebXML Business Process specifications with a 1.*  
> major version have a version indicating the version of the 
> Process-Specification document; in major version 2, the 
> specificationVersion attribute indicates the version of  the 
> Process-Specification document (the technical specification itself). 
> An instanceVersion is added to track versioning of specific business 
> process descriptions, such as those in the context of a particular 
> domain.
>
> Section 8.4.4.6
> 1. This discusses verification that the Process Specification has not 
> changed (via the signature).  How is this approached if an external 
> service provides the values for the late binding (For example, at this 
> time, this is constrained to time to perform in ebBP although this 
> could be expanded). This circumstance likely is not constrained to the 
> ebBP case (reference perhaps policy).
>
> 2. Shouldn't this be generalized if another process spec is used?
> EDITORIAL:
> Change from: "After applying any transforms, it would be necessary to 
> validate the transformed document against the ebXML Business Process 
> Specification Schema[ebBPSS]."
> Change to: After applying any transforms, it would be necessary to 
> validate the transformed document against the process specification, 
> such as the ebXML Business Process Specification Schema[ebBPSS] if used.
>
> 3. Note on 2., a global change may be required for any reference of 
> ebBPSS to generalize. I didn't go to the specificity of referencing 
> them all.
>
> Section 8.4.5
> What considerations are needed for CPA to support MPC?
>
> Section 8.4.5.3
> What if the location changes for the URI? Is another references also 
> required (related to ebBP questions from UBL) or is this handled by 
> the validation ahead of use of the CPA? This question may be broader 
> than this section alone. It appears from discussion in September 2001, 
> that there was a caveat that validation may occur regardless if the 
> CPA was signed and exceptions raised. I currently don't (at least yet) 
> see this constraint in the current specificatin, if still applicable
> (see: 
> http://lists.oasis-open.org/archives/ebxml-cppa/200109/msg00044.html, 
> for example)
>
> Section 8.4.8
> 1. What happens if several delivery channels are used within a process 
> specification?
> ref: "The ServiceBinding element identifies a DeliveryChannel element 
> for all of the business Message traffic that is to be sent or received 
> by the Party within the context of the identified 
> Process-Specification document.  It MUST contain at least one 
> CanReceive or CanSend child element." Is this construed to relate to 
> multiple endpoints with different channelID within a DeliveryChannel 
> rather than multiple DeliveryChannel? If it is the former, this isn't 
> an issue.
>
> See: ...
> - <xsd:complexType name="CollaborationRoleType">
> - <xsd:sequence>
>  <xsd:element ref="tns:ProcessSpecification" />
>  <xsd:element ref="tns:Role" />
>  <xsd:element name="ApplicationCertificateRef" 
> type="tns:CertificateRefType" minOccurs="0" maxOccurs="unbounded" />
>  <xsd:element name="ApplicationSecurityDetailsRef" 
> type="tns:SecurityDetailsRefType" minOccurs="0" />
>  <xsd:element ref="tns:ServiceBinding" />
>  </xsd:sequence>
>  </xsd:complexType>
> ...
>
> Should there not be more than one service binding (particularly if 
> many services are used across a process specification (for example, as 
> defined by the OperationMapping if using ebBP)? Note, earlier this 
> year March 2005, CPP/A and ebBP team discussed this is logically a 
> business service rather than a lower level service. At that time we 
> identified that a process specification could encompass many services; 
> the CollaborationRole could have multiple service bindings. In that 
> discussion, the (business) service was seen as the scope of all the 
> canSend and canReceive in an ActionContext.  I am uncertain these 
> changes have been fully integrated into the current schema.
>
> Section 8.4.10, .11
> Are there any changes required if we integrate the pull-functionality 
> into CPP/A v2.1 (descriptive change only)?
>
> Section 8.4.12
> 1. EDITORIAL:
> Change from: NOTE:  An implementation MAY provide the capability of 
> dynamically assigning delivery channels on a per Message basis during 
> performance of the BinaryCollaboration. The delivery channel selected 
> would be chosen, based on present conditions, from those identified by 
> CanSend elements that refer to the BinaryCollaboration that is sending 
> the Message. On the receiving side, the MSH can use the distinct 
> EndPoints to identify the DeliveryChannel used for this message exchange.
> Change to: NOTE:  An implementation MAY provide the capability of 
> dynamically assigning delivery channels on a per Message basis during 
> performance of the Business Collaboration. The delivery channel 
> selected would be chosen, based on present conditions, from those 
> identified by CanSend elements that refer to the Business 
> Collaboration that is sending the Message. On the receiving side, the 
> MSH can use the distinct EndPoints to identify the DeliveryChannel 
> used for this message exchange.
>
> 2. EDITORIAL: Subsequent to 1. , may need a global change in CPP/A 
> specification where BinaryCollaboration is referenced. A general 
> statement upon first reference might make it easily fixed and then 
> globally updated. This also holds true to similar references in the 
> CPP/A schema.
>
> 3. Note: Also see comment on Section 8.4.5.
>
> 4. At some point in the future, may wish to consider if a combined 
> approach is used where it is know whether or not a business 
> transaction is or isn't used in more than one context (reuse question) 
> and accommodate both together in the CPP/A. The sections that talk 
> about this variability (at least to me) are somewhat confusing. The 
> model of a business transaction is that it is reusable.
>
> Section 8.4.14.3
> EDITORIAL:
> Change from:
> The isConfidential attribute has the possible values of "none", 
> "transient", "persistent", and "transient-and-persistent". These 
> values MUST be interpreted as defined by the ebXML Business Process 
> Specification Schema[ebBPSS].
> Change to:
> The isConfidential attribute has the possible values of "none", 
> "transient", "persistent", and "transient-and-persistent". These 
> values MUST be interpreted as defined by the process specification 
> such as ebXML Business Process Specification Schema[ebBPSS], when used.
>
> Section 8.4.14.10
> If this is true:
> "When synchronous reply mode is in use (see Section 8.4.23.1), the 
> TimeToPerform value SHOULD be used as the connection timeout."
> Then the CPP/A needs to deal with the fact that the TTP is not static 
> and could be acquired and bound at runtime (thus establishing the 
> timeout parameter). Verify, if applicable, this is handled or 
> identified as subject to future changes.
>
> Section 8.4.16
> EDITORIAL:
> Change from:
> The ActionContext element has the following elements:
> zero or one CollaborationActivity element,
> zero or more [XML SCHEMA-1] wildcard elements.
>
> The ActionContext element also has the following attributes:
> a REQUIRED binaryCollaboration attribute,
> a REQUIRED businessTransactionActivity attribute,
> a REQUIRED requestOrResponseAction attribute.
>
> NOTE: See Section 10.6 for a description of the ActionContext2 element 
> that is used for Process Specifications conforming to [ebBPSS2].
>
> Change to:
> The ActionContext element has the following elements:
> zero or one CollaborationActivity element,
> zero or more [XML SCHEMA-1] wildcard elements.
>
> The ActionContext2 element also has the following attributes:
> a REQUIRED businessCollaboration attribute, [1]
> a REQUIRED businessTransactionActivity attribute,
> a REQUIRED requestOrResponseAction attribute.
>
> NOTE: See section 10.6 for a description of the ActionContext2 element 
> that is used for Process Specifications conforming to [ebBPSS2].
>
> [1] See previous comment on Section 8.4.12 related to change of name 
> of BinaryCollaboration. Same holds true for Section 8.4.16.1, 
> 8.4.16.2, etc. (like I said, global change may be required).
> [end1]

[start2] second set of comments
Section 8.4.5
What considerations are needed for CPA to support MPC?
[add] Must address in B4 as well.

Section 8.4.23
May need to re-evaluate these sections regarding synchronous messaging 
and what is included in the ebXML message. Section is primarily focused 
on synchronous exchanges with no corresponding asynchronous.

Section 8.4.23.1
May need to abstract this as other process specifications may not 
recognize the concepts of Receipt and Acceptance Acknowledgements.

Section 8.4.23.3
On this "NOTE:  By enabling the use of signed Acknowledgment for 
reliably delivered messages, a weak form of non-repudiation of receipt 
can be supported. This is considered weaker than the Receipt 
Acknowledgment signal because no schema check can be performed on the 
payload prior to the return of the Acknowledgment. The 
ackSignatureRequested attribute can be set independent of the value for 
the isNonRepudiationReceiptRequired attribute under the 
BusinessTransactionCharacteristics element. Thus, even if the original 
Process-Specification specifies that non-repudiation of receipt is to be 
performed, the CPP and/or CPA can override this requirement, set 
isNonRepudiationReceiptRequired to "false" and ackSignatureRequested to 
"always" and thereby achieve the weak form of non-repudiation of receipt."
May need to re-evaluate in the future whether or not this override is 
allowed under party expectations; if those expectations are explicit, 
may need to recognize that and provide a constraint.

===
Note:
1. Didn't review sections under revision for transport, endpoints, etc.
2. Didn't review appendices pending changes.
===

Section 8.4.41
May need revisions in this section relative to ebMS v3.0:
"Semantics of reliable messaging are explained in the ebXML Message 
Service specification[ebMS] chapter on Reliable Messaging Combinations."

Section 9.5.2
Would the concurrentConversations also apply to the number of concurrent 
BTA in play for a business collaboration within a given process definition?

Section 9.12
If there is an override, for example of security or non-repudiation 
(weaker implementation), this affects the parties'  expectations. How is 
this resolved, or is it referenced back to a TPA that allows such (and 
if so, to what extent)? Does the process specification need to specify 
which characteristics may or not may be overridden?

Section 10.5.3
Given the recent extensions for OperationMapping in ebBP, may wish to 
use part of that description in this section where the WSDL location is 
specified (and relevant as a map to the abstract operation name in the 
process description).
[end2]