ebbp comment 2/27/2006: Further Definitions Outside of ebBP (UBL, CIQ,CPPA, etc)

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

I am going to address these in an iterative fashion as follows:

   1. CPPA: Any questions related to CPP/A have been forwarded or that
      team cc: on subsequent emails. The question about CQI has been
      sent today to that team.
   2. ebBP: On specific ebBP possible changes, I will address these
      individually.
   3. Other: Where we should discuss other guidelines, primer, etc.
      Address together in a separate email. DONE

This email takes the 3. item.

>***************************************************************************************************
>... >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).
>  
>
26 February 2006
mm2: Radha, there has been interest expressed by other TC members on 
further specification of what Sacha Schlegel calls the 'Business Service 
Handler' (BSH). This is squarely where this falls.  Would you be 
interested in assisting here? Sacha would welcome this I am sure.

> >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.
>
> arur: 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.
>  
>
mm2: This actually may be part of our examples or an additional white 
paper. Let me explain.  We currently have the modular process 
definitions for UBL v1.0 and SBS.  They can be composed into complex 
business process definitions (recognizing that work is to be done to 
accomplish that).  Your question may be relevant to CPPA, UBL and to 
some extent ebBP. 

    * I've already forwarded to the CPPA team.
    * To my knowledge (and I checked the TC site again today), CIQ was
      discussed early on by the UBL team as part of / related to their
      customization work. Perhaps Stephen Green or Jon Bosak can answer
      how that is proceeding (customization that is).
    * For ebBP, we allow semantic variables to be attached to logical
      business documents or to be externally defined. In addition, in
      the most recent changes, we also allow an external document
      definition reference that further enables more capabilities.
      Whether these are useful in supporting CIQ, I've not yet assessed.
      See (to start) Section 3.4.11. We also talk more about how to use
      them with condition expressions in Section 3.4.10.1. Some
      well-formedness rules exist later in Section 3.8.3.2.

You also asked in a later question about a sample implementation. We 
will have more of those as we expand the examples.

> >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.
>  
>
mm2: This may span needs for a future white paper as well as 
descriptive. If the former, I think this could be further articulated 
with the work Sacha has discussed around BSH (see previous comment).

> >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.
>
mm2: Again, fits into BSI and BSH.

>...>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.
>  
>
mm2:  We do have folks on the Registry team that are starting to trek 
into these waters. Are you interested Radha? Thank you for your 
comments. This is one of a set of emails to address your questions (as 
we prepare for tomorrow's meeting). Regards.