Re: Messaging Service Comment

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

Marty,

Agreed, but for a broker, a typical name resolution scheme
such as DNS or THTTP could be employed in the absense of a
specific TPA.

Chris

mwsachs@us.ibm.com wrote:
> 
> In the IBM tpaML proposal and the prototype run-time, the name resolution
> is in the TPA itself.  Each party is identified by the logical name (e.g.
> DUNS number).  In the communication section, the communication address is
> given and there is an ID REF to the tag that contains the logical name of
> the party.
> 
> 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
> *************************************************************************************
> 
> Christopher Ferris <chris.ferris@east.sun.com> on 08/23/2000 02:24:08 PM
> 
> To:   Martin W Sachs/Watson/IBM@IBMUS
> cc:   ebxml-transport@lists.ebxml.org
> Subject:  Re: Messaging Service Comment
> 
> In a way, I concur with Marty's assessment. However, it would
> seem to me that rather than an "interface" definition (eg API)
> that it is important that we ensure that all of the requisite
> information is present, either in the headers themselves or
> in the associated TPA to enable an implementation to perform
> the necessary magic.
> 
> An example, the use of a "logical" To address. This must be mapped
> to an appropriate URL (for HTTP), email address (for SMTP), etc.
> We shouldn't need to provide an interface to a name resolution
> service (such as DNS or THTTP). This is strictly implementation
> detail. We shouldn't even suggest where this name resolution should
> take place (within the MS or within the communication service
> implementation.
> 
> It would seem to me that the appropriate place for this sort of
> thing might be OMG, Apache or as a JCP JSR (JAXP?) for Java
> implementations.
> I would expect that most providers of an ebXML TR&P MS would provide
> both the MS and the CS (communication service adaptors). If someone
> were to develop a standalone MS with a well defined API for the CS
> adaptors,
> that might be a good thing, but I don't believe that it is in our
> charter to do so.
> 
> The POC demos are providing us with valuable feedback as to whether
> we're providing all of the requisite bits in the headers and/or TPA
> such that a provider can effectively develop an interoperable
> implementation. I think that thus far, we're on track in that regard.
> If not, then we must work with them to understand what their perceived
> needs are and figure out how they can and should be mapped to either
> the headers or the TPA.
> 
> As for the service interface between the MS and the "application",
> I feel that too is outside our charter. Yes, it would be a good thing
> if there were a standard by which all MS implementations were developed,
> but again, OMG, Apache or elsewhere would seem to me to be a more suitable
> choice for this manner of standards development.
> 
> Possibly, we should be working with one of these (or other) organizations
> towards
> this end. However, let's not lose sight of the prime objective here.
> The interoperability we seek with ebXML is focused on inter-enterprise
> interoperability. This is acheived by defining the headers and the TPA,
> not a set of APIs which would allow for an enterprise to exchange
> implementations
> without having to do much in the way of reengineering. YES, that is a good
> thing to have (eventually) but it is NOT a requirement for enabling
> interoperable exchange of messages between enterprises, small or large.
> 
> My $0.02,
> 
> Chris
> 
> mwsachs@us.ibm.com wrote:
> >
> > Again, sorry about the deadline.  This comment belongs on the work list,
> > not as a correction to the current version.
> >
> > Some of the dicussions about interrelations between Reliable Messaging
> and
> > transport protocols point up the need to state the assumptions about the
> > transport function in some manner.  One possibility is some kind of
> > definition of a conceptual interface between the Messaging Service and
> the
> > transport function.  It's fine to say that the messaging service is
> > agnostic to the transport protocol but in real life, the Messaging
> Service
> > run-time must interact with the transport run-time. Design of the
> messaging
> > service protocol must be with the understanding of what goes on in the
> most
> > likely transports.
> >
> > Since it is highly likely that an implementation will include both the
> > messaging service and the transport function, it may be sufficient to
> > express the interactions as a series of informative notes (or an
> > informative appendix) rather than as a formal interface definition. The
> > important point is that the assumptions have to be stated to ensure that
> > the messaging service and transport function will work together
> correctly.
> >
> > 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
> >
> *************************************************************************************
> 
> --
>     _/_/_/_/ _/    _/ _/    _/ 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

-- 
    _/_/_/_/ _/    _/ _/    _/ 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