Issue 3662: IORTemplate (interceptors-rtf) Source: Oracle (Dr. Harold Carr, Ph.D., nobody) Nature: Uncategorized Issue Severity: Summary: This issue relates to a group of issues being raised in interceptors-ftf in order for interceptors to support a server activation framework. The ability of a persistent POA and an activation daemon to exchange IOR templates such that each can construct a valid object reference for the other is enable by the following IDL. /** * A value type that captures the concept of creating * object references according to a template. * * AdapterID is that part of the identity of an Object Adapter (e.g., * POA) that is independent of the server location. * This would be the same as that obtained from ServerRequestInfo. * For persistent POAs, this must be the same value each time the * server is restarted OR the POA is activated. * * Object ID is the value passed to create_reference_with_id or the equivalent * assigned in create_reference. * * Note that the ORB must provide an implementation for * ObjectTemplateFactory and register it. */ valuetype ObjectTemplate { typedef sequence<octet> AdapterID ; typedef sequence<octet> ObjectID ; AdapterID get_adapter_id() ; Object make_object( in ObjectID id ) ; factory init( in Object obj ) ; }; /** * Extend the current IORInfo API in PI as follows. */ local interface IORInfoExt : InterceptorsIDL::IORInfo { ObjectTemplate get_object_template() ; void set_object_template( in ObjectTemplate otemp ) ; } ; These extensions should be incorporated into PI as follows: - Add components_available to the IORInterceptor - Add get/set_object_template to the IORInfo interface. - Access to the object_template attribute is only valid in components_available. Resolution: Exact text to be determined as a new issue if this issue passes. Revised Text: Actions taken: May 30, 2000: received issue January 9, 2001: closed issue Discussion: End of Annotations:===== Date: Tue, 30 May 2000 08:26:18 -0700 (PDT) Message-Id: <200005301526.IAA19188@shorter.eng.sun.com> From: Harold Carr To: interceptors-ftf@omg.org.issues@omg.org Subject: IORTemplate Content-Type: text X-UIDL: #Vpd9G3d!!4G(e9)Xo!! This issue relates to a group of issues being raised in interceptors-ftf in order for interceptors to support a server activation framework. The ability of a persistent POA and an activation daemon to exchange IOR templates such that each can construct a valid object reference for the other is enable by the following IDL. /** * A value type that captures the concept of creating * object references according to a template. * * AdapterID is that part of the identity of an Object Adapter (e.g., * POA) that is independent of the server location. * This would be the same as that obtained from ServerRequestInfo. * For persistent POAs, this must be the same value each time the * server is restarted OR the POA is activated. * * Object ID is the value passed to create_reference_with_id or the equivalent * assigned in create_reference. * * Note that the ORB must provide an implementation for * ObjectTemplateFactory and register it. */ valuetype ObjectTemplate { typedef sequence AdapterID ; typedef sequence ObjectID ; AdapterID get_adapter_id() ; Object make_object( in ObjectID id ) ; factory init( in Object obj ) ; }; /** * Extend the current IORInfo API in PI as follows. */ local interface IORInfoExt : InterceptorsIDL::IORInfo { ObjectTemplate get_object_template() ; void set_object_template( in ObjectTemplate otemp ) ; } ; These extensions should be incorporated into PI as follows: - Add components_available to the IORInterceptor - Add get/set_object_template to the IORInfo interface. - Access to the object_template attribute is only valid in components_available. Date: Tue, 30 May 2000 10:33:28 -0700 (PDT) Message-Id: <200005301733.KAA29297@shorter.eng.sun.com> From: Harold Carr To: interceptors-ftf@omg.org, issues@omg.org Subject: Portable Activation Framework using Portable Interceptors Content-Type: text X-UIDL: BMhd9FO!e9BIBe9&$>e9 Jurgen, this is a discussion of issues I raised earlier, please do not make this an issue. All, OK, as promised, here are how the issues I raised relate to building a portable activation service. Please keep in mind, *THIS IS A USE-CASE*. We are *NOT* trying to standardize location/activation services. We are proposing changes/extensions to portable interceptors based on our prototype of an activation service built using portable interceptors. I've identified the portions of the service which require changes/extensions to the existing PI spec by preceding them with "PI FTF". ORBD Startup - PI FTF - ORBD is started on same port -ORBPersistentServerPort. - ORBD specifies its ORBInitializer class. - ORBDInitializer creates and registers activator reference in initial references. - ORBDInitializer creates and registers a ServerRequestInterceptor. Server Startup - PI FTF - started with PersistentServerId (passed by activator). - Activator passes appropriate ORBInitializer class. - ORBInitializer pre_init creates and registers IORInterceptor. - ORBInitializer post_init uses - ORBInitInfo::resolve_initial_references to obtain a reference to the Activator which it gives to - IORInterceptor for use during POA creation. Server POA Creation In IORInterceptor: - PI FTF - everything happens in new point: components_available. - PI FTF - need access to POA LifeSpanPolicy (to determine if - PERSISTENT). - If persistent then do the following steps. - PI FTF - get the IORTemplate associated with this POA. - Register that template with the activator. - Get the activator's template. - PI FTF - set the adapter's template to the activator's template. - Now, any references created by this POA will "point" to the activator (and contain components appropriate for the activator). - PI FTF - the IORInterceptor must be called each time a POA is (re)created to enable it to exchange information with the - activator. ORBD Server Request Interceptor - Get the adapter_id from ServerRequestInfo. - Lookup the template associated with this id. - If it doesn't exist then request is for the ORBD. - Otherwise - Get the object_id from ServerRequestInfo. - PI FTF - Use the object id to create a new reference from the - server's template. - Raise ForwardRequest. Misc - PI FTF - not explicit is the fact that Java ORBs need an ORB ID for persistent references to be unique: serverId | orbId | poa path/name. - PI FTF - when an object adapter is destroyed it notifies the activator of this fact so that the activator may reclaim resources. Cheers, Harold From: Paul Kyzivat To: "'interceptors-ftf'" Subject: RE: IORTemplate Date: Wed, 31 May 2000 16:10:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: GWcd9,;Ge9An3e98':!! Comments below Paul > From: Harold Carr [mailto:harold.carr@eng.sun.com] > * AdapterID is that part of the identity of an Object Adapter (e.g., > * POA) that is independent of the server location. > * This would be the same as that obtained from ServerRequestInfo. You seem to be making some specific assumptions here that may well not be reasonable for all orbs. - that it is reasonable and practical to embody as an octet sequence the part of the identity of an object adapter that is independent of the server location. - that it is reasonable for this value to be the same as the id obtainable from ServerRequestInfo. (I can't tell if this equivalence is important to you.) > * For persistent POAs, this must be the same value each time the > * server is restarted OR the POA is activated. > * > * Object ID is the value passed to create_reference_with_id > or the equivalent > * assigned in create_reference. > * > * Note that the ORB must provide an implementation for > * ObjectTemplateFactory and register it. > */ > > valuetype ObjectTemplate > { > typedef sequence AdapterID ; > typedef sequence ObjectID ; > > AdapterID get_adapter_id() ; > > Object make_object( in ObjectID id ) ; I don't see how make_object has enough information to do its job. It should also require a repository id. Most significant: I think this requires that I be able, in the context of one orb, to use an ObjectTemplate to make an object reference that is pointed to another server, and that the key be encoded in a way that is consistent with the way that other server will decode it. If the two servers use different orbs, then there is no reason to assume this. While the data representation of the ObjectTemplate will be shared between the two, they can't share the same implementation because it must create an object reference for the orb in which it is run. And the encoding of all the information into an object key is not standardized. Date: Thu, 01 Jun 2000 08:12:04 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: "'interceptors-ftf'" Subject: Re: IORTemplate References: <9B164B713EE9D211B6DC0090273CEEA926BEE2@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 34&e9d=Qe9Wi#!!HL9e9 Paul, Thanks for your response. You went straight to the heart of the matter: the IORTemplate. >- that it is reasonable and practical to embody as an octet sequence the >part of the identity of an object adapter that is independent of the server >location. Isn't that exactly the assumption made when the PI spec specifies OctetSeq ServerRequestInfo::adapter_id >- that it is reasonable for this value to be the same as the id obtainable >from ServerRequestInfo. (I can't tell if this equivalence is important to >you.) Yes, the design does depend on these being equivalent. When a persistent POA is created it gives its IORTemplate to the LASD which maps it: template.get_adapter_id() -> template. When a invocation arrives at the LASD it uses ServerRequestInfo::adapter_id to lookup that template so it can create the reference and raise ForwardRequest. And yes, it does seem reasonable. Why should they be different? >I don't see how make_object has enough information to do its job. >It should also require a repository id. Thanks, you are right. It is easy enough to change the signature of make_object to: Object make_object( CORBA::RepositoryId repo_id, in ObjectID id ) ; However, when an invocation arrives at the LASD, I do not see, at the moment, where to obtain this repo_id. There is one in ServerRequestInfo, but that one assumes that ones has the servant in hand (if I recall/interpret correctly) which will not be the case in an LASD. I'll have to think about this some more (suggestions welcome). >Most significant: > >I think this requires that I be able, in the context of one orb, to >use an >ObjectTemplate to make an object reference that is pointed to another >server, and that the key be encoded in a way that is consistent with >the way >that other server will decode it. > >If the two servers use different orbs, then there is no reason to >assume this. While the data representation of the ObjectTemplate >will >be shared between the two, they can't share the same implementation >because it must create an object reference for the orb in which it is >run. And the encoding of all the information into an object key is >not >standardized. First, since ObjectTemplate is a valuetype, it should be possible to download the implementation of any given instance such that the above should work. However, that said, we do not envision this kind of mixing of object templates. We would be happy to add a restriction which said something like: The ORBD and the server must use the same ORB type (ORBClass in Java). Attempting to call set_object_template with an object template created by a different ORB type would be illegal (although perhaps optional). The problem with this restriction is that it introduces the notion of ORB type, which we would like to avoid. I think there is a service context for carrying ORB type info, but we do not want to depend on it. Is there some way to restate this restriction without introducing ORB type? Or, do downloadable valuetypes make this a moot point (no restriction necessary)? Thanks again, Harold From: Paul Kyzivat To: "'interceptors-ftf'" Subject: RE: IORTemplate Date: Thu, 1 Jun 2000 18:35:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ^_,!!-?Vd9K\2e9SFld9 > From: Harold Carr [mailto:harold.carr@sun.com] > Thanks for your response. You went straight to the heart of the > matter: the IORTemplate. > > >- that it is reasonable and practical to embody as an octet > sequence the > >part of the identity of an object adapter that is > independent of the server > >location. > > Isn't that exactly the assumption made when the PI spec specifies > > OctetSeq ServerRequestInfo::adapter_id I have taken this adapter_id to be a simple key, meaningful within the server to distinguish one POA from another. It might be optimized for lookup in a map to find the adapter. It need not contain all the bits and bytes that need to go into an ior. That is a different set of bits and bytes, that need to be used in an entirely different way. Up until now, all of that information (could be many distinct pieces), could be held in the POA itself. The pieces needed to assemble an IOR can be complex, because, if there are multiple profiles, the objectid may need to be inserted in at several different places. First, it is at least inconvenient to have to encode all of this information as a sequence of octet. And the, once that has been done, it isn't likely to be very suitable as a handle for finding a POA (even though it must contain an identification of the POA in some form). > > >- that it is reasonable for this value to be the same as the > id obtainable > >from ServerRequestInfo. (I can't tell if this equivalence is > important to > >you.) > > Yes, the design does depend on these being equivalent. When a > persistent POA is created it gives its IORTemplate to the LASD which > maps it: template.get_adapter_id() -> template. When a invocation > arrives at the LASD it uses ServerRequestInfo::adapter_id to lookup > that template so it can create the reference and raise > ForwardRequest. > > And yes, it does seem reasonable. Why should they be different? I think I have explained that. > > >I don't see how make_object has enough information to do its job. > >It should also require a repository id. > > Thanks, you are right. It is easy enough to change the signature of > make_object to: > > Object make_object( CORBA::RepositoryId repo_id, in > ObjectID id > ) ; > > However, when an invocation arrives at the LASD, I do not see, at the > moment, where to obtain this repo_id. There is one in > ServerRequestInfo, but that one assumes that ones has the servant in > hand (if I recall/interpret correctly) which will not be the case in > an LASD. I'll have to think about this some more (suggestions > welcome). There aren't any good answers here because you don't have the information. Some possibilities: - in GIOP 1.2, you could reply with NEEDS_ADDRESSING_MODE and force the caller to send you a full IOR, including the repository id - you could just fill in "" as the repository id (since its optional anyway). (Of course this might not be great - the client may decide it needs to do an is_a to decide if the new IOR conforms to the same interface as the old one.) > > >Most significant: > > > >I think this requires that I be able, in the context of one > orb, to use an > >ObjectTemplate to make an object reference that is pointed to another > >server, and that the key be encoded in a way that is > consistent with the way > >that other server will decode it. > > > >If the two servers use different orbs, then there is no reason to > >assume this. While the data representation of the > ObjectTemplate will > >be shared between the two, they can't share the same implementation > >because it must create an object reference for the orb in which it is > >run. And the encoding of all the information into an object > key is not > >standardized. > > First, since ObjectTemplate is a valuetype, it should be possible to > download the implementation of any given instance such that the above > should work. Well, that might work for Java, but probably for nothing else. And what if the two orbs are for different languages? > > However, that said, we do not envision this kind of mixing of object > templates. We would be happy to add a restriction which said > something like: > > The ORBD and the server must use the same ORB type (ORBClass > in Java). Attempting to call set_object_template with an > object template created by a different ORB type would be > illegal (although perhaps optional). If you add this restriction, then I don't see the point in any of this. With the ORBD and the Server sharing an orb, they can use proprietary means to achieve this handshake. > > The problem with this restriction is that it introduces the notion > of > ORB type, which we would like to avoid. I think there is a service > context for carrying ORB type info, but we do not want to depend on > it. Is there some way to restate this restriction without > introducing > ORB type? Or, do downloadable valuetypes make this a moot point (no > restriction necessary)? I share your concern, but I don't see an ideal solution. About the best I can see is to have a fully standardized data representation for an object template. For instance, this might consist of a sequence of octet plus a set of positions in this sequence where an object id must be inserted to form a serialized IOR. (Don't yell - I realize how gross this is; it is simply brainstorming.) Paul Date: Fri, 02 Jun 2000 08:58:05 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: "'interceptors-ftf'" Subject: Re: IORTemplate References: <9B164B713EE9D211B6DC0090273CEEA926BEE8@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: a/L!!3n$e9Nd2e9ZH> OctetSeq ServerRequestInfo::adapter_id > >I have taken this adapter_id to be a simple key, meaningful within the >server to distinguish one POA from another. It might be optimized for lookup >in a map to find the adapter. > >It need not contain all the bits and bytes that need to go into an ior. >... > >First, it is at least inconvenient to have to encode all of this information >as a sequence of octet. And the, once that has been done, it isn't likely to >be very suitable as a handle for finding a POA (even though it must contain >an identification of the POA in some form). I do not think we suggested that the adapter_id contain all the bits that go into an IOR. It should just uniquely identify the Server/ORB/POA that it represents. Two other requirements: ServerRequestInfo::adapter_id and ObjectTemplate::adapter_id must be the same sequence for a given POA (i.e., Server/ORB/POA) and that this sequence should always be the same sequence for a given ServerId/OrbId/POA-path/name. I think this last point is necessary for security's use of adapter_id. If they are going to build their own maps they need assurances that they will be consistent even if server's are restarted and/or poas are destroyed/recreated. > > >I don't see how make_object has enough information to do its job. > >It should also require a repository id. > >Some possibilities: >- in GIOP 1.2, you could reply with NEEDS_ADDRESSING_MODE and force the >caller > to send you a full IOR, including the repository id As you note, NEEDS_ADDRESSING_MODE is possible but I do not think we want to go that route - note general enough and probably does not scale. > >- you could just fill in "" as the repository id (since its optional >anyway). > (Of course this might not be great - the client may decide it needs to do > an is_a to decide if the new IOR conforms to the same interface as the old >one.) Does "" mean it defaults to CORBA::Object? Anyway, just defaulting the created/forwarded reference to CORBA::Object would work. In many ORBs this would not make it back to the client. This would be handled internally as part of the invocation machinery. It could just proceed with the request without even needing to check the repoId. If it did need to check (for example, to narrow to the type the client had originally "asked" for - which implies is_a) this would in the worst case result in one message to the server whose result could then be cached. >> First, since ObjectTemplate is a valuetype, it should be possible to >> download the implementation of any given instance such that the above >> should work. > >Well, that might work for Java, but probably for nothing else. I am not a poster-boy for Java, but I think all languages have to deal with finding the implementations of valuetypes as best they can. Java just seems to win at this present moment in time in this regard. >And what if the two orbs are for different languages? This must have been a question that the people who specified valuetypes had to deal with, no? This is a general problem. However, since we are happy with the "same ORB type" restriction there is no need to pursue this. >> The ORBD and the server must use the same ORB type (ORBClass > >If you add this restriction, then I don't see the point in any of this. >With the ORBD and the Server sharing an orb, they can use proprietary means >to achieve this handshake. The point is: J2EE needs to build activation/location services on public APIs so it can use ANY conformant Java platform (rather than proprietary hooks into an implementation of those APIs). So they can share an ORB at the public interface level, not the implementation level. >> The problem with this restriction is that it introduces the notion of >> ORB type, > >I share your concern, but I don't see an ideal solution. For now we could just state the "same ORB Type" restriction but leave unspecified how that is determined. People that build ORBDs and register servers with such an ORBD would just use the same ORB, that's it. >About the best I can see is to have a fully standardized data representation >for an object template. For instance, this might consist of a sequence of >octet plus a set of positions in this sequence where an object id must be >inserted to form a serialized IOR. (Don't yell - I realize how gross this >is; it is simply brainstorming.) This seems to be necessary if you are trying to solve the above problems (i.e., downloading valuetypes, valuetypes from different languages). However, if the ORB type restriction is in place then I think the existing specification of ObjectTemplate works. Some new points: First, I have been calling the template IORTemplate in the discussion but it is named ObjectTemplate in the code. I am going to update the code to IORTemplate. Because: ObjectTemplate::make_object(...) currently returns a CORBA::Object. I think it should return an IOP::IOR. This is help future-proof this interface. Even though I am suggesting avoiding the need to download or cross-language interoperability of this valuetype for now, if one were to download an appropriate implementation then returning an IOR makes the downloaded code simpler. It is simpler because it does not need to return a CORBA::Object (which implies setting the delegate, etc., which would be different from the host ORBs delegate implementation). By returning an IOR the ORBD can then use the Codec to turn that IOR into a CORBA::Object. This would all then be local to the host ORB. So the latest is: valuetype IORTemplate { typedef sequence< octet > AdapterID ; typedef sequence< octet > ObjectID ; AdapterID get_adapter_id() ; IOP::IOR create_reference_with_id( in ObjectID id ) ; factory init( in Object obj ) ; }; Note that I also changed make_object to create_reference_with_id. This highlights (since named like the POA's operation) the fact that it does not take a repoId and will default to CORBA::Object. What do you think? Thanks, Harold From: Paul Kyzivat To: "'interceptors-ftf'" Subject: RE: IORTemplate Date: Mon, 5 Jun 2000 09:55:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: _6f!!%F^!!K1`d9eLbd9 Harold ( or Ken), Comments below. Paul > -----Original Message----- > From: Harold Carr [mailto:harold.carr@sun.com] > I do not think we suggested that the adapter_id contain all the bits > that go into an IOR. It should just uniquely identify the > Server/ORB/POA that it represents. I don't understand this. You are going to pass these templates between two servers. The receiving server must be able to create references for the original server using the information in the template. Presumable the receiving server knows essentially nothing about the the other server except what is in the template - for instance it doesn't know what profiles are to be in the ior, or what information they should contain. Hence that information must be in the template. But the only information in the template is the adapter id. So that must be where all this information resides. Or are you assuming that in reality a derived valuetype, with added attributes, will be passed, carrying this information? > Does "" mean it defaults to CORBA::Object? Not exactly. The repid in an IOR is optional - it can be "" regardless of the actual type. There was a long discussion of this in interop. I always thought the distinction between "" meaning the id was unspecified and meaning "CORBA::Object" was moot - because all types derive from type object. But Simon was all bent out of shape over this, because in their java implementation it is possible to have objects transmitted in iiop that don't derive from CORBA::Object. I don't think the distinction matters here. > Anyway, just defaulting > the created/forwarded reference to CORBA::Object would work. You might want to check with Simon on java specific issues. > In many ORBs this would not make it back to the client. This would be handled > internally as part of the invocation machinery. It could just proceed > with the request without even needing to check the repoId. If it did > need to check (for example, to narrow to the type the client had > originally "asked" for - which implies is_a) this would in the worst > case result in one message to the server whose result could then be > cached. > I am not a poster-boy for Java, but I think all languages have to deal > with finding the implementations of valuetypes as best they can. Java > just seems to win at this present moment in time in this regard. You are from Sun - you must be a poster boy for Java. :-) Realistically, we must assume that many languages will not be able to load valuetype implementations at runtime - but rather must have them linked in at build time. This presents serious problems if we predicate a design on passing specializations of valuetypes that are discovered at runtime, at least ones that are not truncatable. If you require the server and the ORBD to share an implementation, then this problem goes away. If so, you might as well declare ObjectTemplate (or IORTemplate) to be an abstract valuetype, because there is no meaningful direct implementation of it. (More below on this.) > > >And what if the two orbs are for different languages? > > This must have been a question that the people who specified > valuetypes had to deal with, no? This is a general problem. Well, I am afraid there is a lot of evidence that the people specifying valuetypes did not seriously consider these issues, but rather defined something that could be made to work with Java and gave lip service to the issues of all other languages. > > However, since we are happy with the "same ORB type" restriction > there > is no need to pursue this. > > >> The ORBD and the server must use the same ORB type > (ORBClass > > > >If you add this restriction, then I don't see the point in > any of this. > >With the ORBD and the Server sharing an orb, they can use > proprietary means > >to achieve this handshake. > > The point is: J2EE needs to build activation/location services on > public APIs so it can use ANY conformant Java platform (rather than > proprietary hooks into an implementation of those APIs). Sorry I am not plugged closely into J2EE. I don't follow the logic here. This sounds like J2EE setting arbitrary goals for itself and then asking the OMG to provide the means for meeting them. Why must it do this? Could the J2EE not require added functionality of Java ORBs, beyond what is required by the OMG? Or worst case, couldn't the CORBA Java language binding have some special requirements that aren't required for other language bindings? As things stand, you seem to be asking for added functionality in orbs of all flavors, that adds no benefit - just extra work for orb vendors. If this functionality were to be defined in a way that permitted the ORBD and the server to be provided by different vendors, and to be implemented in different languages, then there might be some point in considering it. Otherwise, this simply seems to be a topic to be addressed by J2EE and J2EE compliant java orb vendors. From: Jeffrey Mischkinsky Message-Id: <200006051543.IAA04220@wheel.dcn.davis.ca.us> Subject: Re: IORTemplate To: paulk@roguewave.com (Paul Kyzivat) Date: Mon, 5 Jun 2000 08:43:35 -0700 (PDT) Cc: interceptors-ftf@omg.org ('interceptors-ftf') In-Reply-To: <9B164B713EE9D211B6DC0090273CEEA926BEEE@bos1.noblenet.com> from "Paul Kyzivat" at Jun 05, 2000 09:55:42 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: l8>e9IRbd91;*e9J$J!! Hi, See my comments interspersed in context. cheers, jeff 'Paul Kyzivat' writes: > > Harold ( or Ken), > > Comments below. > > Paul > > Realistically, we must assume that many languages will not be able to load > valuetype implementations at runtime - but rather must have them linked in > at build time. > > This presents serious problems if we predicate a design on passing > specializations of valuetypes that are discovered at runtime, at least ones > that are not truncatable. > > If you require the server and the ORBD to share an implementation, then this > problem goes away. If so, you might as well declare ObjectTemplate (or > IORTemplate) to be an abstract valuetype, because there is no meaningful > direct implementation of it. > (More below on this.) > > > > > >And what if the two orbs are for different languages? > > > > This must have been a question that the people who specified > > valuetypes had to deal with, no? This is a general problem. > > Well, I am afraid there is a lot of evidence that the people specifying > valuetypes did not seriously consider these issues, but rather defined > something that could be made to work with Java and gave lip service to the > issues of all other languages. OK, you've finally got my attention :-) The people who specified valuetypes realized that passing implementations, discovering new implementations at runtime, dynamically loading in "new" code at runtime, and their associated "friend" issues are in general intractable problems given today's technology. What "those people" did was give lip service to Java, by acknowledging that in some languages and some environments it MIGHT be possbile to download code. It is specifically outside the scope of the CORBA specs how this is arranged. In order to POSSIBLY facilitate doing this, we put in an OPTIONAL capability for the sending side of valuetype to send a callback reference which COULD allow the receiving side to request some extra information from the sending side. This extra information MAY provide enough information for the receiving side to ask the sending side for some code, PROVIDED both sides have a (non CORBA defined, non-standard) way to send each other code. Please note that according to the CORBA standard there is no requirement that the sending side support or provide this capability. The design center for valuetypes was that implementations (as in code) were already available on the receiving side. What is provided is a standard way to register the factory on the receiving side. The assumption is that the factory is already there. We also provided a default way to name implementations, based upon repid, as part of the Java language mapping, because Java makes it relatively easy to do so. Valuetypes allow one to describe and martial state, not code, in a portable, standard way. This was made more than clear at the ORBOS presentations. (I remember standing there repeating over and over again that obv did not require and support the transmission of "viruses" in response to a series of security questions. The basis for the statement was above design center.) > Could the J2EE not require added functionality of Java ORBs, beyond what is > required by the OMG? Or worst case, couldn't the CORBA Java language binding > have some special requirements that aren't required for other language > bindings? Yes and no. Sun can if it so chooses require anything it wants of J2EE implementations. (Sun control the "brand", the trademark, licensing fees, test suites, etc.) OTOH there is an agreement between Sun and the OMG, memorialized in a series of motions and statements made by the PTC and Sun, in which Sun and the OMG agreed to work together in defining CORBA/Java language mappings. As long as Sun controls the Java core in the JDK, any changes they make to those mandatory packages, is a requirement on ALL Java implementations that Sun has "authority" over. So any parts of the Java core that specify/require CORBA related functionality is a requirement on all Java ORBs (that are subject to Sun's requirements). > As things stand, you seem to be asking for added functionality in orbs of > all flavors, that adds no benefit - just extra work for orb vendors. > > If this functionality were to be defined in a way that permitted the ORBD > and the server to be provided by different vendors, and to be implemented in > different languages, then there might be some point in considering it. > Otherwise, this simply seems to be a topic to be addressed by J2EE and J2EE > compliant java orb vendors. > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: IORTemplate Date: Mon, 5 Jun 2000 13:09:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: A\V!!5J)!!dZS!!l1ad9 > From: Jeffrey Mischkinsky [mailto:jmischki@wheel.dcn.davis.ca.us] > > > >And what if the two orbs are for different languages? > > > > > > This must have been a question that the people who specified > > > valuetypes had to deal with, no? This is a general problem. > > > > Well, I am afraid there is a lot of evidence that the > people specifying > > valuetypes did not seriously consider these issues, but > rather defined > > something that could be made to work with Java and gave lip > service to the > > issues of all other languages. > > OK, you've finally got my attention :-) Jeff - well at least I accomplished something! > > The people who specified valuetypes realized that passing > implementations, discovering new implementations at runtime, > dynamically loading in "new" code at runtime, and their associated > "friend" issues are in general intractable problems given today's technology. > > What "those people" did was give lip service to Java, by > acknowledging that in some languages and some environments it > MIGHT be possbile to download code. It is specifically outside the > scope of the CORBA specs how this is arranged. In order to POSSIBLY > facilitate doing this, we put in an OPTIONAL capability for the > sending side of valuetype to send a callback > reference which COULD allow the receiving side to request some extra > information from the sending side. This extra information MAY > provide > enough information for the receiving side to ask the sending side > for > some code, PROVIDED both sides have a (non CORBA defined, > non-standard) > way to send each other code. Please note that according to the CORBA > standard there is no requirement that the sending side > support or provide this capability. > > The design center for valuetypes was that implementations (as > in code) were already > available on the receiving side. What is provided is a standard way > to > register the factory on the receiving side. The assumption is that > the > factory is already there. We also provided a default way to name > implementations, based upon repid, as part of the Java > language mapping, because Java makes it relatively easy to do so. > > Valuetypes allow one to describe and martial state, not code, in a > portable, standard way. This was made more than clear at the ORBOS > presentations. (I remember standing there repeating over and > over again that obv did not require and support the transmission of > "viruses" in response to a series of security questions. The basis > for the statement was above design center.) Thanks for the explanation. I didn't know all of that. I have been naively assuming that the Java implementations were in fact doing (or at least capable of doing) code downloads for valuetypes. Harold's comments led me (probably erroneously) to believe Sun was assuming this capability and perhaps forgetting that wasn't something available in other languages. Your comments help me to focus my position further: the only way these template valuetypes can reasonably work is if the declared state of the valuetype carries all the bits that must go into an IOR except for ObjectId, and must also identify how those the ObjectId should be combined with those bits. Lacking any other attributes, I assumed that all this was in the AdapterId. But another approach would be to provide private attributes carrying added information. (We could probably spend quite awhile arguing about how to encode this information.) Another solution would be to declare the ObjectTemplate abstract, and fail to define any standard concrete derived type. Then the two sides must agree in some other way what type(s) can actually be passed. This will pretty much guarantee that it will only work with two from the same vendor. But I see this as a useless exercise. > > > Could the J2EE not require added functionality of Java > ORBs, beyond what is > > required by the OMG? Or worst case, couldn't the CORBA Java > language binding > > have some special requirements that aren't required for > other language > > bindings? > > Yes and no. Sun can if it so chooses require anything it wants of J2EE > implementations. (Sun control the "brand", the trademark, > licensing fees, test suites, etc.) > > OTOH there is an agreement between Sun and the OMG, memorialized in a > series of motions and statements made by the PTC and Sun, in which Sun and the > OMG agreed to work together in defining CORBA/Java language mappings. > > As long as Sun controls the Java core > in the JDK, any changes they make to those mandatory packages, is a > requirement on ALL Java implementations that Sun has "authority" over. > So any parts of the Java core that specify/require CORBA > related functionality is a requirement on all Java ORBs > (that are subject to Sun's requirements). This seems to provide Sun with sufficient capabilities without jerking other language implementations around. Paul Date: Mon, 5 Jun 2000 17:39:23 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: RE: IORTemplate To: paulk@roguewave.com Cc: interceptors-ftf@omg.org MIME-Version: 1.0 Content-MD5: 6P/nsV0HscNvoXcjNXxg2A== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: Z?Ne9ZN>!!-Z5e9"Ra!! > From: Paul Kyzivat > To: "'interceptors-ftf'" > Subject: RE: IORTemplate > MIME-Version: 1.0 > > Harold ( or Ken), > I'll be handling all of the discussion from the Sun end this week. Harold will catch up for the meeting in Oslo. > Comments below. > > Paul > > > -----Original Message----- > > From: Harold Carr [mailto:harold.carr@sun.com] > > > I do not think we suggested that the adapter_id contain all the > bits > > that go into an IOR. It should just uniquely identify the > > Server/ORB/POA that it represents. > > I don't understand this. > You are going to pass these templates between two servers. > The receiving server must be able to create references for the > original > server using the information in the template. Presumable the > receiving > server knows essentially nothing about the the other server except > what is > in the template - for instance it doesn't know what profiles are to > be in > the ior, or what information they should contain. Hence that > information > must be in the template. > > But the only information in the template is the adapter id. So that > must be > where all this information resides. > > Or are you assuming that in reality a derived valuetype, with added > attributes, will be passed, carrying this information? > This is really the assumption. As you point out below, it should be an abstract valuetype. > > Does "" mean it defaults to CORBA::Object? > > Not exactly. The repid in an IOR is optional - it can be "" regardless of > the actual type. > > There was a long discussion of this in interop. > I always thought the distinction between "" meaning the id was unspecified > and meaning "CORBA::Object" was moot - because all types derive from type > object. > But Simon was all bent out of shape over this, because in their java > implementation it is possible to have objects transmitted in iiop that don't > derive from CORBA::Object. > > I don't think the distinction matters here. > > > Anyway, just defaulting > > the created/forwarded reference to CORBA::Object would work. > > You might want to check with Simon on java specific issues. > > > In many ORBs this would not make it back to the client. This would be > handled > > internally as part of the invocation machinery. It could just proceed > > with the request without even needing to check the repoId. If it did > > need to check (for example, to narrow to the type the client had > > originally "asked" for - which implies is_a) this would in the worst > > case result in one message to the server whose result could then be > > cached. > > > I am not a poster-boy for Java, but I think all languages have to deal > > with finding the implementations of valuetypes as best they can. Java > > just seems to win at this present moment in time in this regard. > > You are from Sun - you must be a poster boy for Java. :-) > Well, there's some truth to that. But we have all worked in many languages in the past, and will probably work in many in the future (just not C++, I hope :-). And I don't believe that Java is the one true way. It's just better than other commonly available languages for a lot of applications. > Realistically, we must assume that many languages will not be able to load > valuetype implementations at runtime - but rather must have them linked in > at build time. > > This presents serious problems if we predicate a design on passing > specializations of valuetypes that are discovered at runtime, at least ones > that are not truncatable. > > If you require the server and the ORBD to share an implementation, then this > problem goes away. If so, you might as well declare ObjectTemplate (or > IORTemplate) to be an abstract valuetype, because there is no meaningful > direct implementation of it. Agreed. > (More below on this.) > > > > > >And what if the two orbs are for different languages? > > > > This must have been a question that the people who specified > > valuetypes had to deal with, no? This is a general problem. > > Well, I am afraid there is a lot of evidence that the people > specifying > valuetypes did not seriously consider these issues, but rather > defined > something that could be made to work with Java and gave lip service > to the > issues of all other languages. > > > > > However, since we are happy with the "same ORB type" restriction > there > > is no need to pursue this. > > > > >> The ORBD and the server must use the same ORB type > > (ORBClass > > > > > >If you add this restriction, then I don't see the point in > > any of this. > > >With the ORBD and the Server sharing an orb, they can use > > proprietary means > > >to achieve this handshake. > > > > The point is: J2EE needs to build activation/location services on > > public APIs so it can use ANY conformant Java platform (rather > than > > proprietary hooks into an implementation of those APIs). > > Sorry I am not plugged closely into J2EE. > I don't follow the logic here. This sounds like J2EE setting > arbitrary goals > for itself and then asking the OMG to provide the means for meeting > them. > Why must it do this? > The goals are certainly not arbitrary. Having the ability to ship a reference implementation of J2EE on a completely standard CORBA ORB is a sound goal for many reasons. We are trying to standardize this through the OMG, since the OMG is the only forum for CORBA related standards. > Could the J2EE not require added functionality of Java ORBs, beyond what is > required by the OMG? Or worst case, couldn't the CORBA Java language binding > have some special requirements that aren't required for other language > bindings? > I don't see this as part of the Java language mapping, but yes, specific requirements could be added for Java ORBs. The OMG is the forum where we develop all CORBA related standards, Java or otherwise. > As things stand, you seem to be asking for added functionality in orbs of > all flavors, that adds no benefit - just extra work for orb vendors. > > If this functionality were to be defined in a way that permitted the ORBD > and the server to be provided by different vendors, and to be implemented in > different languages, then there might be some point in considering it. > Otherwise, this simply seems to be a topic to be addressed by J2EE and J2EE > compliant java orb vendors. > Standardizing the server activation framework to the extent that different ORBDs and servers can interoperate is an interesting project, but it is beyond the scope of our proposal. Our only goal is to be able to ship the J2EE RI on a standard Java ORB. Ken.