[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] 3 different parts: private business processes ::public businessprocesses :: messaging
Hi David See comments inline. Am Montag, den 07.02.2005, 16:24 -0500 schrieb David Webber (XML): > Sacha, > > I believe the White Paper here - and the implementation we developed > for XML2004 Interop addresses all these questions directly - and even > provides source code!! > > See : > > http://ebxmlbook.com/benefits > > and > > http://ebxmlbook.com/interop > > This is why I have been saying that the new ebSOA shall describe how > to take advantage of the new enhanced ebXML. ebXML technical architecture should show one or two example how it can be done (also from an implementers view). > > The nice thing is that you can move from Classic ebXML to Enhanced ebXML > seamlessly as your needs dictate. > > Therefore - the answer to your questions is "Yes!". It is possible to mix > and match > these as necessary to obtain the level of service and interactions that you > need. So its up to the implementor. Providing interfaces between the components is an implementors choice. The interfaces will be proprietary. If I have decided to use the MSH of Independet Software Vendor (ISV) X which does not support BPSS I am stuck with that and cannot add a BPSS component of ISV Z. Please correct me if I got that wrong. Regards Sacha > > The CPA and BPSS relationship are at the heart of allowing you to manage > this - > and if you look at the XML2004 Interop presentation - you can see how this > is done for the various participants. Even allowing management of > "provisioning" > for partners from "test" to "production". > > Thanks, DW > > ----- Original Message ----- > From: "Sacha Schlegel" <sschlegel@cyclonecommerce.com> > To: "ebXML BP" <ebxml-bp@lists.oasis-open.org> > Sent: Monday, February 07, 2005 3:42 PM > Subject: [ebxml-bp] 3 different parts: private business processes :: public > businessprocesses :: messaging > > > > Hi ebBP team > > > > Sorry for stirring up the TC but I came across one or two important > > questions and I would like to continue discuss these questions. > > > > I paste the same email as I sent to the ebxml-dev list. > > > > Regards > > > > Sacha > > > > ------------------------------------------------------ > > > > > > Hi ebxml-dev community > > > > Having seen productive ebXML messages exchanged between ebXML Message > > Service Handlers that were configured with an ebXML CPA in real world is > > pretty cool. ebXML Business Processes are used for CPA generation and > > documentation. > > > > But still not there, yet ... > > > > I am looking forward to see ebXML Business Process being putting more > > into the right perspective for B2B. Introducing ebXML business processes > > in the form of playing an active part in the B2B business collaboration > > seems to be one of the next steps. > > > > There are the private business processes or legacy backend applications > > at each party and now we introduce the public buisness processes [2] > > between the parties. ebXML messaging is providing interoperable, secure > > and reliable ebXML message exchange between the parties. > > > > So amongst others, here are these three components: > > > > 1) private business processes and legacy backend applications > > 2) public business processes (ebXML) > > 3) messaging (ebXML) > > > > The question is how to get these three components to work nicely > > together. > > > > a) Combining 1 and 2 and 3? > > b) Having specified interfaces between each? > > c) Combining 1 and 2? or Combining 2 and 3? (also needs an interface) > > d) Leaving it open? > > > > Any other approaches and directions? > > > > A point I want to make here is, if interfaces are a solution, we have to > > define them, otherwise we cannot take the next steps. > > > > Regards > > > > Sacha > > > > [1] typically for the parties to understand the collaborative business > > process > > [2] Synonym to shared business processes and business collaborations > > > > PS: I did not introduce registry and core components or other components > > which also need consideration. > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]