RE: FW: Proposal: A Registry Browser GUI tool

[Scott Hinkelman/Austin/IBM <srh@us.ibm.com>]

David,
>Scott

>I agree with the idea of a single Party Profile consisting of many parts
for
>the (business) processes, transport protocols etc that the business
>supports.

More specifically, in the PP, all possible transport protocols are
associated
to each step/action within a supported BP. Agree on this relationship?

>This means if you are kicking off a new process without a Party
>Agreement, then you need to specify which business process, which
transport
>etc, you have selected from the options avaialble. This information IMO
just
>HAS to go in the header.

This case,
You don't need to find a Party, and you already know that he supports a
specific mutually understood BP, and you know what capabilities he has
for each step. Pushing this more, you assume he will do business with you
given the BP you indicate, and the steps/matching-technology you indicate.
(This opens discussion on common errors such as UnsupportedBP, etc)
In this case, I agree, put it in the header.

>In fact if you have a Party Agreement where everything is previously
agreed
>that support multiple processes, transports, etc, then you have the same
>problem.

>More specifically you have to either:
>1. Give a unique id to the combination of process, step, transport etc
that
>you are going to use, or (IMO a better way)

I think makes more sense if you know nothing, and need to find and
negotiate everything.

>2. Give the Party Agreement a Unique Id and then give each process, step,
>transport, etc an id that is unique within the Party Agreement.

And this makes more sense once you have reached agreement, and want to
store that agreement in a Registry for reference later (essentially
by reference in the header). I think we need both.

>Thoughts?

>David

Thanks,
Scott Hinkelman
Senior Software Engineer, IBM Austin
Emerging Technologies, SWG
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



"Burdett, David" <david.burdett@commerceone.com> on 09/21/2000 10:43:23 AM

To:   Scott Hinkelman/Austin/IBM@IBMUS
cc:   Martin W Sachs/Watson/IBM@IBMUS, Rik Drummond
      <rvd2@worldnet.att.net>, Ebxml Transport
      <ebxml-transport@lists.ebxml.org>
Subject:  RE: FW: Proposal: A Registry Browser GUI tool



Scott

I agree with the idea of a single Party Profile consisting of many parts
for
the (business) processes, transport protocols etc that the business
supports. This means if you are kicking off a new process without a Party
Agreement, then you need to specify which business process, which transport
etc, you have selected from the options avaialble. This information IMO
just
HAS to go in the header.

In fact if you have a Party Agreement where everything is previously agreed
that support multiple processes, transports, etc, then you have the same
problem.

More specifically you have to either:
1. Give a unique id to the combination of process, step, transport etc that
you are going to use, or (IMO a better way)
2. Give the Party Agreement a Unique Id and then give each process, step,
transport, etc an id that is unique within the Party Agreement.

Thoughts?

David

-----Original Message-----
From: Scott Hinkelman/Austin/IBM [mailto:srh@us.ibm.com]
Sent: Thursday, September 21, 2000 7:20 AM
To: Burdett, David
Cc: Martin W Sachs/Watson/IBM; Rik Drummond; Ebxml Transport
Subject: RE: FW: Proposal: A Registry Browser GUI tool


David,
On yesterday's TP call we discussed some invariant relationships for a
Party and a PP.
This was done as assumptions to the requirements for TP.

There was general consensus that a Party has one PP. Within that PP, there
would be things
like descriptors that describe the supported business processes. They would
point to
identifiable Business Processes, and contain technology mapping
capabilities for
each step/action (essentially roles) supported within that BP.
Note: The PP says nothing about any agreement to anything, just what
BPs are supported by a Party, and the *technology capabilities* per
steps/actions.

At the instance level of an agreement, it would reflect that for BP 1,
step3 it must be via email
for you and I. Another agreement instance may reflect for the same BP/step,
it is HTTP.

Thoughts? It would help if we, TRP, TP, BP could get agreement on some of
these
base invariants soon.

Scott Hinkelman
Senior Software Engineer, IBM Austin
Emerging Technologies, SWG
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



"Burdett, David" <david.burdett@commerceone.com> on 09/21/2000 12:41:59 AM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   Rik Drummond <rvd2@worldnet.att.net>, Ebxml Transport
      <ebxml-transport@lists.ebxml.org>
Subject:  RE: FW: Proposal: A Registry Browser GUI tool



Catching up on email ...

Party A might have to put Party B's information into the header, either by
value or by reference, because there Party B might have several alternative
profiles and Party A needs to identify which one ...

David

-----Original Message-----
From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
Sent: Friday, September 15, 2000 1:40 PM
To: Burdett, David
Cc: Rik Drummond; Ebxml Transport
Subject: RE: FW: Proposal: A Registry Browser GUI tool



OK, in this case, it's a PP instead of a PA.

Having obtained the binding information, I don't understand why Party A has
to put Party B's binding information into the header of a message to B.
What party A has to do is to configure its system to send messages to Party
B using Party B's binding information.

Do we have some mismatch as to what is in the binding information and how
it is to be used?

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/15/2000 04:00:54 PM

