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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

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


Subject: RE: [ebxml-cppa] Re: Notes from BPSS/CPPA conference call



A few questions/comments below.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



"Dale Moberg" <dmoberg@cyclonecommerce.com> on 11/21/2001 11:44:09 AM

To:    Martin W Sachs/Watson/IBM@IBMUS
cc:    <ebtwg-bps@lists.ebtwg.org>, <ebxml-cppa@lists.oasis-open.org>
Subject:    RE: [ebxml-cppa] Re: Notes from BPSS/CPPA conference call



Marty,

This issue was mentioned on the call, and I believe
we did agree that the BPSS instance would always
have a UUID that would uniquely identity and distinguish
it from other BPSS instances.

David Smiley summarized this as:

"Service = BPSS Unique Process Identifier (UUID)
Request to make UUID a URN"

MWS:  What is a BPSS instance?  Suppose I have three separate
"applications" that use the same BPSS instance document. By
this I mean that there is literally one BPSS instance document
that is deployed separately for each application?  Is that
one BPSS instance with one UUID or three BPSS instances with
three distinct UUIDs?  If it's 3 separate BPSS instances with
distinct UUIDs, then I agree that everything is fine.

MWS:  The term "BPSS Instance" needs to be defined, probably
in the BPSS specification.

If a short name is used within an agreement, its
uniqueness would depend upon being
scoped by the CPAId, as you and Hima note.

Some issues that still have not been resolved
concerning standardization of naming conventions
flow from  the following: 1. A BPSS instance is not
guaranteed to have any "functional" unity (that is,
it can consist of unrelated packages of functionality),
2. The CPA currently uses the ServiceBinding
to specify similar treatment for all leaf actions
under a BPSS instance (when BPSS used), and 3. CPAs
may wish to make agreements only over a subset of
leaf actions within a BPSS instance.

Suppose 2 companies want to engage in OrderManagement,
but do not wish to engage in POCancel actions or
POChange actions. [This is not a far-fetched example,
by the way.] If the ServiceBinding embraces all actions
in the instance, they will in effect agree to bindings
for actions that they do not support across the mythical
BSI interface.

These situations may have the following possible remedies
(and I am sure there are others as well!):

1. Create ways to specify a portion
of a BPSS instance as the
targeted package of leaf actions.
That reopens themyriad "name" attributes
from which the service name
could come from. May be feasible though.
2. Create ways to have Override specify
a null binding for
actions not agreed to.
(Not wild about
this one either
as it seems to introduce clutter that
the binding-up-actions as a group)
3. Apply Tony W's XSLT filter ideas to
the BPSS instance to extract
the right ones. If we use this technique,
then we still
should document how the service
naming convention works.

MWS:  There is one more remedy, which is
to create a BPSS instance document that
defines only the functions that will be
used for a particular interaction. This
is probably just a restatement of (3) and
is my preference.

MWS: I agree that we MUST document the service
naming convention for any supported
approach.




-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Wednesday, November 21, 2001 7:34 AM
To: Dale Moberg
Cc: Dan Weinreb; dsmiley@mercator.com; ebtwg-bps@lists.ebtwg.org;
ebxml-cppa@lists.oasis-open.org
Subject: RE: [ebxml-cppa] Re: Notes from BPSS/CPPA conference call



Dale,

It isn't clear to me from previous discussions that when more than one
application behind the same MSH uses the same BPSS instance document,
the
different "BPSS instances" will have unique service names.  Do they all
have the same UUID or unique UUIDs in this case?
If the service names are the same in that case, it's OK as long as they
are
qualified with the CPAId.

Regards,
Marty

************************************************************************
*************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
************************************************************************
*************



Dale Moberg <dmoberg@cyclonecommerce.com> on 11/20/2001 06:44:17 PM

To:    Dan Weinreb <dlw@exceloncorp.com>, dsmiley@mercator.com
cc:    ebtwg-bps@lists.ebtwg.org, ebxml-cppa@lists.oasis-open.org
Subject:    RE: [ebxml-cppa] Re: Notes from BPSS/CPPA conference call



Dan Weinreb asked:

"It seems to me that this would mean that every message sent under the
control of a particular BPSS would have the same Service value.  That
is, all the messages sent by a given business process would all have
the same value for Service.  Is that what was intended?"


Yes, I think that is the current proposal under consideration.

This convention would be coupled with the
constraint that all distinct actions
within the BPSS instance would have
distinct names (both the short version
names and the long Xpath names
would be distinct within a "service")

So an OrderManagement service would
have PurchaseOrder ,  PurchaseOrderChange,
PurchaseOrderCancel, PurchaseOrderAcknowledge
actions, for example.



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebtwg.org/ob/adm.pl>








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


Powered by eList eXpress LLC