Re: Messaging Service Comment

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

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