summary of team meetings at ebXML San Jose Meeting

[mwsachs@us.ibm.com]

The TP team held two meetings during the ebXML San Jose meeting.  Following
is a summary of the meetings.  I have attached the draft objectives
document.

I was elected team lead;  Mike Rawlins was elected vice-lead.

Regular conference calls will be scheduled and a face-to-face team meeting
is planned for mid October at IBM Research, Hawthorne, NY.

Our specification will define both the messaging portion of a trading
partner profile and a 2-partner  TPA based on the definition of the
profile.

Our main tasks (more or less in this order) will be:

   Define objectives and scope (see attached draft)
   Define requirements
   Evaluate available technologies on which a TPA can be based (including
   but not limited to the IBM tpaML proposal).
   Define the information that must be shared between the parties to a TPA.
   Define the structure of the agreement
   Define the relations with the other ebXML technical specifications.
   Define how the trading partner information is shared
     in advance (TPA)
     Dynamically (for spontaneous e-commerce)

We created a statement of objectives (see the attachment).

We discussed how intermediaries fit into the model.  The specification will
include this type of interaction.

We discussed how the line is drawn  between what is in the TPA and the
higher  level business process information.  For its tpaML proposal, IBM
Resarch drew the line such that the run-time middleware does not look into
the message payloads.

There was some discussion of whether the discovery process itself is within
the scope of this team's work.  The extent to which other ebXML teams are
considering the discovery process was unclear to us.  We put discovery on
the futures part of the objectives with a note that it may be out of our
scope.

Karsten Reimer (BP team) described how the business protocol section of the
TPA (message names and schemas, sequencing rules) could be derived from the
ebXML metamodel.

It was pointed out that some US Government and UN recommendations regarding
trading partner agreements may be relevant to us in determining
requirements.  These are identified in the objectives document.  Copies of
some will be made available on the team web site.

Another source of requirements is the other technical teams.  All members
of this team should discuss TP requirements with the teams they represent.

Scott Hinkelman has created a UML model of the IBM tpaML TPA and will make
it available on the team web site.  All team members should become familiar
with it since we may use a UML model as our first deliverable.  See the
work plan below.

Because of the need for a deliverable specification for the Vancouver
meeting (May, 2001), we do not have the luxury of developing the
specification from the beginning.  It was suggested that we might want to
derive the detailed requirements from the IBM tpaML proposal and then
evaluate other sources of TPA requirements, such as the UN recommendations
mentioned above, against tpaML.

Deliverables:

     ebXML management has requested a list of the elements in the profile
     and TPA for the Tokyo meeting.   This could be either a textual
     document or a UML model.
     Management has requested a draft specification for the Vancouver
     meeting, close enough to final so that the approval process could
     begin shortly after Vancouver.

Scott Hinkelman proposed that the final product could be a UML model and
the resulting XMI document.  He pointed out that ebXML in general has to
come to terms with how XMI fits in and this will require some coordination
with OMG.  Mike Rawlins suggested that if we adopt this form of
deliverable, we should also include an XML instantiation of the model.

We discussed the contents of the profile/TPA.  The TPA is a system
configuration file.  It does not deal with business information (the
contents of the message payload).  It does define the names of request and
response messages (e.g. make hotel reservation, process purchase order),
identifies the message schemas and defines message sequencing rules.  In
other words, the TPA concerns itself only with those things that the TRP
messaging service can manage and enforce.  The ebXML metamodel can be used
as the source to derive the message definitions and sequencing rules.
However the TPA specification should not preclude other means of creating
this information (e.g. manually writing a TPA with an authoring tool).

We agreed on the following mission statement: Define a specification for
creating the IT part of a partner profile and a TPA, which is a combination
of two partner profiles.  The specification should facilitate automatic
configuration of a run-time system based on the contents of the TPA.

We  agreed on the following work plan:

   Requirements review (3 weeks)
   Revise TPA UML model by mid-October
     Deliverable for Tokyo
   Draft spec (work mostly in Tokyo)
     complete around Dec. 1
   Approval at Vancouver

Regards,
Marty



(See attached file: TPI Objectives & Scope.doc)

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

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

Lotus Manuscript 1.0