Re: FW: Proposal: A Registry Browser GUI tool

[Christopher Ferris <chris.ferris@east.sun.com>]

seems reasonable to me...

Scott Hinkelman/Austin/IBM wrote:
> 
> 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

-- 
    _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903