RE: Messaging Service Comment

[Scott Hinkelman/Austin/IBM <srh@us.ibm.com>]

Hi Dick,
I was not under the impression that was firm. There was also discussion
about using OMG IDL.
Maybe we need to resurface for a firm concensous.
Thanks,
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



Dick Brooks <dick@8760.com> on 08/27/2000 04:58:19 PM

Please respond to dick@8760.com

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



Marty,

I believe the TR&P group decided, during a con-call two weeks ago, to
define
the MS service interface in UML. This should be sufficiently abstract to
allow implementers the freedom to implement in whatever form they desire.

Scott, I think you were on the con-call when this was decided, did I
remember this correctly?

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: mwsachs@us.ibm.com [mailto:mwsachs@us.ibm.com]
> Sent: Sunday, August 27, 2000 3:40 PM
> To: srh@us.ibm.com
> Cc: Christopher Ferris; ebxml-transport@lists.ebxml.org
> Subject: Re: Messaging Service Comment
>
>
> List-Unsubscribe:
>  <mailto:ebxml-transport-request@lists.ebxml.org?body=unsubscribe>
> List-Archive: <http://lists.ebxml.org/archives/ebxml-transport>
> List-Help: <http://lists.ebxml.org/doc/email-manage.html>,
>  <mailto:ebxml-transport-request@lists.ebxml.org?body=help>
>
> 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
>
>
>
>
>
>
>