OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-tp message

[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]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC