Issue 1719: No typecodes for abstract interfaces (obv-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: There are no typecodes for abstract interfaces. Does this mean that abstract interfaces cannot be members of structs, unions, or values? If so, I think this is a problem and we should add typecodes for abstract interfaces. Resolution: Revised Text: Actions taken: July 22, 1998: received issue Discussion: End of Annotations:===== Return-Path: Date: Wed, 22 Jul 1998 15:57:42 +0100 From: Simon Nash Reply-To: nash@hursley.ibm.com Organization: IBM To: obv-rtf@omg.org Cc: issues@omg.org Subject: Abstract interface issues 2. There are no typecodes for abstract interfaces. Does this mean that abstract interfaces cannot be members of structs, unions, or values? If so, I think this is a problem and we should add typecodes for abstract interfaces. Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Wed, 29 Jul 1998 09:59:44 -0400 To: nash@hursley.ibm.com From: Steve Vinoski Subject: Re: Abstract interface issues Cc: obv-rtf@omg.org, ab@omg.org References: <199807251147.HAA01885@boston.iona.ie> At 02:14 PM 7/28/98 +0100, Simon Nash wrote: >> What this implies is that unlike TypeCodes for any other IDL type, >> a >> TypeCode for an AIT must contain both static and **dynamic** >> information. >> As far as the existing CORBA type system goes, this is an entirely >> new >> concept, and a non-trivial one at that. >> >Isn't this exactly what happens if a runtime value is a subtype of >> its >declared type? More information is passed at runtime than is known >> at >compile time. Think of an abstract interface as (conceptually) a >union of CORBA::Object and ValueBase. We should be able to encode >> this >into a TypeCode quite easily. I agree the same thing happens at run time with valuetypes. Unfortunately, OBV in general, and abstract interfaces in particular, have seriously damaged the years of work it took to get CORBA to the point of being suitable for supporting DII- and DSI-based programs. These types of programs are required for building bridging systems between CORBA and other distributed systems, such as network management systems. Given CORBA's primary role as an integration technology (I know this may shock some OBV submitters, but CORBA is not now, and never was intended to be, just a new version of Java RMI), the fact that value types and abstract interfaces cannot be used with the DII and DSI should be enough to send it back to the Architecture Board for reconsideration. Consider how a DSI-based application works: the ORB receives a request, unmarshals the object key and operation name, and then invokes the Dynamic Implementation Routine (DIR) for the target object. The DIR uses the operation name to determine the parameter types for the operation. It puts the TypeCodes for the in and inout arguments into an NVList which it then passes to ServerRequest::arguments(). This action tells the ORB how to unmarshal the arguments. If the TypeCodes in that NVList do not accurately describe what's actually present in the on-the-wire encoding for those arguments, unmarshaling fails. Now consider what happens when either an abstract interface or a valuetype that is more derived than the formal parameter type is passed. The DSI application only knows the static types of the formal parameters, so it is incapable of telling the ORB what the actual type of the operation argument is. Oops. Because of these problems, the OBV spec should be modified to include a specific warning that DII and DSI users should avoid using valuetypes or abstract interfaces in the operation signatures for their IDL interfaces if possible. If this is not done, people are going to go "value happy" and start using these things everywhere, and then they will be very unhappy when they later discover their dynamic CORBA applications do not work with their fancy OBV-based interfaces. One way of slightly improving the DII and DSI problems would be to add Bill Janssen's "final" keyword. This would allow a valuetype to be "sealed" against further derivation. This means that the type of any argument passed for a "final" formal parameter type could never be a more-derived type. The TypeCode for such a valuetype would therefore be able to completely describe its contents. Because the requirements for TypeCodes for abstract interfaces have only begun to be investigated, and given that today is the RTF deadline and we have no proposal for this on the table, I recommend that this OBV RTF defer the abstract interface TypeCode issue so that it can be properly solved in the next go-around. I also strongly recommend that someone on the AB produce a detailed report describing all the serious problems that OBV has introduced into the CORBA spec. I would be more than happy to help produce such a report. At the very least, such a report would help us avoid damaging CORBA again with future technology adoptions, and it would also hopefully help us fix all the problems that OBV has introduced. --steve Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Thu, 30 Jul 1998 07:26:41 +1000 (EST) From: Michi Henning To: Steve Vinoski cc: nash@hursley.ibm.com, obv-rtf@omg.org, ab@omg.org Subject: Re: Abstract interface issues On Wed, 29 Jul 1998, Steve Vinoski wrote: > I also strongly recommend that someone on the AB produce a detailed report > describing all the serious problems that OBV has introduced into the CORBA > spec. I would be more than happy to help produce such a report. At the very > least, such a report would help us avoid damaging CORBA again with future > technology adoptions, and it would also hopefully help us fix all the > problems that OBV has introduced. Nah, why bother? Let's just go ahead and worry about the problems later, in the grand old tradition. After all, no-one seemed to be too upset about unimplementable interceptors, so why would anyone be upset about problems with OBV? :-( Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Date: Wed, 29 Jul 1998 17:06:01 -0700 From: "Jon Goldberg" Reply-To: goldberg@inprise.com To: Steve Vinoski CC: nash@hursley.ibm.com, ab@omg.org, obv-rtf@omg.org Subject: Re: Abstract interface issues References: <199807251147.HAA01885@boston.iona.ie> Steve Vinoski wrote: > > Consider how a DSI-based application works: the ORB receives a > request, > unmarshals the object key and operation name, and then invokes the > Dynamic > Implementation Routine (DIR) for the target object. The DIR uses the > operation name to determine the parameter types for the > operation. It puts > the TypeCodes for the in and inout arguments into an NVList which it > then > passes to ServerRequest::arguments(). This action tells the ORB how > to > unmarshal the arguments. If the TypeCodes in that NVList do not > accurately > describe what's actually present in the on-the-wire encoding for > those > arguments, unmarshaling fails. > > Now consider what happens when either an abstract interface or a > valuetype > that is more derived than the formal parameter type is passed. The > DSI > application only knows the static types of the formal parameters, so > it is > incapable of telling the ORB what the actual type of the operation > argument > is. Oops. I don't think this is quite as dire as Steve describes. If you take this from a slightly different perspective: * The DSI application is responsible for setting up the Request so the arguments can be demarshaled. Before values, the type system was limited so that all types on the wire were either of known size/shape (such as any marshaled object reference) or were fully self-describing (anys). Therefore, the DSI application has responsibility... #1. know the formal type of all parameters and inform the ORB of their size/shape by registering the typecode with the ServerRequest::arguments() * Value types have added a new animal, which is not fully self-describing (there is no typecode marshaled with each value) and is also not of a known static size. As a result, DSI applications are impacted. No longer is the static type of the formal parameter enough information for the ORB in every case. However, when the static information is not enough, the marshaled value *does* tell the receiver enough information to know what its actual type is. At this point, the traditional DSI application has only given the ORB structural information for the formal type. What else needs to happen? The DSI application would have to fulfill a new responsibility... #2. know the actual types of values that are to be supported, and register a ValueFactory with the ORB for each of these. Is this really that great of a burden? If the server is truly dynamic (such as an EventChannel), all types passed are going to be of type any regardless, so there is no issue. If the server is intended to do some local work on the value, it needs to have type information for that value anyway (to do extraction/narrowing from the populated ServerRequest::arguments()), so there isn't any new burden here either. The real issue I do see is described under Issue #1685. Let's say the intermediate DSI server is responsible for extracting the passed parameter as some base type of the value it received, without knowing information about its more derived components. Truncation allows this to work fine, since the DSI application will only register a ValueFactory for the base values of which it has knowledge. When it receives a derived but truncatable value, it will lop off the additional derived state. The real issue is if you want this DSI intermediary to then pass the value over to some other server. Consider the following: valuetype BaseVal { ... }; valuetype DerivedVal : BaseVal { ...}; interface MiddleServer { void oper(in BaseVal mb); }; interface BackendServer { void real_work(in BaseVal bb); }; OBV allows the Middle and Backend Servers to receive a DerivedVal for parameter 'b'. Let's say the MiddleServer is implemented with DSI. It wants to extract the parameter 'mb' and invoke real_work() on some BackendServer. It does *not* want truncation to occur. The derived value should be passed along intact. The BackendServer is assumed to know about the DervedVal type. If the MiddleServer only knows about BaseVal, a MARSHAL exception will be raised when trying to interpret the oper() request. For this to work properly, the MiddleServer would have to be loaded with ValueFactories (and hence implementations) of all real types. Note that the dynamic code that implements the oper() (in the dynamic servant) need not be aware of the presence of this code. It is an administrative step that the application itself must be updated so the ORB knows what to do with these types. You can even have the ORB itself dynamically update on the fly as long as you make the implementations accessible. I agree that it would be ideal if even that step were not necessary. Issue 1685 therefore remains open in the hopes that an even more transparent solution can be added to OBV. > I also strongly recommend that someone on the AB produce a detailed report > describing all the serious problems that OBV has introduced into the CORBA > spec. I would be more than happy to help produce such a report. At the very > least, such a report would help us avoid damaging CORBA again with future > technology adoptions, and it would also hopefully help us fix all the > problems that OBV has introduced. Hopefully the above example/discussion of Issue 1685 is useful. It certainly is subtle and we don't want to hide the issue from users of CORBA who are considering the applicability of OBV within their application design. On the other hand, I don't agree with the impression that the sky is caving in on us under the weight of OBV. take care, Jon Return-Path: Date: Wed, 29 Jul 1998 18:43:23 PDT Sender: Bill Janssen From: Bill Janssen To: nash@hursley.ibm.com, Steve Vinoski Subject: Re: Abstract interface issues CC: obv-rtf@omg.org, ab@omg.org References: <199807251147.HAA01885@boston.iona.ie> <199807291403.KAA19892@boston.iona.ie> Excerpts from local.omg: 29-Jul-98 Re: Abstract interface issues Steve Vinoski@iona.com (3921*) > I also strongly recommend that someone on the AB produce a detailed report > describing all the serious problems that OBV has introduced into the CORBA > spec. I would be more than happy to help produce such a report. As you all know, I share many of Steve's concerns with OBV in its present form, and its harmful effect on the CORBA type system and general architectural integrity. I, too, would be happy to contribute to such a report. Bill Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Fri, 31 Jul 1998 18:43:45 -0400 To: goldberg@inprise.com From: Steve Vinoski Subject: Re: Abstract interface issues Cc: ab@omg.org, obv-rtf@omg.org References: <199807251147.HAA01885@boston.iona.ie> [We have been experiencing significant email problems, and as a result, the following response never made it to the list, according to the ab mailing list archive. Here it is again.] At 05:06 PM 7/29/98 -0700, Jon Goldberg wrote: >I don't think this is quite as dire as Steve describes. Whether or not this is "dire" is completely subjective and is not the issue, Jon. Since you are an ardent supporter of OBV, it is no surprise that your opinion would be that I am exaggerating the issue (I was accused by one of your co-workers of the same thing for the keyword identifier mess, if you'll recall). The simple fact of the matter is that the bridging capabilities that CORBA used to offer for its whole type system have now been broken by OBV. >If you >take this from a slightly different perspective: > >* The DSI application is responsible for setting up the >Request so the arguments can be demarshaled. Before values, >the type system was limited so that all types on the wire >were either of known size/shape (such as any marshaled object >reference) or were fully self-describing (anys). Therefore, >the DSI application has responsibility... > #1. know the formal type of all parameters and inform the > ORB of their size/shape by registering the typecode > with the ServerRequest::arguments() > >* Value types have added a new animal, which is not fully >self-describing (there is no typecode marshaled with each >value) and is also not of a known static size. >As a result, DSI applications are impacted. No longer is >the static type of the formal parameter enough information >for the ORB in every case. However, when the static information >is not enough, the marshaled value *does* tell the receiver >enough information to know what its actual type is. At this >point, the traditional DSI application has only given the >ORB structural information for the formal type. What >else needs to happen? The DSI application would have to >fulfill a new responsibility... > #2. know the actual types of values that are to be > supported, and register a ValueFactory with the ORB > for each of these. > >Is this really that great of a burden? YES!!!! It is a tremendous burden for many production applications. Would you want your high-volume system that needs to be available 24x7 needing to dynamically load code just to process messages? I frankly am shocked that you would consider this to be a non-issue! There are non-trivial versioning, security, and administrative issues to solve when dealing with dynamically loading functionality, and yet you seem to make it sound like it's no big deal. >If the server is truly dynamic (such as an EventChannel), all >types passed are going to be of type any regardless, so there >is no issue. Yes, there is still an issue. If the any holds a TypeCode which describes a base type instead of the actual derived value that it holds, you have the same problem. Since some IDL compilers do not produce type-safe Any insertion operators unless given a special option, it would be quite simple for an application to accidentally insert a derived valuetype into an Any but only get a base valuetype TypeCode into the Any with it. OBV operates on the principle that sender and receiver fall into one of the following two categories: 1) Sender and receiver were developed together and they implicitly know all the types, both base and derived, that will be passed between them. 2) Sender and receiver are both capable of downloading any implementations for types that they were not originally built with. Some applications that are developed for small workgroups fall into the first category. What about applications that must operate over larger domains, such as entire business sites, or geographically-scattered business divisions? Java and perhaps Smalltalk implementations fall into the second category. What about C++ and C? Remember, CORBA is about integration. If I have a C++ server that is reliable and performs well, I should not need to convert it to Java just so my Java CORBA clients can pass valuetypes to it. >If the server is intended to do some local >work on the value, it needs to have type information for >that value anyway (to do extraction/narrowing from >the populated ServerRequest::arguments()), so there >isn't any new burden here either. Are you kidding? Sorry, but you are completely wrong there. In pre-OBV CORBA 2.2, I could send any type to a DSI-based server, and it could use the DynAny features to examine, manipulate, and even create values for any type at all by only providing a TypeCode. And I do mean *any* type. Now, with the new OBV valuetypes, TypeCodes are insufficient for this purpose -- unless a valuetype argument exactly matches its formal parameter type, a DSI program is out of luck unless it can somehow magically load an implementation for that valuetype. >The real issue I do see is described under Issue #1685. > That's yet another facet of the same problem that I would like to see addressed. >Let's say the intermediate DSI server is responsible for >extracting the passed parameter as some base type of the >value it received, without knowing information about >its more derived components. Truncation allows this to >work fine, since the DSI application will only register >a ValueFactory for the base values of which it has >knowledge. You're making two huge assumptions here: 1) That the DSI server is capable of downloading or otherwise dynamically loading implementations for the valuetypes it must be capable of receiving. As I pointed out earlier, this is an unacceptable requirement for many production servers. 2) That the formal valuetype parameters are marked truncatable so that truncation is meaningful for them. This too means that anyone who thinks there's a chance that their IDL interfaces might ever be implemented by a DSI server needs to take care to use truncatable wherever appropriate in their valuetype inheritance hierarchies. This assumption is obviously a poor one as well. >On the other hand, I don't agree with the impression >that the sky is caving in on us under the weight of OBV. I never said the sky was falling, but please don't try to make light of the fact that there is a serious problem here. As I said in my original message, it took years to get CORBA to the point of being able to support bridging fairly easily. OBV has changed that overnight. I believe the facts speak for themselves: when I raised this issue recently in the OBV RTF, one prominent submitter said, "What is bridging? I don't even know how the DSI works." --steve Return-Path: Date: Sat, 01 Aug 1998 13:30:57 -0700 From: "Jon Goldberg" Reply-To: goldberg@inprise.com To: Steve Vinoski CC: ab@omg.org, obv-rtf@omg.org Subject: Re: Abstract interface issues References: <199807251147.HAA01885@boston.iona.ie> <199807312251.SAA21124@boston.iona.ie> Hi- Thanks for re-sending your mail. I was wondering where it had gone for so long... Steve Vinoski wrote: > > [We have been experiencing significant email problems, and as a > result, the > following response never made it to the list, according to the ab > mailing > list archive. Here it is again.] > > At 05:06 PM 7/29/98 -0700, Jon Goldberg wrote: > > The simple fact of the matter is that the bridging capabilities that > CORBA > used to offer for its whole type system have now been broken by OBV. > > >If you > >take this from a slightly different perspective: > > > >* The DSI application is responsible for setting up the > >Request so the arguments can be demarshaled. Before values, > >the type system was limited so that all types on the wire > >were either of known size/shape (such as any marshaled object > >reference) or were fully self-describing (anys). Therefore, > >the DSI application has responsibility... > > #1. know the formal type of all parameters and inform the > > ORB of their size/shape by registering the typecode > > with the ServerRequest::arguments() > > > >* Value types have added a new animal, which is not fully > >self-describing (there is no typecode marshaled with each > >value) and is also not of a known static size. > >As a result, DSI applications are impacted. No longer is > >the static type of the formal parameter enough information > >for the ORB in every case. However, when the static information > >is not enough, the marshaled value *does* tell the receiver > >enough information to know what its actual type is. At this > >point, the traditional DSI application has only given the > >ORB structural information for the formal type. What > >else needs to happen? The DSI application would have to > >fulfill a new responsibility... > > #2. know the actual types of values that are to be > > supported, and register a ValueFactory with the ORB > > for each of these. > > > >Is this really that great of a burden? > > YES!!!! It is a tremendous burden for many production > applications. Would > you want your high-volume system that needs to be available 24x7 > needing to > dynamically load code just to process messages? I frankly am shocked > that > you would consider this to be a non-issue! There are non-trivial > versioning, security, and administrative issues to solve when > dealing with > dynamically loading functionality, and yet you seem to make it sound > like > it's no big deal. I claim that there will be a large class of servers that uses this dynamic loading of implementations. It is certainly non-trivial. I didn't want to give the impression that it is easy to support. But it isn't that great of a burden on the application developer! It is work for vendors to do, and once we do it our customers will have a very powerful and safe tool in their hands. In some languages (like Java) their is built-in support for this so it should be easier to provide. In other languages, we have a harder job on our hands. > >If the server is truly dynamic (such as an EventChannel), all > >types passed are going to be of type any regardless, so there > >is no issue. > > Yes, there is still an issue. If the any holds a TypeCode which > describes a > base type instead of the actual derived value that it holds, you > have the > same problem. Since some IDL compilers do not produce type-safe Any > insertion operators unless given a special option, it would be quite > simple > for an application to accidentally insert a derived valuetype into > an Any > but only get a base valuetype TypeCode into the Any with it. This scenario cannot be allowed to happen. The inserter is responsible for putting the correct typecode in the Any. If I insert a derived value using my base class inserter, it means (as you suggest) I am missing the code for my derived class type-safe Any insertion operators. At runtime, the client application will have one of the following occur: (a) truncation. This only happens if the application designer makes the value truncatable. This is probably not the common case. Regardless, the typecode and the value are in synch within the Any. (b) the client gets a marshal exception when inserting the value as a base type without any type information for the derived one. There is no difference here from the static invocation case. If I am missing the implementation (or in this case the proper generated code) my application will fail. In this case, I get the exception locally (where I attempt insertion) in the client rather than in the receiving server. An application coding error will always cause problems. In the common case (b) above, the developer discovers this error pretty quickly. It would be nice if it were a C-T error rather than a runtime one, but that isn't possible here. > OBV operates on the principle that sender and receiver fall into one of the > following two categories: > > 1) Sender and receiver were developed together and they implicitly know all > the types, both base and derived, that will be passed between them. > > 2) Sender and receiver are both capable of downloading any implementations > for types that they were not originally built with. there is a third possibility which fits well for the dynamic server you discuss below: 3) Receiver is capable of obtaining the typecode for any type it receives. It can interpret the data for this type, but knows nothing about its operations. There is no implementation, just a description of its state. > Some applications that are developed for small workgroups fall into the > first category. What about applications that must operate over larger > domains, such as entire business sites, or geographically-scattered > business divisions? > > Java and perhaps Smalltalk implementations fall into the second category. > What about C++ and C? Remember, CORBA is about integration. If I have a C++ > server that is reliable and performs well, I should not need to convert it > to Java just so my Java CORBA clients can pass valuetypes to it. I agree completely. I also know you can implement good dynamic servers in C and C++ that are reliable, perform well, and use values. > >If the server is intended to do some local > >work on the value, it needs to have type information for > >that value anyway (to do extraction/narrowing from > >the populated ServerRequest::arguments()), so there > >isn't any new burden here either. > > Are you kidding? Sorry, but you are completely wrong there. In > pre-OBV > CORBA 2.2, I could send any type to a DSI-based server, and it could > use > the DynAny features to examine, manipulate, and even create values > for any > type at all by only providing a TypeCode. And I do mean *any* type. > > Now, with the new OBV valuetypes, TypeCodes are insufficient for > this > purpose -- unless a valuetype argument exactly matches its formal > parameter > type, a DSI program is out of luck unless it can somehow magically > load an > implementation for that valuetype. TypeCodes are sufficient. It's just the typecode based on the formal parameter that is insufficient. We need a way to get the typecode for the actual parameter instead. Before valuetypes, you needed to dynamically obtain TypeCodes. To be purely dynamic, you would need to go to an Interface Repository to find the operation signature including the TypeCodes for all the formal arguments. With valuetypes as currently specified, there is a problem as you point out. Assuming DynValues do allow dynamic traversal of the value, you still need to get the typecode of the actual parameter, not the formal parameter from the operation signature. There is a hook missing to synch this up properly. This is definitely an issue, but all the information is currently in the encoding so this can work once that hook is defined. > >The real issue I do see is described under Issue #1685. > > > > That's yet another facet of the same problem that I would like to > see > addressed. > [Steve deleted and summarized the rest of my message as having two "assumptions". To be clear, only one of the following assumptions must hold for any given application. Both assumptions are not required for any given implementation of the dynamic server:] > You're making two huge assumptions here: > > 1) That the DSI server is capable of downloading or otherwise > dynamically > loading implementations for the valuetypes it must be capable of > receiving. > As I pointed out earlier, this is an unacceptable requirement for > many > production servers. Actually, it now appears simpler to me. Assuming DynValue works properly (there is probably work that needs to be done here), all that is needed is a TypeCode. As I indicate above, there needs to be a hook so that when the arguments are marshaled, the actual parameter TypeCode can be used and not the formal parameter TypeCode. This is not currently specified. The full implementation is not necessary for a truly dynamic server that doesn't actually invoke any operations on the Value but just needs to get its state. > 2) That the formal valuetype parameters are marked truncatable so that > truncation is meaningful for them. This too means that anyone who thinks > there's a chance that their IDL interfaces might ever be implemented by a > DSI server needs to take care to use truncatable wherever appropriate in > their valuetype inheritance hierarchies. This assumption is obviously a > poor one as well. This really has nothing to do with DSI. The truncation would be used by anyone who expects the receiver to have less knowledge of the type, but the derived operations/state are not necessary for correctness of the application. DSI is a special case where the receiver statically has *no* information. This probably has narrow applicability, so I don't see any further need to discuss it here. If the application is designed to use truncation, there is no issue. The more interesting case is certainly #1 above, and that's why I spent most of my last message focusing on that situation. take care, Jon