RE: Service and action elements

[Martin W Sachs <mwsachs@us.ibm.com>]

David,

Thank you for making some of my points more precise.  I agree with
everything you say below.

My basic concern was that on reading the service and action descriptions in
the message service specification, it was not clear to me that it is
explicit enough about how these elements are to be used.  It is the service
and action elements that route the message at the receiving party to the
software that will process the message.  The message sender has to put in
values that can be understood by the message recipient's routing function.
Those of us who have been discussing this stuff for months understand these
matters but I don't think it will be clear to someone looking at the
specification for the first time.  I would like to see an explicit
statement of this form:

   If a CPA and BPSS instance document (Process Specification document is
   the term in the CPA spec) are in use, the message sender SHALL use the
   value of the name attribute of the X element in the Process
   Specification document as the value of the Service element and the value
   of the name attribute of the Y element in the Process  Specification
   document as the value of the Action element.

   If a CPA and Process Specification document are not being used, the two
   parties MUST exchange information about what values to give the Service
   and Action elements by means outside the scope of this 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
*************************************************************************************



"Burdett, David" <david.burdett@commerceone.com> on 07/10/2001 11:26:27 AM

To:   Martin W Sachs/Watson/IBM@IBMUS, michael.m.ho@sybase.com
cc:   ebxml-msg@lists.oasis-open.org, ebxml-bp@lists.ebxml.org
Subject:  RE: Service and action elements



I have different interpretation ...

Below it says ...
>>
·    Action equates to a Requesting or Responding Business Activity
·    Service is a set of related actions for a single AuthorizedRole
supported by a party
<<
This definition is also repeated in the ebXML Messaging spec.

The key point here is that it is the actions for a **single
AuthorizedRole**. This would mean, for example, that there would be one
"Service" for the "Buyer" role, for example and a separate service for the
"Supplier" role. This makes practical sense, I think, since:
1. The buyer and supplier roles are separate and, for a given transaction,
will almost always be carried out by different parties
2. You will often use separate software, potentially at different URLs for
the buyer and supplier role even if one company does both.

As far as choosing names is concerned it really is down to the designer of
the business process and service to specify what they are. The idea of
Service and Action is for them to have similar meanings to an Object Class
and its associated Method calls. I anticipate that some sample definitions
will be available before too long.

Regards

David

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Friday, July 06, 2001 1:10 PM
To: michael.m.ho@sybase.com
Cc: ebxml-msg@lists.oasis-open.org; ebxml-bp@lists.ebxml.org
Subject: Re: Service and action elements



Michael,

Based on what you have said below, I believe that the correct answer is
that the value of Service should be the name of the binary collaboration
from which the message was issued and the value of Action should be the
name of the business transaction that issued the message.   Since both
sender and recipient are using the same BPSS instance document, the names
should be understood by the recipient and mapped to the correct method call
to process the message.

You are correct that the definitions must come from one source and both
parties must agree to abide by it.  If there is a CPA, that CPA is pointing
to the one BPSS instance document that both parties have agreed to use.

If there is no CPA, then the two parties must exchange the Service and
Action information outband.

I believe that the descriptions of Service and Action in the Message
Service specification are a bit too vague to assure interoperability. Since
each party must know the values of Service and Action that apply to the
other party, some means of obtaining that knowledge should be specified.
Examples of points to be made:

   If the two parties are using a CPA and single BPSS instance document,
   the value of Service SHALL be the value the name attribute of the binary
   collaboration that sent the message, and the value of Action SHALL be
   the value of the name attribute of the business transaction that sent
   the message.

   If the two parties are not using a CPA, they must exchange the values of
   Service and Action outband.

I have copied your reply and my reply to the ebXML-MSG and ebXML-BP lists
in the hope of additional discussion.

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

*********



michael.m.ho@sybase.com on 07/06/2001 02:57:18 PM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   michael.m.ho@sybase.com
Subject:  Service and action elements



Hi Marty:

We are not clear on how the service and action elements are used within
a business collaboration. I read the minutes from the Vienna F2F meeting
and cannot come to a conclusion on the usage of these elements.

So far, it has been stated that Service refer to a set of BT and action
refers
to the BT itself. One would equate Service to the binary collaboration.
However,
this interpretation creates the following issue. If we have 2
collaborations,
A and B. Collaboration A uses collaboration B as one of its activities and
furthermore, B is the first activity within A. The CPA specifies that both
collaboration A and B (by itself) is valid between the two partners.
When collaboration A starts, we starts B and the first message from a BT
within B arrives, do we expect the Service element to carry collaboration A
or B?
If it carries the name of collaboration B, we cannot tell whether it is for
A
or B (by itself). If it carries A, does it mean that all message has A as
the
service elements? It seems that it will be better if we have a composite
name
e.g. A.B or something so we can distinguish the different activities within
A.

Perhaps our assumption that mulitple collaborations within a CPA is not
correct. But Tony seems to think that it can represent more than one
service. (see below)

Could it be that Service is a sequence of "labels" created by the author
of the BPSS and both partners uses the same list of "labels".

In the minutes below, it talks of a buy service and sell service or
buy-sell
service. It seems that the definition of either must come from one source
and both parties agree to abide by it to make any sense.

If these confusions are already addressed in other documents/specifications
we would really appreciate that you can let us know where they may be.
I search for quite some time and cannot find any. The current versions of
ebXML specifications do not clarify the confusion for us.

Thanks
Michael
Sybase eBD (e-Business Division)






Joint meeting with TRP Team (1 of 2)


We held a lengthy discussion intended to coordinate our definitions of
service and action.  Topics included how to map those terms to constituents
of the BPSS model, and whether two parties collaborate via a pair of
complementary services, e.g., buying and selling services, or share one
overall service, e.g., buy-sell.  Tony expressed a strong preference for
the first interpretation as being consistent with common usage, e.g., WSDL.
We discussed characterizing service as a set of one or more related
business transactions from BPSS, and action as a requesting business
activity or responding business activity (also from BPSS).

Service and Action

We talked about two alternative revisions as detailed in Marty's May 3,
2001 posting on "Proposal for improvements to ServiceBinding and Override
elements".    By consensus, the team preferred the first proposal ?
removing the name attribute of the ServiceBinding element and adding a
Service sub-element that has a type attribute.  We agreed to adopt that
change pending Chris' availability to update the DTD, XSD, and examples
accordingly.  [On Wednesday, we reviewed the proposal with Chris whereupon
he agreed to implement the necessary changes.]

In preparation for a joint meeting with TRP, we discussed the relationship
between CPP/CPA and TRP/BP notions of service, action, binary collaboration
and role.  It was noted that authorizing roles could serve as a filter on a
BPSS document that MAY yield a unique binary collaboration.  There was
discussion, but not consensus, about whether there should be a one-to-one
relationship between a CPP and a service.  (Your correspondent felt that it
should be possible for a CPP to represent more than on service.



Joint meeting with TRP (2 of 2)


We met again with the TRP team to revisit the terms service and action.
Scott Hinkelman presented a diagram that he and David Burdett prepared to
show the relation between those terms as conceived by the BP and TRP teams
(see Scott's May 8, 2001 posting to the TRP list on the subject of "BP/TRP
Service/Action discussion diagram in Vienna".  Following discussion of the
diagram, the approximate consensus of the TRP team seemed to be as follows:

·    Action equates to a Requesting or Responding Business Activity
·    Service is a set of related actions for a single AuthorizedRole
supported by a party

After the TP team returned to its own meeting room, we concluded that our
specification is still aligned with TRP usage and that no change to our
specification was necessitated by the discussion.