Issue 3626: CORBA as a layer in layered systems (interceptors-rtf) Source: Oracle (Dr. Harold Carr, Ph.D., nobody) Nature: Uncategorized Issue Severity: Summary: It seems that most people are saying that the "services are ORB-scoped, that's just the way CORBA works - end of story. But I think it would be beneficial to consider what that implies to the application program and to situations where CORBA is embedded in other frameworks. Here is the general problem: ORB orbX = ORB.init(...); Foo ref1 = // get a ref that somehow ends up with a different orb Foo ref2 = // ditto someService1 = // get service which somehow ends up with a different orb someService2 = // ditto someService1.begin(); someService2.begin(); ref1.bar(...); ref2.bar(...); someOtherProcedure(...); someService1.end(); someService2.end(); The workarounds of getting all the refs into the same ORB-scope as the service is complicated when multiple services are involved. How does one get the services to be in the same ORB-scope? It is also complicated when one calls subroutines which may use refs with other orbs that should participate in the service. If one doesn't own the code then they cannot change the code to change the ref's scope. Resolution: Close issue. No Change. Revised Text: Actions taken: May 19, 2000: received issue January 9, 2001: closed issue Discussion: End of Annotations:===== Date: Fri, 19 May 2000 10:48:39 -0700 (PDT) Message-Id: <200005191748.KAA03174@shorter.eng.sun.com> From: Harold Carr To: interceptors-ftf@omg.org Subject: CORBA as a layer in layered systems Content-Type: text X-UIDL: fd%e9D2H!!$0ld9",E!! It seems that most people are saying that the "services are ORB-scoped, that's just the way CORBA works - end of story. But I think it would be beneficial to consider what that implies to the application program and to situations where CORBA is embedded in other frameworks. Here is the general problem: ORB orbX = ORB.init(...); Foo ref1 = // get a ref that somehow ends up with a different orb Foo ref2 = // ditto someService1 = // get service which somehow ends up with a different orb someService2 = // ditto someService1.begin(); someService2.begin(); ref1.bar(...); ref2.bar(...); someOtherProcedure(...); someService1.end(); someService2.end(); The workarounds of getting all the refs into the same ORB-scope as the service is complicated when multiple services are involved. How does one get the services to be in the same ORB-scope? It is also complicated when one calls subroutines which may use refs with other orbs that should participate in the service. If one doesn't own the code then they cannot change the code to change the ref's scope. Responses to my JNDI example say JNDI can/should be changed for this purpose. Changing JNDI is not the point - it is just an example of the above general case. What is important to consider is the general SPI model that JNDI uses - it has a bigger universe than just CORBA. Such a model makes it difficult to add an ORB to APIs. The service scope problem seems to be particularly acute for J2EE because J2EE is a general framework layered above CORBA. For CORBA to continue to be useful when embedded in such systems implies that CORBA specific details should not leak to the enclosing layer and it should not complicate the programmer's model. There is no fundamental reason that J2EE needs to use CORBA. It would be beneficial for CORBA to be open to such use cases. This issue pops up in Java because of SPI models (like JNDI) and mobile code. It is relatively easy for an application to end up with multiple ORBs (even ORBs from different vendors or with different versions). Bob Kukura pointed out that CORBA has not "been designed/evolved with the intent of fullly supporting the use of "anonymous" ORBs where the application doesn't control the ORB level policies." A language such as Java foregrounds the need to begin to consider this issue. The object->string->object workaround does not scale and probably does not even work for the general case in the pseudocode above. Perhaps adding ORBID to Java ORB.init would help. However, before discussing the idea ORBID idea I think it would be useful to see if others feel it would be useful to think about CORBA embedded in systems which use CORBA as infrastructure. Cheers, Harold From: Paul Kyzivat To: interceptors-ftf@omg.org Subject: RE: CORBA as a layer in layered systems Date: Fri, 19 May 2000 14:33:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Q?Be9EkXd9#Zkd9SD7!! Harold, I am not sure exactly what you want. As best I can tell, you want all orb services to be globally scoped and apply to all orbs. Isn't this simply a variation on the notion that ORBs (or ORBids) are themselves globally scoped? If it wasn't acceptable to have globally scoped ORBs, why is is ok to have globally scoped orb services? If these things are not visible to one another because of security concerns, isn't it equally a concern that invocations on an object activated with one orb might be visible to orb services unknown to that orb? The problem you are grappling with seems similar to OTS's problem managing arbitrary resources. In the case of OTS, I believe the resources need to register with the OTS in order to be managed. If some unregisterd stateful resource is used from within a transaction then the acid properties of the transaction are compromised. Paul > -----Original Message----- > From: Harold Carr [mailto:harold.carr@eng.sun.com] > Sent: Friday, May 19, 2000 1:49 PM > To: interceptors-ftf@omg.org > Subject: CORBA as a layer in layered systems > > > > It seems that most people are saying that the "services are > ORB-scoped, that's just the way CORBA works - end of story. But I > think it would be beneficial to consider what that implies to the > application program and to situations where CORBA is embedded in other > frameworks. Here is the general problem: > > ORB orbX = ORB.init(...); > Foo ref1 = // get a ref that somehow ends up with a different orb > Foo ref2 = // ditto > someService1 = // get service which somehow ends up with > a different orb > someService2 = // ditto > someService1.begin(); > someService2.begin(); > ref1.bar(...); > ref2.bar(...); > someOtherProcedure(...); > someService1.end(); > someService2.end(); > > The workarounds of getting all the refs into the same ORB-scope as the > service is complicated when multiple services are involved. How does > one get the services to be in the same ORB-scope? It is also > complicated when one calls subroutines which may use refs with other > orbs that should participate in the service. If one doesn't own the > code then they cannot change the code to change the ref's scope. > > Responses to my JNDI example say JNDI can/should be changed for this > purpose. Changing JNDI is not the point - it is just an example of > the above general case. What is important to consider is the general > SPI model that JNDI uses - it has a bigger universe than just CORBA. > Such a model makes it difficult to add an ORB to APIs. > > The service scope problem seems to be particularly acute for J2EE > because J2EE is a general framework layered above CORBA. For CORBA to > continue to be useful when embedded in such systems implies that CORBA > specific details should not leak to the enclosing layer and it should > not complicate the programmer's model. There is no fundamental reason > that J2EE needs to use CORBA. It would be beneficial for CORBA to be > open to such use cases. > > This issue pops up in Java because of SPI models (like JNDI) and > mobile code. It is relatively easy for an application to end up with > multiple ORBs (even ORBs from different vendors or with different > versions). > > Bob Kukura pointed out that CORBA has not "been designed/evolved with > the intent of fullly supporting the use of "anonymous" ORBs where the > application doesn't control the ORB level policies." A language such > as Java foregrounds the need to begin to consider this issue. > > The object->string->object workaround does not scale and probably does > not even work for the general case in the pseudocode above. Perhaps > adding ORBID to Java ORB.init would help. > > However, before discussing the idea ORBID idea I think it would be > useful to see if others feel it would be useful to think about CORBA > embedded in systems which use CORBA as infrastructure. > > Cheers, > Harold > Date: Tue, 23 May 2000 09:23:16 -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@omg.org Subject: Re: CORBA as a layer in layered systems References: <9B164B713EE9D211B6DC0090273CEEA926BEAA@bos1.noblenet.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: V4Ge9a`\!!W=Be9QP;e9 Everyone (particularly Paul and Bob Kukura): Thanks for your responses. The examples I have been giving have all been motivated by the fact that it is very easy to get multiple ORBs (with different versions and vendors) in a Java program. I was thinking out load on how to make them cooperate easily. I agree with you that this is a variation on globally-scoped ORBs. Just like resources register with OTS, a service needs to register with an ORB. But I would still like to find a way to handle the example situations I have given. It is now beginning to seem that adding ORBid to the Java-mapping (in some form which did not compromise security) would be beneficial in this regard. I am exploring this idea and will say more later, but I'd love to hear ideas along these lines from others. Cheers, Harold Paul Kyzivat wrote: > > Harold, > > I am not sure exactly what you want. As best I can tell, you want all orb > services to be globally scoped and apply to all orbs. > > Isn't this simply a variation on the notion that ORBs (or ORBids) are > themselves globally scoped? > > If it wasn't acceptable to have globally scoped ORBs, why is is ok to have > globally scoped orb services? > > If these things are not visible to one another because of security concerns, > isn't it equally a concern that invocations on an object activated with one > orb might be visible to orb services unknown to that orb? > > The problem you are grappling with seems similar to OTS's problem managing > arbitrary resources. In the case of OTS, I believe the resources need to > register with the OTS in order to be managed. If some unregisterd stateful > resource is used from within a transaction then the acid properties of the > transaction are compromised. > > Paul > > > -----Original Message----- > > From: Harold Carr [mailto:harold.carr@eng.sun.com] > > Sent: Friday, May 19, 2000 1:49 PM > > To: interceptors-ftf@omg.org > > Subject: CORBA as a layer in layered systems > > > > > > > > It seems that most people are saying that the "services are > > ORB-scoped, that's just the way CORBA works - end of story. But I > > think it would be beneficial to consider what that implies to the > > application program and to situations where CORBA is embedded in other > > frameworks. Here is the general problem: > > > > ORB orbX = ORB.init(...); > > Foo ref1 = // get a ref that somehow ends up with a different orb > > Foo ref2 = // ditto > > someService1 = // get service which somehow ends up with > > a different orb > > someService2 = // ditto > > someService1.begin(); > > someService2.begin(); > > ref1.bar(...); > > ref2.bar(...); > > someOtherProcedure(...); > > someService1.end(); > > someService2.end(); > > > > The workarounds of getting all the refs into the same ORB-scope as the > > service is complicated when multiple services are involved. How does > > one get the services to be in the same ORB-scope? It is also > > complicated when one calls subroutines which may use refs with other > > orbs that should participate in the service. If one doesn't own the > > code then they cannot change the code to change the ref's scope. > > > > Responses to my JNDI example say JNDI can/should be changed for this > > purpose. Changing JNDI is not the point - it is just an example of > > the above general case. What is important to consider is the general > > SPI model that JNDI uses - it has a bigger universe than just CORBA. > > Such a model makes it difficult to add an ORB to APIs. > > > > The service scope problem seems to be particularly acute for J2EE > > because J2EE is a general framework layered above CORBA. For CORBA to > > continue to be useful when embedded in such systems implies that CORBA > > specific details should not leak to the enclosing layer and it should > > not complicate the programmer's model. There is no fundamental reason > > that J2EE needs to use CORBA. It would be beneficial for CORBA to be > > open to such use cases. > > > > This issue pops up in Java because of SPI models (like JNDI) and > > mobile code. It is relatively easy for an application to end up with > > multiple ORBs (even ORBs from different vendors or with different > > versions). > > > > Bob Kukura pointed out that CORBA has not "been designed/evolved with > > the intent of fullly supporting the use of "anonymous" ORBs where the > > application doesn't control the ORB level policies." A language such > > as Java foregrounds the need to begin to consider this issue. > > > > The object->string->object workaround does not scale and probably does > > not even work for the general case in the pseudocode above. Perhaps > > adding ORBID to Java ORB.init would help. > > > > However, before discussing the idea ORBID idea I think it would be > > useful to see if others feel it would be useful to think about CORBA > > embedded in systems which use CORBA as infrastructure. > > > > Cheers, > > Harold > >