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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

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


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


John,

Ah - OK.  The public / private side is of course critical.

Public exposure of CPA is not recommended unless the parties
choose to do that and it suits their business model
(eg - like publically posting a WSDL).

But you may post a public CPA template with recommended
settings - that people can then set and modify for their
actual use.

Interestingly - the idea of named profiles works well for
public CPA templates - since you could actually not expose
the lowlevel details that the profile references...

You might even be able to do that right now with refID values - but
probably less obvious - given the tight dependencies in
the current CPA XML syntax (its very unforgiving right now
of experimental variations from the "norm" it expects !).

DW


----- Original Message ----- 
From: "Yunker, John" <yunker@amazon.com>
To: "Dale Moberg" <dmoberg@cyclonecommerce.com>; "David Webber (XML)"
<david@drrw.info>; "Monica J. Martin" <Monica.Martin@Sun.COM>
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 1:28 PM
Subject: [ebsoa] RE: [ebxml-bp] Re: [ebsoa] Re: [ebxml-bp] Closing the gap
between MSI and BSI and move on


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







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