[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Minutes of today's conference call.
Following are the minutes of today's conference call, provided by Anne
Hendry.
The next call will be on October 18. The starting time and agenda will be
determined at next week's face to face.
Regards,
Marty
------------------------------------------------------------------------------------------------
TP Minutes
October 4th, 2000
Attendees:
Marty Sachs
Chris Ferris
Anne Hendry
Tony Weida
Dale Moberg
Sarma Vangala
Farrukh Najmi
Karsten Riemer
Next call:
10/18 - time to be decided at F2F.
Technical Editor:
Daniel Ling (in Singapore)
Comments on Requirements doc:
1) Application process is still a problem
Does it need to show what's going on internally and w/ another
partner?
MM business collaboration protocol is used to describe
interaction]
between two processes, but the TP definition will point to
the MM.
Is BP here defined as something internal to the organization?
Processes are either aware of what is being exchanged,
or are back-end processes.
Application process is too vague, business process is too
specific.
This needs to cover more than the business process.
Don't want to imply that this is only for commercial puproses.
Concept of collaborative process is correct here - has both
internal
and external aspect.
OK, so Collaborative Process replaces Application Process
- it goes beyond terms and conditions (business rules)
that are not necessarily embodied in a business process
The stuff within the model for a specific business process
is called the collaboration business process.
Does collaboration model only include the exchanges between the
business services/agents/partners? Yes.
Will include collaboration business process and rules.
Change this to Collaborative process
2) Numbering of requirements
Tony (or other) to find a better solution by next week, or leave
as it is.
3) definition #8: Service Interface
Can't prescribe how PIPs are used, but we might choose to break
out the PIPs under separate service interfaces.
Each party has one profile and when a PA is
formed,
you have only what each party agreed to do. Marty will correct.
4) Section 1.2
change security parameters to security profile (in 2nd bullet
list)
requests: not necessarily a request, as in request/reply
may be just a publish;
change to message that each party may send to another
message and request can be used interchangeably
5) security (not in document)
Some ascpects of the security might not actually be in the
document,
but may be in some sort of validation authority. We should make
sure
that what we come up with can support validation that doesn't
require
storing anything locally on disk (eg. using URI). Chris will
add.
6) should be reviewed for international trade impact? Marty to send
to Edwin Young.
7) how many phases will there be for this document?
Everything here is phase I except for this last section.
8) Should the requirements be prioritized? If so, we should make sure
they
are clearly defined.
9) Should be able to specify a RosettaNet process as well as an ebXML
process.
You should be able to point to a different animal completely for a
collaborative process and still have it work. As long as both
parties
can read it.
If TPP holds nothing but a pointer to the process definition and
assumes
that the two partners can manually agree, then ok, but if the TPP
is to
hold any semantics about the process, then that will be
problematic.
In 'TPAML' spelling out a collaborative protocol is distinct from a
description of a business process. If description of steps is in a
TPA
document then you shouldn't have to spell it out.
A TPA shall optionally have a pointer to a document that is not
ebXML specific.
TPA should be operational.
10) #6 Define how a PA may be composed from two PPs
For reusability, a TPA always consists of two TPPs - that you don't
define
the TPA before you have the TPPs. But why preclude two partners
writing a
TPA themselves? If the TPA vary in structure from the TPPs? If
the PA is
simply a concatenation of two PPs, then that should be ok. You
should be
able to extract a PA from a PP.
Look at #4 (pg 3). Should be possible to automatically extract a
PA from
a PP. Dale: not sure this will be a good thing. What if just one
PA of
a PP is agreed to? Requirement to retrieve original PP is overly
strong.
What if it's just to extract PA from a PP? OK.
Can you specify the technical requirements of a PP separately so it
can
also be reused? Def of which messages can be exchanged under what
conditions (Collaboration Protocol) shall be loosely coupled from
the
Business Protocol (technical description/document
exchange/transport)
(so you can have 1:many). This should be a phase 1 req. Business
side
should be separate (physically) from the Technical side (in a
separate document).
The messaging would be on the technical side.
11) TPP doc should be a configuration file with sufficient information
from which you can create a service interface? Yes, but not
probably
for first phase (futures). This will probably be a consequence of
how
the TP is defined anyway.
Vice Lead
---------
Don't need vice-lead right now.
Public access
-------------
+ will move the tpaML doc to the public site and point to it from IBM
DeveloperWorks so that the public can find it. It will clearly
state that tpaMP is an IBM proposal.
Architecture document:
Should we engage with someone in the Architecture group?
We should review the architecture document and during F2F
have someone craft something for their document for TP.
Otherwise it would have to be done during Tokyo.
*************************************************************************************
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
*************************************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC