Thoughts on the specification metamodel

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

Here are some thoughts on the specification metamodel based on the recent
discussions and XML example. Some of these points are new and some amplify
points made during the recent conference calls.

The content of the specification for the XML output of the specification
metamodel must provide enough information for a vendor to build an
installation tool that can read the XML for any business process and
configure the systems of a  specific pair of partners to enable them to do
business.  Could the metamodel generate a DTD that covers any business
process?

We will need to define links between the specification layerand the rest of
the CPP/CPA to enable specific items in that layer to be referred to by the
rest of the CPP/CPA. The linking mechanism should be specified now even if
we decide defer applications of it to a later phase, to avoid complications
later.

   NOTE:  since the IBM tpaML proposal is stated as a single xml document,
   ID REF attributes are sufficient for these links.

   Example:  To be able to associate specific delivery channels with
   specific request or response messages.  This capability exists in tpaML
   based on examples in RosettaNet.

   Example:  If there are parameters in the specification layer which are
   only given values during the process of constructing a CPA from two
   CPPs, it will be necessary to refer to these parameters from the rest of
   the CPP/CPA. An example is the timing parameters. (An alternative for
   this case is to make the contents of the specification XML layer
   directly subject to the negotiation process.)

   Example:  if the specification layer xml is always in terms of roles,
   elsewhere in the CPP/CPA, the party ID for each role would have to be
   stated.  To do this, mention of a role elsewhere in the CPP/CPA must
   mean the role of the same name in the specification layer xml.

Transitions:  The Specification metamodel doesn't have a notion of
disabling a commercial transaction.  This notion is in tpaML.

   Disable is probably not needed if the choreography is strict sequential
   execution of C-Ts under control of the transition tags.

   Disable might be needed if there is ever a point at which any of several
   C-Ts can be next or if more than one can be the next one executed.

In the 11/29/00 phone call, Karsten said that the service interaction is a
set of C-Ts with no ordering implied.  If no transitions are stated, the
C-Ts can be issued in any order.

   This suggests the need for "disable" since depending on the path
   initially taken, a point may be reached where not all C-Ts are allowed.

   Is it intended that once a <Transition> is executed, it rules out all
   C-Ts except the "to" C-T?  But then, what is the state after that "to"
   C-T is executed if it doesn't have <Transition>?  (in tpaML, if an
   action does not include a sequencing rule, the enabled and disabled
   states of all the actions are unchanged.)

In the 11/29 phone call, Karsten mentioned the notion of "startpoint" as
indicating which C-T is the first in the service interaction but I didn't
see an example of this in the xml example that was distributed.

   The runtime has to know which C-T is allowed to be first so it can
   determine that the C-Ts are being issued in the correct odrder.

   Should we provide for more than one C-T to be permitted as the first
   one?  (tpaML has this notion).

   Providing for more than one C-T to be permitted as the first also
   suggests the need for disabling C-Ts.  For example, if both A and B are
   permitted as the initial C-T, then when one is issued, it might be
   necessary to disable the other one.

In the 11/29 phone call, Karsten stated that the model has no way to define
a "1-sided" interface as might be needed in a CPP to indicate "these are
the C-Ts that I accept".

   One possibility is to generate the xml for one explicit party and one
   role.

   Another possibility is to generate the xml for two roles and indicate
   elsewhere in the CPP which role the owner of the CPP plays.  This would
   require a means to assure that mention of a role elsewhere in the CPP or
   CPA means the role with the same name in the rest of the CPP/CPA.

Request:  Does the type attribute identify the DTD or schema?

A commercial transation may have multiple sequential responses, e.g. the
series of confirmation messages that are sometimes used.  Can the model
represent these intermediate responses?  Will it simply generate multiple
Response tags for these?

   If so, we will need a way to state that the responses occur in order.
   Perhaps the order can be given by the order of the Response tags.

   We will also have to distinguish sequential responses from mutually
   exclusive responses (e.g. OrderConfirmation and OrderDenied in the xml
   example that was distributed).  One possibility is to define the tag
   ExceptionResponse for exceptions rather than using Response.

Timing: tpaML defines a retry interval in response to requests from various
people in IBM.

Under the service interaction OrderCollaboration:

   Shouldn't the C-T activity "QuoteRequest" be included?

   QuoteCT identifies a commercial transaction wheras all the other C-T
   activites refer to request tags.

   The C-T activity "Order" has type "OrderCT" while the "Order" request
   has type="Order".  This is the only C-T actvity with a type attribute.
   Is the type attribute spurious here?

Synchronization was briefly discussed in the 11/29 phone call but I don't
think we were clear on this.  The case is:

   Commercial transactions A and B may be issued (logically) concurrently.
   Transaction C can be issued only when both A and B have completed
   successfully.  How is this to be expressed?  One possibility is a
   transition with two guard attributes.  "AND" between the two guards
   would be implied.

   This raises other questions: How do I express the rule that following
   C-T D, A and B can be issued logically concurrently?

   How do I express that C-T E can be issued after either A or B?  This is
   probably done simply by writing two transitions:  One whose "from" is
   A's response message; one whose "from" is B's response message.

Does the model provide "richer" choreography than shown in the XML example?
If so, what is provided?

What is the difference between BusinessCollaboration and
ServiceInteraction?

WarrantyManagementNotification:  This takes place entirely inside the
seller.  Therefore, it doesn't belong here.  The xml should define only
what goes on between two parties, not what takes place inside one party.
There could be C-Ts for RequestWarranty (buyer to seller) and SendWarranty
(seller to buyer).

Shipper interactions:  As with WarrantyMangementNotification, shipper
interactions seem to be entirely inside each party and don't belong here.
There could be a ReceivedShipment C-T which the buyer issues to the seller
after receiving the shipment.

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