To:   Martin W Sachs/Watson/IBM@IBMUS, Rik Drummond <rvd2@worldnet.att.net>
cc:   Ebxml Transport <ebxml-transport@lists.ebxml.org>
Subject:  RE: FW: Proposal: A Registry Browser GUI tool



Marty said ...

>>>This [transport binding] information cannot be specified in the message
header because the
message cannot flow without a communication protocol being in place.<<<

Not necessarily. There is a use case where:

1. Party A downloads binding information about Party B using a simple URL
from a web site either Party B's web site or a registry (UDDI?)
2. Then, in the header of a message, Party A refers to or includes Party
B's
binding information as well as similar information about Party A and
specifies which bindings to use.
3. Party A sends the message to Party B

Where's the TPA (or is PA now) ?

David

-----Original Message-----
From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
Sent: Thursday, September 14, 2000 3:25 PM
To: Rik Drummond
Cc: Ebxml Transport
Subject: RE: FW: Proposal: A Registry Browser GUI tool



Expaaaaaanding:

"Bindings to specific technologies belong in the TPA."

I am using the term "bindings" to refer to the means of specifying, for
example, what communication protocol is used with the messaging service for
a given business relationship.

Assume that the messaging service can be used with more than one
communication protocol, communication security definition, etc.  What is
needed is a means of specifying the name and parameters of the
communication protocol to be used for a particular business relationship.
This information cannot be specified in the message header because the
message cannot flow without a communication protocol being in place.
Therefore, the binding must be specified somewhere outside the messaging
service.  The natural place is the TPA.  The transport section of the tpaML
specifies what communication protocol and communication security parameters
will be used for message exchanges under that TPA.

What may be needed in the messaging service specification is some kind of
abstract definition of how information is exchanged between the messaging
service and the underlying transport level.

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



*********



Rik Drummond <rvd2@worldnet.att.net> on 09/14/2000 05:40:02 PM

To:
cc:   Ebxml Transport <ebxml-transport@lists.ebxml.org>
Subject:  RE: FW: Proposal: A Registry Browser GUI tool



you might want to expand on what you mean here... best regards, rik

-----Original Message-----
From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
Sent: Thursday, September 14, 2000 4:28 PM
To: Rik Drummond
Cc: Ebxml Transport
Subject: Re: FW: Proposal: A Registry Browser GUI tool



Bindings to specific technologies belong in the TPA.

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




*********



Rik Drummond <rvd2@worldnet.att.net> on 09/14/2000 04:34:05 PM

To:   Ebxml Transport <ebxml-transport@lists.ebxml.org>
cc:
Subject:  FW: Proposal: A Registry Browser GUI tool





-----Original Message-----
From: Farrukh Najmi [mailto:Farrukh.Najmi@east.sun.com]
Sent: Thursday, September 14, 2000 3:05 PM
To: Farrukh Najmi
Cc: David RR Webber; Nicholas Kassem; ebXML poc
Subject: Re: Proposal: A Registry Browser GUI tool



In consultation with other members and having thought about the binding
issue
I have
come to think that bindings to specific technologies do not belong in the
spec at this time. I think
that an RS implementation must provide an interoperable TRP based api.

An RS implementation is free to provide any other APIs in addition to the
required TRP api as an implementation specific detail.

Farrukh Najmi wrote:

> First a correction.
>
> It is the simple layer that sits on top of the TRP layer not the other
> way around.
>
> The RS provides a technology netral interface
> to services in UML form. Binding can be defined to various technologies
> and are planned
> to be specified in the appendix of RS spec.
>
> My own RS implementation provides a Java binding that makes it completely
> obvious and simple for
> the RS client (e.g. RS Browser GUI tool) to access the RS blissfully
> ignorant of the
> underlying communication (ebXML TRP).
>
> Demonstrating the RS functionality and its interoperable interface is
> what RegRep needs to do
> for Tokyo not the simple Java binding layer. Ofcourse by that time I will
> offer the Java binding to
> RR team for acceptance in RS sppendix as just another binding to RS.
> Others are free to submit
> LDAP, SOAP, DASL whatever bindings in the same level playing field.
>
> David RR Webber wrote:
>
> > Message text written by Nicholas Kassem
> > >
> > I beg to differ. You seem to imply that ebXML TRP has some systemic
> > performance limitations precluding its' use in B2C scenarios. I don't
> > accept this assertion.
> >
> > <<<<<<<<<<<<<<<<
> >
> > No - I'm not saying that - I'm saying there's alot of overhead
> > in there that are out of place for a simple primitive interface.
> >
> > I've realized now that the TRP layer can sit on top of the
> > primitive layer.
> >
> > That way if you want to talk to the primitives via TRP - cool,
> > that will work.  But findamentally you have to be able to issue
> > the primitive calls directly too.
> >
> > Demonstrating the primitives layer is what RegRep needs to
> > do - not the TRP layer - we know that works already!
> >
> > DW.
>
> --
> Regards,
> Farrukh

--
Regards,
Farrukh