OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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
TPA spans both MS and BP, and the MS UML effort must address TPA in the
The tpaUML submission is available upon request (since the internal web
are apparently hosed). The submission package is 2.5 MB, and does not
Rational Rose to view it.

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
Subject:  Re: representation of interfaces to the messaging service


Yes, I remember you volunteered for a strawman UML service interface.
I'm 100% for it.

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.
>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
>> >which I have seen referred to as the OSI interface model. It is
>> >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
>> >   Confirm:  BOTTOM conveys the results of one or more service requests
>> >   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
>> >that the BP-TRP interface will have to be in UML to mesh with the BP
>> >model. This OSI interface representation is not anywhere as rich as UML
>> >it is a compact easily understood representation.  If we use a UML
>> >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

>> >*********
>> >
>> >

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC