[Fwd: [ebxml-bp] Responses from Arur Public Comment

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

So everyone can see Radha Arur's responses to my initial inputs.  This 
should help with tomorrow's discussion (it never made it to the list I 
think).

--- Begin Message ---

• From: radha.arur@polaris.co.in
• To: Monica J Martin <Monica.Martin@Sun.COM>,"David RR Webber (XML)" <david@drrw.info>
• Date: Wed, 22 Feb 2006 15:27:51 +0530

David, Monica,

Thanks for the feedback. I have given my feedback in blue wherever comments
are requested or questions were raised.

***************************************************************************************************
One thing that is consistently missing with respect to the CPA - is the top
down trading partner management aspects.
Most people - given the high degree of technical tagness in the CPA itself
- tend to have the bottom up view of CPA.

My experience is focusing on how to use the Registry, CPA and ebMS together
to faciliate partner control / collaboration of wide communities.  So
partners can use CPA ID as a linkage mechanism that controls access,
versioning and interoperability.

-     Yes, the complexity exists because of overlapping functionalities
between registries and CPA.
-     Adding to that is the adherence of FERA reference guide mechanism so
that a B2B gateway can support, ESB, MQUEUE and Web service intermediation.
How far that fits with this specification?

This is an architecture and design realization that needs to happen.  So
the CPA is performing as an orchestration linkage tool - rather than just a
set of config' parameters for your ebMS...

Also - from the BSI perspective - we need profiles and templates - of
standard sets of configurations - such as "Normal Transmit", "Urgent Msg",
"Low priority Msg".  You can do this right now with CPA - but it does not
jump out at you as *the* preferred way of making CPA easier to do.

I guess a few pointers then on the BSI side - support context and role; use
templates; versioning; and exploit the feature set the architecture
provides to do top down collaboration integration.

The engineers can then take all the wonderful tagness available today - and
figure out how to provide that in a simple and coherent way that mere
mortals can use (hopefully!).

Your comments are definitely helpful in guiding how to package and present
the concepts so that can happen.

 Thanks.

And of course - there are things - like the collaboration engine - that we
are scheduled to work in much more detail on for V3.0 now that V2.02 if
finally in the books!

 >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 recommended work?
 >
 >
 mm1: I'd direct this question to CPPA team. I'll forward to that team
 and cc: you.

  O.K – This is the most important implementation question that most of the
 customers face in SOA space.  Also if customer information and another
 activity which / is coupled with another business process can be depicted
 as a complex business process, it will be all the more relevant or
 important.

 >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?

 > May be. Will also be of benefit, if the specification can include all
 types of models that a versatile B2B gateway should support.

 >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?

-     Separate white -paper may be a better option.

 >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.

-      A single reference will be easier.

 >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.

-     O.k.

 >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
 under-specified. 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.

-     O.k.

 >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
 .

 - o.k. I will have a look at it. The more relevant one will be the one
 -which is referred to a case mentioned in question no.2.

Radha Arur
This e-Mail may contain proprietary and confidential information and is sent for the intended recipient(s) only. 
If by an addressing or transmission error this mail has been misdirected to you, you are requested to delete this mail immediately.
You are also hereby notified that any use, any form of reproduction, dissemination, copying, disclosure, modification,
distribution and/or publication of this e-mail message, contents or its attachment other than by its intended recipient/s is strictly prohibited.

Visit Us at http://www.polaris.co.in

--- End Message ---