[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]