[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: FW: Proposal: A Registry Browser GUI tool
Chris
You make an important, but fine distinction.
I think that a first party, by putting a PP in a registry, implies that a
second party that sends the first party a message that complies with the
terms in the first party's PP either:
1. will be unconditionally processed and accepted, (which I think is what
you are suggesting), or
2. may be processed if the first party finds the request acceptable (which
is what I would suggest).
Reallistically either *could* be true and maybe the PP should indicate which
applies.
Thoughts?
David
-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@East.Sun.COM]
Sent: Monday, September 25, 2000 9:10 AM
To: Ebxml Transport
Subject: Re: FW: Proposal: A Registry Browser GUI tool
Actually, there is an implicit agreement in place BEFORE the
first message is sent. By advertising a PP in a registry which
intimates that any party may use it is an IMPLIED PA. The party
which sends the first message (along with its PP) also has an
IMPLIED PA because by the very act of sending a PP to party A
it is stating that it AGREES to abide by the PP of party A
so long as party A abides by B's PP which accompanies the
original message.
Chris
Martin W Sachs/Watson/IBM wrote:
>
> Scott,
>
> I'm not sure what opposing view you are referring to. In the last
exchange
> between David and me, David indicated that Party A could obtain Party B's
> PP from a register and send B a message containing the bindings for B to
> use in communicating with A. Skipping the intermediate steps, I believe
> that David and I are agreed that the message from A to B is sent without a
> prior agreement and once B replies to A, an implicit agreement has taken
> place.
>
> 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
>
****************************************************************************
*********
>
> Scott Hinkelman/Austin/IBM@IBMUS on 09/24/2000 06:35:55 PM
>
> To: "Burdett, David" <david.burdett@commerceone.com>
> 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
>
> David,
> Yep. Some messages are sent without an agreement. It does however make me
> think
> on the need to rank technology bindings (below).
>
> Marty,
> I'm somewhat confused on what I indicated to be an opposing
> view..............?
>
> All,
> what is in my head now on the base PP/Spontaneous Business relationships
> are:
>
> -> A Party has one PartyProfile.
> That PP *may* be registered into a Registry. We may consider
> defining an InfrastructureBusinessProcess with specific technology for
> obtaining
> a PP directly from a Party once you know of the business. Results of this
> request could be "here is my PP", "I maintain my PP in this Registry, so
go
> here",
> etc.
>
> -> A PartyProfile contains one BusinessProcessCollection. I'm suggesting
> this as an
> explicit entity in order to keep the supported BusinessProcesses within
one
> containment
> in the Profile, in order keep the door open for a Party to present other
> information in the
> Profile not related to BusinessProcesses.
>
> -> The BusinessProcessCollection contains BusinessProcessDescriptors.
> A BusinessProcessDesciptor contains one reference to an
> IdentifiableBusinessProcess,
> which could be a reference into a Registry for a RegisteredBusinessProcess
> (default), or
> some user-defined way (same issue as Partyid and URI default).
> A BusinessProcessDescriptor also contains a list of steps/actions that the
> business
> supports within that IdentifiableBusinessProcess. Each supported
> step/action contains
> a list of technology capabilities (perhaps ranked to support spontaneous
> business
> invocation success likelihood) that indicate what *can* be used, not what
> *will* be used.
> None of this is an agreement, and all of it is associated with a Party.
>
> Further, we would define several more InfrastructureBusinessProcesses to
> facilitate
> "coming to an IdentifiableAgreement" instance (which *may* be registered
in
> a Registry or held
> privately as long as its identity makes sense to the involved Parties)
> to be used for future business transactions between those specific
Parties.
> (This leads to more thought on required underlying
> InfrastructureCommonErrors, etc....)
>
> Thoughts?
>
> 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/24/2000 11:03:46 AM
>
> To: Martin W Sachs/Watson/IBM@IBMUS, Scott Hinkelman/Austin/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
>
> I agree Marty, agreement is reached when B returns a message back to A.
The
> key point is though that some messages are being sent *before* there is
any
> agreement.
>
> David
>
> -----Original Message-----
> From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
> Sent: Saturday, September 23, 2000 1:30 PM
> To: Scott Hinkelman/Austin/IBM
> Cc: Burdett, David; Rik Drummond; Ebxml Transport
> Subject: RE: FW: Proposal: A Registry Browser GUI tool
>
> I agree with David on this one. Even in a single profile, there could be
> different technology bindings for different processes or alternative
> bindings for the same processes. This is the reason that the tpaML
> proposal has multiple delivery channels.
>
> In David's scenario, there is no prior agreement. However the function of
> the agreement is performed by B including the selected binding information
> of Party A in its first message to A. There is even a modicum of
> negotiation here because A certainly has the option of rejecting that
> message for whatever reason.
>
> What we are really doing here is beginning the negotiation of the details
> in the PPs and the protocol for using them.
>
> 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
>
****************************************************************************
>
> *********
>
> Scott Hinkelman
> 09/21/2000 10:19 AM
>
> To: "Burdett, David" <david.burdett@commerceone.com>
> cc: Martin W Sachs/Watson/IBM@IBMUS, Rik Drummond
> <rvd2@worldnet.att.net>, Ebxml Transport
> <ebxml-transport@lists.ebxml.org>
> From: Scott Hinkelman/Austin/IBM@IBMUS
> Subject: RE: FW: Proposal: A Registry Browser GUI tool (Document link:
> Martin W. Sachs)
>
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC