RE: Messaging Service Comment

[Dick Brooks <dick@8760.com>]

Scott,

You're right, I remember agreeing to the use of UML for consistency with
other groups, but I'm not sure there was a hum of consensus for this
approach.

Rik/Chris, could we have an agenda item on this weeks con-call to address
the abstract service interface issue.

Thanks,

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: Scott Hinkelman/Austin/IBM [mailto:srh@us.ibm.com]
> Sent: Sunday, August 27, 2000 5:45 PM
> To: Dick Brooks
> Cc: Martin W Sachs/Watson/IBM; Christopher Ferris;
> ebxml-transport@lists.ebxml.org
> Subject: RE: Messaging Service Comment
>
>
> 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
> >
> >
> >
> >
> >
> >
> >
>
>
>