Re: [ebxml-bp-comment] Public Comment

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

Radha,
First we appreciate your comments and once we discuss in the ebBP team, 
we may ask that you attend a call to investigate your comments further. 
Thank you. See some very initial comments inline.

>Comment from: radha.arur@polaris.co.in
>Name: Radha Arur
>Title: AVP
>Organization: PSLL
>Regarding Specification:
>
>Feedback on ebxmlbP ver 2.0 
>
>Good points:
>1. The distinction between Collaboration, Message  AND the interaction and dependancies between Business Process Interface and Message Interface are very well articulated. 
>
>2. The definition of  types of Gateways and the distinction between Binary and Multiparty collaboration are very clearly defined. 
>  
>
mm1: Thank you.

>Suggestion for improvements:
>1.Though the distinction and the dependencies between BSInterface and MSInterface are defined, it is not clearly specified (though suggested) how the MSI can be used without BSI.  i.e Does the BSI remain redundant in that situation? 
>  
>
mm1: Whether the business process delegates to the messaging 
infrastructure is an implementation choice rather than dictated by the 
specification. And, whether these are used together or individually is 
also the same. Given the current capabilities of messaging services, 
there are capabilities that are expected by the business process that 
are not supported. Examples include: Acceptance Acknowledgements after 
business processing on the business document is completed (either 
successfully or otherwise). The ebBP team has had discussions surrounding:

   1. More specification of the handlers involved for messaging and the
      business service, which I believe is important in your question.
      This further specification or definition likely would fall outside
      of the core technical specification. No decision has been made
      whether it would be part of a primer or how-to guide, an
      additional white paper or other document. The glue has been seen
      to be the CPP/A between the two.
   2. To what degree specification should be made. One key point in our
      discussions has been the optimal balance between flexibility
      (given what is used at runtime) and the constraints placed on
      implementations if the definition assumes particular technologies.
      For example, we discussed at length that the BSI could be a
      gateway, a service, middleware, an application or any combination
      of these (or other possibilities we've not specified).

>2.Relation with other specification – 
>    i.e how the CPA and CVV should interact with CQI – Customer Information Quality TC recommendated work?  
>  
>
mm1: I'd direct this question to CPPA team. I'll forward to that team 
and cc: you.

>3. CPA actually specifies the interface with access points defined by the business process specification. Elaboration / clarification on  this sentence? Does it mean BSI is CPA? 
>
mm1: The CPPA articulates the technical mechanisms that configure a 
runtime system and encourage interoperability between two parties that 
may use different applications or software from different vendors. The 
CPP/A defines the way two parties// will interact in performing the 
chosen business collaborations. The BSI understands business 
collaborations, the associated BTA, the business state, and the 
encompassing conditions, constraints, and expectations of the parties 
involved. The CPP/A currently supports the notion of business 
transactions between collaborating roles. For example, the CPP/A 
currently can provide a reference to timing parameters to a business 
collaboration but technical mechanisms are yet to be defined to 
accommodate (in CPP/A and in the underlying messaging). Another key 
example is for web services. The business process defines a fairly 
succinct way to map business transaction activities to an abstract name 
for a web service operations. The technical mechanisms for the 
interface, the namespace, access, etc. are actually defined by the 
configurable capabilities in the CPP/A (as they should be). If this 
further description assists in answering your question, is it sufficient 
to articulate in the appendices to enable understanding by our user 
communities?

>4. Rules for the Collaboration Monitoring engine is left too much to the discretion of the application and has not specified any framework or guideline and may also take input how this interacts with F2F activity.  i.e How the messaging and collaboration layer work together is not specified or not easily tracable. 
>  
>
mm1: See the previous comment that the implementation is not dictated 
and why. That does not mean however we could provide additional guidance 
for collaboration monitoring. In an anticipated subsequent version, we 
intend to expand the status visibility capabilities, for example. 
Whether or not such specification between the collaboration and 
messaging layer should be in the ebBP specification is an open question. 
Given what I have articulated thus far, a primer or white paper may be 
the more appropriate mechanism. What are your thoughts and suggestions?

>5.Distinction between Business message and signal and the relation with BSI may be explicitly mentioned. 
>  
>
mm1: The BSI understands both and their relevance to success or failure 
(whether technical and/or business). If you look at Section 3.6.3 in the 
technical specification (on public web site: 
http://www.oasis-open.org/committees/document.php?document_id=16455&wg_abbrev=ebxml-bp 
[pdf in .zip]), it discusses how business messages with an associated 
business document and business signals relate to success or failure. If 
we link these two discussions in the Appendices, Appendix A, will that 
increase your understanding? The specification, appendices, and the 
schema and documentation are used together.

>6. The difference between Substantive business message and normal business message since both refers to the same in many situations. 
>  
>
mm1: We can increase the description to make this consistent. I will 
work through in the specification where changes may be required. This is 
editorial in nature.

>7. Explanation of Relevance of state synchronization and state alignment may need to be mentioned.
>  
>
mm1: In Section 3.4.2 (see reference above for link), we do describe 
this. I will go through the specification and see where this is 
underspecified. We are clear in the specification that the expectations 
of the parties and their shared understanding is imperative for business 
collaboration. State alignment is key to enable that. I'll provide 
further comments once I go through the specification more fully to 
address your question.

>8.Relationship to repository is very much at abstract level. May/ should  provide a better implementation recommendation. 
>  
>
mm1: This may be an excellent opportunity for a profile. We have had 
some initial interest in one related to ebXML Registry/Repository.

>9. A sample implementation on how the specification can be used between applications in the organization (especially for a complex business transaction ) with the use of Fork, Decision and Joint Gateway will be really useful. 
>  
>
mm1: We do have this in an example on the public web site (criminal 
justice in the Netherlands). We will have more UBL v2.0 supported ebBP 
definitions that do the same likely very soon. See: 
http://www.oasis-open.org/committees/document.php?document_id=16436&wg_abbrev=ebxml-bp. 
I'd encourage your further comment to this initial set of responses. We 
are very appreciative for your response and continued interest in ebBP.

Thank you.