Subject: Re: ebXML development dependencies and TPAs
FYI
*************************************************************************************
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
*************************************************************************************
---------------------- Forwarded by Martin W Sachs/Watson/IBM on 09/06/2000
03:52 PM ---------------------------
Christopher Ferris <chris.ferris@east.sun.com> on 09/06/2000 12:03:48 PM
To: John Ibbotson/UK/IBM@IBMGB
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
Powered by
eList eXpress LLC