Path: utzoo!utgpu!watserv1!watmath!att!emory!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!magnus.ircc.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!dset.UUCP!shia
From: shia@dset.UUCP (Dan Shia)
Newsgroups: comp.protocols.iso.dev-environ
Subject: RE: ROSE and RON
Message-ID: <9102280535.AA24202@>
Date: 28 Feb 91 05:35:53 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 56


Chris,

Sorry about responding to your previous posting this late. I have been tied
up with our OMG submission. However, I think the information provided here
should still be valid.

>One of the limitations of the ROS that was mentioned is that there is
>no provision for a performer to issue a request "unilaterally" to the
>client.

This is NOT true. ROS allows definition of "Upward Operations", which
can be invoked by a responder. In fact, CMIS uses this capability very
extensively to support event notifications.

>I would like to understand why linked operations can't be used

Linked operation is slightly different from an Upward Operation in that
a linked operation can only be invoked while the parent operation is
being invoked. Once the parent operation is completed, a performer cannot
invoke a linked operation.

>there is movement to do away with the RON and ROS.  This seems to
>me, if it is true, to be some what of a step backwards.

I totally agree with you. ROS is such a powerful standard. It should be
used where ever possible to avoid reinventing the wheel.
The best kept secrete of the OSI community is that the combination of
ACSE and ROS can fullfil all requirements of an RPC and beyond.
Anyone who has doubt about this should contact me for more information.

>It seems to me that this promotes the development of tools
>that help automate some of the control flow of an application (e.g.,
>rosy and the various boilerplates.)

DSET Corp. has developed a comprehensive object-oriented development tool
based on ROS to do exactly what you have suggested. We can provide more
information for anyone who is interested.

>with some extensions of the RON to support some form of structural
>inheritance other than simply importing from other modules.

If you are interested in inheritance, you may want to consult with
the working draft version of "Extended Application Layer Structure" (XALS)
currently being circulated within ANSI X3T5.5 group. It defines "Application
Service Objects" (ASO) which can be used as the unit of inheritance.
However, ASO can be used only to construct a service interface (or Application
Context) of an Application Process using inheritance. The inheritance issue
of the internal behavior of an Application Process is not addressed by XALS.
In DSET we have extended XALS with a "Complex Finite State Machine" (CFSM)
to be the unit of inheritance for constructing the internal behavior of
an Application Process. Our experience shows that using inheritance can
facilitate the definition of both service interface
and internal behavior of an Applicaiton Process.

Dan