Re: Messaging Service Comment

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

Dick/All,

During last weeks call, Gordon agreed to develop a strawdog
for a UML model of the "Service Interface" which he would
submit to the list for review prior to the f2f in Dallas.
I also agreed that we could devote a couple of hours for
Gordon to present the model to the rest of the team which
would be followed by a brief discussion.

The goal of this would be to garner support for a new
subteam to be formed which would continue the work
begun by Gordon.

Chris

Dick Brooks wrote:
> 
> 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
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >

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