Re: Messaging Service Comment

[mwsachs@us.ibm.com]

This discussion relates to the architectural interface between the
BPspecification and the Messaging Service specification (TRP) which has to
be somewhere in the ebXML standards in order to ensure that the BP and TRP
specifications mesh together property.  The argument has been whether or
not you want to express that interface as an API at all or rather as a
simple list of functions that BP and TRP assume of each other to enable
information to flow through the stack.  Arguments also relate to whether
that interface should be normative or informative (non-normative).  In
other standards, "informative" often wins because implementers don't want
to be bound to an interface which in fact may be buried inside their
product and not visible to anyone or anything else.  Some standards use a
conceptual request-response notation which provides a compact
representation of the information which has to flow between the two
adjacent layers.

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
08/25/2000 09:34 AM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   Christopher Ferris <chris.ferris@east.sun.com>,
      ebxml-transport@lists.ebxml.org
From: Scott Hinkelman/Austin/IBM@IBMUS
Subject:  Re: Messaging Service Comment  (Document link: Martin W. Sachs)

I agree with Chris. There are other appropriate places for APIs to be
defined or live outside
of ebXML. One obvious and successful example is that of SOAP 1.1, where the
SOAP spec
defines a pure XML wire format, and the Apache Project now owns a popular
Java API (SOAP4J)
submitted as open source from IBM. This model appears to have benefit to
the industry
in whole.

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



Martin W Sachs/Watson/IBM@IBMUS on 08/24/2000 05:04:32 PM

To:   Christopher Ferris <chris.ferris@east.sun.com>
cc:   ebxml-transport@lists.ebxml.org
Subject:  Re: Messaging Service Comment



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