tomlic@MCC.COM (Chris Tomlinson) (01/09/91)
The SQL Access Group (SAG) has developed a version of RDA written in ASN.1 for their use. The most recent draft proposal from ISO used the RON. In talking with some of the members of SAG it seems that it is generally felt that RON and ROS really don't offer much of value and in fact have some limitations that make it more palitable to simply work with ASN.1, using ACSE and otherwise accessing the Presentation Services directly. 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. I would like to understand why linked operations can't be used or why it isn't more appropriate to extend the ROS to get the desired functionality. The concern is that apparently w.r.t. at least RDA, 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. In looking at the ASN.1 spec of RDA from the SAG, the specification of arguments, results, and errors are separated into choices rather than being collected together on a per operation basis. It is not clear how tools can make use of this (procedural) style of specification other than by the implicit correspondence of context specific tags for each of the arguments, results, and error types. It seems to me that one of important benefits of the RON is that it binds the corresponding argument, result, and (list of) error types together in the notion of operation. This is essentially an object-based specification approach. 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.) I would be most interested in other users views on this topic and any information as to whether there really is such a movement away from ROS and RON. I am aware that there is some work on Open Distributed Processing and thought that this was to be based on the ROS, presumably with some extensions of the RON to support some form of structural inheritance other than simply importing from other modules.
ghatak@CS.UTK.EDU (01/09/91)
Dear all, I have read Chris Tomlinson's message with interest. I beg a thousand pardon's for being so uninformed, but what is RON and what does the SAG do ? Apart from that, I feel that ROS is good, it has helped me greatly in formulating my applications over ISODE, with rosy. The demise of ROS would be a blow, unless something better takes it's place. At the moment, I am unable to make any useful comments on this issue, but I am interested in this matter. Note: The "Open Book", by Marshall Rose has said that the ROS facility is probably the most endearing facility of the ISO seven layered model or something to that effect --- so there ! Sincerely, Subhendu Ghatak
shia@dset.UUCP (Dan Shia) (02/28/91)
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