Issue 3419: Bridge Interoperability of the Java mapping with the EJB-to-CCM mapping (components-ftf) Source: International Business Machines (Mr. Ignacio Silva-Lepe, isilval(at)us.ibm.com) Nature: Uncategorized Issue Severity: Summary: he following sub-issues need to be addressed to make sure that CCM/EJB bridge implementations are interoperable. In particular, these sub-issues have in common that the current definition of the bridge relies on the Java-to-IDL mapping, which in certain cases does not match the requirements of the EJB-to-CCM mapping. Sub-issue: METHOD NAMES IN STANDARD INTERFACES The names for some methods defined on standard interfaces, for example <home-name>Implicit.find_by_primary_key or <home-name>Implicit.create, differ from the names that their EJB counterparts get mapped to under Java-to-IDL (in the example these would be <home-name>.findByPrimaryKey and create__keytype, respectively). When this happens, the translation from one form of the name to the other can happen at either the client or the server side of the bridge. FOR INTEROPERABILITY, it is necessary to eliminate this ambiguity. Choices for doing this include requiring the client stub to always do the translation or requiring the server skeleton to take into account both name forms. The actual problem we are getting hit by here is overloaded names. Methods like remove and create in EJBHome and user-defined EJB homes can only be mapped to remove__XXX and create__XXX under Java-to-IDL, yet the definitions of the corresponding methods in <home-name>Implicit are remove and create, respectively. I can understand that these implicit home names were defined as such because <home-name>Implicit is a standard interface (although the fact that its name is prefixed by <home-name> is a bit troubling) and, if for no other reason, because the XXX in create_XXX cannot be known in general. So, if we stick to the standard names, there is a mismatch. Notice however that I said that the mapping is done under Java-to-IDL. Perhaps I should not say that but the CCM spec is not clear about this and in fact it states that the create methods in an EJB home are mapped to factory names under Java-to-IDL. So we may actually be talking about two different issues: (1) use different mapping rules for create with no primary key, in which case we need to ammend the spec to this effect; (2) perform a translation, in which case we have an interoperability issue. Sub-issue: HANDLING STANDARD EXCEPTIONS Standard exceptions thrown by EJB methods, such as DuplicateKeyException, have a mapping specification to IDL (under the current Java-to-IDL specification) that does not match the exceptions that they map to under the CCM spec (in the example this would be DuplicateKeyValue). This requires that the bridge perform a run-time translation of exceptions from the Java-to-IDL mapping to the CCM mapping at either the client stub or the server skeleton. FOR INTEROPERABILITY, it is further necessary that the location of the translation be fixed. Early prototype implementation suggests that it is more advantageous for the client stub to perform the translation since otherwise the server skeleton would need to know what kind of client it is talking to: a CCM client or an EJB client. A larger issue that this falls under is the reconciliation of the Java-to-IDL mapping with the EJB-to-CCM mapping. If and when the larger issue is resolved, this issue would largely disappear. This also falls under the Java-to-IDL mismatch. Our choices seem to be: (1) define the standard exceptions, e.g. Components::DuplicateKeyValue, as if they had been mapped from Java under Java-to-IDL, (2) map the exceptions from Java under rules different from those on Java-to-IDL; (3) perform a translation. Choice (1) may be too intrusive but it could be rationalized with a "integration with EJB" argument. Choices (2) and (3) are similar to the above. Sub-issue: PASSING A PRIMARY KEY PARAMETER A number of methods defined by standard interfaces, such as remove defined by EJBHome, include in their signature a primary key value and define its type to be java.lang.Object, which under RMI-IIOP is mapped to CORBA::Any. Since the primary key is actually an object passed by value and thus mapped to an IDL value type, a run-time translation must be performed from the value type to Any and viceversa whenever a method that includes a primary key is called. FOR INTEROPERABILITY, it is necessary that the location of this translation be fixed. Choices for doing this include requiring the client stub to always do the translation or requiring the server skeleton to take into account both a value or an Any that could possibly be coming from any given client. In additon, if a primary key is returned it may be more advantageous for the client to perform this translation, since the server skeleton may not know what form the client is expecting. Here again the problem is that, under Java-to-IDL, java.lang.Object gets mapped to ::java::lang::Object (not CORBA::Any actually, as per the actual Java-to-IDL I am looking at) for methods like EJBHome.remove, whereas the key is expected to be passed as a value type. So the choices seem to be: (1) use rules other than those in Java-to-IDL for the mapping or (2) perform a translation. Resolution: see below Revised Text: In section 64.3, page 64-182, add: 64.3.3 Interoperability of the View As stated in section 64.3.2, translation of CORBA Component requests into EJB requests can happen at either the client-side, the server-side, or a combination of the two. However, in order to provide interoperability of implementations of CORBA component views of EJBs, a minimal number of translation points must be performed and they must be performed at an explicitly defined location: either the client-side or the server-side. These translation points are, for the implementation of a CORBA component view of an EJB, and for an EJB home interface: * Translation of specific method names The following methods shall translate their names as indicated. CCM Interface Method name EJB Interface Translation CCMHome get_component_def EJBHome getEJBMetaData remove_component remove <name>Implicit find_by_primary_key <name> findByPrimaryKey remove remove__java_lang_Object create create__java_lang_Object get_primary_key EJBObject getPrimaryKey * Handling of standard exceptions The following exceptions, caught by the indicated methods, shall be translated as indicated before raising them to their CORBA clients. CCM Interface Method name Exception caught Translation CCMHome get_component_def RemoteException CORBA UNKNOWN remove_component RemoveException RemoveFailure RemoteException CORBA UNKNOWN <name>Implicit create DuplicateKeyException DuplicateKeyValue CreateException CreateFailure find_by_primary_key ObjectNotFoundException UnknownKeyValue FinderException FinderFailure remove RemoveException RemoveFailure RemoteException CORBA UNKNOWN get_primary_key RemoteException CORBA UNKNOWN Note: RemoteException is translated into CORBA UNKNOWN system exception according to rules defined in formal/01-06-07, section 1.4.7. * Handling of a primary key parameter The methods create, find_by_primary_key and remove, defined by < home >Implicit shall translate the primary key valuetype they get as input parameter to a CORBA::Any equivalent. Likewise, the method get_primary_key defined by < home >Implicit shall translate the CORBA::Any value of the primary key it gets as a result from its request into an equivalent primary key valuetype before returning it. For the implementation of a CORBA component view of an EJB, and for an EJB home interface, the translation points are: * Translation of specific method names The following methods shall translate their names as indicated. CCM Interface Method name EJB Interface Translation CCMObject get_home EJBObject getEJBHome get_primary_key getPrimaryKey * Handling of standard exceptions The following exceptions, caught by the indicated methods, shall be translated as indicated before raising them to their CORBA clients. CCM Interface Method name Exception caught Translation CCMObject get_home RemoteException CORBA UNKNOWN get_primary_key RemoteException CORBA UNKNOWN remove RemoveException RemoveFailure RemoteException CORBA UNKNOWN Note: RemoteException is translated into CORBA UNKNOWN system exception according to rules defined in formal/01-06-07, section 1.4.7. * Handling of a primary key parameter The method get_primary_key, defined by CCMObject, shall translate the CORBA::Any value of the primary key it gets as a result from its request into an equivalent Components::PrimaryKeyBase valuetype before returning it. In section 64.3 change the number of section 64.3.3 to 64.3.4 In section 64.4, page 64-189, add: 64.4.3 Interoperability of the View As stated in section 64.4.2, translation of EJB requests into CORBA Component requests can happen at either the client-side, the server-side, or a combination of the two. However, in order to provide interoperability of implementations of EJB views of CORBA components, a minimal number of translation points must be performed and they must be performed at an explicitly defined location: either the client-side or the server-side. These translation points are, for the implementation of an EJB view of a CORBA component, and for a CCMHome interface: * Translation of specific method names The following methods shall translate their names as indicated. EJB Interface Method name CCM Interface Translation EJBHome remove CCMHome remove_component <name> findByPrimaryKey <name>Implicit find_by_primary_key remove__java_lang_Object remove create__java_lang_Object create * Handling of standard exceptions The following exceptions, caught by the indicated methods, shall be translated as indicated before raising them to their EJB clients. EJB Interface Method name Exception caught Translation EJBHome remove RemoveFailure RemoveException CORBA system exception RemoteException remove__java_lang_Object RemoveFailure RemoveException CORBA system exception RemoteException <name> create CreateFailure CreateException DuplicateKeyValue DuplicateKeyException findByPrimaryKey UnknownKeyValue ObjectNotFoundException FinderFailure FinderException Note: CORBA system exception is translated into RemoteException according to rules defined in formal/01-06-07, section 1.4.8. * Handling of a primary key parameter The methods create and findByPrimaryKey, defined by < name >, and remove__java_lang_Object, defined by EJBHome shall translate the primary key valuetype they get as input parameter to a CORBA::Any equivalent. For the implementation of an EJB view of a CORBA component, and for a CCM interface, the translation points are: * Translation of specific method names The following methods shall translate their names as indicated. EJB Interface Method name CCM Interface Translation EJBObject getEJBHome CCMObject get_home getPrimaryKey get_primary_key isIdentical CORBA::Object is_equivalent * Handling of standard exceptions The following exceptions, caught by the indicated methods, shall be translated as indicated before raising them to their EJB clients. EJB Interface Method name Exception caught Translation EJBObject getEJBHome CORBA system exception RemoteException getPrimaryKey CORBA system exception RemoteException remove RemoveFailure RemoveException CORBA system exception RemoteException isIdentical CORBA system exception RemoteException Note: CORBA system exception is translated into RemoteException according to rules defined in formal/01-06-07, section 1.4.8. * Handling of a primary key parameter The method getPrimaryKey, defined by EJBObject, shall translate the CORBA::Any value of the primary key it gets as a result from its request into an equivalent Java Object valuetype before returning it. In section 64.4 change the number of section 64.4.3 to 64.4.4 In section 64, page 64-190, add: 64.5 Compliance with the Interoperability of Integration Views As stated in sections 64.3.3 and 64.4.3, request translations must happen at an explicitly defined location: either the client-side or the server side. Rather than mandate one location arbitrarily, a number of levels of compliance with the interoperability of integration views are defined. Vendors shall clearly state what level of interoperability is supported by their implementations. These levels are: NONE: Integration view implementations that comply with this level actually perform no request translations. These implementations can still interoperate with other implementations that understand non-translated requests, e.g., implementations compliant with levels SERVER-SIDE and FULL. CLIENT-SIDE: Translation occurs either in the address space of a client stub or in a separate address space downstream from the client stub but before the resulting GIOP request gets sent to the server. SERVER-SIDE: Translation occurs either in the address space of a server skeleton or in a separate address space upstream from the server skeleton but after the GIOP request has been received from the client. The presence of a server-side view must not prevent native (i.e., non-translated) access to the component. FULL: Integration view implementations that comply with this level comply with both the CLIENT-SIDE and SERVER-SIDE levels. Note that a stand-alone bridge in a separate address space complies at this level since it is both upstream of the client (SERVER-SIDE) and downstream of the server (CLIENT-SIDE) FULL: Integration view implementations that comply with this level comply with both the CLIENT and the SERVER levels. The following table illustrates the possible combinations of level compliance that are implied by the previous definitions. Rows in the table denote implementations compliant with a given level that send a request. Columns denote implementations compliant with a given level that receive a request. So, for example, a SERVER-SIDE implementation cannot interoperate with a CLIENT-SIDE implementation because the SERVER-SIDE implementation does not translate on send and the CLIENT-SIDE implementation does not translate on receive. NONE CLIENT-SIDE SERVER-SIDE FULL NONE no no yes yes CLIENT-SIDE no yes yes yes SERVER-SIDE no no yes yes FULL yes yes yes yes In section 64 change the number of section 64.5 to 64.6 Actions taken: March 14, 2000: received issue May 13, 2002: closed issue Discussion: Require that client or server stubs of home and remote interfaces for both CORBA Component views of EJBs as well as EJB views of CORBA Components include the necessary code to perform the translations outlined in the summary. End of Annotations:===== From: isilval@us.ibm.com X-Lotus-FromDomain: IBMUS To: issues@omg.org, components-ftf@omg.org Message-ID: <852568A2.0057CF13.00@D51MTA03.pok.ibm.com> Date: Tue, 14 Mar 2000 10:59:11 -0500 Subject: CCM Issue: Bridge Interoperability and reconciliation of the Java -to-IDL mapping with the EJB-to-CCM mapping Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: 9o[!!_&F!!Fp9!!bgN!! Summary: The following sub-issues need to be addressed to make sure that CCM/EJB bridge implementations are interoperable. In particular, these sub-issues have in common that the current definition of the bridge relies on the Java-to-IDL mapping, which in certain cases does not match the requirements of the EJB-to-CCM mapping. Sub-issue: METHOD NAMES IN STANDARD INTERFACES The names for some methods defined on standard interfaces, for example Implicit.find_by_primary_key or Implicit.create, differ from the names that their EJB counterparts get mapped to under Java-to-IDL (in the example these would be .findByPrimaryKey and create__keytype, respectively). When this happens, the translation from one form of the name to the other can happen at either the client or the server side of the bridge. FOR INTEROPERABILITY, it is necessary to eliminate this ambiguity. Choices for doing this include requiring the client stub to always do the translation or requiring the server skeleton to take into account both name forms. The actual problem we are getting hit by here is overloaded names. Methods like remove and create in EJBHome and user-defined EJB homes can only be mapped to remove__XXX and create__XXX under Java-to-IDL, yet the definitions of the corresponding methods in Implicit are remove and create, respectively. I can understand that these implicit home names were defined as such because Implicit is a standard interface (although the fact that its name is prefixed by is a bit troubling) and, if for no other reason, because the XXX in create_XXX cannot be known in general. So, if we stick to the standard names, there is a mismatch. Notice however that I said that the mapping is done under Java-to-IDL. Perhaps I should not say that but the CCM spec is not clear about this and in fact it states that the create methods in an EJB home are mapped to factory names under Java-to-IDL. So we may actually be talking about two different issues: (1) use different mapping rules for create with no primary key, in which case we need to ammend the spec to this effect; (2) perform a translation, in which case we have an interoperability issue. Sub-issue: HANDLING STANDARD EXCEPTIONS Standard exceptions thrown by EJB methods, such as DuplicateKeyException, have a mapping specification to IDL (under the current Java-to-IDL specification) that does not match the exceptions that they map to under the CCM spec (in the example this would be DuplicateKeyValue). This requires that the bridge perform a run-time translation of exceptions from the Java-to-IDL mapping to the CCM mapping at either the client stub or the server skeleton. FOR INTEROPERABILITY, it is further necessary that the location of the translation be fixed. Early prototype implementation suggests that it is more advantageous for the client stub to perform the translation since otherwise the server skeleton would need to know what kind of client it is talking to: a CCM client or an EJB client. A larger issue that this falls under is the reconciliation of the Java-to-IDL mapping with the EJB-to-CCM mapping. If and when the larger issue is resolved, this issue would largely disappear. This also falls under the Java-to-IDL mismatch. Our choices seem to be: (1) define the standard exceptions, e.g. Components::DuplicateKeyValue, as if they had been mapped from Java under Java-to-IDL, (2) map the exceptions from Java under rules different from those on Java-to-IDL; (3) perform a translation. Choice (1) may be too intrusive but it could be rationalized with a "integration with EJB" argument. Choices (2) and (3) are similar to the above. Sub-issue: PASSING A PRIMARY KEY PARAMETER A number of methods defined by standard interfaces, such as remove defined by EJBHome, include in their signature a primary key value and define its type to be java.lang.Object, which under RMI-IIOP is mapped to CORBA::Any. Since the primary key is actually an object passed by value and thus mapped to an IDL value type, a run-time translation must be performed from the value type to Any and viceversa whenever a method that includes a primary key is called. FOR INTEROPERABILITY, it is necessary that the location of this translation be fixed. Choices for doing this include requiring the client stub to always do the translation or requiring the server skeleton to take into account both a value or an Any that could possibly be coming from any given client. In additon, if a primary key is returned it may be more advantageous for the client to perform this translation, since the server skeleton may not know what form the client is expecting. Here again the problem is that, under Java-to-IDL, java.lang.Object gets mapped to ::java::lang::Object (not CORBA::Any actually, as per the actual Java-to-IDL I am looking at) for methods like EJBHome.remove, whereas the key is expected to be passed as a value type. So the choices seem to be: (1) use rules other than those in Java-to-IDL for the mapping or (2) perform a translation. Ignacio Silva-Lepe IBM T. J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598, USA INTERNET: isilval@us.ibm.com WWW: http://www.zgnews.com/silva Phone: (914) 784 7003 Fax: (914) 784 6040 X-Sender: aconway@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 18 Dec 2000 14:45:38 -0500 To: components-ftf@omg.org From: Alan Conway Subject: Re: Components FTF vote 5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: (m#"!!(\!!=>b!!~g[!! Regarding the FTF I have a serious concern about the resolution proposed for issue 3419 http://cgi.omg.org/pub/componentsftf/components-ftf-Vote5.htm#Issue3419 The nub of the resolution is to "Require that client stubs of home and remote interfaces for both CORBA Component views of EJBs as well as EJB views of CORBA Components include the necessary code to perform the translations outlined in the summary." This appears to be a brutal violation of IDL encapsulation - unless I am misunderstanding something here, that makes the client stubs aware of the implementation details of a component interface. I see a number of serious problems with this: * Plain vanilla CORBA clients that are CCM-unaware have no hope of having the relevant hackery in their IDL stubs, so this rules out most real-life CORBA systems as clients. * Even CCM-aware client stubs still have to figure out whether they are talking to an EJB disguised as a CCM or a "real" CCM. The resolution says nothing about how to do this. If this knowledge is compiled into the stubs, then what do you do to a deployed system when an EJB component implementation is replaced by a C++ one or vice versa? This may be tenable in an all Java system where clients download their stubs, but not in a system that involves rebuilding large numbers of C++ clients or taking down mission critical COBOL transactions. I'm not sure what the best resolution is, but I think the only tenable solution is a bridge component that lives close to the server and does the appropriate translation. It shoudl be a vendor issue exactly how you implement the bridging, but I think you'll end up with different IORs for the EJB and CCM views of the component. Two ways I can think of doing it off-hand are: * Separate bridge process does translation. Supply separate IORs to clients: direct for EJB, via bridge for CCM. * Built-in bridging: Still supply separate IORs to clients, but in this case they only differ in object key. The bridge can use the object key to determine whether the client does or does not require translation and act accordingly. The most complex part of this would be the need to "bridgify" references coming out of the component correctly. This shouldn't be insurmountable though. It's a bit unfortunate to have to supply separate IORs, but not really that big a deal since the Home pattern implies only a few entry point IORs to be managed in the system in any case. Alan Conway, Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. X-Sender: aconway@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 03 Jan 2001 10:59:25 -0500 To: "Ignacio Silva-Lepe" , "Bernard Normier" From: Alan Conway Subject: Re: IONA votes on Components FTF Vote 5 Cc: "Edward Cobb" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: NK%e9)S[d9O87!!4o~!! Hi Ignacio, I'm happy with the idea that the translation is performed by the bridge, but not with requiring that the bridging be done in the clients. This makes deployed clients dependent on the *implementation* of an object, not just it's interface - what happens to deployed C++ clients with linked in if you replace a "native" CCM component with an EJB one or vice versa? System rebuild, that's what. The wording needs to be along the lines that: * Server side application code must be completely unaware of the translation. * Client side application code must be completely unaware of the translation. * The EJB/CCM bridge performs translation as necessary. It is up to the implementation to determine whether the work is done at the client side, the server side or by an intermediate process. * It is up to the implementation to provide a mechanism for both bridged and unbridged communication. A client-side bridge could achieve this by providing bridged and unbridged stubs. A server-side or intermediate bridge could achieve this by providing bridged and unbridged versions of the IOR. (there may be more clever ways to do this, I haven't thought very hard about it.) I'm still very uncomfortable with all of this however. It points to a much more severe underlying problem with the Java-IDL mapping. What we're seeing here is the emergence of the fact that the mapping is just not useable from a developer perspective. CCM is essentially saying "Oh, no big deal, we'll patch over these inconveniences by customizing the mapping a little." However if the OMG can't use the mapping as it stands, how realistic is it to expect that anyone else can? I'm not sure what we can do about it at this point, but I'm raising it in case someone else does. At 02:41 PM 1/2/01 -0500, Ignacio Silva-Lepe wrote: Hi Bernard, Please see my reply in ... Best regards, -- Ignacio Ignacio Silva-Lepe IBM T. J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598, USA INTERNET: isilval@us.ibm.com WWW: http://www.zgnews.com/silva Phone: (914) 784 7003 Fax: (914) 784 6040 "Bernard Normier" on 12/22/2000 03:22:55 PM To: "Edward Cobb" , cc: Subject: IONA votes on Components FTF Vote 5 http://cgi.omg.org/pub/componentsftf/components-ftf-Vote5.htm IONA votes as follows: [...] Issue 3419: Bridge Interoperability of the Java mapping with the EJB-to-CCM mapping ----------------------------------------------------------------- As pointed out by Alan Conway and Jeff Mischinsky, the proposal makes plain CORBA client stubs aware that the target objects are implemented using EJB. Please see Alan's email. We find this unacceptable; therefore IONA votes NO on issue 3419, and exercises its VETO to prevent the adoption of this proposal. As I pointed out in my reply to Jeff, I should have been more precise in the language of the resolution proposal. Ultimately, the intention is that the translations be performed at the client's side but, as Jeff correctly points out, only as part of the bridge or view's implementation. That is, clients that communicate with a Component directly (not via the bridge) should not be impacted by this resolution. This way, the skeleton does not have to deal with different kinds of clients talking to it differently. Please let me know if this is the only concern with this resolution. [...] Regards, Bernard Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. Importance: Normal Subject: Re: IONA votes on Components FTF Vote 5 To: Alan Conway Cc: "Bernard Normier" , "Edward Cobb" , X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Ignacio Silva-Lepe" Date: Wed, 3 Jan 2001 15:38:57 -0500 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 5.0.6 |December 14, 2000) at 01/03/2001 03:38:59 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: W^D!!V_,!!(50e9X,h!! Hi Alan, I could not agree with you more with respect to the problem with the Java-to-IDL mapping. The problem only gets compounded by CCM. I mean, CCM actually raises in my mind the issue of introducing an EJB to CCM mapping as an extension of the Java-to-IDL mapping. One problem with this issue though is that this extended mapping is not straightforward in its own right. One example of a complication is precisely what issue 3419 is trying to address, the fact that corresponding interfaces (EJBObject vs CCMObject and EJBHome vs CCMHome) are not syntactically the same. Add to that the problems of method name overloading and the like and what you end up with is a need to perform translations. Now, if these translations are not pin-pointed to either the client-side or the server-side, it seems to me that you have an interoperation problem, which is the net of issue 3419. Now, it seems to me that the dependency of a client on the implementation of an object is not given solely by the resolution to this issue. Wouldn't this dependency exist in general if we tried to go from a bridged access to a server to a non-bridged access or viceversa? Perhaps I'm missing something but it seems to me that I should be possible to hide the details of the translation prescribed by 3419 in the implementation of the bridge. -- Ignacio Ignacio Silva-Lepe IBM T. J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598, USA INTERNET: isilval@us.ibm.com WWW: http://www.zgnews.com/silva Phone: (914) 784 7003 Fax: (914) 784 6040 Alan Conway on 01/03/2001 10:59:25 AM To: Ignacio Silva-Lepe/Watson/IBM@IBMUS, "Bernard Normier" cc: "Edward Cobb" , Subject: Re: IONA votes on Components FTF Vote 5 Hi Ignacio, I'm happy with the idea that the translation is performed by the bridge, but not with requiring that the bridging be done in the clients. This makes deployed clients dependent on the *implementation* of an object, not just it's interface - what happens to deployed C++ clients with linked in if you replace a "native" CCM component with an EJB one or vice versa? System rebuild, that's what. The wording needs to be along the lines that: * Server side application code must be completely unaware of the translation. * Client side application code must be completely unaware of the translation. * The EJB/CCM bridge performs translation as necessary. It is up to the implementation to determine whether the work is done at the client side, the server side or by an intermediate process. * It is up to the implementation to provide a mechanism for both bridged and unbridged communication. A client-side bridge could achieve this by providing bridged and unbridged stubs. A server-side or intermediate bridge could achieve this by providing bridged and unbridged versions of the IOR. (there may be more clever ways to do this, I haven't thought very hard about it.) I'm still very uncomfortable with all of this however. It points to a much more severe underlying problem with the Java-IDL mapping. What we're seeing here is the emergence of the fact that the mapping is just not useable from a developer perspective. CCM is essentially saying "Oh, no big deal, we'll patch over these inconveniences by customizing the mapping a little." However if the OMG can't use the mapping as it stands, how realistic is it to expect that anyone else can? I'm not sure what we can do about it at this point, but I'm raising it in case someone else does. At 02:41 PM 1/2/01 -0500, Ignacio Silva-Lepe wrote: >Hi Bernard, > >Please see my reply in ... > >Best regards, > >-- Ignacio > >Ignacio Silva-Lepe >IBM T. J. Watson Research Center >P.O. Box 704 Yorktown Heights, NY 10598, USA >INTERNET: isilval@us.ibm.com >WWW: http://www.zgnews.com/silva >Phone: (914) 784 7003 Fax: (914) 784 6040 > > >"Bernard Normier" on 12/22/2000 03:22:55 >PM > >To: "Edward Cobb" , >cc: >Subject: IONA votes on Components FTF Vote 5 > > > >http://cgi.omg.org/pub/componentsftf/components-ftf-Vote5.htm > >IONA votes as follows: > >[...] > >Issue 3419: Bridge Interoperability of the Java mapping with the >EJB-to-CCM mapping >----------------------------------------------------------------- >As pointed out by Alan Conway and Jeff Mischinsky, the proposal >makes plain CORBA client stubs aware that the target objects >are implemented using EJB. Please see Alan's email. > >We find this unacceptable; therefore IONA votes NO on issue 3419, >and exercises its VETO to prevent the adoption of this proposal. > > >As I pointed out in my reply to Jeff, I should have been more precise >in >the language of the resolution proposal. Ultimately, the intention is >that >the translations be performed at the client's side but, as Jeff >correctly >points out, only as part of the bridge or view's implementation. That >is, >clients that communicate with a Component directly (not via the >bridge) >should not be impacted by this resolution. This way, the skeleton >does not >have to deal with different kinds of clients talking to it >differently. >Please let me know if this is the only concern with this resolution. > > > >[...] > >Regards, > >Bernard Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. X-Sender: aconway@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 03 Jan 2001 16:53:14 -0500 To: "Ignacio Silva-Lepe" From: Alan Conway Subject: Re: IONA votes on Components FTF Vote 5 Cc: "Bernard Normier" , "Edward Cobb" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: M`X!!p%,!!D(od9*hRd9 At 03:38 PM 1/3/01 -0500, Ignacio Silva-Lepe wrote: Now, it seems to me that the dependency of a client on the implementation of an object is not given solely by the resolution to this issue. Wouldn't this dependency exist in general if we tried to go from a bridged access to a server to a non-bridged access or viceversa? Perhaps I'm missing something but it seems to me that I should be possible to hide the details of the translation prescribed by 3419 in the implementation of the bridge. It's possible for the bridge to hide the change *provided* the bridge is not statically linked into all the clients - which is the origin of my original misgivings on the topic. If the bridge is a separate entity then it should be able to translate on behalf of all the clients that are "out of sync" with the actual implementation (perhaps at the cost of distributing different IORs to the different sets of clients, e.g. via parallel bridged and non-bridged naming hierarchies.) If you have a mixture of clients with statically linked bridging and non-bridging stubs then what does the server do? You have to have a separate translator anyway to bring these disparate clients line, so why bother putting this in the clients in the first place? You could perhaps invoke some client side stub magic based on IOR tags so the stubs could switch between bridging and non-bridging modes but that just makes my stomach turn. Not that we should necessarily rule it out if some vendor thinks that's a good idea, but we definitely shouldn't lock everyone into that approach. In particular it doesn't do much for older ORB clients that don't have the benefit of this new stub magic. There are a whole lot more worms in the EJB/CORBA interop can - as soon as you say "bridge", watch out for someone behind you saying "security and transactions" - but I think that's going well outside the scope of this discussion. Cheers, Alan. Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. Importance: Normal Subject: Re: IONA votes on Components FTF Vote 5 To: Alan Conway Cc: "Bernard Normier" , "Edward Cobb" , X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Ignacio Silva-Lepe" Date: Thu, 4 Jan 2001 10:58:51 -0500 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 5.0.6 |December 14, 2000) at 01/04/2001 10:58:51 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: ^WLe9'k6!!)~ ... Best regards, -- Ignacio Ignacio Silva-Lepe IBM T. J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598, USA INTERNET: isilval@us.ibm.com WWW: http://www.zgnews.com/silva Phone: (914) 784 7003 Fax: (914) 784 6040 Alan Conway on 01/03/2001 04:53:14 PM To: Ignacio Silva-Lepe/Watson/IBM@IBMUS cc: "Bernard Normier" , "Edward Cobb" , Subject: Re: IONA votes on Components FTF Vote 5 At 03:38 PM 1/3/01 -0500, Ignacio Silva-Lepe wrote: >Now, it seems to me that the dependency of a client on the implementation >of an object is not given solely by the resolution to this issue. Wouldn't >this dependency exist in general if we tried to go from a bridged access to >a server to a non-bridged access or viceversa? Perhaps I'm missing >something but it seems to me that I should be possible to hide the details >of the translation prescribed by 3419 in the implementation of the bridge. It's possible for the bridge to hide the change *provided* the bridge is not statically linked into all the clients - which is the origin of my original misgivings on the topic. If the bridge is a separate entity then it should be able to translate on behalf of all the clients that are "out of sync" with the actual implementation (perhaps at the cost of distributing different IORs to the different sets of clients, e.g. via parallel bridged and non-bridged naming hierarchies.) If you have a mixture of clients with statically linked bridging and non-bridging stubs then what does the server do? You have to have a separate translator anyway to bring these disparate clients line, so why bother putting this in the clients in the first place? Hmmm ... I'm not sure I follow. If a client uses a bridging stub (statically linked or not) that does the translation, then doesn't the server only see the translated request, which would presumably be equivalent to that produced by a non-bridging stub? You could perhaps invoke some client side stub magic based on IOR tags so the stubs could switch between bridging and non-bridging modes but that just makes my stomach turn. Not that we should necessarily rule it out if some vendor thinks that's a good idea, but we definitely shouldn't lock everyone into that approach. In particular it doesn't do much for older ORB clients that don't have the benefit of this new stub magic. There are a whole lot more worms in the EJB/CORBA interop can - as soon as you say "bridge", watch out for someone behind you saying "security and transactions" - but I think that's going well outside the scope of this discussion. Cheers, Alan. >Alan Conway, Senior Engineer, IONA Technologies. >E-mail: alan.conway@iona.com Tel: +1(819)843-5859 >Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. X-Sender: aconway@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 04 Jan 2001 12:05:23 -0500 To: "Ignacio Silva-Lepe" From: Alan Conway Subject: Re: IONA votes on Components FTF Vote 5 Cc: "Bernard Normier" , "Edward Cobb" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: `(B!!<[Ge9_K=e9/5U!! At 10:58 AM 1/4/01 -0500, Ignacio Silva-Lepe wrote: [snip: my objections to client stubs doing translation] Hmmm ... I'm not sure I follow. If a client uses a bridging stub (statically linked or not) that does the translation, then doesn't the server only see the translated request, which would presumably be equivalent to that produced by a non-bridging stub? True, the translation is hidden from the *server*, but not from the client. How can a normal CORBA client using a CCM-unaware ORB call on an EJB masquerading as a CCM? What do you do with all the clients if you replace the implementation of a component that used to be EJB with C++ or something else? Expecting clients to violate the standard rules of GIOP encoding based on somehow knowing the *implementation* platform of the object they are calling runs entirely counter to everything I understand CORBA to be about. Cheers, Alan. Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. From: Jeffrey Mischkinsky Message-Id: <200101041755.JAA16050@wheel.dcn.davis.ca.us> Subject: Re: IONA votes on Components FTF Vote 5 To: alan.conway@iona.com (Alan Conway) Date: Thu, 4 Jan 2001 09:55:22 -0800 (PST) Cc: isilval@us.ibm.com (Ignacio Silva-Lepe), bernard.normier@iona.com (Bernard Normier), ed.cobb@bea.com (Edward Cobb), components-ftf@omg.org In-Reply-To: <5.0.2.1.2.20010104115735.02bdf3b0@mail.boston.amer.iona.com> from "Alan Conway" at Jan 04, 2001 12:05:23 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ~3ld9b9Ae9ehRd9ONf!! 'Alan Conway' writes: > > At 10:58 AM 1/4/01 -0500, Ignacio Silva-Lepe wrote: > >[snip: my objections to client stubs doing translation] > > > >Hmmm ... I'm not sure I follow. If a client uses a bridging stub > >(statically linked or not) that does the translation, then doesn't the > >server only see the translated request, which would presumably be > >equivalent to that produced by a non-bridging stub? > > > > True, the translation is hidden from the *server*, but not from the client. > How can a normal CORBA client using a CCM-unaware ORB call on an EJB > masquerading as a CCM? What do you do with all the clients if you replace > the implementation of a component that used to be EJB with C++ or something > else? Expecting clients to violate the standard rules of GIOP encoding > based on somehow knowing the *implementation* platform of the object they > are calling runs entirely counter to everything I understand CORBA to be about. Hi, I'm probably completely confused here, but isn't the IDL different. It starts out with component foo ..... rather than interface foo.... Afterall a component type is different from an interface type, and "the system" knows (or should know) that. So doesn't that make it ok to have a different language mapping, which translates to a different stub on the client? Can someone straighten out my twisted neurons? jeff jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 From: thomas.s.hawker@mail.sprint.com X-OpenMail-Hops: 1 Date: Thu, 4 Jan 2001 12:31:16 -0600 Message-Id: Subject: RE: IONA votes on Components FTF Vote 5 MIME-Version: 1.0 TO: alan.conway@iona.com, jmischki@wheel.dcn.davis.ca.us CC: components-ftf@omg.org Content-Type: multipart/mixed; boundary="openmail-part-3870bb66-00000001" X-UIDL: ]I&"!%Qmd9X#gd9Qi*!! Hi. OK, I'm confused now too. But I guess this whole thing is confusing. Isn't the "equivalent" interface -- and the various derivational mappings to construct that equivalent interface -- defined such that a component unaware client can correctly access a component object as if it were merely a "normal" remote object? Thus, if I'm running my program somewhere and it invokes an object, it shouldn't be able to tell that that object was, in fact, a component, especially if I'm using DII or otherwise working from the equivalent interface definition. Wouldn't that solve, or at least constrain, some of this EJB/CCM mapping problem, simply so that an unaware client isn't affected? Do we need to do something funny with the IOR or GIOP/IIOP? Now, how I would get my hands on the "equivalent interface", as opposed to the component definition, is another problem. I don't recall anything in the spec about how I could produce that equivalent interface for use with a 2.x client (say, because I'm using an embedded ORB). Here at Sprint we have someone building a CCM implementation, and he had to write an IDL 3.0 to IDL 2.3 translator, thus generating the equivalent interface in order to build all of the other stuff. Tom Hawker, Iconixx thawker@iconixx.com > -----Original Message----- > From: Jeffrey Mischkinsky [mailto:jmischki@wheel.dcn.davis.ca.us] > Sent: Thursday, January 4, 2001 11:55 AM > To: Alan Conway > Cc: Ignacio Silva-Lepe; Bernard Normier; Edward Cobb; > components-ftf@omg.org > Subject: Re: IONA votes on Components FTF Vote 5 > > > 'Alan Conway' writes: > > > > At 10:58 AM 1/4/01 -0500, Ignacio Silva-Lepe wrote: > > >[snip: my objections to client stubs doing translation] > > > > > >Hmmm ... I'm not sure I follow. If a client uses a bridging stub > > >(statically linked or not) that does the translation, then > doesn't the > > >server only see the translated request, which would presumably be > > >equivalent to that produced by a non-bridging stub? > > > > > > > True, the translation is hidden from the *server*, but not > from the client. > > How can a normal CORBA client using a CCM-unaware ORB call > on an EJB > > masquerading as a CCM? What do you do with all the clients > if you replace > > the implementation of a component that used to be EJB with > C++ or something > > else? Expecting clients to violate the standard rules of > GIOP encoding > > based on somehow knowing the *implementation* platform of > the object they > > are calling runs entirely counter to everything I > understand CORBA to be about. > > Hi, > I'm probably completely confused here, but isn't the IDL > different. > It starts out with component foo ..... rather than > interface foo.... > Afterall a component type is different from an interface type, and > "the system" knows (or should know) that. > So doesn't that make it ok to have a different language mapping, > which translates to a different stub on the client? > > Can someone straighten out my twisted neurons? > > jeff > > > jeff > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeff@persistence.com +1 650-372-3604 X-Sender: aconway@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 04 Jan 2001 14:04:17 -0500 To: Jeffrey Mischkinsky From: Alan Conway Subject: Re: IONA votes on Components FTF Vote 5 Cc: isilval@us.ibm.com (Ignacio Silva-Lepe), bernard.normier@iona.com (Bernard Normier), ed.cobb@bea.com (Edward Cobb), components-ftf@omg.org In-Reply-To: <200101041755.JAA16050@wheel.dcn.davis.ca.us> References: <5.0.2.1.2.20010104115735.02bdf3b0@mail.boston.amer.iona.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: m\md9+6bd9SHb!!GS%e9 Glad to see I've at least managed to confuse people ;) I'll try for a non-confusing summary of the issue as I understand (or misunderstand) it, let me know if I fail miserably (or if I'm completely bonkers.) Here's what I believe lead up to the resolution I objected to: 1. We have a standard Java-to-IDL mapping that is good for RMI over IIOP, but creates pretty hairy interfaces for a non-Java CORBA developer to program to. 2. We have a mapping from EJB to a CCM "view" that *almost* uses Java-IDL, but due to overlap in what CCM and EJB are doing, plus the general hairiness of Java-IDL (in particular around collections and enumerations) it is not quite the standard mapping. CCM proposes that *most* EJB operations map as per Java-IDL, but some special operations (create, find etc.) have special mappings. 3. We have a requirement that a CCM client should be able to call on an EJB via it's CCM view without the EJB being aware that it's not a "normal" EJB client making the call. 4. We have a proposal that we solve the problem by having the client side stubs for the CCM view do the necessary translation so that client code can make CCM-flavored calls, but the EJB will receive the EJB-flavored calls. Here's where I started jumping up and down: 3a: Requirement 3 above is absolutely correct, but there's a complementary client-side requirement. A CCM client should be able to call on a CCM component without having to know whether it's implemented as "native" CCM or as a view of an EJB. If I give you the CCM IDL for a component, you should be able to build a client without *any* further information. I certainly should not have to tell you whether I plan to implement it using EJB, C++, COBOL, VB scripts or gnomes running around in a box; and provided I don't change the interface I should be free to change my implementation without forcing you to rebuild your clients or download new stubs. 4x: Putting translating stubs breaks requirement 3a, at least in statically linked language environments because you have to know when you link the client whether to use EJB-bridging stubs or non-EJB-bridging-stubs. Now you could propose some kind of "smart" stubs that can tell the difference at runtime. Apart from questions of how you'd do it (IOR tags most likely), this is another Big Hack. What do you do when the OMG wants to standardize a CCM view of the next hot component model and your smart stubs aren't smart enough anymore? Basically putting ANYTHING on the client side that involves knowledge of the server implementation technology flies in the face of everything I love about CORBA. Let me know if that still doesn't make sense. Cheers, Alan. At 09:55 AM 1/4/01 -0800, Jeffrey Mischkinsky wrote: 'Alan Conway' writes: > > At 10:58 AM 1/4/01 -0500, Ignacio Silva-Lepe wrote: > >[snip: my objections to client stubs doing translation] > > > >Hmmm ... I'm not sure I follow. If a client uses a bridging stub > >(statically linked or not) that does the translation, then doesn't the > >server only see the translated request, which would presumably be > >equivalent to that produced by a non-bridging stub? > > > > True, the translation is hidden from the *server*, but not from the client. > How can a normal CORBA client using a CCM-unaware ORB call on an EJB > masquerading as a CCM? What do you do with all the clients if you replace > the implementation of a component that used to be EJB with C++ or something > else? Expecting clients to violate the standard rules of GIOP encoding > based on somehow knowing the *implementation* platform of the object they > are calling runs entirely counter to everything I understand CORBA to be about. Hi, I'm probably completely confused here, but isn't the IDL different. It starts out with component foo ..... rather than interface foo.... Afterall a component type is different from an interface type, and "the system" knows (or should know) that. So doesn't that make it ok to have a different language mapping, which translates to a different stub on the client? Can someone straighten out my twisted neurons? jeff Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. X-Sender: aconway@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 04 Jan 2001 14:26:06 -0500 To: thomas.s.hawker@mail.sprint.com, jmischki@wheel.dcn.davis.ca.us From: Alan Conway Subject: RE: IONA votes on Components FTF Vote 5 Cc: components-ftf@omg.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: +Tjd90"h!!/CGe9*E[!! Thanks Thomas - I think you've found the key to me explaining myself properly. Equivalent IDL gives us a simple concrete example: Every CCM home has an equivalent interface with implicit operation find_by_primary_key(). The CCM to EJB mapping requires this map to findByPrimaryKey. Regardless how we deal with CCM aware clients (and I submit there's no good client-side solution to this), a vanilla CORBA stub cannot possibly know that calls to find_by_primary_key should result in findByPrimaryKey GIOP requests just because there's an EJB hiding at the other end of an IOR. The whole half-standard, half-custom CCM-EJB mapping scares me, but at the very least any bridging has to be kept out of the client (or left to vendor discretion as to exactly where it belongs) Cheers, Alan. At 12:31 PM 1/4/01 -0600, thomas.s.hawker@mail.sprint.com wrote: Hi. OK, I'm confused now too. But I guess this whole thing is confusing. Isn't the "equivalent" interface -- and the various derivational mappings to construct that equivalent interface -- defined such that a component unaware client can correctly access a component object as if it were merely a "normal" remote object? Thus, if I'm running my program somewhere and it invokes an object, it shouldn't be able to tell that that object was, in fact, a component, especially if I'm using DII or otherwise working from the equivalent interface definition. Wouldn't that solve, or at least constrain, some of this EJB/CCM mapping problem, simply so that an unaware client isn't affected? Do we need to do something funny with the IOR or GIOP/IIOP? Now, how I would get my hands on the "equivalent interface", as opposed to the component definition, is another problem. I don't recall anything in the spec about how I could produce that equivalent interface for use with a 2.x client (say, because I'm using an embedded ORB). Here at Sprint we have someone building a CCM implementation, and he had to write an IDL 3.0 to IDL 2.3 translator, thus generating the equivalent interface in order to build all of the other stuff. Tom Hawker, Iconixx thawker@iconixx.com > -----Original Message----- > From: Jeffrey Mischkinsky [mailto:jmischki@wheel.dcn.davis.ca.us] > Sent: Thursday, January 4, 2001 11:55 AM > To: Alan Conway > Cc: Ignacio Silva-Lepe; Bernard Normier; Edward Cobb; > components-ftf@omg.org > Subject: Re: IONA votes on Components FTF Vote 5 > > > 'Alan Conway' writes: > > > > At 10:58 AM 1/4/01 -0500, Ignacio Silva-Lepe wrote: > > >[snip: my objections to client stubs doing translation] > > > > > >Hmmm ... I'm not sure I follow. If a client uses a bridging stub > > >(statically linked or not) that does the translation, then > doesn't the > > >server only see the translated request, which would presumably be > > >equivalent to that produced by a non-bridging stub? > > > > > > > True, the translation is hidden from the *server*, but not > from the client. > > How can a normal CORBA client using a CCM-unaware ORB call > on an EJB > > masquerading as a CCM? What do you do with all the clients > if you replace > > the implementation of a component that used to be EJB with > C++ or something > > else? Expecting clients to violate the standard rules of > GIOP encoding > > based on somehow knowing the *implementation* platform of > the object they > > are calling runs entirely counter to everything I > understand CORBA to be about. > > Hi, > I'm probably completely confused here, but isn't the IDL > different. > It starts out with component foo ..... rather than > interface foo.... > Afterall a component type is different from an interface type, and > "the system" knows (or should know) that. > So doesn't that make it ok to have a different language mapping, > which translates to a different stub on the client? > > Can someone straighten out my twisted neurons? > > jeff > > > jeff > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeff@persistence.com +1 650-372-3604 Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. Importance: Normal Subject: Re: IONA votes on Components FTF Vote 5 To: Alan Conway Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Ignacio Silva-Lepe" Date: Thu, 4 Jan 2001 14:55:14 -0500 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 5.0.6 |December 14, 2000) at 01/04/2001 02:55:15 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: ( on 01/04/2001 12:05:23 PM To: Ignacio Silva-Lepe/Watson/IBM@IBMUS cc: "Bernard Normier" , "Edward Cobb" , Subject: Re: IONA votes on Components FTF Vote 5 At 10:58 AM 1/4/01 -0500, Ignacio Silva-Lepe wrote: >[snip: my objections to client stubs doing translation] > >Hmmm ... I'm not sure I follow. If a client uses a bridging stub >(statically linked or not) that does the translation, then doesn't the >server only see the translated request, which would presumably be >equivalent to that produced by a non-bridging stub? > True, the translation is hidden from the *server*, but not from the client. How can a normal CORBA client using a CCM-unaware ORB call on an EJB masquerading as a CCM? What do you do with all the clients if you replace the implementation of a component that used to be EJB with C++ or something else? Expecting clients to violate the standard rules of GIOP encoding based on somehow knowing the *implementation* platform of the object they are calling runs entirely counter to everything I understand CORBA to be about. It does not seem to me that the translation is exposed to the client either. Let me try to explain how I understand things and perhaps we can find where we diverge. The EJB-CCM bridge is more than a cross-language artifact. It is necessary because, while very close, the CCM and the EJB models differ, from fundamental things like handles and meta-data to mundane things like syntax (findByPrimaryKey vs find_by_primary_key for instance). Thus, a single client cannot access both types of component "natively", it will access one of them via the bridge. But this is only an implementation distinction. Let's say a C++ client is used to accessing a CORBA Component natively (which may be written in C++ or COBOL for instance). The stub that it uses does not need to perform a translation and it exposes a given interface. If the component is now re-written as an EJB the client's stub's implementation will need to change (and not just because a translation needs to happen, necessarily) but its interface should remain the same, as far as I can tell. Cheers, Alan. Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. Importance: Normal Subject: RE: IONA votes on Components FTF Vote 5 To: Alan Conway Cc: thomas.s.hawker@mail.sprint.com, jmischki@wheel.dcn.davis.ca.us, components-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Ignacio Silva-Lepe" Date: Thu, 4 Jan 2001 15:04:39 -0500 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 5.0.6 |December 14, 2000) at 01/04/2001 03:04:39 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: !cI!!VC!!!m]]d9YONe9 Ignacio Silva-Lepe IBM T. J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598, USA INTERNET: isilval@us.ibm.com WWW: http://www.zgnews.com/silva Phone: (914) 784 7003 Fax: (914) 784 6040 Alan Conway on 01/04/2001 02:26:06 PM To: thomas.s.hawker@mail.sprint.com, jmischki@wheel.dcn.davis.ca.us cc: components-ftf@omg.org Subject: RE: IONA votes on Components FTF Vote 5 Thanks Thomas - I think you've found the key to me explaining myself properly. Equivalent IDL gives us a simple concrete example: Every CCM home has an equivalent interface with implicit operation find_by_primary_key(). The CCM to EJB mapping requires this map to findByPrimaryKey. Regardless how we deal with CCM aware clients (and I submit there's no good client-side solution to this), a vanilla CORBA stub cannot possibly know that calls to find_by_primary_key should result in findByPrimaryKey GIOP requests just because there's an EJB hiding at the other end of an IOR. A vanilla CORBA client would probably use a bridged stub as well, wouldn't it? Now, I agree there's a difference between accessing a regular CORBA server vs a CORBA Component, but that's regardless whether the CORBA Component is an EJB or not, isn't it? The whole half-standard, half-custom CCM-EJB mapping scares me, but at the very least any bridging has to be kept out of the client (or left to vendor discretion as to exactly where it belongs) Cheers, Alan. At 12:31 PM 1/4/01 -0600, thomas.s.hawker@mail.sprint.com wrote: >Hi. > >OK, I'm confused now too. But I guess this whole thing is confusing. >Isn't the "equivalent" interface -- and the various derivational >mappings to construct that equivalent interface -- defined such that a >component unaware client can correctly access a component object as if >it were merely a "normal" remote object? Thus, if I'm running my >program somewhere and it invokes an object, it shouldn't be able to tell >that that object was, in fact, a component, especially if I'm using DII >or otherwise working from the equivalent interface definition. Wouldn't >that solve, or at least constrain, some of this EJB/CCM mapping problem, >simply so that an unaware client isn't affected? Do we need to do >something funny with the IOR or GIOP/IIOP? > >Now, how I would get my hands on the "equivalent interface", as opposed >to the component definition, is another problem. I don't recall >anything in the spec about how I could produce that equivalent interface >for use with a 2.x client (say, because I'm using an embedded ORB). >Here at Sprint we have someone building a CCM implementation, and he had >to write an IDL 3.0 to IDL 2.3 translator, thus generating the >equivalent interface in order to build all of the other stuff. > >Tom Hawker, Iconixx >thawker@iconixx.com > > > > -----Original Message----- > > From: Jeffrey Mischkinsky [mailto:jmischki@wheel.dcn.davis.ca.us] > > Sent: Thursday, January 4, 2001 11:55 AM > > To: Alan Conway > > Cc: Ignacio Silva-Lepe; Bernard Normier; Edward Cobb; > > components-ftf@omg.org > > Subject: Re: IONA votes on Components FTF Vote 5 > > > > > > 'Alan Conway' writes: > > > > > > At 10:58 AM 1/4/01 -0500, Ignacio Silva-Lepe wrote: > > > >[snip: my objections to client stubs doing translation] > > > > > > > >Hmmm ... I'm not sure I follow. If a client uses a bridging stub > > > >(statically linked or not) that does the translation, then > > doesn't the > > > >server only see the translated request, which would presumably be > > > >equivalent to that produced by a non-bridging stub? > > > > > > > > > > True, the translation is hidden from the *server*, but not > > from the client. > > > How can a normal CORBA client using a CCM-unaware ORB call > > on an EJB > > > masquerading as a CCM? What do you do with all the clients > > if you replace > > > the implementation of a component that used to be EJB with > > C++ or something > > > else? Expecting clients to violate the standard rules of > > GIOP encoding > > > based on somehow knowing the *implementation* platform of > > the object they > > > are calling runs entirely counter to everything I > > understand CORBA to be about. > > > > Hi, > > I'm probably completely confused here, but isn't the IDL > > different. > > It starts out with component foo ..... rather than > > interface foo.... > > Afterall a component type is different from an interface type, and > > "the system" knows (or should know) that. > > So doesn't that make it ok to have a different language mapping, > > which translates to a different stub on the client? > > > > Can someone straighten out my twisted neurons? > > > > jeff > > > > > > jeff > > > > -- > > Jeff Mischkinsky > > jmischki@dcn.davis.ca.us +1 530-758-9850 > > jeff@persistence.com +1 650-372-3604 Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. Importance: Normal Subject: RE: IONA votes on Components FTF Vote 5 To: Alan Conway Cc: thomas.s.hawker@mail.sprint.com, jmischki@wheel.dcn.davis.ca.us, components-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Ignacio Silva-Lepe" Date: Thu, 4 Jan 2001 15:04:39 -0500 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 5.0.6 |December 14, 2000) at 01/04/2001 03:04:39 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: (UE!!0DM!!J/=e9NIQe9 Ignacio Silva-Lepe IBM T. J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598, USA INTERNET: isilval@us.ibm.com WWW: http://www.zgnews.com/silva Phone: (914) 784 7003 Fax: (914) 784 6040 Alan Conway on 01/04/2001 02:26:06 PM To: thomas.s.hawker@mail.sprint.com, jmischki@wheel.dcn.davis.ca.us cc: components-ftf@omg.org Subject: RE: IONA votes on Components FTF Vote 5 Thanks Thomas - I think you've found the key to me explaining myself properly. Equivalent IDL gives us a simple concrete example: Every CCM home has an equivalent interface with implicit operation find_by_primary_key(). The CCM to EJB mapping requires this map to findByPrimaryKey. Regardless how we deal with CCM aware clients (and I submit there's no good client-side solution to this), a vanilla CORBA stub cannot possibly know that calls to find_by_primary_key should result in findByPrimaryKey GIOP requests just because there's an EJB hiding at the other end of an IOR. A vanilla CORBA client would probably use a bridged stub as well, wouldn't it? Now, I agree there's a difference between accessing a regular CORBA server vs a CORBA Component, but that's regardless whether the CORBA Component is an EJB or not, isn't it? The whole half-standard, half-custom CCM-EJB mapping scares me, but at the very least any bridging has to be kept out of the client (or left to vendor discretion as to exactly where it belongs) Cheers, Alan. At 12:31 PM 1/4/01 -0600, thomas.s.hawker@mail.sprint.com wrote: >Hi. > >OK, I'm confused now too. But I guess this whole thing is confusing. >Isn't the "equivalent" interface -- and the various derivational >mappings to construct that equivalent interface -- defined such that a >component unaware client can correctly access a component object as if >it were merely a "normal" remote object? Thus, if I'm running my >program somewhere and it invokes an object, it shouldn't be able to tell >that that object was, in fact, a component, especially if I'm using DII >or otherwise working from the equivalent interface definition. Wouldn't >that solve, or at least constrain, some of this EJB/CCM mapping problem, >simply so that an unaware client isn't affected? Do we need to do >something funny with the IOR or GIOP/IIOP? > >Now, how I would get my hands on the "equivalent interface", as opposed >to the component definition, is another problem. I don't recall >anything in the spec about how I could produce that equivalent interface >for use with a 2.x client (say, because I'm using an embedded ORB). >Here at Sprint we have someone building a CCM implementation, and he had >to write an IDL 3.0 to IDL 2.3 translator, thus generating the >equivalent interface in order to build all of the other stuff. > >Tom Hawker, Iconixx >thawker@iconixx.com > > > > -----Original Message----- > > From: Jeffrey Mischkinsky [mailto:jmischki@wheel.dcn.davis.ca.us] > > Sent: Thursday, January 4, 2001 11:55 AM > > To: Alan Conway > > Cc: Ignacio Silva-Lepe; Bernard Normier; Edward Cobb; > > components-ftf@omg.org > > Subject: Re: IONA votes on Components FTF Vote 5 > > > > > > 'Alan Conway' writes: > > > > > > At 10:58 AM 1/4/01 -0500, Ignacio Silva-Lepe wrote: > > > >[snip: my objections to client stubs doing translation] > > > > > > > >Hmmm ... I'm not sure I follow. If a client uses a bridging stub > > > >(statically linked or not) that does the translation, then > > doesn't the > > > >server only see the translated request, which would presumably be > > > >equivalent to that produced by a non-bridging stub? > > > > > > > > > > True, the translation is hidden from the *server*, but not > > from the client. > > > How can a normal CORBA client using a CCM-unaware ORB call > > on an EJB > > > masquerading as a CCM? What do you do with all the clients > > if you replace > > > the implementation of a component that used to be EJB with > > C++ or something > > > else? Expecting clients to violate the standard rules of > > GIOP encoding > > > based on somehow knowing the *implementation* platform of > > the object they > > > are calling runs entirely counter to everything I > > understand CORBA to be about. > > > > Hi, > > I'm probably completely confused here, but isn't the IDL > > different. > > It starts out with component foo ..... rather than > > interface foo.... > > Afterall a component type is different from an interface type, and > > "the system" knows (or should know) that. > > So doesn't that make it ok to have a different language mapping, > > which translates to a different stub on the client? > > > > Can someone straighten out my twisted neurons? > > > > jeff > > > > > > jeff > > > > -- > > Jeff Mischkinsky > > jmischki@dcn.davis.ca.us +1 530-758-9850 > > jeff@persistence.com +1 650-372-3604 Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. From: thomas.s.hawker@mail.sprint.com X-OpenMail-Hops: 1 Date: Thu, 4 Jan 2001 15:24:18 -0600 Message-Id: Subject: RE: IONA votes on Components FTF Vote 5 MIME-Version: 1.0 TO: alan.conway@iona.com, jmischki@wheel.dcn.davis.ca.us CC: components-ftf@omg.org Content-Type: multipart/mixed; boundary="openmail-part-38783cfb-00000001" X-UIDL: aT_!!'37e9T3'!!?T]d9 Yuk, this is a mess. I am merging comments from different but related threads, so please continue reading below. > -----Original Message----- > From: alan.conway [mailto:alan.conway@iona.com] > Sent: Thursday, January 4, 2001 1:26 PM > To: thomas.s.hawker; jmischki; alan.conway > Cc: components-ftf > Subject: RE: IONA votes on Components FTF Vote 5 > > > Thanks Thomas - I think you've found the key to me explaining > myself properly. > > Equivalent IDL gives us a simple concrete example: Every CCM > home has an > equivalent interface with implicit operation > find_by_primary_key(). The CCM > to EJB mapping requires this map to findByPrimaryKey. > Regardless how we > deal with CCM aware clients (and I submit there's no good client-side > solution to this), a vanilla CORBA stub cannot possibly know > that calls to > find_by_primary_key should result in findByPrimaryKey GIOP > requests just > because there's an EJB hiding at the other end of an IOR. > > The whole half-standard, half-custom CCM-EJB mapping scares > me, but at the > very least any bridging has to be kept out of the client (or > left to vendor > discretion as to exactly where it belongs) > > Cheers, > Alan. Let's try to work out a few more of the implications. I'm a detail-oriented person, so I'm going to explore some of the implications with respect to implementation. Pardon me, but I'm a Smalltalk expert, know my way around C++ (but CORBA in C++ only cursorily), and have avoided Java like the plague. Bear with me. We have component aware and component unaware clients. I have a mapping specification between the CCM and EJB component technologies that deals with how semantics between and requests made from a [component aware?] CORBA client must be translated in certain cases for the EJB. Consider a dual scenario, an original implementation of "factory" and "instance" with rewrites in both CCM and EJB, where my old clients and any new clients must be able to access either implementation transparently. The only permissible distinguishing artifact will be the accessed IOR. Assume it is unpredictable which IOR a client gets, so no client can be written a priori to deal with EJB. [I will permit dual-use stub generation and linking, but no client code changes allowed.] Assume further that, in the original implementation, all of the operation names correspond to the CCM equivalent(s). To complicate things, consider that the IOR may change on every invocation the client makes (sort of like a service component). OK, I think that's sufficiently real. I've only had to handle similar problems 6 or 7 times. The reasoning behind these restrictions and assumptions should be apparent, as large commercial CORBA deployments are going to convert from vanilla object to component technology piecemeal, and most likely there will be political infighting and huge turf wars over the programming language and implementation. We have the redeeming grace that such conversions are likely to happen with glacial speed. 1. OLD CLIENT to OLD IMPLEMENTATION. This is the "existing" implementation, and because of the assumptions, nothing should break. 2. NEW CLIENT to OLD IMPLEMENTATION. 3. OLD CLIENT to CCM IMPLEMENTATION. I suspect, but am really guessing, that because the operational signatures are identical, this is a no brainer. I recognize we may have a problem because the repository ID may have changed, but I am assuming that we've somehow handled that, perhaps by "forcing" the ID to a common value (the old one). 4. OLD CLIENT to EJB IMPLEMENTATION. In any sequence of requests, there is the reasonable probability that the old, component unaware client is going to perform one of those "translated" methods. It seems obvious this will happen almost immediately with the factory operations. Since this situation is the "old" client, it seems to me that the IOR it gets must necessarily be to a bridged stub - anything else and it isn't the "old" client. I'm willing to treat this as a degenerate case. 5. NEW CLIENT to EJB IMPLEMENTATION (Smart Stubs, Component Unaware). I assume with this one I've relinked the code with new stub libraries, but the client itself is not component aware. (I'm willing to concede the libraries might be, and maybe even the ORB, but that would necessarily be hidden from the client application, so the client remains "component unaware".) I would like to avoid client recompilation in this, but that may be unreasonable. Now, any and all distinctions become a function of the stub. Either we have an external bridge, in which case the stub will never know or care, or we have tagged somethings [IORs], in which case the stub must handle the tag in some fashion to perform appropriate translations. This raises the interesting problem, however, of how that something [IOR] got tagged! It's been awhile since I last read this, but how does an EJB expose a CORBA object reference to itself? Someone somewhere converted an EJB handle or whatever to an IOR, but isn't that the function of a bridge? If I've already got the bridge, why am I messing with the stubs?!? 6. NEW CLIENT to EJB IMPLEMENTATION (Component Aware) I'm pretty sure this amounts to the previous case but less transparently. The client must distinguish between plain and component implementations, and I think that stinks. IMHO, clients [or more correctly, the client application code] should *never* know or care. This case seems to require dynamic binding, smart stubs, or a bridged stub. I don't know how I would access two variants simultaneously by different threads. There is no easy solution to this one. We either force external bridging, force smart stubs, or force denial of simultaneous duality. I'm in favor of going easy on the ORB vendors and forcing an external bridge, especially since I'm dense today and can't think of any other way to get an IOR to an EJB in the first place. Besides, the vendors are going to have enough headaches just with adding components in general. What have I missed? ---- OK, here are Ignacio's comments. > -----Original Message----- > From: Ignacio Silva-Lepe [mailto:isilval@us.ibm.com] > Sent: Thursday, January 4, 2001 1:55 PM > To: Alan Conway > Cc: components-ftf@omg.org > Subject: Re: IONA votes on Components FTF Vote 5 > > > > > > > Ignacio Silva-Lepe > IBM T. J. Watson Research Center > P.O. Box 704 Yorktown Heights, NY 10598, USA > INTERNET: isilval@us.ibm.com > WWW: http://www.zgnews.com/silva > Phone: (914) 784 7003 Fax: (914) 784 6040 > > > Alan Conway on 01/04/2001 12:05:23 PM > > To: Ignacio Silva-Lepe/Watson/IBM@IBMUS > cc: "Bernard Normier" , "Edward Cobb" > , > Subject: Re: IONA votes on Components FTF Vote 5 > > > > At 10:58 AM 1/4/01 -0500, Ignacio Silva-Lepe wrote: > >[snip: my objections to client stubs doing translation] > > > >Hmmm ... I'm not sure I follow. If a client uses a bridging stub > >(statically linked or not) that does the translation, then > doesn't the > >server only see the translated request, which would presumably be > >equivalent to that produced by a non-bridging stub? > > I would hope so. > True, the translation is hidden from the *server*, but not > from the client. > How can a normal CORBA client using a CCM-unaware ORB call on an EJB > masquerading as a CCM? What do you do with all the clients if > you replace > the implementation of a component that used to be EJB with > C++ or something > else? Expecting clients to violate the standard rules of GIOP > encoding > based on somehow knowing the *implementation* platform of the > object they > are calling runs entirely counter to everything I understand > CORBA to be > about. > > > It does not seem to me that the translation is exposed to the client > either. > > Let me try to explain how I understand things and perhaps we > can find where > we diverge. The EJB-CCM bridge is more than a cross-language > artifact. It > is necessary because, while very close, the CCM and the EJB > models differ, > from fundamental things like handles and meta-data to mundane > things like > syntax (findByPrimaryKey vs find_by_primary_key for instance). Thus, > a > single client cannot access both types of component > "natively", it will > access one of them via the bridge. I'm not sure that's really true, especially since I can make this dynamic and transparent in Smalltalk. I'm not sure it should be the case even in C++. > ... But this is only an implementation > distinction. Let's say a C++ client is used to accessing a > CORBA Component > natively (which may be written in C++ or COBOL for instance). > The stub that > it uses does not need to perform a translation and it exposes a > given > interface. If the component is now re-written as an EJB the > client's stub's > implementation will need to change (and not just because a > translation > needs to happen, necessarily) but its interface should remain > the same, as > far as I can tell. > OK, I agree that the interface - the programmatic calls made by the client to the stub - should not change. I guess this means that if I *don't* change the stub, I'm forced to a bridge. Is that right? Tom Hawker, Iconixx thawker@iconixx.com X-Sender: aconway@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 05 Jan 2001 13:13:25 -0500 To: components-ftf@omg.org From: Alan Conway Subject: RE: IONA votes on Components FTF Vote 5 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: eH>e9g9id9b=Qd9+Wod9 Ignacio and I talked over resolution 3419, and reached common understanding but not resolution. While writing this summary I came up with a possible resolution. I'll summarize our understanding first and then outline my proposal. ==== Summary of conversation There are basically 3 places where bridging can happen: 1. In client address space. 2. In server address space. 3. In a separate bridge process. Part of the debate over 3419 was just misunderstanding of language. I took "client side" to mean 1 only, whereas Ignacio takes it to mean either 1 or 3 at vendor discretion, but with 3 being a "client side phenomenon" - i.e. regardless of whether bridging is in or out of the client process, it's up to client-side configuration to organize for bridging to happen. The server should not be involved. My counter-point is that you can make a symmetrical argument that the client should be protected, which suggests that 2 or "3 on the server side" is the way to go. We agreed that there are arguments for both sides, we failed to agree that the arguments on either side are sufficiently compelling to mandate one or the other. The worry is that without mandating, we risk incompatibility between different vendor offerings. To add to the fun remember we have to think about EJB clients of CCMs as well as vice-versa, so we have to solve this problem in both directions. ==== My suggested resolution: Rather than mandate one approach, we can weed out few sensible levels of EJB-interop compliance for a CCM implementation, so vendors have the choice but must clearly state the level at which they provide EJB interop, not in terms of where bridging happens, but in terms of what the implementation can talk to: NONE: No built-in EJB support. We should allow this because you can still potentially get interop via an external bridge by some other vendor or with a "CCM-aware" EJB implementation. CLIENT: Provides tools to build CCM clients that can make calls on unmodified, CCM-unaware EJB servers. This implies client-side bridging, either in stubs or a separate bridge process. May require re-configuring or re-building the client to talk to a native CCM vs. an EJB (yuk!) SERVER: Allows unmodified CCM-unaware EJB clients to call on EJB views of CCM components, while simultaneously allowing native CCM clients to to call on the CCM views of those components. There may be separte IORs for the EJB view and the CCM view (it's conceivable a clever server could publish a single IOR and figure out the conversions on the fly, but I'd be skeptical and definitely wouldn't mandate this.) Implies server-side bridging, either in the CCM server itself or a separate bridge process.. FULL: Satisfies both CLIENT and SERVER. This will leave the user some flexibility at configuration/deployment time about where to do the bridging for their application, but as Thomas pointed out in his scenarios e-mail, users may need this flexibilty in migrating systems. Implies either stand-alone briding or a combination of client and server side. Note that CLIENT and SERVER are not incompatible, because SERVER requires that both native CCM and native EJB clients be able to access an appropriate view (possibly thru separate IORs) and CLIENT requires that you can build a client to talk to either an EJB or a native CCM (possibly at the cost of rebuilding the client.) Indeed a CCM client with translating stubs could actually talk to an EJB view on a translating CCM server! Obviously FULL is the most desirable level of compliance because it is guaranteed to inter-operate with anything, but the lower levels are all likely to be useful in sufficiently important scenarios. The simplest implementation of FULL is an out-of-process bridge, but it doesn't rule out a combination of many-flavored client stubs and server-side skeleton or interceptor bridging if that's the way the vendor(s) want to go. Hope this is moving us forward, please comment early because I'm leaving on vacation from Jan 10-22 and I'd like to see some agreement before I go. Cheers, Alan. Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. From: thomas.s.hawker@mail.sprint.com X-OpenMail-Hops: 1 Date: Fri, 5 Jan 2001 16:19:49 -0600 Message-Id: Subject: RE: IONA votes on Components FTF Vote 5 MIME-Version: 1.0 TO: components-ftf@omg.org Content-Type: multipart/mixed; boundary="openmail-part-3897eb35-00000001" X-UIDL: 00@e9(#c!!~3Ie97,\d9 Alan, Ignacio, and all, After rereading the latest messages, I concur with Alan's summary and proposal. I won't say I understand everything or the related implications, but IMO it solves the problems I see facing a customer/user in the transition to or use of components. I have snipped and added a few pertinent comments below. > -----Original Message----- > From: Alan Conway [mailto:alan.conway@iona.com] > > [snipped] > > ==== Summary of conversation > > There are basically 3 places where bridging can happen: > 1. In client address space. > 2. In server address space. > 3. In a separate bridge process. > > [snipped] > > We agreed that there are arguments for both sides, we failed to agree that > the arguments on either side are sufficiently compelling to mandate one or > the other. The worry is that without mandating, we risk incompatibility > between different vendor offerings. To add to the fun remember we have to > think about EJB clients of CCMs as well as vice-versa, so we have to solve > this problem in both directions. This agreement and understanding, I think, is very important to the case. As was pointed out on this or another thread, we [parties acting as or on behalf of the OMG] should be careful to maximize the possibilities for market forces to achieve a final or preferred solution. Because there is no "compelling" argument for any of the choices, we should avoid requiring one over another, and let consumers and vendors reach equilibrium. > ==== My suggested resolution: > > [snipped] > > NONE: We're going to need this one for early experimentation and migration efforts. Vendors are likely to want to add component support in a staged fashion rather than all at once both for revenue and market presence reasons as well as to acquire customer feedback along the way. Customers are unlikely to deploy to multiple component technologies and expect interoperation between them. At least we'll have a story for later on... > CLIENT: I think it will prove possible to leave clients alone to talk to a CCM-aware bridge. I seem to recall that this is a requirement anyway - isn't a CCM-unaware client supposed to be able to talk to a component? The fact that the component bridges to an EJB should be irrelevant. >From a migration standpoint, being able to avoid changes to existing clients will be a strong selling point to the consumer. My experience leads me to believe that adding the bridge will be more palatable than upgrading clients, no matter how simple the effort involved, especially if there is more than one client application. This will be true for all cases except where the extra delay isn't tolerable, a very small minority. > SERVER: I agree. Let the vendors define how smart they want to be. > FULL: The desired compliance point, but I don't think it will be realistic in the short term. For large-scale customer installations, a demand for this should ultimately be realized, hence we are probably assured that we'll reach this level of compliance eventually by one or more vendors. > [snipped] Thanks, Alan, for a clear and concise summary and IMHO an effective solution for the spec. Tom Hawker, Iconixx thawker@iconixx.com X-Sender: aconway@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 08 Jan 2001 16:19:13 -0500 To: "Ignacio Silva-Lepe" From: Alan Conway Subject: RE: IONA votes on Components FTF Vote 5 Cc: components-ftf@omg.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: =3M!!?L%"!FL/!!pIC!! Hi Ignacio, Thomas et al. Glad to see we're getting closer to resolution! Just to concur with Ignacio's concern below and echo Thomas comments about leaving the field as open as possible to vendors: I don't want the spec to mandate that a bridge MUST use separate IOR's for CCM and EJB views of the same component, but I want it allowed because it's the most obvious way to implement that I can think of. If a vendor is clever enough to do it on a single IOR, then it's a fine market differentiator - reduced management overhead but no interop problems. I do have some vague ideas about how I might try to implement the single IOR solution it's sufficiently hairy that I wouldn't swear it can be done until I'd prototyped it, and even if it worked the simpler solution might win anyway for maintenance reasons. The big problem I see with single-IOR for two views is that each view essentially presents a different namespace for operation names, and I'm not sure you can guarantee avoiding name clashes between an unfortunately named CCM factory operation and some EJB operation for example. The receiving bridge just gets the op name in the GIOP message, not the full signature so a clash makes for a crash! Cheers, Alan. At 12:12 PM 1/8/01 -0500, Ignacio Silva-Lepe wrote: Thanks Alan for the summary of our conversation. I think it does reflect our concerns and where we are in trying to resolve them. Your suggested resolution does sound like a step in the right direction and, as far as I can tell, I does address the interop issue. I'm not sure I'm entirely happy with a solution involving multiple IORs for bridged vs non-bridged servers and I wonder whether there's any other way to provide the SERVER level. But this is an issue of form rather than one of function, at least in my mind. Also, we probably want to state explicitly the level combinations that are not going to work, e.g., NONE+CLIENT. I would like to hear other people's comments before we declare victory. Jeff, Jishnu, Patrick, Ed, anyone else? Does this approach sound reasonable? Any objections or subtleties being missed? Best regards, -- Ignacio Ignacio Silva-Lepe IBM T. J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598, USA INTERNET: isilval@us.ibm.com WWW: http://www.zgnews.com/silva Phone: (914) 784 7003 Fax: (914) 784 6040 Alan Conway on 01/05/2001 01:13:25 PM To: components-ftf@omg.org cc: Subject: RE: IONA votes on Components FTF Vote 5 Ignacio and I talked over resolution 3419, and reached common understanding but not resolution. While writing this summary I came up with a possible resolution. I'll summarize our understanding first and then outline my proposal. ==== Summary of conversation There are basically 3 places where bridging can happen: 1. In client address space. 2. In server address space. 3. In a separate bridge process. Part of the debate over 3419 was just misunderstanding of language. I took "client side" to mean 1 only, whereas Ignacio takes it to mean either 1 or 3 at vendor discretion, but with 3 being a "client side phenomenon" - i.e. regardless of whether bridging is in or out of the client process, it's up to client-side configuration to organize for bridging to happen. The server should not be involved. My counter-point is that you can make a symmetrical argument that the client should be protected, which suggests that 2 or "3 on the server side" is the way to go. We agreed that there are arguments for both sides, we failed to agree that the arguments on either side are sufficiently compelling to mandate one or the other. The worry is that without mandating, we risk incompatibility between different vendor offerings. To add to the fun remember we have to think about EJB clients of CCMs as well as vice-versa, so we have to solve this problem in both directions. ==== My suggested resolution: Rather than mandate one approach, we can weed out few sensible levels of EJB-interop compliance for a CCM implementation, so vendors have the choice but must clearly state the level at which they provide EJB interop, not in terms of where bridging happens, but in terms of what the implementation can talk to: NONE: No built-in EJB support. We should allow this because you can still potentially get interop via an external bridge by some other vendor or with a "CCM-aware" EJB implementation. CLIENT: Provides tools to build CCM clients that can make calls on unmodified, CCM-unaware EJB servers. This implies client-side bridging, either in stubs or a separate bridge process. May require re-configuring or re-building the client to talk to a native CCM vs. an EJB (yuk!) SERVER: Allows unmodified CCM-unaware EJB clients to call on EJB views of CCM components, while simultaneously allowing native CCM clients to to call on the CCM views of those components. There may be separte IORs for the EJB view and the CCM view (it's conceivable a clever server could publish a single IOR and figure out the conversions on the fly, but I'd be skeptical and definitely wouldn't mandate this.) Implies server-side bridging, either in the CCM server itself or a separate bridge process.. FULL: Satisfies both CLIENT and SERVER. This will leave the user some flexibility at configuration/deployment time about where to do the bridging for their application, but as Thomas pointed out in his scenarios e-mail, users may need this flexibilty in migrating systems. Implies either stand-alone briding or a combination of client and server side. Note that CLIENT and SERVER are not incompatible, because SERVER requires that both native CCM and native EJB clients be able to access an appropriate view (possibly thru separate IORs) and CLIENT requires that you can build a client to talk to either an EJB or a native CCM (possibly at the cost of rebuilding the client.) Indeed a CCM client with translating stubs could actually talk to an EJB view on a translating CCM server! Obviously FULL is the most desirable level of compliance because it is guaranteed to inter-operate with anything, but the lower levels are all likely to be useful in sufficiently important scenarios. The simplest implementation of FULL is an out-of-process bridge, but it doesn't rule out a combination of many-flavored client stubs and server-side skeleton or interceptor bridging if that's the way the vendor(s) want to go. Hope this is moving us forward, please comment early because I'm leaving on vacation from Jan 10-22 and I'd like to see some agreement before I go. Cheers, Alan. Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. From: thomas.s.hawker@mail.sprint.com X-OpenMail-Hops: 1 Date: Mon, 8 Jan 2001 16:37:30 -0600 Message-Id: Subject: RE: IONA votes on Components FTF Vote 5 MIME-Version: 1.0 TO: alan.conway@iona.com CC: components-ftf@omg.org Content-Type: multipart/mixed; boundary="openmail-part-38bddbbe-00000001" X-UIDL: IGBe9'$5e9l;!e9J&m!! Alan, Just a note on how-to's. I've had reason to explore the capabilities of IORs in detail. Because an IOR actually contains multiple profiles, I think it is possible to achieve what you want by either having multiple profiles or through vendor specific tags on one or more profiles. The tags can provide the necessary (and I believe sufficient) context information to resolve ambiguities. Since the "request" would always go to the "bridge", the bridge should be able to decipher the tags to determine what it really needs to do. There might be tag items that we know or can deduce will help and standardize them as part of the resolution / recommendation. Tom Hawker, Iconixx thawker@iconixx.com > -----Original Message----- > From: Alan Conway [mailto:alan.conway@iona.com] > Sent: Monday, January 8, 2001 3:19 PM > To: Ignacio Silva-Lepe > Cc: components-ftf@omg.org > Subject: RE: IONA votes on Components FTF Vote 5 > > > Hi Ignacio, Thomas et al. > > Glad to see we're getting closer to resolution! > > Just to concur with Ignacio's concern below and echo Thomas comments about > leaving the field as open as possible to vendors: I don't want the spec to > mandate that a bridge MUST use separate IOR's for CCM and EJB views of the > same component, but I want it allowed because it's the most obvious way to > implement that I can think of. If a vendor is clever enough to do it on a > single IOR, then it's a fine market differentiator - reduced management > overhead but no interop problems. I do have some vague ideas about how I > might try to implement the single IOR solution it's sufficiently hairy that > I wouldn't swear it can be done until I'd prototyped it, and even if it > worked the simpler solution might win anyway for maintenance reasons. > > [snipped] Sender: jbiggar@corvette.floorboard.com Message-ID: <3A5A4A9D.5AB56EC5@floorboard.com> Date: Mon, 08 Jan 2001 15:17:49 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: thomas.s.hawker@mail.sprint.com, components-ftf@omg.org Subject: Re: IONA votes on Components FTF Vote 5 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: > Alan, > > Just a note on how-to's. > > I've had reason to explore the capabilities of IORs in detail. Because > an IOR actually contains multiple profiles, I think it is possible to > achieve what you want by either having multiple profiles or through > vendor specific tags on one or more profiles. The tags can provide the > necessary (and I believe sufficient) context information to resolve > ambiguities. Since the "request" would always go to the "bridge", the > bridge should be able to decipher the tags to determine what it really > needs to do. There might be tag items that we know or can deduce will > help and standardize them as part of the resolution / recommendation. This approach is only possible if you use the NEEDS_ADDRESSING_MODE reply in GIOP 1.2 in order to get the client side to send the Profile or IOR in toto, since GIOP only sends the ObjectKey part of the IOR profile by default. Alternatively, you could use two different profiles and embed the information the bridge needs in the object key. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Sender: aconway@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 09 Jan 2001 08:35:15 -0500 To: thomas.s.hawker@mail.sprint.com From: Alan Conway Subject: RE: IONA votes on Components FTF Vote 5 Cc: components-ftf@omg.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: -p#!!]4id9b"Yd9phbd9 Hi Thomas, Far as I remember the only part of the IOR in a GIOP request header (hence the only part seen by the bridge) is the object key, so I don't think tags help us here unless there is proprietary collusion between client stubs and the bridge (which means we need another IOR anyway for clients from a different vendor.) Multiple profiles don't help either since they're profiles for objects with different interfaces - and you can't put two repository ids in an IOR. Just to note here, I don't think having two IORs is really a problem. It's not so hard to publish two parallel naming hierarchies - one for your EJB clients and one for your CCM clients. You could even do it in an external tool that runs over the "natural" name service and generates a parallel "bridgified" hierarchy so your server doesn't even have to be aware of it. Since EJB and CCM are typically only going to publish Home objects there are just a few static entries to manage anyway. If you ever do switch from an EJB to CCM implementation or vice versa, then the requirement to update IORs is pretty standard - this tends to happen anytime you make a major change to an implementation and it's one of the big reasons the naming service is there in the first place. I would guess that making a single IOR refer to two entirely different interfaces would create more confusion than convenience. Cheers, Alan. At 04:37 PM 1/8/01 -0600, thomas.s.hawker@mail.sprint.com wrote: Alan, Just a note on how-to's. I've had reason to explore the capabilities of IORs in detail. Because an IOR actually contains multiple profiles, I think it is possible to achieve what you want by either having multiple profiles or through vendor specific tags on one or more profiles. The tags can provide the necessary (and I believe sufficient) context information to resolve ambiguities. Since the "request" would always go to the "bridge", the bridge should be able to decipher the tags to determine what it really needs to do. There might be tag items that we know or can deduce will help and standardize them as part of the resolution / recommendation. Tom Hawker, Iconixx thawker@iconixx.com > -----Original Message----- > From: Alan Conway [mailto:alan.conway@iona.com] > Sent: Monday, January 8, 2001 3:19 PM > To: Ignacio Silva-Lepe > Cc: components-ftf@omg.org > Subject: RE: IONA votes on Components FTF Vote 5 > > > Hi Ignacio, Thomas et al. > > Glad to see we're getting closer to resolution! > > Just to concur with Ignacio's concern below and echo Thomas comments about > leaving the field as open as possible to vendors: I don't want the spec to > mandate that a bridge MUST use separate IOR's for CCM and EJB views of the > same component, but I want it allowed because it's the most obvious way to > implement that I can think of. If a vendor is clever enough to do it on a > single IOR, then it's a fine market differentiator - reduced management > overhead but no interop problems. I do have some vague ideas about how I > might try to implement the single IOR solution it's sufficiently hairy that > I wouldn't swear it can be done until I'd prototyped it, and even if it > worked the simpler solution might win anyway for maintenance reasons. > > [snipped] Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. X-Sender: aconway@mail.boston.amer.iona.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 09 Jan 2001 08:54:46 -0500 To: Jonathan Biggar , thomas.s.hawker@mail.sprint.com, components-ftf@omg.org From: Alan Conway Subject: Re: IONA votes on Components FTF Vote 5 In-Reply-To: <3A5A4A9D.5AB56EC5@floorboard.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: SRm!!FG*e9)V$"!G0)!! Didn't know about that! My GIOP is a bit rusty. However it doesn't solve the problem. The *client* has to know which profile or addressing mode to choose based on information that is not available to it unless there are tags in the IOR saying "I'm really an EJB object, so if you're a CCM client use profile 1 but if you're an EJB client use profile 2". Cheers, Alan. At 03:17 PM 1/8/01 -0800, Jonathan Biggar wrote: thomas.s.hawker@mail.sprint.com wrote: > > Alan, > > Just a note on how-to's. > > I've had reason to explore the capabilities of IORs in detail. Because > an IOR actually contains multiple profiles, I think it is possible to > achieve what you want by either having multiple profiles or through > vendor specific tags on one or more profiles. The tags can provide the > necessary (and I believe sufficient) context information to resolve > ambiguities. Since the "request" would always go to the "bridge", the > bridge should be able to decipher the tags to determine what it really > needs to do. There might be tag items that we know or can deduce will > help and standardize them as part of the resolution / recommendation. This approach is only possible if you use the NEEDS_ADDRESSING_MODE reply in GIOP 1.2 in order to get the client side to send the Profile or IOR in toto, since GIOP only sends the ObjectKey part of the IOR profile by default. Alternatively, you could use two different profiles and embed the information the bridge needs in the object key. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. From: thomas.s.hawker@mail.sprint.com X-OpenMail-Hops: 1 Date: Tue, 9 Jan 2001 08:53:44 -0600 Message-Id: Subject: RE: IONA votes on Components FTF Vote 5 MIME-Version: 1.0 TO: alan.conway@iona.com CC: components-ftf@omg.org Content-Type: multipart/mixed; boundary="openmail-part-38c6e342-00000001" X-UIDL: GDTd9lFLe9Imed9kdb!! Hi Alan, I had forgotten before Jon's reply that the IOR is not normally sent. Having multiple IORs isn't a problem except for how name space management will work during the migration process. I guess that doesn't affect the issue, only the end-user strategy on how they will achieve migration with "fixed" and "unfixed" clients. Tom > -----Original Message----- > From: alan.conway [mailto:alan.conway@iona.com] > Sent: Tuesday, January 9, 2001 7:35 AM > To: thomas.s.hawker; alan.conway > Cc: components-ftf > Subject: RE: IONA votes on Components FTF Vote 5 > > > Hi Thomas, > > [snipped] > > Just to note here, I don't think having two IORs is really a problem. It's > not so hard to publish two parallel naming hierarchies - one for your EJB > clients and one for your CCM clients. You could even do it in an external > tool that runs over the "natural" name service and generates a parallel > "bridgified" hierarchy so your server doesn't even have to be aware of it. > Since EJB and CCM are typically only going to publish Home objects there > are just a few static entries to manage anyway. > > If you ever do switch from an EJB to CCM implementation or vice versa, then > the requirement to update IORs is pretty standard - this tends to happen > anytime you make a major change to an implementation and it's one of the > big reasons the naming service is there in the first place. Date: Wed, 10 Jan 2001 15:55:30 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ignacio Silva-Lepe Cc: Alan Conway , components-ftf@omg.org Subject: Re: IONA votes on Components FTF Vote 5 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: *@4!!mV5e9)]!!!P`%e9 Ignacio Silva-Lepe wrote: > > Thanks Alan for the summary of our conversation. I think it does reflect > our concerns and where we are in trying to resolve them. Your suggested > resolution does sound like a step in the right direction and, as far as I > can tell, I does address the interop issue. I'm not sure I'm entirely happy > with a solution involving multiple IORs for bridged vs non-bridged servers > and I wonder whether there's any other way to provide the SERVER level. But > this is an issue of form rather than one of function, at least in my mind. > Also, we probably want to state explicitly the level combinations that are > not going to work, e.g., NONE+CLIENT. > > I would like to hear other people's comments before we declare victory. > Jeff, Jishnu, Patrick, Ed, anyone else? Does this approach sound > reasonable? Any objections or subtleties being missed? Sounds like a good direction to proceed in. It is worth filling in some of the details and produce a more complete proposal for resolution, so that we can then explore the "missed subtelities" question a bit more. Jishnu. -- Jishnu Mukerji Senior Systems Architect, EIAL Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jis@fpk.hp.com Importance: Normal Subject: RE: IONA votes on Components FTF Vote 5 To: Alan Conway Cc: components-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Ignacio Silva-Lepe" Date: Mon, 8 Jan 2001 12:12:12 -0500 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 5.0.6 |December 14, 2000) at 01/08/2001 12:12:13 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: !_Ke9I*md9O*Je9`Vhd9 Thanks Alan for the summary of our conversation. I think it does reflect our concerns and where we are in trying to resolve them. Your suggested resolution does sound like a step in the right direction and, as far as I can tell, I does address the interop issue. I'm not sure I'm entirely happy with a solution involving multiple IORs for bridged vs non-bridged servers and I wonder whether there's any other way to provide the SERVER level. But this is an issue of form rather than one of function, at least in my mind. Also, we probably want to state explicitly the level combinations that are not going to work, e.g., NONE+CLIENT. I would like to hear other people's comments before we declare victory. Jeff, Jishnu, Patrick, Ed, anyone else? Does this approach sound reasonable? Any objections or subtleties being missed? Best regards, -- Ignacio Ignacio Silva-Lepe IBM T. J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598, USA INTERNET: isilval@us.ibm.com WWW: http://www.zgnews.com/silva Phone: (914) 784 7003 Fax: (914) 784 6040 Alan Conway on 01/05/2001 01:13:25 PM To: components-ftf@omg.org cc: Subject: RE: IONA votes on Components FTF Vote 5 Ignacio and I talked over resolution 3419, and reached common understanding but not resolution. While writing this summary I came up with a possible resolution. I'll summarize our understanding first and then outline my proposal. ==== Summary of conversation There are basically 3 places where bridging can happen: 1. In client address space. 2. In server address space. 3. In a separate bridge process. Part of the debate over 3419 was just misunderstanding of language. I took "client side" to mean 1 only, whereas Ignacio takes it to mean either 1 or 3 at vendor discretion, but with 3 being a "client side phenomenon" - i.e. regardless of whether bridging is in or out of the client process, it's up to client-side configuration to organize for bridging to happen. The server should not be involved. My counter-point is that you can make a symmetrical argument that the client should be protected, which suggests that 2 or "3 on the server side" is the way to go. We agreed that there are arguments for both sides, we failed to agree that the arguments on either side are sufficiently compelling to mandate one or the other. The worry is that without mandating, we risk incompatibility between different vendor offerings. To add to the fun remember we have to think about EJB clients of CCMs as well as vice-versa, so we have to solve this problem in both directions. ==== My suggested resolution: Rather than mandate one approach, we can weed out few sensible levels of EJB-interop compliance for a CCM implementation, so vendors have the choice but must clearly state the level at which they provide EJB interop, not in terms of where bridging happens, but in terms of what the implementation can talk to: NONE: No built-in EJB support. We should allow this because you can still potentially get interop via an external bridge by some other vendor or with a "CCM-aware" EJB implementation. CLIENT: Provides tools to build CCM clients that can make calls on unmodified, CCM-unaware EJB servers. This implies client-side bridging, either in stubs or a separate bridge process. May require re-configuring or re-building the client to talk to a native CCM vs. an EJB (yuk!) SERVER: Allows unmodified CCM-unaware EJB clients to call on EJB views of CCM components, while simultaneously allowing native CCM clients to to call on the CCM views of those components. There may be separte IORs for the EJB view and the CCM view (it's conceivable a clever server could publish a single IOR and figure out the conversions on the fly, but I'd be skeptical and definitely wouldn't mandate this.) Implies server-side bridging, either in the CCM server itself or a separate bridge process.. FULL: Satisfies both CLIENT and SERVER. This will leave the user some flexibility at configuration/deployment time about where to do the bridging for their application, but as Thomas pointed out in his scenarios e-mail, users may need this flexibilty in migrating systems. Implies either stand-alone briding or a combination of client and server side. Note that CLIENT and SERVER are not incompatible, because SERVER requires that both native CCM and native EJB clients be able to access an appropriate view (possibly thru separate IORs) and CLIENT requires that you can build a client to talk to either an EJB or a native CCM (possibly at the cost of rebuilding the client.) Indeed a CCM client with translating stubs could actually talk to an EJB view on a translating CCM server! Obviously FULL is the most desirable level of compliance because it is guaranteed to inter-operate with anything, but the lower levels are all likely to be useful in sufficiently important scenarios. The simplest implementation of FULL is an out-of-process bridge, but it doesn't rule out a combination of many-flavored client stubs and server-side skeleton or interceptor bridging if that's the way the vendor(s) want to go. Hope this is moving us forward, please comment early because I'm leaving on vacation from Jan 10-22 and I'd like to see some agreement before I go. Cheers, Alan. Alan Conway, Senior Engineer, IONA Technologies. E-mail: alan.conway@iona.com Tel: +1(819)843-5859 Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. Importance: Normal Subject: Re: PRSW vote on CCM FTF vote 5 To: components-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Ignacio Silva-Lepe" Date: Tue, 2 Jan 2001 14:45:15 -0500 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 5.0.6 |December 14, 2000) at 01/02/2001 02:45:16 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: :iO!!]B(e9`eSd9*^@!! I agree with Jeff's position. I should have been more precise about the language of the resolution. The intention is indeed that the implementation of the view or bridge (specifically, that part of it residing at the client's side) be responsible for the translations. So, given that Jeff's understanding is correct as far as I can see, hopefully it will only be a matter of fixing the language in the proposal and put it up for a revote. But please, do let us know whether this reasoning is ok with everyone. -- Ignacio Ignacio Silva-Lepe IBM T. J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598, USA INTERNET: isilval@us.ibm.com WWW: http://www.zgnews.com/silva Phone: (914) 784 7003 Fax: (914) 784 6040 Jeffrey Mischkinsky on 12/21/2000 04:34:25 PM To: ed.cobb@bea.com (Edward Cobb) cc: components-ftf@omg.org Subject: PRSW vote on CCM FTF vote 5 PRSW votes YES on all issues in Vote 5 EXCEPT 3419. PRSW votes NO 3419 for the following reason: I read iona's email on the subject and think (hope?) there is a bit of a misunderstanding. The text of the proposal talks about the "client stub" being responsible for performing the mapping. The way I understand things, it is the implementation of the "view" or "bridge" that is responsible for making the translations The view has to make things look right to both the client and the server. If i'm correct then it should be relatively easy to fix the language in the proposal and do a quick revote. But I think it would be a serious mistake to publish the language as is. If i'm incorrect then someone needs to convince me that Iona's concerns are not serious before I'd be willing to change my vote. jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff@persistence.com +1 650-372-3604 Importance: Normal Subject: Issue 3419 - proposed resolution; was: RE: IONA votes on Components FTF Vote 5 To: Edward Cobb Cc: Alan Conway , components-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Ignacio Silva-Lepe" Date: Mon, 5 Feb 2001 15:34:51 -0500 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 5.0.6a |January 17, 2001) at 02/05/2001 03:35:44 PM MIME-Version: 1.0 Content-Disposition: inline Content-Type: multipart/mixed; Boundary="0__=852569EA00707DE88f9e8a93df938690918c852569EA00707DE8" X-UIDL: !4Zd9GRT!!9#"!!Q$"!! Ok, Alan and I have finally rounded up a resolution and revised text for Issue 3419 based on the ongoing discussion. Here's the proposal that I intend to submit for a vote. Please let me know if there are any remaining concerns. Alan, please note that on the exceptions question I actually realized that we had addressed it in issue 3182, so I have incorporated its resolution here. In particular, note the use of RemoveFailure, FinderFailure and CreateFailure. Cheers, -- Ignacio (See attached file: components-ftf - Issue 3419.html) Ignacio Silva-Lepe IBM T. J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598, USA INTERNET: isilval@us.ibm.com WWW: http://www.zgnews.com/silva Phone: (914) 784 7003 Fax: (914) 784 6040 Edward Cobb on 01/16/2001 12:42:18 PM To: Ignacio Silva-Lepe/Watson/IBM@IBMUS, Alan Conway cc: components-ftf@omg.org Subject: RE: IONA votes on Components FTF Vote 5 Sounds reasonable to me. Let's see a proposal to decide. At 12:12 PM 1/8/01 -0500, Ignacio Silva-Lepe wrote: > >Thanks Alan for the summary of our conversation. I think it does reflect >our concerns and where we are in trying to resolve them. Your suggested >resolution does sound like a step in the right direction and, as far as I >can tell, I does address the interop issue. I'm not sure I'm entirely happy >with a solution involving multiple IORs for bridged vs non-bridged servers >and I wonder whether there's any other way to provide the SERVER level. But >this is an issue of form rather than one of function, at least in my mind. >Also, we probably want to state explicitly the level combinations that are >not going to work, e.g., NONE+CLIENT. > >I would like to hear other people's comments before we declare victory. >Jeff, Jishnu, Patrick, Ed, anyone else? Does this approach sound >reasonable? Any objections or subtleties being missed? > >Best regards, > >-- Ignacio > >Ignacio Silva-Lepe >IBM T. J. Watson Research Center >P.O. Box 704 Yorktown Heights, NY 10598, USA >INTERNET: isilval@us.ibm.com >WWW: http://www.zgnews.com/silva >Phone: (914) 784 7003 Fax: (914) 784 6040 > > >Alan Conway on 01/05/2001 01:13:25 PM > >To: components-ftf@omg.org >cc: >Subject: RE: IONA votes on Components FTF Vote 5 > > > >Ignacio and I talked over resolution 3419, and reached common understanding >but not resolution. While writing this summary I came up with a possible >resolution. I'll summarize our understanding first and then outline my >proposal. > >==== Summary of conversation > >There are basically 3 places where bridging can happen: >1. In client address space. >2. In server address space. >3. In a separate bridge process. > >Part of the debate over 3419 was just misunderstanding of language. I took >"client side" to mean 1 only, whereas Ignacio takes it to mean either 1 or >3 at vendor discretion, but with 3 being a "client side phenomenon" - i.e. >regardless of whether bridging is in or out of the client process, it's up >to client-side configuration to organize for bridging to happen. The server >should not be involved. > >My counter-point is that you can make a symmetrical argument that the >client should be protected, which suggests that 2 or "3 on the server side" >is the way to go. > >We agreed that there are arguments for both sides, we failed to agree that >the arguments on either side are sufficiently compelling to mandate one or >the other. The worry is that without mandating, we risk incompatibility >between different vendor offerings. To add to the fun remember we have to >think about EJB clients of CCMs as well as vice-versa, so we have to solve >this problem in both directions. > >==== My suggested resolution: > >Rather than mandate one approach, we can weed out few sensible levels of >EJB-interop compliance for a CCM implementation, so vendors have the choice >but must clearly state the level at which they provide EJB interop, not in >terms of where bridging happens, but in terms of what the implementation >can talk to: > >NONE: No built-in EJB support. We should allow this because you can still >potentially get interop via an external bridge by some other vendor or with >a "CCM-aware" EJB implementation. > >CLIENT: Provides tools to build CCM clients that can make calls on >unmodified, CCM-unaware EJB servers. This implies client-side bridging, >either in stubs or a separate bridge process. May require re-configuring or >re-building the client to talk to a native CCM vs. an EJB (yuk!) > >SERVER: Allows unmodified CCM-unaware EJB clients to call on EJB views of >CCM components, while simultaneously allowing native CCM clients to to call >on the CCM views of those components. There may be separte IORs for the EJB >view and the CCM view (it's conceivable a clever server could publish a >single IOR and figure out the conversions on the fly, but I'd be skeptical >and definitely wouldn't mandate this.) Implies server-side bridging, either >in the CCM server itself or a separate bridge process.. > >FULL: Satisfies both CLIENT and SERVER. This will leave the user some >flexibility at configuration/deployment time about where to do the bridging >for their application, but as Thomas pointed out in his scenarios e-mail, >users may need this flexibilty in migrating systems. Implies either >stand-alone briding or a combination of client and server side. > >Note that CLIENT and SERVER are not incompatible, because SERVER requires >that both native CCM and native EJB clients be able to access an >appropriate view (possibly thru separate IORs) and CLIENT requires that you >can build a client to talk to either an EJB or a native CCM (possibly at >the cost of rebuilding the client.) Indeed a CCM client with translating >stubs could actually talk to an EJB view on a translating CCM server! > >Obviously FULL is the most desirable level of compliance because it is >guaranteed to inter-operate with anything, but the lower levels are all >likely to be useful in sufficiently important scenarios. The simplest >implementation of FULL is an out-of-process bridge, but it doesn't rule out >a combination of many-flavored client stubs and server-side skeleton or >interceptor bridging if that's the way the vendor(s) want to go. > >Hope this is moving us forward, please comment early because I'm leaving on >vacation from Jan 10-22 and I'd like to see some agreement before I go. > >Cheers, >Alan. > > > >Alan Conway, Senior Engineer, IONA Technologies. >E-mail: alan.conway@iona.com Tel: +1(819)843-5859 >Snail-mail: 660 Genest, Magog, QC, J1X 4Y7, Canada. > > > > > > ************************************************************** Ed Cobb, Vice President, Advanced Technology & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8942 / Mobile: 408-464-0733 E-mail: ed.cobb@bea.com ************************************************************** [] components-ftf - Issue 3419.htm Importance: Normal Subject: Re: CCM Issues To: Philippe.Merle@lifl.fr Cc: components-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Ignacio Silva-Lepe" Date: Mon, 27 Aug 2001 14:08:32 -0400 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 5.0.8 |June 18, 2001) at 08/27/2001 02:08:33 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: P,~!!O<(!!]d$e92dQd9 Hello Philippe, About Issue 3419 and the use of CCMException (see your attached comments on the resolution of the issue). The cases in which I have introduced it do not seem to me to be appropriate for any other CCM exception, that's why I used it. Since a CORBA system exception (as I understand it) cannot be listed in raises expressions (at least that's true for standard exceptions) then the ambiguity creeps up again about what a particular implementation should do (ie, which specific standard exception to raise). Perhaps it would be better to raise a new issue to add CCMException to the signature of the methods in question. Is this bound to become too big an issue to resolve? -- Ignacio Your comment: I don't agree with Issue 3419 because if EJB RemoteException exceptions are translated to Components::CCMException then we also need to change signatures of the related CCMObject and CCMHome operations to add CCMException in their raises clause. I will prefer to use CORBA system exceptions here or CreateFailure, FinderFailure and RemoveFailure when they are appropriate. Ignacio Silva-Lepe IBM T. J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598, USA INTERNET: isilval@us.ibm.com WWW: http://www.zgnews.com/silva Phone: (914) 784 7003 Fax: (914) 784 6040 From: Philippe.Merle@lifl.fr Received: from (merle@localhost) by karjala.lifl.fr (8.9.1b+Sun/jtpda-5.3.3) id KAA28667 ; Tue, 28 Aug 2001 10:40:59 +0200 (MET DST) Date: Tue, 28 Aug 2001 10:40:59 +0200 (MET DST) Message-Id: <200108280840.KAA28667@karjala.lifl.fr> To: isilval@us.ibm.com Subject: Re: CCM Issues Cc: components-ftf@omg.org X-Sun-Charset: US-ASCII Content-Type: text X-UIDL: /[ed92_@!! Subject: Re: CCM Issues > From: "Ignacio Silva-Lepe" > > Hello Philippe, > > About Issue 3419 and the use of CCMException (see your attached > comments on > the resolution of the issue). The cases in which I have introduced > it do > not seem to me to be appropriate for any other CCM exception, that's > why I > used it. Since a CORBA system exception (as I understand it) cannot > be > listed in raises expressions (at least that's true for standard > exceptions) > then the ambiguity creeps up again about what a particular > implementation > should do (ie, which specific standard exception to raise). Perhaps > it > would be better to raise a new issue to add CCMException to the > signature > of the methods in question. Is this bound to become too big an issue > to > resolve? The CCM to EJB mapping (and vice-versa) is based on top of the RMI/IDL specification. As I was not already a Java to IDL expert, I have firstly read the " Java to IDL Mapping 1.1 Specification " (formal/01-06-07) before having an opinion. In formal/01-06-07 section 1.4.7 page 1-33, the spec says : " 1.4.7 Mapping RMI Exceptions to CORBA System Exceptions To ensure correct RMI exception passing semantics when running over IIOP, all Java exceptions thrown by the server implementation must be passed back to the client. Exceptions that are instances of (or subclasses of) RMI/IDL exception types declared by the method are marshaled as user exceptions in the usual way. All other Java exceptions are marshaled as CORBA UNKNOWN system exceptions whose GIOP Reply message includes an UnknownExceptionInfo service context containing the marshaled Java exception thrown by the server implementation. The Java exception is marshaled using the rules for CDR marshaling of value types as defined by the GIOP specification, applied in conjunction with the rules for mapping RMI/IDL value types to IDL as defined in Section 1.3.5, Mapping for RMI/IDL Value Types, on page 1-14 of this specification. " And section 1.4.8 page 1-33 provides mapping rules for some standard RMI exceptions to equivalent standard CORBA system exceptions. COMM_FAILURE java.rmi.MarshalException INV_OBJREF java.rmi.NoSuchObjectException NO_PERMISSION java.rmi.AccessException MARSHAL java.rmi.MarshalException BAD_PARAM java.rmi.MarshalException OBJECT_NOT_EXIST java.rmi.NoSuchObjectException TRANSACTION_REQUIRED javax.transaction.TransactionRequiredException TRANSACTION_ROLLEDBACK javax.transaction.TransactionRolledbackException INVALID_TRANSACTION javax.transaction.InvalidTransactionException Then I think that, in your resolution for Issue 3419, you just should say that any Java RMI RemoteException raised by an EJB operation is mapped to a CORBA system exception according to rules defined in formal/01-06-07 sections 1.4.7 and 1.4.8. Then this allows us to define a clear semantics for the CCM to EJB mapping without requiring to add CCMException to some CCMObject and CCMHome operations. > -- Ignacio > > Your comment: > > I don't agree with Issue 3419 because if EJB RemoteException exceptions are > translated to Components::CCMException then we also need to change > signatures of the related CCMObject and CCMHome operations to add > CCMException in their raises clause. I will prefer to use CORBA system > exceptions here or CreateFailure, FinderFailure and RemoveFailure when they > are appropriate. > > Ignacio Silva-Lepe > IBM T. J. Watson Research Center > P.O. Box 704 Yorktown Heights, NY 10598, USA > INTERNET: isilval@us.ibm.com > WWW: http://www.zgnews.com/silva > Phone: (914) 784 7003 Fax: (914) 784 6040 > A+ Philippe Merle -- ___________________________________________________________________________ Dr. Philippe Merle - Associate Researcher at INRIA Laboratoire d'Informatique Fondamentale de Lille UPRESA 8022 CNRS - U.F.R. I.E.E.A. - Batiment M3 Universite des Sciences et Technologies de Lille 59655 Villeneuve d'Ascq CEDEX France Tel: (33) (0)3 20 43 47 21 Fax: (33) (0)3 20 43 65 66 E-Mail: Philippe.Merle@lifl.fr Home Page: http://www.lifl.fr/~merle See also: http://corbaweb.lifl.fr/ ___________________________________________________________________________ Importance: Normal Subject: Re: CCM Issues To: Philippe.Merle@lifl.fr Cc: components-ftf@omg.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Ignacio Silva-Lepe" Date: Tue, 28 Aug 2001 10:05:05 -0400 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 5.0.8 |June 18, 2001) at 08/28/2001 10:05:09 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: -X@e9fKOe9eb5e9>]`!! Ok, using the RMI/IDL rules for translating RemoteException back and forth sounds reasonable. It is not as explicit in the definition of the method signatures, but it seems that that's precisely what we are trying to avoid. So, if there is no other objection, I will use Philippe's proposal. -- Ignacio Ignacio Silva-Lepe IBM T. J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598, USA INTERNET: isilval@us.ibm.com WWW: http://www.zgnews.com/silva Phone: (914) 784 7003 Fax: (914) 784 6040 Philippe.Merle@lifl.fr on 08/28/2001 04:40:59 AM To: Ignacio Silva-Lepe/Watson/IBM@IBMUS cc: components-ftf@omg.org Subject: Re: CCM Issues Hello Ignacio, > Subject: Re: CCM Issues > From: "Ignacio Silva-Lepe" > > Hello Philippe, > > About Issue 3419 and the use of CCMException (see your attached > comments on > the resolution of the issue). The cases in which I have introduced > it do > not seem to me to be appropriate for any other CCM exception, that's > why I > used it. Since a CORBA system exception (as I understand it) cannot > be > listed in raises expressions (at least that's true for standard exceptions) > then the ambiguity creeps up again about what a particular > implementation > should do (ie, which specific standard exception to raise). Perhaps > it > would be better to raise a new issue to add CCMException to the > signature > of the methods in question. Is this bound to become too big an issue > to > resolve? The CCM to EJB mapping (and vice-versa) is based on top of the RMI/IDL specification. As I was not already a Java to IDL expert, I have firstly read the " Java to IDL Mapping 1.1 Specification " (formal/01-06-07) before having an opinion. In formal/01-06-07 section 1.4.7 page 1-33, the spec says : " 1.4.7 Mapping RMI Exceptions to CORBA System Exceptions To ensure correct RMI exception passing semantics when running over IIOP, all Java exceptions thrown by the server implementation must be passed back to the client. Exceptions that are instances of (or subclasses of) RMI/IDL exception types declared by the method are marshaled as user exceptions in the usual way. All other Java exceptions are marshaled as CORBA UNKNOWN system exceptions whose GIOP Reply message includes an UnknownExceptionInfo service context containing the marshaled Java exception thrown by the server implementation. The Java exception is marshaled using the rules for CDR marshaling of value types as defined by the GIOP specification, applied in conjunction with the rules for mapping RMI/IDL value types to IDL as defined in Section 1.3.5, Mapping for RMI/IDL Value Types, on page 1-14 of this specification. " And section 1.4.8 page 1-33 provides mapping rules for some standard RMI exceptions to equivalent standard CORBA system exceptions. COMM_FAILURE java.rmi.MarshalException INV_OBJREF java.rmi.NoSuchObjectException NO_PERMISSION java.rmi.AccessException MARSHAL java.rmi.MarshalException BAD_PARAM java.rmi.MarshalException OBJECT_NOT_EXIST java.rmi.NoSuchObjectException TRANSACTION_REQUIRED javax.transaction.TransactionRequiredException TRANSACTION_ROLLEDBACK javax.transaction.TransactionRolledbackException INVALID_TRANSACTION javax.transaction.InvalidTransactionException Then I think that, in your resolution for Issue 3419, you just should say that any Java RMI RemoteException raised by an EJB operation is mapped to a CORBA system exception according to rules defined in formal/01-06-07 sections 1.4.7 and 1.4.8. Then this allows us to define a clear semantics for the CCM to EJB mapping without requiring to add CCMException to some CCMObject and CCMHome operations. > -- Ignacio > > Your comment: > > I don't agree with Issue 3419 because if EJB RemoteException >exceptions are > translated to Components::CCMException then we also need to change > signatures of the related CCMObject and CCMHome operations to add > CCMException in their raises clause. I will prefer to use CORBA >system > exceptions here or CreateFailure, FinderFailure and RemoveFailure >when they > are appropriate. > > Ignacio Silva-Lepe > IBM T. J. Watson Research Center > P.O. Box 704 Yorktown Heights, NY 10598, USA > INTERNET: isilval@us.ibm.com > WWW: http://www.zgnews.com/silva > Phone: (914) 784 7003 Fax: (914) 784 6040 > A+ Philippe Merle -- ___________________________________________________________________________ Dr. Philippe Merle - Associate Researcher at INRIA Laboratoire d'Informatique Fondamentale de Lille UPRESA 8022 CNRS - U.F.R. I.E.E.A. - Batiment M3 Universite des Sciences et Technologies de Lille 59655 Villeneuve d'Ascq CEDEX France Tel: (33) (0)3 20 43 47 21 Fax: (33) (0)3 20 43 65 66 E-Mail: Philippe.Merle@lifl.fr Home Page: http://www.lifl.fr/~merle See also: http://corbaweb.lifl.fr/ ___________________________________________________________________________ Importance: Normal Subject: Qs and Cs To: Philippe.Merle@lifl.fr Cc: components-ftf@omg.org, andrew@omg.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Ignacio Silva-Lepe" Date: Fri, 9 Nov 2001 10:54:40 -0500 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 5.0.8 |June 18, 2001) at 11/09/2001 10:54:41 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: GmAe9+j"!!Ad,e9/>(!! Hello Philippe, I have a few questions and clarifications: 1- It seems to me that issue 3419 does not entail a support text change only, and it probably does so a significant change. The main issue is to require implementors to provide certain level of support for interoperability. If you agree, I'll report it as significant change. 2- This reminds me about the whole EJB integration topic. Are we going to complete the FTF with this chapter still in? I suppose what I am asking is whether any of the implementors has accounted for it. If not, then we may not be able to keep it in the spec, will we? 3- I understand that implementors will have until Nov 30/2002 to deliver an implementation. Does this mean that the spec can be delivered without knowing what parts of it will ultimately be implemented? 4- Do implementors have a description of their implementations and how they impact the shape of the spec? Anyhow, I am not trying to undo all the hard work that's been done and that has brought us so close to successfully completing the FTF. So, in particular, I am hoping that the answers to 2 and 3 are 'yes'. Those AB members amongst us, any comments? -- Ignacio Ignacio Silva-Lepe IBM T. J. Watson Research Center P.O. Box 704 Yorktown Heights, NY 10598, USA INTERNET: isilval@us.ibm.com WWW: http://www.zgnews.com/silva Phone: (914) 784 7003 Fax: (914) 784 6040 From: Jeffrey Mischkinsky Message-Id: <200111091623.IAA26325@wheel.dcn.davis.ca.us> Subject: Re: Qs and Cs To: isilval@us.ibm.com (Ignacio Silva-Lepe) Date: Fri, 9 Nov 2001 08:23:01 -0800 (PST) Cc: Philippe.Merle@lifl.fr, components-ftf@omg.org, andrew@omg.org, soley@omg.org In-Reply-To: from "Ignacio Silva-Lepe" at Nov 09, 2001 10:54:40 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: 0cQd9@e:!!P/Qd9'F"!! 'Ignacio Silva-Lepe' writes: > > Hello Philippe, > > I have a few questions and clarifications: > > 1- It seems to me that issue 3419 does not entail a support text change > only, and it probably does so a significant change. The main issue is to > require implementors to provide certain level of support for > interoperability. If you agree, I'll report it as significant change. > 2- This reminds me about the whole EJB integration topic. Are we going to > complete the FTF with this chapter still in? I suppose what I am asking is > whether any of the implementors has accounted for it. If not, then we may > not be able to keep it in the spec, will we? > 3- I understand that implementors will have until Nov 30/2002 to deliver an > implementation. Does this mean that the spec can be delivered without > knowing what parts of it will ultimately be implemented? I don't think so. The whole point of the ftf process and the implementation delivery req was to restore some integrity to the omg's "commercial availability" req. Basically the idea was that if 2 years after adopting a spec, and 3+ years after submitters swore on a figurative stack of bibles that what they were proposing was existing technology that would be shortly productized, there STILL wasn't an implementation (not even a comercially available product), then it's time to give it up. How can one possibly say that an FTF is completed with no implementation, when the whole point of "finalization" is to demonstrate that the finalized spec is implementable? > 4- Do implementors have a description of their implementations and how they > impact the shape of the spec? > > Anyhow, I am not trying to undo all the hard work that's been done and that > has brought us so close to successfully completing the FTF. So, in > particular, I am hoping that the answers to 2 and 3 are 'yes'. Those AB > members amongst us, any comments? I'm not either. I would really like to see a successful fruition of all the efforts of the many people who've been involved in CCM. Lots of people have put lots of energy into it since the RFP was issued way back at the Stresa meeting, in May 97 or 98 I think it was. jeff > > -- Ignacio > > Ignacio Silva-Lepe > IBM T. J. Watson Research Center > P.O. Box 704 Yorktown Heights, NY 10598, USA > INTERNET: isilval@us.ibm.com > WWW: http://www.zgnews.com/silva > Phone: (914) 784 7003 Fax: (914) 784 6040 > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff.mischkinsky@oracle.com +1 650-506-1975 From: Philippe.Merle@lifl.fr Received: from (merle@localhost) by karjala.lifl.fr (8.9.1b+Sun/jtpda-5.3.3) id RAA01786 ; Fri, 9 Nov 2001 17:41:18 +0100 (MET) Date: Fri, 9 Nov 2001 17:41:18 +0100 (MET) Message-Id: <200111091641.RAA01786@karjala.lifl.fr> To: isilval@us.ibm.com Subject: Re: Qs and Cs Cc: components-ftf@omg.org, andrew@omg.org X-Sun-Charset: US-ASCII Content-Type: text X-UIDL: i<:e9gWXd9~] Subject: Qs and Cs > From: "Ignacio Silva-Lepe" > > Hello Philippe, > > I have a few questions and clarifications: > > 1- It seems to me that issue 3419 does not entail a support text > change > only, and it probably does so a significant change. The main issue > is to > require implementors to provide certain level of support for > interoperability. If you agree, I'll report it as significant > change. I agree and will include this change into the final report. > 2- This reminds me about the whole EJB integration topic. Are we going to > complete the FTF with this chapter still in? I suppose what I am asking is > whether any of the implementors has accounted for it. If not, then we may > not be able to keep it in the spec, will we? I hope that commercial CCM implementations will provide this part. > 3- I understand that implementors will have until Nov 30/2002 to deliver an > implementation. Does this mean that the spec can be delivered without > knowing what parts of it will ultimately be implemented? As any OMG specs, first products don't implement all expected features. Next releases will provide these missed features according to market needs. > 4- Do implementors have a description of their implementations and how they > impact the shape of the spec? For our OpenCCM implementation, see http://corbaweb.lifl.fr/OpenCCM/ http://corbaweb.lifl.fr/OpenCCM/docs/1st_ObjectWeb_Conference.ps http://corbaweb.lifl.fr/OpenCCM/docs/1st_ObjectWeb_Conference_flyer.pdf > > Anyhow, I am not trying to undo all the hard work that's been done > and that > has brought us so close to successfully completing the FTF. So, in > particular, I am hoping that the answers to 2 and 3 are 'yes'. Those > AB > members amongst us, any comments? > > -- Ignacio > > Ignacio Silva-Lepe > IBM T. J. Watson Research Center > P.O. Box 704 Yorktown Heights, NY 10598, USA > INTERNET: isilval@us.ibm.com > WWW: http://www.zgnews.com/silva > Phone: (914) 784 7003 Fax: (914) 784 6040 > A+ Philippe Merle -- ___________________________________________________________________________ Dr. Philippe Merle - Associate Researcher at INRIA Laboratoire d'Informatique Fondamentale de Lille UPRESA 8022 CNRS - U.F.R. I.E.E.A. - Batiment M3 Universite des Sciences et Technologies de Lille 59655 Villeneuve d'Ascq CEDEX France Tel: (33) (0)3 20 43 47 21 Fax: (33) (0)3 20 43 65 66 E-Mail: Philippe.Merle@lifl.fr Home Page: http://www.lifl.fr/~merle See also: http://corbaweb.lifl.fr/ ___________________________________________________________________________ Date: Fri, 9 Nov 2001 18:05:49 +0100 From: 520065607613-0001@t-online.de (Frank Pilhofer) To: Ignacio Silva-Lepe Cc: Philippe.Merle@lifl.fr, components-ftf@omg.org, andrew@omg.org Subject: Re: Qs and Cs Message-ID: <20011109180549.C520@rose.fpx.de> Reply-To: Frank Pilhofer References: Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from isilval@us.ibm.com on Fri, Nov 09, 2001 at 10:54:40AM -0500 X-Sender: 520065607613-0001@t-dialin.net Content-Type: text/plain; charset=us-ascii X-UIDL: p8T!!^>L!!;j#!![9X!! Ignacio Silva-Lepe wrote: > > 3- I understand that implementors will have until Nov 30/2002 to deliver an > implementation. Does this mean that the spec can be delivered without > knowing what parts of it will ultimately be implemented? > At Danvers we had a discussion with Andrew Watson, and this was what we read between the lines of the current Policies and Procedures: there must be an implementation one year after the end of the last FTF, else the specification becomes unadopted. So the answer to your question is yes. > > 4- Do implementors have a description of their implementations and >how they > impact the shape of the spec? > Alcatel/FPX has an implementation for extended service and session components so far. I think that between all of the implementors, a large part of the spec is already covered. EJB interoperability may be a blind spot here, I don't know if anybody's working on that. Frank -- Frank Pilhofer ........................................... fp@fpx.de Isn't it amazing how political candidates can give you all their good points and qualifications in a thirty-second TV commercial? - A. E. Neuman X-Sender: evans@mail.cpi.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 09 Nov 2001 13:10:24 -0500 To: Frank Pilhofer , Ignacio Silva-Lepe From: "J. Scott Evans" Subject: Re: Qs and Cs Cc: Philippe.Merle@lifl.fr, components-ftf@omg.org, andrew@omg.org In-Reply-To: <20011109180549.C520@rose.fpx.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: :ged95A(e9Si%!!pTZd9 Hi Ignacio, At 06:05 PM 11/9/01 +0100, Frank Pilhofer wrote: Ignacio Silva-Lepe wrote: > > 3- I understand that implementors will have until Nov 30/2002 to deliver an > implementation. Does this mean that the spec can be delivered without > knowing what parts of it will ultimately be implemented? > At Danvers we had a discussion with Andrew Watson, and this was what we read between the lines of the current Policies and Procedures: there must be an implementation one year after the end of the last FTF, else the specification becomes unadopted. So the answer to your question is yes. I'd second this opinion. I'd also qualify Frank's statement a little in that I believe that no single implementation must implement ALL of the spec. Rather, all of the spec must be demonstrated that it can be implemented (through one or more implementations). I'm pretty confident that as a group we will be able to demonstrate by 11/30/02 that all of the spec can be implemented. > > 4- Do implementors have a description of their implementations and >how they > impact the shape of the spec? > Alcatel/FPX has an implementation for extended service and session components so far. I think that between all of the implementors, a large part of the spec is already covered. EJB interoperability may be a blind spot here, I don't know if anybody's working on that. CPI has an implementation for extended service, session, process, and entity components with CIDL compiler for monolithic segments including container managed persistence using PSS. We also have implemented most of the deployment API but there are quite a few use cases/scenarios that can be created with the descriptors and we only support a few use cases. Our implementation still requires update to resolutions of vote 8 assuming it passes. We don't have transaction or security but that is expected by 11/30/02. I doubt that we will tackle EJB interoperability any time soon so I hope that someone else will be able to make the attempt by 11/30/02. My two cents. Scott Frank -- Frank Pilhofer ........................................... fp@fpx.de Isn't it amazing how political candidates can give you all their good points and qualifications in a thirty-second TV commercial? - A. E. Neuman