TP teleconference minutes - Feb. 28, 2001

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

Here are Tony Weida's minutes of the Feb. 28 conference call, with a few
minor additions by me.

Regards,
Marty


Attendees:

Jamie Clark
Dale Moberg
Becky Reed
Marty Sachs
Tony Weida


Becky is working on the new FTP definition to be finalized by Friday night.

Dale noted that the Security team has a teleconference going on at the same
time as our call.

Marty reminded us of concerns he has about send capabilities (for details
of
this and other items, see his Feb. 26 listserv posting on "CPA-CPP ver.
0.92
distributed today").  First, send properties are tied to specific receive
protocols.  According to Marty, Chris thought that was okay.  Also,
SendingProtocol is a child of Transport.  Dale responded that he put it
there to aid CPA negotiation based on CPPs. We decided to leave the send
capabilities as is.

Dale agreed with Marty that the cardinality for SendingProtocol in a CPA is
exactly one.

Tony accepted an action item to contact Chris and settle with him on the
mechanism for validating references to process specifications. One specific
issue is whether there should be separate digests of the
Process-Specification
Documents or whether they should be included within the overall signature
of the CPP or CPA.

Marty raise the question of whether a Packaging element is needed under
Override elements and reported that Chris thought it unnecessary, that
overrides should have packaging requirements in common with their
ServiceBinding.

Marty pointed out that the DTD specifies the cardinality of the Packaging
element as one or more, but the text of our spec says exactly one.
Conclusion: TBD.

Marty asked about the cardinality of the triplet of child elements under
Packaging.  Action item: Marty will discuss this with Dale.

Tony questioned whether validation of ProcessSpecification references (via
digests) should be done on an all-or-nothing basis.  After some discussion,
it was agreed for phase one (at least) that if any ProcessSpecification
reference is found to be invalid, the whole CPA is to be considered
invalid.
Depending on the outcome of discussions between Tony and Chris, this
relates
to the ProcessSpecification and/or Signature elements.

Marty pointed out that if a pair of Parties doing business under multiple
business processes wishes to be able to modify a single
Process-Specification
document without interrupting business under the others, they should create
a sepaate CPA for that process.  It was noted that when a CPA references
multiple Process-Specification Documents, it should be assumed that those
processes are interrelated and invalidating the CPA and all of the Process-
Specification documents when a problem develops with one of them is the
correct action from a business viewpoint.


Marty noted (at
least) two cases where Parties might wish to test wether invalidation has
occurred:

1. When constructing a CPA from CPPs, the CPPs and the referenced Process
Specification Documents could be tested to see if anything has changed
since the CPP was constructed.

2. Once the CPA has been installed, the Parties might want periodically
to test it and the referenced Process-Specification Documents for validity.
It was observed that when a CPA and the referenced Process-Specification
documents are installed in a system, the information in them is generally
digested by the installation tool and the original documents are not
actively involved in runtime operations.  So the Parties are doing business
based on the state of the CPA and Process Specification documents when they
were installed and changes to these documents do not affect ongoing
operations
unless and until they have to be reinstalled.

It was agreed that our document should discuss when ProcessSpecification
references may be "cached" and when they may be checked for validity.

Jamie noted that the Specification Schema team is making a couple of key
assumptions regarding collaborations:

1. There can be infinite nesting of collaborations

2. Multi-party collaborations can always be reduced to sets of binary
collaborations, each with a separate CPA

Marty agreed that proceeding along the lines of #2 is consistent with the
current state of the art in CPA processing.

There will be no teleconference next week; our next meeting is scheduled
for
March 14.

Respectfully submitted,
Tony Weida


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

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