Re: representation of interfaces to the messaging service

[Henry Lowe <hlowe@omg.org>]

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
>>
>****************************************************************************
>> >*********
>> >
>> >