CPP capability model draft 19112000

["Moberg, Dale" <Dale_Moberg@stercomm.com>]

Here is an updated discussion of some ideas
for modelling capabilities in the CPP.

The major change between this version intended for
discussion Wednesday and the Tokyo version
is that the principles for matching the
MsgDocument subtree are proposed. 

(Why am I calling a subtree "MsgDocument"?
No really good reason except that the
data that pertains to message packaging
formats, message security formats, and
document types (dtds and xsds) that are
needed to be declared for interoperable
collaborations are gathered in this subtree.
So the subtree describes aspects of the
message as well as the documents. A
better name for this subtree would 
be welcome!)

(Some sample XML illustrations will
be coming later this week after it is
at least well-formed and has all the
elements indicated as needed when using the
approach described below.)

Dale Moberg

==================================================

A CPP capability item may be viewed as a sequence:

<Role,BP-Service,BP-Action,MsgDocument(),TransportList()>

[Please note that the above analysis is very tentative;
see the open question section for possible additions
or other changes.]

A CPP capability list consists of a sequence of capability items.

A CPP will contain a capability list and possibly some other
information, such as contact info and so on, that may be needed
to form a CPA but not needed for the merge/intersection/match
process at the core of constructing basic CPAs (earlier called
maximal intersections).

The preliminary, non-normative, non-optimized merge/intersection algorithm 
for computing a CPA from two CPPs is:

