[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-bp] Re: [ebxml-bp-comment] Public Comment
Hi David, Monica, Radha Radha, I understand very well that it would be very nice to be able to read about one ebXML reference implementation. A reference implementation should include the "preparation" tasks. o creation or reuse of the top down collaborative business processes and business documents (or use standards like the Universal Business Language (UBL)). o creation of ebXML Collaboration Protocol Profiles (CPPs) and ebXML Collaboration Protocol Agreements (CPAs) based upon the collaborative business processes o Usage of an ebXML Registry/Repository to store and later query these artifacts. The reference implementation should then include the "execution" tasks: o Usage of an Business Service Handler (non official ebXML name), that interprets, monitors the transactions of the collaborative business processes, monitors the timers, handles all the different in parallel instances of the collaborative business processes. Generally such a BSH would know about the collaborative business processes. Such a BSH can potentially take care of those ebXML Business Process business signals, eg it could be the instance that creates the signals at the appropriate times or forward incoming business signals to the respective applications. o Last, the usage of an ebXML Message Service Handler (MSH) that can be configured with an ebXML CPA. ebXML is all about what is happening between the two B's in B2B, like Patrik Yee nicely puts it. Of course it would be highly interesting how to then connect the public and the private worlds. Some samples could be provided how people are doing that today or how it could be done. Actually I think we are getting there, slowly ... there is clear adoption of the pursuit of the ebXML vision. A description, or whitepaper like Monica suggests would I think be very helpful for new ebXML endusers. I can only agree with that. ebXML Business Process, those collaborative business processes, is of a central role but I think we cannot yet harvest the fruits of these efforts. Just imagine to have an information system that can tell you pretty much every aspect of your hundreds or even thousands in parallel executing collaborative business processes :) Integrate the relations with the private business processes that happen and you would get a very transparent view of your business state within the business ecosystem. One more comment inline for David ... On Tue, 2006-02-21 at 10:36 -0700, David RR Webber (XML) wrote: > Monica / Radha, > > One thing that is consistently missed WRT 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. > > 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!). Good point and good call. Sacha > > Your comments are definately helpful in guiding how to package and > present the concepts so that can happen. > > 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! > > Thanks, DW > > > > > -------- Original Message -------- > Subject: [ebxml-bp] Re: [ebxml-bp-comment] Public Comment > From: Monica J Martin <Monica.Martin@Sun.COM> > Date: Tue, February 21, 2006 11:59 am > To: radha.arur@polaris.co.in > Cc: ebxml-bp-comment@lists.oasis-open.org, ebXML BP > <ebxml-bp@lists.oasis-open.org> > > 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]