RE: ebXML development dependencies and TPAs

["Burdett, David" <david.burdett@commerceone.com>]

I think we're all in agreement on this ;)

David

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
Sent: Wednesday, September 06, 2000 9:04 AM
To: john_ibbotson@uk.ibm.com
Cc: ebxml-transport@lists.ebxml.org
Subject: Re: ebXML development dependencies and TPAs


I concur with John.

Chris

john_ibbotson@uk.ibm.com wrote:
> 
> I agree that doing both in parallel is the best plan. Both teams can then
> test the assumptions made by the other.
> For now, the TPA representation in UML will be the best appoach since it
> allows us to concentrate on the contents of a TPA rather than get bogged
> down in religious debates on XML syntax. Once the model is agreed then an
> XML rendering is trivial.
> John
> 
> MQSeries Technical Strategy & Planning,
> IBM UK Ltd, Hursley Park,
> Winchester, SO21 2JN
> 
> Tel: +44 (0)1962 815188
> Fax: +44 (0)1962 816898
> Notes Id: John Ibbotson/UK/IBM
> email: john_ibbotson@uk.ibm.com
> 
> richard drummond <rvd2@worldnet.att.net> on 09/06/2000 02:31:27 AM
> 
> Please respond to richard drummond <rvd2@worldnet.att.net>
> 
> To:
> cc:   ebxml-transport@lists.ebxml.org (bcc: John Ibbotson/UK/IBM)
> Subject:  RE: ebXML development dependencies and TPAs
> 
> my take would be to do them in parallel, by having marty and scott list
the
> parameters they think each team needs in the tpa. that way we can easily
> determine where the over lap is... how about that for a solution?   rik
> 
> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Tuesday, September 05, 2000 8:11 PM
> To: 'Martin W Sachs/Watson/IBM'
> Cc: ebxml-transport@lists.ebxml.org; ebxml-tp@lists.ebxml.org
> Subject: RE: ebXML development dependencies and TPAs
> 
> I agree as long as we recognize that there may be significant re-work.
It's
> all really a question of balance. You want to make progress, but you don't
> want to have to re-do work because of other dependencies.
> 
> David
> 
> -----Original Message-----
> From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
> Sent: Tuesday, September 05, 2000 3:44 PM
> To: Burdett, David
> Cc: ebxml-transport@lists.ebxml.org; ebxml-tp@lists.ebxml.org
> Subject: Re: ebXML development dependencies and TPAs
> 
> David,
> 
> On the other hand, thinking about what goes in the TPA may provide insight
> as to what belongs in the messaging service specification and its upper
and
> lower interfaces.  Doing the messaging service and TPA in parallel should
> provide useful feedback between the two teams.
> 
> 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
>
****************************************************************************
> 
> *********
> 
> "Burdett, David" <david.burdett@commerceone.com> on 09/05/2000 06:13:34 PM
> 
> To:   ebxml-transport@lists.ebxml.org
> cc:
> Subject:  ebXML development dependencies and TPAs
> 
> Scott/Marty
> 
> I'm not sure of the benefit of developing tpaUML now as I think it is too
> soon and will need to change because of dependencies on other work we do.
> My
> take on thes dependencies are as follows ...
> 
> 1. Two parties need to know information about each another before they can
> carry out ecommerce.
> 2. The information they need to know is, at least partly, dependent on the
> specifications that ebXML is developing especially for TRP and BP.
> 3. The information contained in the TPA is dependent on the information
> that
> needs to be shared.
> 
> So I conclude that we can't define what goes in a TPA until we have gone
> much further in defining our specs.
> 
> Does this argument make sense? Am I missing something?
> 
> If my argument makes sense we should focus on our ebXML specs first since
> it
> is the first dependency.
> 
> David
> 
> -----Original Message-----
> From: Scott Hinkelman/Austin/IBM [mailto:srh@us.ibm.com]
> Sent: Wednesday, August 30, 2000 11:52 AM
> To: ebxml-transport@lists.ebxml.org
> Subject: Re: representation of interfaces to the messaging service
> 
> Now that this is going to happen in UML, beware that we are beginning work
> in the
> BP team to integrate *tpaUML* (the UML rendering for tpaML) with the BP
UML
> MetaModel.
> TPA spans both MS and BP, and the MS UML effort must address TPA in the
> model.
> The tpaUML submission is available upon request (since the internal web
> pages
> are apparently hosed). The submission package is 2.5 MB, and does not
> require
> Rational Rose to view it.
> 
> 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
> 
> Henry Lowe <hlowe@omg.org> on 08/30/2000 01:25:08 PM
> 
> To:   ebxml-transport@lists.ebxml.org
> cc:
> Subject:  Re: representation of interfaces to the messaging service
> 
> Gordon,
> 
> Yes, I remember you volunteered for a strawman UML service interface.
> I'm 100% for it.
> 
> Henry
> -------------------------------------
> At 08:47 AM 08/30/2000 -0700, Gordon van Huizen wrote:
> >Hi Henry,
> >
> >The current plan is to develop the service interface in UML. I'm hoping
> >to provide a strawman service interface at the Dallas face-to-face,
> >unless tomorrow's con call results in a revised plan or orientation for
> >developing the interface portion of the spec.
> >
> >The discussions regarding layering are useful, though, toward the goal
> >of a cleanly defined interface with well understood factoring of the
> >service interface and transport issues.
> >
> >-gvh-
> >
> >Henry Lowe wrote:
> >>
> >> Marty,
> >>
> >> As a former OSI type, this is the sort of think I was thinking
> >> of when I mentioned the use of a conceptual interface (I/F).
> >> However,
> >> 1. you need to add parameters to the primitives (afraid I'd have
> >>    to look at an old document to see exactly how we used to do it,
> >>    and
> >> 2. this notation only deals with events which involved a protocol
> >>    exchange, i.e., it doesn't cover (what we used to call "local")
> >>    events which don't cause protocol to be sent or result from
> >>    protocol being received.
> >>
> >> Item 2 would have to be dealt with for ebXML, IMHO.  It is usable,
> >> however, and can be extended to cover local events where necessary.
> >>
> >> Rather than start using the OSI approach (which after all, has its
> >> origins in the late 1970's), I would support your second suggestion
> >> of using UML as it's richer (and also being used by the BP folk as
> >> I understand).
> >>
> >> Best regards,
> >> Henry
> >> ------------------------------------------
> >> At 10:21 AM 08/30/2000 -0400, mwsachs@us.ibm.com wrote:
> >> >There is an inter-layer interface representation that some standards
> use,
> >> >which I have seen referred to as the OSI interface model. It is
> considered
> >> >to be technology and implementation independent and definitely won't
be
> >> >confused with an API. It is expressed in natural language.
> >> >
> >> >Consider a 2-layer structure, TOP and BOTTOM.  The conceptual
interface
> >> >between the TOP and BOTTOM is expressed in terms of four primitives:
> >> >
> >> >   Request:  TOP makes a request to BOTTOM for a specified service.
> >> >   Indication:  BOTTOM sends a particular signal to TOP
> >> >   Response:  TOP sends the results of the previous Indication to
> BOTTOM.
> >> >   Confirm:  BOTTOM conveys the results of one or more service
requests
> to
> >> >   TOP.
> >> >
> >> >The specific request, etc. and the name of the "sending" level are
> >> >concatenated to the primitive name thus: TOP_Data.Request.
> >> >
> >> >Text associated with the primitive specifies the characteristics of
the
> >> >primitive, such as when generated, effect on receipt, and status.
> >> >
> >> >Associated with naming the primitive is a brief description of the
> >> >semantics (typically one sentence).
> >> >
> >> >Examples of this are in the ANSI Fibre Channel Physical and Signaling
> >> >Interface specification which I unfortunately have only on paper.
> >> >
> >> >I mention this only to add to the spectrum of choice.  It is highly
> likely
> >> >that the BP-TRP interface will have to be in UML to mesh with the BP
> meta
> >> >model. This OSI interface representation is not anywhere as rich as
UML
> but
> >> >it is a compact easily understood representation.  If we use a UML
> model,
> >> >we will certainly have to add the same kind of explanatory text.
> >> >
> >> >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