For each CPPitem in CPP(1)
  For each CPPitem in CPP(2)
      If ( Service(1) == Service(2) 
	and  Matches(Action(1),Action(2) )
	and  Matches(Role(1),Role(2)) 
        and  Matches(MsgDocument(1) , (MsgDocument(2)) 
	and there exists an X in TransportList(1) and Y in TransportList(2)
	     such that Connectable(X,Y) 
	     Then add capability pair to the base CPA
             else TBD (for example, save for constructing
                      gap list to aid human set up or
	              to arrange for automated bridging
	              technology such as communication hubs or
                      translation service hubs, etc.)

Preliminary Comments

The service identifiers need to be the same for a merge to occur.  A
service identitifier can be regarded as a package of actions, all
connected by some higher level grouping or context, not the concern of
the CPP. Without shared services somewhere, no business collaboration
can occur.

For actions, the merge algorithm will need to "know" how an action
matches some other action. What it means for an action to match
another is defined by BP. In simple cases, a match means that the
response action is one that is relevant to and expected for the
request action, at the business level of description.

Presumably for simple bilateral (two party) collaborations involving
only two roles, each service package will somehow specify an action
correlation table for a service. Therefore the TP group should work
with the BP group to make certain that the correlatives of actions are
specified in a form suitable for use by those modules computing a
basic CPA from CPPs.

Matching for roles should likewise be defined by the BP WG.  For
simple cases, matching roles will probably be superfluous because if
matching of actions occurs, presumably the parties will occupy the
appropriate roles. (?) The role concept may eventually be useful for
checking on more complicated collaborations involving multirole
BPs. The BP group is expected to provide dspecifications that will
clarify how the role match method is to be understood.

The most complicated matching will be required for two subtrees: the
MsgDocument subtree and the TransportList for that MsgDocument.

The MsgDocument subtree in a capability item is to provide a
declarative specification for the protocol data unit (PDU) that
transfers a document as part of a message transported between parties;
this data flow thereby implements one part of a BP. The information in
a MsgDocument subtree both characterizes the PDU structure explicitly
and also implicitly indicates the message processing capabilites
required in packaging and unpackaging documents within a message PDU.

Information contained in the MsgDocument subtree provides technical
information on how the BP service's actions are implemented. It is an
explicit goal to allow distinct MsgDocument packages for a given
action. The differences in these subtrees will reflect different
packaging options including differences in security profiles.

Otherwise put, the MsgDocument tree contains information concerning
those packaging conventions that need to be agreed upon so that a
message service layer can accept business information from an
application, put it on the wire using a transport, and have the
business data retrieved and made available to the application on the
other side. Likewise, it contains information needed to characterize
the response document.

For example,the RNIF layer of RosettaNet, the AS1 and AS2 layers of
IETF's EDIINT, and ebXML's TRP layer will all provide packaging
specifications, declaratively specified within MsgDocument capability
elements. The information in this subtree needs to indicate what is
needed for interoperability but may also include some information
needed for a runtime to configure itself to participate in the
security and packaging profiles. The way in which a middleware message
l ayer makes use of the MsgDocument information is entirely
implementation dependent.  The XML produced here can be thought of as
an exchange format between totally independent middleware
implementations that seek to operate using a shared "message/security
interoperabiity profile".

The basic principles governing the match at the MsgDocument level seem
to be as follows: The sender must be able to generate the document
format associated with the sender's request action and the receiver
must be able to parse the msgdocument format associated with the
request action; conversely, the receiver must be able to generate the
msgdocument format associated with the response action while the
original sender must be able to parse the msgdocument format
associated with the receiver's response format. When that occurs, and
the associated security apparatus is aligned, there should be
interoperability within the service, for the roles played in the
service's actions. So in setting up the msgdocument format capability
subtree, besides the actual format information used, there need to be
fields indicating whether a business process collaborator (we used to
say party here...)  can generate, parse, or both generate and parse a
given document format associated with a service's action. Then the
roles of the parties should allow us to check that the request
document can be generated by the sender and parsed by the receiver
while the response document can be generated by the receiver and
parsed by the original sender. Hope that is clear enough for starters.

The match needed for the transportation list is again probably Role or
Action relative in the following way:

Consider using HTTP as a transport.  The HTTP listener capability
(with its associated URL) will normally be in some sort of responder
role. If a URL is provided for the requester, that means that the
responder needs to be capable of sending the response to that
URL. Otherwise the response could be provided directly backf over the
same connection that the requester has opened.  So it will not be
sufficent to simply indicate in a transport list item that the
protocol uses HTTP; the specific way in which the collaborators can
use HTTP for their Roles and actions need to be matched up to assure
interoperability.

So if there are BP requirements that make use of the infamous
distinction between "synchronous" or "asynchronous" connections, there
needs to be a check whether the response action of Role(2) to the
request action of Role(1) comes back on the same or on a different TCP
connection. For asynchronous HTtp, each side would need to have
a HTTP listener. (This is what the "connectable" predicate will
analyze into.)

If an agreement is subject to a higher level BP indication (such as
reliability or asynchronous connections) presumably additional checks
need to be made on the candidate matches.

In the following XML example, the goal is to indicate what the
MsgDocument subtree might contain for a simple profile for ebXML using
S/MIME signatures. The TRP group and the Security TA subgroup will
need to agree on the suitability of these profiles. (This XML infoset
coming later in a separate file.)

By using profiles, there will no longer be an obligation to find the
"one security packaging scheme fits all" solution for ebXML. A variety
of packaging schemes for a given service's correlated actions can
exist, and specific agreements can be reached reflecting security
policies and specific risks for a given collaboration situation.

If we provide the tools needed to adapt to other current schemes as
well as future schemes responding to more complex future functionality
and requirements, the result will more likely be of continuing value.

I am hoping that Chris Ferris will come up with a transportation
subtree that might be suitable for the transportation list.

The other elements (action, service, and role) appear at present to be
simpler to capture and may not involve any subtrees at all. Maybe just
an attribute here and there to indicate constraints on the action, or
some special property of role... or service (versioning?)


/*===============================================
 Open questions Nov. 19 list.
=================================================*/

0. The above needs to be reviewed and analyzed from a variety of
relevant perspectives to make certain that the right information is
identified for the MsgDocument subtree.  The perspectives for review
and analysis include: what is needed in these subtrees for
interoperability, what is needed for profile information exchange,
what is needed to drive configuration of middleware layers, and what
is needed to ensure appropriate support for BP, TRP, RegRep, and other
ebXML specifications.


1. Will a publish/subscribe collaboration fit into the
request/response framework presumed above?

2. Are there other conversation models that resist being viewed as a
special cases (including chaining) of request/response? (Forks and
branches may cause problems; conversation patterns with these
structures have not yet been modelled in explicit BPs within ebXML as
far as I know, though the precondition/postcondition formalism
certainly would permit it.)

3. Are multi-role BPs accomodated here? What multi-role BPs exist at
present?  Any special transport constraints?

4. The role of signals and acknowledgements?  In the tpaML, request,
responses and other items were all tied together in a sequence if the
conversation included all these elements. Here we are trying to do at
most a duplex conversation (the so-called synchronous case) and
usually simplex parts of conversations (when request and response come
by separate connections).  Should signals, acks, nacks, error reports,
and message service messages just be viewed as actions within special
services?  This allows a CPA to be formed from capabilities that lack
the full feature sets (omitting a particular positive ack, for
example) Is this good or bad?  Should we add in the signal ack error
message layer as part of the document profile? It is already the most
complex? Should we shove it into the transportation subtree? Should we
create another subtree to handle these?  Do we have to enforce
standards or just come up with the base CPA at a technical
interoperability level that may not fully conform to some industry
specification "required" features?

5. Is Role needed? I think it will be useful to tell which side of the
Message and Document processing each party is on for the document
associated with each action.

6. Can there be multiple ways in which distinct MsgDocuments relate to
the same Service and Action? (For example in versioning...) Should
there be a MsgDocument list then? How to indicate that possibly
distinct transport lists go with distinct MsgDocuments? Probably
closer to a normal form the way the tuple is now.

7. Figure out how to decompose/uncouple the CTE choice from the
transportation option. CTEs only needed in SMTP, not in FTP or HTTP or
binary clean transports.

]