OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: ebCPPA 2/26/2006: Comment to ebBP for CPPA


Here are comments we received in the minor 15-day public review of ebBP 
v2.0.2 that actually are important to CPP/A. I indicated Radha I'd 
forward to you for comment and redress. Thanks.

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]