[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
Dale, The definition of "BPSS Instance" in your posting ("chunk of XKL") is to loose to be useful. The real question is the definition of what that UUID is attached to. If it's just "a chunk of XML", then the implication to me is that if several instances of an application are deployed with different CPAs, but all referring to the same BPSS instance document, then the UUID is the same for all of them. That is actually OK as long as the UUID is always qualified with the CPAId. I would like to suggest that a more useful definition of "BPSS Instance" is based on the deployment rather than the chunk of XML, I.e. the BPSS instance document deployed for a specific instance of an application. I would then expect a unique UUID to be associated with each deployed instance of that (or any) BPSS instance document. I suspect that either of the above approaches (CPAId.UUID or UUID for each deployed instance) would work as long as everything is clearly spelled out in the specification. 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 12:52:56 PM 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 Just a quick response. By "BPSS instance" I just mean a chunk of XML that conforms to the BPSS schema, er, DTD. Maybe there is some more elaborate definition but I don't recall seeing it anywhere. As far as the remedies go, I think we are in basic agreement on what is required. I would like BPSS to provide some requirements or at least recommendations on how BP designers should group, and with it, some guidance on where named subservice packages might be found. Still, however, real users will want to pick and choose based on the realities of their backend systems. So some approach like 3 or 4 is likely to be needed in practice. Dale -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Wednesday, November 21, 2001 10:42 AM To: Dale Moberg Cc: ebtwg-bps@lists.ebtwg.org; ebxml-cppa@lists.oasis-open.org 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