RE: [ebxml-bp] Re: [ebsoa] Re: [ebxml-bp] Closing the gap between MSI and BSI and move on

["Yunker, John" <yunker@amazon.com>]

Good catch Dale.

When I said CPA plays a role, I was referencing that the CPA can contain the discrete identification of the physical MSI, and override some of the business rules (e.g. timeouts).  I didn't mean to expand it's role.

Regarding public/private, my feeling is that the BSI is public while the BS is private (analagous to the public interface to a private set of application classes).  This is something we should make sure we are aligned on.

John

-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] 
Sent: Friday, February 04, 2005 10:17 AM
To: Yunker, John; David Webber (XML); Monica J. Martin
Cc: Sacha Schlegel; ebXML BP; ebxml-msg@lists.oasis-open.org; ebsoa
Subject: RE: [ebxml-bp] Re: [ebsoa] Re: [ebxml-bp] Closing the gap between MSI and BSI and move on


Here begins a rare disagreement with John.

I am dubious that the CPPA is the right place to try to define the way the BSI is deployed in an environment containing software playing a MSH role.

The CPPA represents the agreement about parameters defining expectations concerning selected options for the collaboration protocol used by business process participants. That means it really only deals with configuration of the public process, not the private process. The private process is not something a collaborator "gets a say in," so to speak; so their agreement on these internal employment details is neither required nor solicited. 

And it is the configuration of private process details that a deployment and configuration technology would need to address. I don't believe that either WSBPEL or anything in the WS-Policy area addresses this area squarely either. Some aspects might be touched upon by things like J2EE deployment descriptors (clearly not deployment environment neutral), and even within that tradition, deployment descriptors are not uniformly loved (search on Deployment Descriptors: the Achilles' Heel of J2EE or similar). I also think that if we spec out too many requirements in this area we endanger the loose-coupling of the underlying SOAP based messaging. Finally, too many requirements can lead us to a situation in which we begin to appeal to end users who have a totally blank canvas upon which to build. Very few of these around, no matter what the size or sophistication of their IT infrastructure. 

Anyway there's my $.02 of reservations.


-----Original Message-----
From: Yunker, John [mailto:yunker@amazon.com] 
Sent: Friday, February 04, 2005 10:47 AM
To: David Webber (XML); Monica J. Martin
Cc: Sacha Schlegel; ebXML BP; ebxml-msg@lists.oasis-open.org; ebsoa
Subject: RE: [ebxml-bp] Re: [ebsoa] Re: [ebxml-bp] Closing the gap between MSI and BSI and move on

re: "since the heavy lifting on this probably can be differed and continued by the ebSOA team more effectively beyond that start point"

David, I believe that one thing that is needed is the details of how the BSI business interface is executed via the MSI messaging interface. Currently the BPSS is the only place to put the details of that mapping. IMO while the ebSOA is responsible for outlining the high-level architecture for MSI/BSI dependency (especially in an SOA implementation), the BPSS is exactly where the bulk of the tedious work on defining the details of those dependencies is currently taking place (and the only one I see working actively on a packaged definition of a BSI).

Since we insist (and I agree we should) on championing the MSI/BSI views, we should make sure we include detailed definitions of the attributes of the dependencies between those views, and engage ebMS/CPA on exactly how that mapping is executed in a fully ebXML solution.

I think that the BPSS spec does a decent job of this already in a general sense.  Propose that we review and (where appropriate) tighten the packaging of BSI/MSI dependencies, and talk about either including examples or follow-on documents that show reference ebMS/CPA/BPSS dependencies for BSI and MSI...

My 2 cents.
John

-----Original Message-----
From: David Webber (XML) [mailto:david@drrw.info] 
Sent: Friday, February 04, 2005 9:00 AM
To: Monica J. Martin
Cc: Sacha Schlegel; ebXML BP; ebxml-msg@lists.oasis-open.org; ebsoa
Subject: [ebxml-bp] Re: [ebsoa] Re: [ebxml-bp] Closing the gap between MSI and BSI and move on


Monica,

I'm agreeing with that - but I was also saying that
the BPSS team need only set the scene here fior
the V2 specification - since the heavy lifting on
this probably can be differed and continued
by the ebSOA team more effectively beyond
that start point.

There's abviously more that can be done in
terms of detailed specification of the mechanisms
and options for controlling the interactions
between the various moving parts here. And
that of coruse carries us into the BPSS V3 too.

Thanks, DW

----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: "David Webber (XML)" <david@drrw.info>
Cc: "Sacha Schlegel" <sschlegel@cyclonecommerce.com>; "ebXML BP" <ebxml-bp@lists.oasis-open.org>; <ebxml-msg@lists.oasis-open.org>; "ebsoa" <ebsoa@lists.oasis-open.org>
Sent: Friday, February 04, 2005 11:34 AM
Subject: [ebsoa] Re: [ebxml-bp] Closing the gap between MSI and BSI and move on


> David Webber (XML) wrote:
>
> >Webber: Sacha,
> >I think this is also something that involves the ebSOA team - as
> >these are part of the patterns needed.
> >
> >We can certainly jointly develop this - and put initial outline work
> >in the BPSS specification - that can then be more formally detailed 
> >for the ebSOA work in 2005 here.
> >
> >Thanks, DW
> >
> >
> mm1: David, I would suggest we have some clear boundaries before
> engaging ebSOA team. Some of the discussion surrounds assumptions 
> about the role of the MSI or BSI should be clarified by the 
> experienced parties and experts involved from ebBP and ebMS teams (not

> to say there are not experts in ebSOA). Thanks.
>
>
>