Re: representation of interfaces to the messaging service

[Gordon van Huizen <gvanhuiz@progress.com>]

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
> >****************************************************************************
> >*********
> >
> >
begin:vcard 
n:Van Huizen;Gordon
tel;work:510-848-1988
x-mozilla-html:TRUE
url:http://www.sonicmq.com
org:Progress Software;XML and Internet Technology
adr:;;14 Oak Park;Bedford;MA;01730;
version:2.1
email;internet:gvh@progress.com
title:Director, Product Management
fn:Gordon Van Huizen
end:vcard