RE: Registry Services, TPA formation,and TPA-Registry Responsibi liti es.

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

Forgot to copy this one to the list.

Regards,
Marty

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

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
*************************************************************************************
---------------------- Forwarded by Martin W Sachs/Watson/IBM on 09/13/2000
09:40 AM ---------------------------

Martin W Sachs
09/13/2000 09:40 AM

To:   "Burdett, David" <david.burdett@commerceone.com>
cc:
From: Martin W Sachs/Watson/IBM@IBMUS
Subject:  RE: Registry Services, TPA formation, and TPA-Registry Responsibi
      liti es.  (Document link: Martin W. Sachs)

I agree that there is a lot of value to separating the messaging definition
from the business process definition.

Bear in mind, however, that choices in one place can affect choices in the
other place.  For example, if any actions are defined as synchronous, then
(at the current state of the art), HTTP must be included in the messaging
section.  This means that people or machines composing TPAs which include
business process information must have a view of the combined business
process and messaging definitions so they are aware of any
interdependencies between choices in the two places.

Remember:  Even though ebXML is not doing any work on transport (i.e.
communications), the TPP and TPA must include transport information since
agreements are needed on transport parameters.

Regards,
Marty

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

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



"Burdett, David" <david.burdett@commerceone.com> on 09/13/2000 08:30:46 AM

To:   Martin W Sachs/Watson/IBM@IBMUS, "Moberg, Dale"
      <Dale_Moberg@stercomm.com>
cc:   ebxml-tp@lists.ebxml.org
Subject:  RE: Registry Services, TPA formation, and TPA-Registry Responsibi
      liti es.



I think there is a lot of value in separating "message service" from
"process" related profiles/agreements since I think that message services
can much more easily be negotiated automatically without human involvement.
This then also leads to the notion that, at one level, we can have
completely separate TPPs and TPAs for a Messaging Service that can then be
used or selected when negotiating a Business Process if you need to.

David

-----Original Message-----
From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
Sent: Tuesday, September 12, 2000 10:35 AM
To: Moberg, Dale
Cc: ebxml-tp@lists.ebxml.org
Subject: Re: Registry Services, TPA formation, and TPA-Registry
Responsibiliti es.



Dale,

You are raising a good set of issues to consider.  I have a few off the
cuff observations.

I view the TPF process as fundamentally outside the registry.  The
repository holds TPPs and TPAs.  A TPA can be created fromTTPs and stored
back in the repository via the registry.  TPF might be an optional service
that some registries might wish to offer but it should not be required that
all TPF take place in a registry service.

I consider that using a single ebXMLspec independently of the others is
still a valid and important objective.

You are quite right that the TPF process cannot be totally mechanical.  It
has to include interaction with the individual parties for some of the
reasons you suggest.  Of course, that interaction must be built into the
TPF process whether it is part of ther registry or external to it.

I also suggest that we consider that TPF is a subject for a later stage of
ebXML and for the time being, focus on the contents of the TPP and TPA as
static entities.  When we later start to consider TPF, we might discover
the need for additional tags to control the TPF process (i.e. automated
negotation) but these can be added as an enhancement - or we might decide
that they belong in an associated document rather than in the TPP itself.


Regards,
Marty
****************************************************************************

*********

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

*********



"Moberg, Dale" <Dale_Moberg@stercomm.com> on 09/12/2000 11:39:44 AM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   ebxml-tp@lists.ebxml.org
Subject:  Registry Services, TPA formation, and TPA-Registry Responsibiliti
      es.




I have now read the "Objectives and Scope" for the TP team,
the Registry Services drafts from Farrukh, the Registry
"Business Domain" draft, and wish to raise a question:

Let TPP= trading-partner/party-profile.
Let TPA= trading-partner/party-agreement.
Let TPF= Bilateral TPA formation process from TPPs.

Should there be a TPF that is _independent_ of the Registry?

In the "Objectives and Scope" document, point 16 says that the spec
"Harmonizes with other ebXML specifications while being able to
be used independently of them."

If this is still an objective, I think we need to consider
more use cases and also reconsider what is needed for
the service layer(s) in TPF.

I previously supplied some use cases, at least one of which does
not require registry services, except maybe to register/retrieve
TPPs.

Closely related to this issue is whether we have
both negotiation and discovery based TPFs.

Business rules applied when negotiating TPAs may not be
information that users wish to export to a registry.
I get the impression that the TPF process
is to be carried out by processes within the registry.
This would be ok if there are no "choices" involved (that is
the TPA is some purely mechanical merge of TPPs-- a macro
subsititution of roles to TP ids, for example).

But when there are, for example, multiple delivery channels, business
policies may apply to the choice among channels and may
be based on outside information about the proposed TP. For example,
a company may do a look up on DUNS number of its proposed Trading
Party to find the company's credit worthiness and then select
what channel is to be used. (Small volume, SMTP; large volume,
set up an account, password and directory for FTP, and so on.)