Issue 5108: J2EE ORB Socket Factory API (java-rtf) Source: International Business Machines (Ms. Anne E. Collins, nobody) Nature: Uncategorized Issue Severity: Summary: In order to meet the interoperability compliance requirements, ORBs must include an IIOP implementation using TCP/IP plain text sockets. J2EE implementations are required to support CSIv2 and thus need additional control over the sockets an ORB creates. It may be necessary - to get the ORB to listen on additional sockets, of differing types - to get the ORB to connect to alternative sockets, of different types, for a given IOR - for information about these sockets to be included in object references exported by the ORB - for socket data to be available to request interceptors, e.g SSL certificates Portable IORInterceptors can be used to add this information as tagged components in the profiles within an IOR. A mechanism is required to modify the ORB's behaviour to allow it to handle different socket types, listen on additional sockets, connect to alternative sockets and make additional data available to interceptors. Since this is a J2EE requirement which needs speedy resolution, it seems appropriate to resolve it by the addition of Java specific APIs in the IDL to Java specification. For example, - a pluggable ORB socket factory could be introduced which would be used whenever the ORB needed to create a serverSocket or an outbound socket for a given IOR or end point - a means of registering such a socket factory would be required. Options for this include:- . adding an ORB method: this may cause problems in initialisation . adding a Java specific extension to the PI ORBInitInfo interface so that the registration would need to be called from the pre_init/post_init methods in an ORBInitializer: this ties the Socket Factory with PIs, but both are likely to be required for J2EE. - a means of specifying ports on which an ORB/POA should listen would be useful but this may be infeasible as part of this issue due to the variety of ORB/POA implementations. - the PI Client and ServerRequestInfo and IORInfo interfaces may need to be extended to support access to Connection related data Resolution: Revised Text: Actions taken: April 9, 2002: received issue Discussion: End of Annotations:===== Subject: Re: J2EE ORB Socket Factory API To: java-rtf@omg.org Cc: issues@omg.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Ann Dalton1" Date: Tue, 9 Apr 2002 11:50:48 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a |January 7, 2002) at 09/04/2002 11:49:59 In order to meet the interoperability compliance requirements, ORBs must include an IIOP implementation using TCP/IP plain text sockets. J2EE implementations are required to support CSIv2 and thus need additional control over the sockets an ORB creates. It may be necessary - to get the ORB to listen on additional sockets, of differing types - to get the ORB to connect to alternative sockets, of different types, for a given IOR - for information about these sockets to be included in object references exported by the ORB - for socket data to be available to request interceptors, e.g SSL certificates Portable IORInterceptors can be used to add this information as tagged components in the profiles within an IOR. A mechanism is required to modify the ORB's behaviour to allow it to handle different socket types, listen on additional sockets, connect to alternative sockets and make additional data available to interceptors. Since this is a J2EE requirement which needs speedy resolution, it seems appropriate to resolve it by the addition of Java specific APIs in the IDL to Java specification. For example, - a pluggable ORB socket factory could be introduced which would be used whenever the ORB needed to create a serverSocket or an outbound socket for a given IOR or end point - a means of registering such a socket factory would be required. Options for this include:- . adding an ORB method: this may cause problems in initialisation . adding a Java specific extension to the PI ORBInitInfo interface so that the registration would need to be called from the pre_init/post_init methods in an ORBInitializer: this ties the Socket Factory with PIs, but both are likely to be required for J2EE. - a means of specifying ports on which an ORB/POA should listen would be useful but this may be infeasible as part of this issue due to the variety of ORB/POA implementations. - the PI Client and ServerRequestInfo and IORInfo interfaces may need to be extended to support access to Connection related data Comments/thoughts would be appreciated before I draft a proposal to address this. X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Apr 2002 11:56:44 -0700 To: "Ann Dalton1" , java-rtf@omg.org From: Andy Piper Subject: Re: J2EE ORB Socket Factory API Correct me if I'm wrong, but doesn't the Sun JDK have all these features (especially JDK 1.4)? So are we just talking about standardizing what is already out there? Either way its a good thing. Thanks andy At 11:50 AM 4/9/02 +0100, Ann Dalton1 wrote: In order to meet the interoperability compliance requirements, ORBs must include an IIOP implementation using TCP/IP plain text sockets. J2EE implementations are required to support CSIv2 and thus need additional control over the sockets an ORB creates. It may be necessary - to get the ORB to listen on additional sockets, of differing types - to get the ORB to connect to alternative sockets, of different types, for a given IOR - for information about these sockets to be included in object references exported by the ORB - for socket data to be available to request interceptors, e.g SSL certificates Portable IORInterceptors can be used to add this information as tagged components in the profiles within an IOR. A mechanism is required to modify the ORB's behaviour to allow it to handle different socket types, listen on additional sockets, connect to alternative sockets and make additional data available to interceptors. Since this is a J2EE requirement which needs speedy resolution, it seems appropriate to resolve it by the addition of Java specific APIs in the IDL to Java specification. For example, - a pluggable ORB socket factory could be introduced which would be used whenever the ORB needed to create a serverSocket or an outbound socket for a given IOR or end point - a means of registering such a socket factory would be required. Options for this include:- . adding an ORB method: this may cause problems in initialisation . adding a Java specific extension to the PI ORBInitInfo interface so that the registration would need to be called from the pre_init/post_init methods in an ORBInitializer: this ties the Socket Factory with PIs, but both are likely to be required for J2EE. - a means of specifying ports on which an ORB/POA should listen would be useful but this may be infeasible as part of this issue due to the variety of ORB/POA implementations. - the PI Client and ServerRequestInfo and IORInfo interfaces may need to be extended to support access to Connection related data Comments/thoughts would be appreciated before I draft a proposal to address this. Subject: Re: J2EE ORB Socket Factory API To: Andy Piper Cc: java-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Ann Dalton1" Date: Wed, 10 Apr 2002 20:16:30 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a |January 7, 2002) at 10/04/2002 20:15:40 Andy, Yes, we are talking about standardising the features currently present, in proprietary form, in the Sun and other JDKs. Ann Andy Piper To: Ann Dalton1/UK/IBM@IBMGB, java-rtf@omg.org cc: 10/04/2002 19:56 Subject: Re: J2EE ORB Socket Factory API Please respond to Andy Piper Correct me if I'm wrong, but doesn't the Sun JDK have all these features (especially JDK 1.4)? So are we just talking about standardizing what is already out there? Either way its a good thing. Thanks andy At 11:50 AM 4/9/02 +0100, Ann Dalton1 wrote: >In order to meet the interoperability compliance requirements, >ORBs must include an IIOP implementation using TCP/IP plain text >sockets. J2EE implementations are required to support CSIv2 and X-Authentication-Warning: emerald.omg.org: hobbit.omg.org [192.67.184.3] didn't use HELO protocol Date: Thu, 11 Apr 2002 11:04:52 +0100 From: Eoghan Glynn X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Ann Dalton1 CC: java-rtf@omg.org, issues@omg.org Subject: Re: J2EE ORB Socket Factory API X-OriginalArrivalTime: 11 Apr 2002 10:04:53.0036 (UTC) FILETIME=[53094EC0:01C1E140] Ann, Have you considered that there are ORB implementations where the ORB core is completely unaware of the details of Socket/ServerSocket creation and instead these are handled by separate transport plugins (e.g. IIOP, TLS, multicast etc)? I don't see a strong case in your mail for standardizing the mechanisms used to control the behaviour of these transport components. Its inevitable that different ORB implementations will have existing proprietary mechanisms which differ radically, for example driven via configuration, policies, or programmatically. It would be difficult to reconcile these mechanisms to a single standard without favouring some at the expense of others. Its also completely unclear how this mechanism would work for an ORB that's not tightly bound to TCP-based transports. Finally how do you propose to accomodate the different mechanisms used to create sockets in the java.net and java.nio packages? Regards, Eoghan. Ann Dalton1 wrote: > > In order to meet the interoperability compliance requirements, > ORBs must include an IIOP implementation using TCP/IP plain text > sockets. J2EE implementations are required to support CSIv2 and > thus need additional control over the sockets an ORB creates. > It may be necessary > - to get the ORB to listen on additional sockets, of differing > types > - to get the ORB to connect to alternative sockets, of different > types, for a given IOR > - for information about these sockets to be included in object > references exported by the ORB > - for socket data to be available to request interceptors, e.g > SSL certificates > > Portable IORInterceptors can be used to add this information as > tagged components in the profiles within an IOR. > > A mechanism is required to modify the ORB's behaviour to allow > it to handle different socket types, listen on additional sockets, > connect to alternative sockets and make additional data available > to interceptors. > > Since this is a J2EE requirement which needs speedy resolution, > it seems appropriate to resolve it by the addition of Java > specific APIs in the IDL to Java specification. For example, > > - a pluggable ORB socket factory could be introduced which would > be used whenever the ORB needed to create a serverSocket or an > outbound socket for a given IOR or end point > > - a means of registering such a socket factory would be required. > Options for this include:- > . adding an ORB method: this may cause problems in initialisation > . adding a Java specific extension to the PI ORBInitInfo interface > so that the registration would need to be called from the > pre_init/post_init methods in an ORBInitializer: this ties the > Socket Factory with PIs, but both are likely to be required > for J2EE. > > - a means of specifying ports on which an ORB/POA should listen > would be useful but this may be infeasible as part of this issue > due to the variety of ORB/POA implementations. > > - the PI Client and ServerRequestInfo and IORInfo interfaces may > need to be extended to support access to Connection related data > > Comments/thoughts would be appreciated before I draft a proposal to > address this. -- Eoghan Glynn, Principal Engineer, IONA Technologies. "END 2 ANYWHERE" http://www.iona.com The IONA Building mailto:eglynn@iona.com Shelbourne Road tel :+353-1-6372439 Ballsbridge cell:+353-86-8175024 Dublin 4 Ireland Subject: Re: J2EE ORB Socket Factory API To: Eoghan Glynn Cc: issues@omg.org, java-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Ann Dalton1" Date: Thu, 11 Apr 2002 13:45:09 +0100 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a |January 7, 2002) at 11/04/2002 13:44:25 Eoghan, Thanks for considering this. Yes, I had considered ORB implementations with separate Transport plugins, especially since ours is one such. I should perhaps have made it clearer that this proposal applies to the IIOP transport, rather than the ORB per se. I'm seeking only to standardize the behaviour for IIOP as that is mandated for CORBA interop compliance, and extensions to it are required for any J2EE implementation. Any ORB that doesn't support IIOP wouldn't support this extension to it. I had thought that introduction of a simple SocketFactory mechanism would not impact any IIOP implementation greatly. Is this still a concern in the light of the above? It seemed to me that a socket factory could be consistent with both net and nio. I anticipate that the object created by the ORBSocketFactory would be an ORBSocket, an instance of an interface that mirrors java.net.Socket (or a subset thereof if we could agree on one). The ORBSocket implementation could delegate to, or be a subclass of, java.net.Socket, or not, and may or may not be SocketChannel aware. However, I haven't looked at nio in detail so would really appreciate your thoughts on any problems or difficulties you foresee with that approach. Many thanks, Ann Eoghan Glynn To: Ann Dalton1/UK/IBM@IBMGB cc: java-rtf@omg.org, issues@omg.org 11/04/2002 11:04 Subject: Re: J2EE ORB Socket Factory API Please respond to Eoghan Glynn Ann, Have you considered that there are ORB implementations where the ORB core is completely unaware of the details of Socket/ServerSocket creation and instead these are handled by separate transport plugins (e.g. IIOP, TLS, multicast etc)? I don't see a strong case in your mail for standardizing the mechanisms used to control the behaviour of these transport components. Its inevitable that different ORB implementations will have existing proprietary mechanisms which differ radically, for example driven via configuration, policies, or programmatically. It would be difficult to reconcile these mechanisms to a single standard without favouring some at the expense of others. Its also completely unclear how this mechanism would work for an ORB that's not tightly bound to TCP-based transports. Finally how do you propose to accomodate the different mechanisms used to create sockets in the java.net and java.nio packages? Regards, Eoghan. Ann Dalton1 wrote: > > In order to meet the interoperability compliance requirements, > ORBs must include an IIOP implementation using TCP/IP plain text > sockets. J2EE implementations are required to support CSIv2 and > thus need additional control over the sockets an ORB creates. > It may be necessary > - to get the ORB to listen on additional sockets, of differing > types > - to get the ORB to connect to alternative sockets, of different > types, for a given IOR > - for information about these sockets to be included in object > references exported by the ORB > - for socket data to be available to request interceptors, e.g > SSL certificates > > Portable IORInterceptors can be used to add this information as > tagged components in the profiles within an IOR. > > A mechanism is required to modify the ORB's behaviour to allow > it to handle different socket types, listen on additional sockets, > connect to alternative sockets and make additional data available > to interceptors. > > Since this is a J2EE requirement which needs speedy resolution, > it seems appropriate to resolve it by the addition of Java > specific APIs in the IDL to Java specification. For example, > > - a pluggable ORB socket factory could be introduced which would > be used whenever the ORB needed to create a serverSocket or an > outbound socket for a given IOR or end point > > - a means of registering such a socket factory would be required. > Options for this include:- > . adding an ORB method: this may cause problems in initialisation > . adding a Java specific extension to the PI ORBInitInfo interface > so that the registration would need to be called from the > pre_init/post_init methods in an ORBInitializer: this ties the > Socket Factory with PIs, but both are likely to be required > for J2EE. > > - a means of specifying ports on which an ORB/POA should listen > would be useful but this may be infeasible as part of this issue > due to the variety of ORB/POA implementations. > > - the PI Client and ServerRequestInfo and IORInfo interfaces may > need to be extended to support access to Connection related data > > Comments/thoughts would be appreciated before I draft a proposal to > address this. -- Eoghan Glynn, Principal Engineer, IONA Technologies. "END 2 ANYWHERE" http://www.iona.com The IONA Building mailto:eglynn@iona.com Shelbourne Road tel :+353-1-6372439 Ballsbridge cell:+353-86-8175024 Dublin 4 Ireland Date: Thu, 11 Apr 2002 14:43:49 +0100 From: Eoghan Glynn X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Ann Dalton1 CC: issues@omg.org, java-rtf@omg.org Subject: Re: J2EE ORB Socket Factory API X-OriginalArrivalTime: 11 Apr 2002 13:43:50.0805 (UTC) FILETIME=[E9C1C450:01C1E15E] Anne, I'm still very uneasy about the prospect of exposing and standardizing what are in my opinion fundamental ORB implementation details. On the java.nio front, the mechanisms used to create, monitor and read/write to a SocketChannel are fundamentally different to the java.net.Socket case. For example, an IIOP plugin written to use java.net.Socket would generally need to emulate async reads for the next incoming GIOP message via a synchronous read on a separate thread per connection. On the other hand, an IIOP plugin based on SocketChannels would generally use a single selector thread to monitor multiple connections for activity. These fundamentally different modes of operation cannot be reconciled simply by facading the channel behind an interface that mirrors java.net.Socket as you suggest. Given that we already have two different Java network I/O models, its possible there may be others in the future - constraining ORBs to use standardized SocketFactories would IMO act as a blocker to ORB vendors adopting new network I/O models such as java.nio. Limiting the standardized SocketFactory to IIOP does not necessarily limit the impact on an ORB implementation. For example, our ORB encapsulates the transport layer in a separate plugin that's used by IIOP, TLS, HTTP and other TCP-based protocols. Let me step back and ask why you're proposing to allow the application control socket creation? If its just intended to allow control over whether a normal or secure socket is created in order to disable/enable CSIv2, then surely standardized security policies would provide a much better mechanism than allowing application to directly control socket creation? Finally, I also see serious issues in allowing the application control the allocation of listen ports in a standardized way, as there are so many propreitary and vendor-specific mechanisms at work here, for example: - configuration of fixed well-known ports and port ranges - proxification of IORs to enable concentrators and firewalls - server replication, fault tolerance and load balancing straregies based on encoding multiple addresses in IORs (via multiple IIOP - profiles and/or TAG_ALTERNATE_IIOP_ADDRESS components) - activation/location mechanisms based on forwarding agents - re-directing clients to servers, where servers register addressing info upfront - with the forwarding agent Regards, Eoghan. Ann Dalton1 wrote: > > Eoghan, > Thanks for considering this. > > Yes, I had considered ORB implementations with separate Transport > plugins, especially since ours is one such. I should perhaps have made > it clearer that this proposal applies to the IIOP transport, rather > than the ORB per se. > > I'm seeking only to standardize the behaviour for IIOP as that is > mandated for CORBA interop compliance, and extensions to it are > required for any J2EE implementation. Any ORB that doesn't support > IIOP wouldn't support this extension to it. > > I had thought that introduction of a simple SocketFactory mechanism > would not impact any IIOP implementation greatly. Is this still a > concern in the light of the above? > > It seemed to me that a socket factory could be consistent with both > net and nio. I anticipate that the object created by the > ORBSocketFactory would be an ORBSocket, an instance of an interface > that mirrors java.net.Socket (or a subset thereof if we could agree > on one). The ORBSocket implementation could delegate to, or be a > subclass of, java.net.Socket, or not, and may or may not be > SocketChannel aware. > However, I haven't looked at nio in detail so would really appreciate > your thoughts on any problems or difficulties you foresee with that > approach. > > Many thanks, > Ann > > > Eoghan Glynn > To: Ann Dalton1/UK/IBM@IBMGB > cc: java-rtf@omg.org, issues@omg.org > 11/04/2002 11:04 Subject: Re: J2EE ORB Socket Factory API > Please respond to > Eoghan Glynn > > > > Ann, > > Have you considered that there are ORB implementations where the ORB > core is completely unaware of the details of Socket/ServerSocket > creation and instead these are handled by separate transport plugins > (e.g. IIOP, TLS, multicast etc)? > > I don't see a strong case in your mail for standardizing the mechanisms > used to control the behaviour of these transport components. > > Its inevitable that different ORB implementations will have existing > proprietary mechanisms which differ radically, for example driven via > configuration, policies, or programmatically. It would be difficult to > reconcile these mechanisms to a single standard without favouring some > at the expense of others. > > Its also completely unclear how this mechanism would work for an ORB > that's not tightly bound to TCP-based transports. > > Finally how do you propose to accomodate the different mechanisms used > to create sockets in the java.net and java.nio packages? > > Regards, > Eoghan. > > Ann Dalton1 wrote: > > > > In order to meet the interoperability compliance requirements, > > ORBs must include an IIOP implementation using TCP/IP plain text > > sockets. J2EE implementations are required to support CSIv2 and > > thus need additional control over the sockets an ORB creates. > > It may be necessary > > - to get the ORB to listen on additional sockets, of differing > > types > > - to get the ORB to connect to alternative sockets, of different > > types, for a given IOR > > - for information about these sockets to be included in object > > references exported by the ORB > > - for socket data to be available to request interceptors, e.g > > SSL certificates > > > > Portable IORInterceptors can be used to add this information as > > tagged components in the profiles within an IOR. > > > > A mechanism is required to modify the ORB's behaviour to allow > > it to handle different socket types, listen on additional sockets, > > connect to alternative sockets and make additional data available > > to interceptors. > > > > Since this is a J2EE requirement which needs speedy resolution, > > it seems appropriate to resolve it by the addition of Java > > specific APIs in the IDL to Java specification. For example, > > > > - a pluggable ORB socket factory could be introduced which would > > be used whenever the ORB needed to create a serverSocket or an > > outbound socket for a given IOR or end point > > > > - a means of registering such a socket factory would be required. > > Options for this include:- > > . adding an ORB method: this may cause problems in initialisation > > . adding a Java specific extension to the PI ORBInitInfo interface > > so that the registration would need to be called from the > > pre_init/post_init methods in an ORBInitializer: this ties the > > Socket Factory with PIs, but both are likely to be required > > for J2EE. > > > > - a means of specifying ports on which an ORB/POA should listen > > would be useful but this may be infeasible as part of this issue > > due to the variety of ORB/POA implementations. > > > > - the PI Client and ServerRequestInfo and IORInfo interfaces may > > need to be extended to support access to Connection related data > > > > Comments/thoughts would be appreciated before I draft a proposal to > > address this. -- Eoghan Glynn, Principal Engineer, IONA Technologies. "END 2 ANYWHERE" http://www.iona.com The IONA Building mailto:eglynn@iona.com Shelbourne Road tel :+353-1-6372439 Ballsbridge cell:+353-86-8175024 Dublin 4 Ireland Date: Thu, 11 Apr 2002 11:56:27 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard Company X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: "Manfred R. Koethe" Cc: Ann Dalton1 , Eoghan Glynn , corba-rtf@omg.org, java-rtf@omg.org Subject: Re: J2EE ORB Socket Factory API "Manfred R. Koethe" wrote: > > Ann and Eoghan, > > First, I took the liberty to remove "issues" from the distribution > list (to give Juergen a rest :-) ), but added the corba-rtf, since > this really needs their attention.... > > On the thechnical matters, I'm very concerned to standardize internal > interfaces vital to the ORB implementation. This would impose a > serious limitation and would be an obstacle for high-performance > implementations. Eoghan's idea to introduce a standardized *policy*, > which instructs the ORB on the desired behavior is IMHO the right > way to address this problem. > > Regards, > > Manfred One thing worth mentioning here is that this sort of extension for enhancing portability of functionality within J2EE could be carried out either at the OMG or through JCP. I think if something like this is done, it is better that it happen through the OMG, since it is an extension of an OMG standard. However, at the end of the day OMG has no way of preventing this from happening through JCP. I suspect that to make implemenetations of things like CSIv2 truly portable in J2EE, this sort of a mechanism either via policy or via interface is necessary. Let us hope that we can figure out a way for the right thing to happen at the right place. Jishnu. Date: Thu, 11 Apr 2002 12:03:31 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard Company X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: "Manfred R. Koethe" Cc: Ann Dalton1 , Eoghan Glynn , corba-rtf@omg.org, java-rtf@omg.org Subject: Re: J2EE ORB Socket Factory API "Manfred R. Koethe" wrote: > > Ann and Eoghan, > > First, I took the liberty to remove "issues" from the distribution > list (to giv Juergen a rest :-) ), but added the corba-rtf, since > this really needs their attention.... Actually, my preference would be to not get Core RTF involved in this, since this is a special requirement to enable a certain kind of portability in Java only. We have done this sort of differentiation between Java and other language platforms in the past in terms of providing binary portability in Java and not in others. So please focus the discussion of this issue at least for now in the Java RTF and not in Core RTF. It is currently a Java RTF issue 5108. So until the Java RTF after due consideration decides to send it to Core RTF, it is a Java RTF issue. Thanks, Jishnu Mukerji Chair CORBA Core RTF Date: Thu, 11 Apr 2002 09:18:42 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: J2EE ORB Socket Factory API To: ann_dalton@uk.ibm.com, eglynn@iona.com Cc: java-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc >From: Eoghan Glynn >X-Accept-Language: en >MIME-Version: 1.0 >To: Ann Dalton1 >CC: issues@omg.org, java-rtf@omg.org >Subject: Re: J2EE ORB Socket Factory API Eohgan, You mail makes many good points. I want to respond quickly to one point in particular: > >Let me step back and ask why you're proposing to allow the >application >control socket creation? If its just intended to allow control over >whether a normal or secure socket is created in order to >disable/enable >CSIv2, then surely standardized security policies would provide a >much >better mechanism than allowing application to directly control socket >creation? > I'm not sure that this can be done without putting the CSIv2 implementation in the ORB core. I do not want CSIv2 in the ORB code. Our current implementation plugs CSIv2 in using interceptors and the socket factory. A policy on the server side would imply putting the construction of the rather complex CSIv2 tagged components into the ORB. It would also create a new level of APIs related to CSIv2 to pass in certificate information to the ORB. Ken. Date: Thu, 11 Apr 2002 17:51:54 +0100 From: Eoghan Glynn X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Ken Cavanaugh CC: ann_dalton@uk.ibm.com, java-rtf@omg.org Subject: Re: J2EE ORB Socket Factory API X-OriginalArrivalTime: 11 Apr 2002 16:51:56.0684 (UTC) FILETIME=[30AA3CC0:01C1E179] Ken, I don't understand why a policy-based approach to enabling CSIv2 would necessarily pollute the ORB core with CSIv2 details. If the ORB's CSIv2 support is sufficiently encapsulated, for example in a plugin outside the ORB core, then the details of CSIv2 tagged components etc. could be hidden from the ORB core. If a policy-driven mechanism is not sufficient in itself and additional APIs are required to specify CSIv2 certs then so be it - this seems a much better approach than exposing socket creation. The additional APIs need not be defined on the ORB itself, but rather on say a CSIv2Admin interface which is accessed via ORB::resolve_initial_references(). Regards, Eoghan. Ken Cavanaugh wrote: > > >Let me step back and ask why you're proposing to allow the application > >control socket creation? If its just intended to allow control over > >whether a normal or secure socket is created in order to disable/enable > >CSIv2, then surely standardized security policies would provide a much > >better mechanism than allowing application to directly control socket > >creation? > > > > I'm not sure that this can be done without putting the CSIv2 implementation > in the ORB core. I do not want CSIv2 in the ORB code. Our current > implementation plugs CSIv2 in using interceptors and the socket factory. > A policy on the server side would imply putting the construction of > the rather complex CSIv2 tagged components into the ORB. It would also > create a new level of APIs related to CSIv2 to pass in certificate > information to the ORB. > > Ken. -- Eoghan Glynn, Principal Engineer, IONA Technologies. "END 2 ANYWHERE" http://www.iona.com The IONA Building mailto:eglynn@iona.com Shelbourne Road tel :+353-1-6372439 Ballsbridge cell:+353-86-8175024 Dublin 4 Ireland X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 11 Apr 2002 10:49:03 -0700 To: "Manfred R. Koethe" , Ann Dalton1 From: Andy Piper Subject: Re: J2EE ORB Socket Factory API Cc: Eoghan Glynn , corba-rtf@omg.org, java-rtf@omg.org Just to add some datapoints. We currently already use both IBM's and Sun's proprietary mechanisms for doing this. It would be much better for us if it was standardized. Standard but optional would be much better IMO than just plain proprietary. I agree that making it mandatory imposes too many burdens on Orb implementations, and heaven knows quite enough of the implementation is specified already :) You could actually argue that this requirement is specific to J2SE implementations (of which IBM and Sun each have one). So maybe a JCP *would* be a better route for this discussion. Thanks andy At 10:52 AM 4/11/02 -0400, Manfred R. Koethe wrote: Ann and Eoghan, First, I took the liberty to remove "issues" from the distribution list (to giv Juergen a rest :-) ), but added the corba-rtf, since this really needs their attention.... On the thechnical matters, I'm very concerned to standardize internal interfaces vital to the ORB implementation. This would impose a serious limitation and would be an obstacle for high-performance implementations. Eoghan's idea to introduce a standardized *policy*, which instructs the ORB on the desired behavior is IMHO the right way to address this problem. Regards, Manfred Eoghan Glynn wrote: Anne, I'm still very uneasy about the prospect of exposing and standardizing what are in my opinion fundamental ORB implementation details. On the java.nio front, the mechanisms used to create, monitor and read/write to a SocketChannel are fundamentally different to the java.net.Socket case. For example, an IIOP plugin written to use java.net.Socket would generally need to emulate async reads for the next incoming GIOP message via a synchronous read on a separate thread per connection. On the other hand, an IIOP plugin based on SocketChannels would generally use a single selector thread to monitor multiple connections for activity. These fundamentally different modes of operation cannot be reconciled simply by facading the channel behind an interface that mirrors java.net.Socket as you suggest. Given that we already have two different Java network I/O models, its possible there may be others in the future - constraining ORBs to use standardized SocketFactories would IMO act as a blocker to ORB vendors adopting new network I/O models such as java.nio. Limiting the standardized SocketFactory to IIOP does not necessarily limit the impact on an ORB implementation. For example, our ORB encapsulates the transport layer in a separate plugin that's used by IIOP, TLS, HTTP and other TCP-based protocols. Let me step back and ask why you're proposing to allow the application control socket creation? If its just intended to allow control over whether a normal or secure socket is created in order to disable/enable CSIv2, then surely standardized security policies would provide a much better mechanism than allowing application to directly control socket creation? Finally, I also see serious issues in allowing the application control the allocation of listen ports in a standardized way, as there are so many propreitary and vendor-specific mechanisms at work here, for example: - configuration of fixed well-known ports and port ranges - proxification of IORs to enable concentrators and firewalls - server replication, fault tolerance and load balancing straregies based on encoding multiple addresses in IORs (via multiple IIOP profiles and/or TAG_ALTERNATE_IIOP_ADDRESS components) - activation/location mechanisms based on forwarding agents re-directing clients to servers, where servers register addressing info upfront with the forwarding agent Regards, Eoghan. Ann Dalton1 wrote: Eoghan, Thanks for considering this. Yes, I had considered ORB implementations with separate Transport plugins, especially since ours is one such. I should perhaps have made it clearer that this proposal applies to the IIOP transport, rather than the ORB per se. I'm seeking only to standardize the behaviour for IIOP as that is mandated for CORBA interop compliance, and extensions to it are required for any J2EE implementation. Any ORB that doesn't support IIOP wouldn't support this extension to it. I had thought that introduction of a simple SocketFactory mechanism would not impact any IIOP implementation greatly. Is this still a concern in the light of the above? It seemed to me that a socket factory could be consistent with both net and nio. I anticipate that the object created by the ORBSocketFactory would be an ORBSocket, an instance of an interface that mirrors java.net.Socket (or a subset thereof if we could agree on one). The ORBSocket implementation could delegate to, or be a subclass of, java.net.Socket, or not, and may or may not be SocketChannel aware. However, I haven't looked at nio in detail so would really appreciate your thoughts on any problems or difficulties you foresee with that approach. Many thanks, Ann Eoghan Glynn To: Ann Dalton1/UK/IBM@IBMGB cc: java-rtf@omg.org, issues@omg.org 11/04/2002 11:04 Subject: Re: J2EE ORB Socket Factory API Please respond to Eoghan Glynn Ann, Have you considered that there are ORB implementations where the ORB core is completely unaware of the details of Socket/ServerSocket creation and instead these are handled by separate transport plugins (e.g. IIOP, TLS, multicast etc)? I don't see a strong case in your mail for standardizing the mechanisms used to control the behaviour of these transport components. Its inevitable that different ORB implementations will have existing proprietary mechanisms which differ radically, for example driven via configuration, policies, or programmatically. It would be difficult to reconcile these mechanisms to a single standard without favouring some at the expense of others. Its also completely unclear how this mechanism would work for an ORB that's not tightly bound to TCP-based transports. Finally how do you propose to accomodate the different mechanisms used to create sockets in the java.net and java.nio packages? Regards, Eoghan. Ann Dalton1 wrote: In order to meet the interoperability compliance requirements, ORBs must include an IIOP implementation using TCP/IP plain text sockets. J2EE implementations are required to support CSIv2 and thus need additional control over the sockets an ORB creates. It may be necessary - to get the ORB to listen on additional sockets, of differing types - to get the ORB to connect to alternative sockets, of different types, for a given IOR - for information about these sockets to be included in object references exported by the ORB - for socket data to be available to request interceptors, e.g SSL certificates Portable IORInterceptors can be used to add this information as tagged components in the profiles within an IOR. A mechanism is required to modify the ORB's behaviour to allow it to handle different socket types, listen on additional sockets, connect to alternative sockets and make additional data available to interceptors. Since this is a J2EE requirement which needs speedy resolution, it seems appropriate to resolve it by the addition of Java specific APIs in the IDL to Java specification. For example, - a pluggable ORB socket factory could be introduced which would be used whenever the ORB needed to create a serverSocket or an outbound socket for a given IOR or end point - a means of registering such a socket factory would be required. Options for this include:- . adding an ORB method: this may cause problems in initialisation . adding a Java specific extension to the PI ORBInitInfo interface so that the registration would need to be called from the pre_init/post_init methods in an ORBInitializer: this ties the Socket Factory with PIs, but both are likely to be required for J2EE. - a means of specifying ports on which an ORB/POA should listen would be useful but this may be infeasible as part of this issue due to the variety of ORB/POA implementations. - the PI Client and ServerRequestInfo and IORInfo interfaces may need to be extended to support access to Connection related data Comments/thoughts would be appreciated before I draft a proposal to address this. -- ___________________ / Manfred R. Koethe \_____________________________________ 88solutions Corp. E-Mail: koethe@88solutions.com 37 Mague Avenue Tel: +1 (617) 916 5886 Newton, MA 02465-1553 FAX: +1 (617) 916 5887 U.S.A. _____________________________"We make your business flow"_ X-Sender: ecobb@santa-clara.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 11 Apr 2002 11:08:10 -0700 To: Andy Piper , "Manfred R. Koethe" , Ann Dalton1 From: Edward Cobb Subject: Re: J2EE ORB Socket Factory API Cc: Eoghan Glynn , corba-rtf@omg.org, java-rtf@omg.org I don't think the JCP is the right venue to address this problem. Since OMG owns the core technology, there is a danger of diversion of you go down that track. Much safer to keep it all together in OMG. I agree with Jishnu. Long before there was a J2EE (some of us remember that), it was an OMG objective to provide portability for Java APIs as well as interoperability. The fact that the CSIv2 spec did not meet that objective means that one of the Java RTFs gets to fix it. At 10:49 AM 4/11/2002 -0700, Andy Piper wrote: Just to add some datapoints. We currently already use both IBM's and Sun's proprietary mechanisms for doing this. It would be much better for us if it was standardized. Standard but optional would be much better IMO than just plain proprietary. I agree that making it mandatory imposes too many burdens on Orb implementations, and heaven knows quite enough of the implementation is specified already :) You could actually argue that this requirement is specific to J2SE implementations (of which IBM and Sun each have one). So maybe a JCP *would* be a better route for this discussion. Thanks andy At 10:52 AM 4/11/02 -0400, Manfred R. Koethe wrote: Ann and Eoghan, First, I took the liberty to remove "issues" from the distribution list (to giv Juergen a rest :-) ), but added the corba-rtf, since this really needs their attention.... On the thechnical matters, I'm very concerned to standardize internal interfaces vital to the ORB implementation. This would impose a serious limitation and would be an obstacle for high-performance implementations. Eoghan's idea to introduce a standardized *policy*, which instructs the ORB on the desired behavior is IMHO the right way to address this problem. Regards, Manfred Eoghan Glynn wrote: Anne, I'm still very uneasy about the prospect of exposing and standardizing what are in my opinion fundamental ORB implementation details. On the java.nio front, the mechanisms used to create, monitor and read/write to a SocketChannel are fundamentally different to the java.net.Socket case. For example, an IIOP plugin written to use java.net.Socket would generally need to emulate async reads for the next incoming GIOP message via a synchronous read on a separate thread per connection. On the other hand, an IIOP plugin based on SocketChannels would generally use a single selector thread to monitor multiple connections for activity. These fundamentally different modes of operation cannot be reconciled simply by facading the channel behind an interface that mirrors java.net.Socket as you suggest. Given that we already have two different Java network I/O models, its possible there may be others in the future - constraining ORBs to use standardized SocketFactories would IMO act as a blocker to ORB vendors adopting new network I/O models such as java.nio. Limiting the standardized SocketFactory to IIOP does not necessarily limit the impact on an ORB implementation. For example, our ORB encapsulates the transport layer in a separate plugin that's used by IIOP, TLS, HTTP and other TCP-based protocols. Let me step back and ask why you're proposing to allow the application control socket creation? If its just intended to allow control over whether a normal or secure socket is created in order to disable/enable CSIv2, then surely standardized security policies would provide a much better mechanism than allowing application to directly control socket creation? Finally, I also see serious issues in allowing the application control the allocation of listen ports in a standardized way, as there are so many propreitary and vendor-specific mechanisms at work here, for example: - configuration of fixed well-known ports and port ranges - proxification of IORs to enable concentrators and firewalls - server replication, fault tolerance and load balancing straregies based on encoding multiple addresses in IORs (via multiple IIOP profiles and/or TAG_ALTERNATE_IIOP_ADDRESS components) - activation/location mechanisms based on forwarding agents re-directing clients to servers, where servers register addressing info upfront with the forwarding agent Regards, Eoghan. Ann Dalton1 wrote: Eoghan, Thanks for considering this. Yes, I had considered ORB implementations with separate Transport plugins, especially since ours is one such. I should perhaps have made it clearer that this proposal applies to the IIOP transport, rather than the ORB per se. I'm seeking only to standardize the behaviour for IIOP as that is mandated for CORBA interop compliance, and extensions to it are required for any J2EE implementation. Any ORB that doesn't support IIOP wouldn't support this extension to it. I had thought that introduction of a simple SocketFactory mechanism would not impact any IIOP implementation greatly. Is this still a concern in the light of the above? It seemed to me that a socket factory could be consistent with both net and nio. I anticipate that the object created by the ORBSocketFactory would be an ORBSocket, an instance of an interface that mirrors java.net.Socket (or a subset thereof if we could agree on one). The ORBSocket implementation could delegate to, or be a subclass of, java.net.Socket, or not, and may or may not be SocketChannel aware. However, I haven't looked at nio in detail so would really appreciate your thoughts on any problems or difficulties you foresee with that approach. Many thanks, Ann Eoghan Glynn To: Ann Dalton1/UK/IBM@IBMGB cc: java-rtf@omg.org, issues@omg.org 11/04/2002 11:04 Subject: Re: J2EE ORB Socket Factory API Please respond to Eoghan Glynn Ann, Have you considered that there are ORB implementations where the ORB core is completely unaware of the details of Socket/ServerSocket creation and instead these are handled by separate transport plugins (e.g. IIOP, TLS, multicast etc)? I don't see a strong case in your mail for standardizing the mechanisms used to control the behaviour of these transport components. Its inevitable that different ORB implementations will have existing proprietary mechanisms which differ radically, for example driven via configuration, policies, or programmatically. It would be difficult to reconcile these mechanisms to a single standard without favouring some at the expense of others. Its also completely unclear how this mechanism would work for an ORB that's not tightly bound to TCP-based transports. Finally how do you propose to accomodate the different mechanisms used to create sockets in the java.net and java.nio packages? Regards, Eoghan. Ann Dalton1 wrote: In order to meet the interoperability compliance requirements, ORBs must include an IIOP implementation using TCP/IP plain text sockets. J2EE implementations are required to support CSIv2 and thus need additional control over the sockets an ORB creates. It may be necessary - to get the ORB to listen on additional sockets, of differing types - to get the ORB to connect to alternative sockets, of different types, for a given IOR - for information about these sockets to be included in object references exported by the ORB - for socket data to be available to request interceptors, e.g SSL certificates Portable IORInterceptors can be used to add this information as tagged components in the profiles within an IOR. A mechanism is required to modify the ORB's behaviour to allow it to handle different socket types, listen on additional sockets, connect to alternative sockets and make additional data available to interceptors. Since this is a J2EE requirement which needs speedy resolution, it seems appropriate to resolve it by the addition of Java specific APIs in the IDL to Java specification. For example, - a pluggable ORB socket factory could be introduced which would be used whenever the ORB needed to create a serverSocket or an outbound socket for a given IOR or end point - a means of registering such a socket factory would be required. Options for this include:- . adding an ORB method: this may cause problems in initialisation . adding a Java specific extension to the PI ORBInitInfo interface so that the registration would need to be called from the pre_init/post_init methods in an ORBInitializer: this ties the Socket Factory with PIs, but both are likely to be required for J2EE. - a means of specifying ports on which an ORB/POA should listen would be useful but this may be infeasible as part of this issue due to the variety of ORB/POA implementations. - the PI Client and ServerRequestInfo and IORInfo interfaces may need to be extended to support access to Connection related data Comments/thoughts would be appreciated before I draft a proposal to address this. -- ___________________ / Manfred R. Koethe \_____________________________________ 88solutions Corp. E-Mail: koethe@88solutions.com 37 Mague Avenue Tel: +1 (617) 916 5886 Newton, MA 02465-1553 FAX: +1 (617) 916 5887 U.S.A. _____________________________"We make your business flow"_ ************************************************************** Edward Cobb, Vice President, Architecture & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8914 / Mobile: 408-464-0733 E-mail: ed.cobb@bea.com / Wireless: ecobb@palm.com ************************************************************** Date: Fri, 12 Apr 2002 09:07:26 +0100 From: Eoghan Glynn X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Andy Piper CC: "Manfred R. Koethe" , Ann Dalton1 , corba-rtf@omg.org, java-rtf@omg.org Subject: Re: J2EE ORB Socket Factory API X-OriginalArrivalTime: 12 Apr 2002 08:07:21.0928 (UTC) FILETIME=[12A95C80:01C1E1F9] Andy, I think we may be stepping close to the line between discussing what's righteous for the spec, and what's convenient for individual implementations. I definitely see the value in providing a standard mechanism to enable CSIv2 - I'm concerned though that exposing an ORB socket factory to achieve this is at completely the wrong level of abstraction. Regards, Eoghan. Andy Piper wrote: > > Just to add some datapoints. We currently already use both IBM's and Sun's > proprietary mechanisms for doing this. It would be much better for us if it > was standardized. Standard but optional would be much better IMO than just > plain proprietary. I agree that making it mandatory imposes too many > burdens on Orb implementations, and heaven knows quite enough of the > implementation is specified already :) > > You could actually argue that this requirement is specific to J2SE > implementations (of which IBM and Sun each have one). So maybe a JCP > *would* be a better route for this discussion. > > Thanks > > andy > > At 10:52 AM 4/11/02 -0400, Manfred R. Koethe wrote: > >Ann and Eoghan, > > > >First, I took the liberty to remove "issues" from the distribution > >list (to giv Juergen a rest :-) ), but added the corba-rtf, since > >this really needs their attention.... > > > >On the thechnical matters, I'm very concerned to standardize internal > >interfaces vital to the ORB implementation. This would impose a > >serious limitation and would be an obstacle for high-performance > >implementations. Eoghan's idea to introduce a standardized *policy*, > >which instructs the ORB on the desired behavior is IMHO the right > >way to address this problem. > > > >Regards, > > > >Manfred > > > >Eoghan Glynn wrote: > > > >>Anne, > >>I'm still very uneasy about the prospect of exposing and standardizing > >>what are in my opinion fundamental ORB implementation details. > >>On the java.nio front, the mechanisms used to create, monitor and > >>read/write to a SocketChannel are fundamentally different to the > >>java.net.Socket case. For example, an IIOP plugin written to use > >>java.net.Socket would generally need to emulate async reads for the next > >>incoming GIOP message via a synchronous read on a separate thread per > >>connection. On the other hand, an IIOP plugin based on SocketChannels > >>would generally use a single selector thread to monitor multiple > >>connections for activity. These fundamentally different modes of > >>operation cannot be reconciled simply by facading the channel behind an > >>interface that mirrors java.net.Socket as you suggest. > >>Given that we already have two different Java network I/O models, its > >>possible there may be others in the future - constraining ORBs to use > >>standardized SocketFactories would IMO act as a blocker to ORB vendors > >>adopting new network I/O models such as java.nio. > >>Limiting the standardized SocketFactory to IIOP does not necessarily > >>limit the impact on an ORB implementation. For example, our ORB > >>encapsulates the transport layer in a separate plugin that's used by > >>IIOP, TLS, HTTP and other TCP-based protocols. > >>Let me step back and ask why you're proposing to allow the application > >>control socket creation? If its just intended to allow control over > >>whether a normal or secure socket is created in order to disable/enable > >>CSIv2, then surely standardized security policies would provide a much > >>better mechanism than allowing application to directly control socket > >>creation? > >>Finally, I also see serious issues in allowing the application control > >>the allocation of listen ports in a standardized way, as there are so > >>many propreitary and vendor-specific mechanisms at work here, for > >>example: > >>- configuration of fixed well-known ports and port ranges > >>- proxification of IORs to enable concentrators and firewalls > >>- server replication, fault tolerance and load balancing straregies > >>based on encoding multiple addresses in IORs (via multiple IIOP profiles > >>and/or TAG_ALTERNATE_IIOP_ADDRESS components) > >>- activation/location mechanisms based on forwarding agents re-directing > >>clients to servers, where servers register addressing info upfront with > >>the forwarding agent > >>Regards, > >>Eoghan. > >>Ann Dalton1 wrote: > >> > >>>Eoghan, > >>>Thanks for considering this. > >>> > >>>Yes, I had considered ORB implementations with separate Transport > >>>plugins, especially since ours is one such. I should perhaps have made > >>>it clearer that this proposal applies to the IIOP transport, rather > >>>than the ORB per se. > >>> > >>>I'm seeking only to standardize the behaviour for IIOP as that is > >>>mandated for CORBA interop compliance, and extensions to it are > >>>required for any J2EE implementation. Any ORB that doesn't support > >>>IIOP wouldn't support this extension to it. > >>> > >>>I had thought that introduction of a simple SocketFactory mechanism > >>>would not impact any IIOP implementation greatly. Is this still a > >>>concern in the light of the above? > >>> > >>>It seemed to me that a socket factory could be consistent with both > >>>net and nio. I anticipate that the object created by the > >>>ORBSocketFactory would be an ORBSocket, an instance of an interface > >>>that mirrors java.net.Socket (or a subset thereof if we could agree > >>>on one). The ORBSocket implementation could delegate to, or be a > >>>subclass of, java.net.Socket, or not, and may or may not be > >>>SocketChannel aware. > >>>However, I haven't looked at nio in detail so would really appreciate > >>>your thoughts on any problems or difficulties you foresee with that > >>>approach. > >>> > >>>Many thanks, > >>>Ann > >>> > >>> > >>> Eoghan Glynn > >>> To: Ann > >>> Dalton1/UK/IBM@IBMGB > >>> cc: > >>> java-rtf@omg.org, issues@omg.org > >>> 11/04/2002 11:04 Subject: Re: J2EE ORB > >>> Socket Factory API > >>> Please respond to > >>> Eoghan Glynn > >>> > >>> > >>> > >>>Ann, > >>> > >>>Have you considered that there are ORB implementations where the ORB > >>>core is completely unaware of the details of Socket/ServerSocket > >>>creation and instead these are handled by separate transport plugins > >>>(e.g. IIOP, TLS, multicast etc)? > >>> > >>>I don't see a strong case in your mail for standardizing the mechanisms > >>>used to control the behaviour of these transport components. > >>> > >>>Its inevitable that different ORB implementations will have existing > >>>proprietary mechanisms which differ radically, for example driven via > >>>configuration, policies, or programmatically. It would be difficult to > >>>reconcile these mechanisms to a single standard without favouring some > >>>at the expense of others. > >>> > >>>Its also completely unclear how this mechanism would work for an ORB > >>>that's not tightly bound to TCP-based transports. > >>> > >>>Finally how do you propose to accomodate the different mechanisms used > >>>to create sockets in the java.net and java.nio packages? > >>> > >>>Regards, > >>>Eoghan. > >>> > >>>Ann Dalton1 wrote: > >>> > >>>>In order to meet the interoperability compliance requirements, > >>>>ORBs must include an IIOP implementation using TCP/IP plain text > >>>>sockets. J2EE implementations are required to support CSIv2 and > >>>>thus need additional control over the sockets an ORB creates. > >>>>It may be necessary > >>>>- to get the ORB to listen on additional sockets, of differing > >>>> types > >>>>- to get the ORB to connect to alternative sockets, of different > >>>> types, for a given IOR > >>>>- for information about these sockets to be included in object > >>>> references exported by the ORB > >>>>- for socket data to be available to request interceptors, e.g > >>>> SSL certificates > >>>> > >>>>Portable IORInterceptors can be used to add this information as > >>>>tagged components in the profiles within an IOR. > >>>> > >>>>A mechanism is required to modify the ORB's behaviour to allow > >>>>it to handle different socket types, listen on additional sockets, > >>>>connect to alternative sockets and make additional data available > >>>>to interceptors. > >>>> > >>>>Since this is a J2EE requirement which needs speedy resolution, > >>>>it seems appropriate to resolve it by the addition of Java > >>>>specific APIs in the IDL to Java specification. For example, > >>>> > >>>>- a pluggable ORB socket factory could be introduced which would > >>>> be used whenever the ORB needed to create a serverSocket or an > >>>> outbound socket for a given IOR or end point > >>>> > >>>>- a means of registering such a socket factory would be required. > >>>> Options for this include:- > >>>> . adding an ORB method: this may cause problems in initialisation > >>>> . adding a Java specific extension to the PI ORBInitInfo interface > >>>> so that the registration would need to be called from the > >>>> pre_init/post_init methods in an ORBInitializer: this ties the > >>>> Socket Factory with PIs, but both are likely to be required > >>>> for J2EE. > >>>> > >>>>- a means of specifying ports on which an ORB/POA should listen > >>>> would be useful but this may be infeasible as part of this issue > >>>> due to the variety of ORB/POA implementations. > >>>> > >>>>- the PI Client and ServerRequestInfo and IORInfo interfaces may > >>>> need to be extended to support access to Connection related data > >>>> > >>>>Comments/thoughts would be appreciated before I draft a proposal to > >>>>address this. > > > > > >-- > > ___________________ > >/ Manfred R. Koethe \_____________________________________ > > 88solutions Corp. E-Mail: koethe@88solutions.com > > 37 Mague Avenue Tel: +1 (617) 916 5886 > > Newton, MA 02465-1553 FAX: +1 (617) 916 5887 > > U.S.A. > >_____________________________"We make your business flow"_ > > > > -- Eoghan Glynn, Principal Engineer, IONA Technologies. "END 2 ANYWHERE" http://www.iona.com The IONA Building mailto:eglynn@iona.com Shelbourne Road tel :+353-1-6372439 Ballsbridge cell:+353-86-8175024 Dublin 4 Ireland Date: Fri, 12 Apr 2002 09:07:29 +0100 From: Eoghan Glynn X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Edward Cobb CC: Andy Piper , "Manfred R. Koethe" , Ann Dalton1 , corba-rtf@omg.org, java-rtf@omg.org Subject: Re: J2EE ORB Socket Factory API X-OriginalArrivalTime: 12 Apr 2002 08:07:24.0162 (UTC) FILETIME=[13FE3E20:01C1E1F9] Edward, Agreed that providing Java CSIv2 portability is good objective. My concern is that an inappropriately low-level approach (exposing an ORB socket factory) has been proposed to achieve this. Regards, Eoghan Edward Cobb wrote: > > I don't think the JCP is the right venue to address this problem. > Since OMG owns the core technology, there is a danger of diversion of you > go down that track. Much safer to keep it all together in OMG. > I agree with Jishnu. Long before there was a J2EE (some of us > remember that), it was an OMG objective to provide portability for Java > APIs as well as interoperability. The fact that the CSIv2 spec did not meet > that objective means that one of the Java RTFs gets to fix it. > > At 10:49 AM 4/11/2002 -0700, Andy Piper wrote: > >Just to add some datapoints. We currently already use both IBM's and Sun's > >proprietary mechanisms for doing this. It would be much better for us if > >it was standardized. Standard but optional would be much better IMO than > >just plain proprietary. I agree that making it mandatory imposes too many > >burdens on Orb implementations, and heaven knows quite enough of the > >implementation is specified already :) > > > >You could actually argue that this requirement is specific to J2SE > >implementations (of which IBM and Sun each have one). So maybe a JCP > >*would* be a better route for this discussion. > > > >Thanks > > > >andy > > > >At 10:52 AM 4/11/02 -0400, Manfred R. Koethe wrote: > >>Ann and Eoghan, > >> > >>First, I took the liberty to remove "issues" from the distribution > >>list (to giv Juergen a rest :-) ), but added the corba-rtf, since > >>this really needs their attention.... > >> > >>On the thechnical matters, I'm very concerned to standardize internal > >>interfaces vital to the ORB implementation. This would impose a > >>serious limitation and would be an obstacle for high-performance > >>implementations. Eoghan's idea to introduce a standardized *policy*, > >>which instructs the ORB on the desired behavior is IMHO the right > >>way to address this problem. > >> > >>Regards, > >> > >>Manfred > >> > >>Eoghan Glynn wrote: > >> > >>>Anne, > >>>I'm still very uneasy about the prospect of exposing and standardizing > >>>what are in my opinion fundamental ORB implementation details. > >>>On the java.nio front, the mechanisms used to create, monitor and > >>>read/write to a SocketChannel are fundamentally different to the > >>>java.net.Socket case. For example, an IIOP plugin written to use > >>>java.net.Socket would generally need to emulate async reads for the next > >>>incoming GIOP message via a synchronous read on a separate thread per > >>>connection. On the other hand, an IIOP plugin based on SocketChannels > >>>would generally use a single selector thread to monitor multiple > >>>connections for activity. These fundamentally different modes of > >>>operation cannot be reconciled simply by facading the channel behind an > >>>interface that mirrors java.net.Socket as you suggest. > >>>Given that we already have two different Java network I/O models, its > >>>possible there may be others in the future - constraining ORBs to use > >>>standardized SocketFactories would IMO act as a blocker to ORB vendors > >>>adopting new network I/O models such as java.nio. > >>>Limiting the standardized SocketFactory to IIOP does not necessarily > >>>limit the impact on an ORB implementation. For example, our ORB > >>>encapsulates the transport layer in a separate plugin that's used by > >>>IIOP, TLS, HTTP and other TCP-based protocols. > >>>Let me step back and ask why you're proposing to allow the application > >>>control socket creation? If its just intended to allow control over > >>>whether a normal or secure socket is created in order to disable/enable > >>>CSIv2, then surely standardized security policies would provide a much > >>>better mechanism than allowing application to directly control socket > >>>creation? > >>>Finally, I also see serious issues in allowing the application control > >>>the allocation of listen ports in a standardized way, as there are so > >>>many propreitary and vendor-specific mechanisms at work here, for > >>>example: > >>>- configuration of fixed well-known ports and port ranges > >>>- proxification of IORs to enable concentrators and firewalls > >>>- server replication, fault tolerance and load balancing straregies > >>>based on encoding multiple addresses in IORs (via multiple IIOP profiles > >>>and/or TAG_ALTERNATE_IIOP_ADDRESS components) > >>>- activation/location mechanisms based on forwarding agents re-directing > >>>clients to servers, where servers register addressing info upfront with > >>>the forwarding agent > >>>Regards, > >>>Eoghan. > >>>Ann Dalton1 wrote: > >>> > >>>>Eoghan, > >>>>Thanks for considering this. > >>>> > >>>>Yes, I had considered ORB implementations with separate Transport > >>>>plugins, especially since ours is one such. I should perhaps have made > >>>>it clearer that this proposal applies to the IIOP transport, rather > >>>>than the ORB per se. > >>>> > >>>>I'm seeking only to standardize the behaviour for IIOP as that is > >>>>mandated for CORBA interop compliance, and extensions to it are > >>>>required for any J2EE implementation. Any ORB that doesn't support > >>>>IIOP wouldn't support this extension to it. > >>>> > >>>>I had thought that introduction of a simple SocketFactory mechanism > >>>>would not impact any IIOP implementation greatly. Is this still a > >>>>concern in the light of the above? > >>>> > >>>>It seemed to me that a socket factory could be consistent with both > >>>>net and nio. I anticipate that the object created by the > >>>>ORBSocketFactory would be an ORBSocket, an instance of an interface > >>>>that mirrors java.net.Socket (or a subset thereof if we could agree > >>>>on one). The ORBSocket implementation could delegate to, or be a > >>>>subclass of, java.net.Socket, or not, and may or may not be > >>>>SocketChannel aware. > >>>>However, I haven't looked at nio in detail so would really appreciate > >>>>your thoughts on any problems or difficulties you foresee with that > >>>>approach. > >>>> > >>>>Many thanks, > >>>>Ann > >>>> > >>>> > >>>> Eoghan Glynn > >>>> To: Ann > >>>> Dalton1/UK/IBM@IBMGB > >>>> cc: java-rtf@omg.org, > >>>> issues@omg.org > >>>> 11/04/2002 11:04 Subject: Re: J2EE ORB > >>>> Socket Factory API > >>>> Please respond to > >>>> Eoghan Glynn > >>>> > >>>> > >>>> > >>>>Ann, > >>>> > >>>>Have you considered that there are ORB implementations where the ORB > >>>>core is completely unaware of the details of Socket/ServerSocket > >>>>creation and instead these are handled by separate transport plugins > >>>>(e.g. IIOP, TLS, multicast etc)? > >>>> > >>>>I don't see a strong case in your mail for standardizing the mechanisms > >>>>used to control the behaviour of these transport components. > >>>> > >>>>Its inevitable that different ORB implementations will have existing > >>>>proprietary mechanisms which differ radically, for example driven via > >>>>configuration, policies, or programmatically. It would be difficult to > >>>>reconcile these mechanisms to a single standard without favouring some > >>>>at the expense of others. > >>>> > >>>>Its also completely unclear how this mechanism would work for an ORB > >>>>that's not tightly bound to TCP-based transports. > >>>> > >>>>Finally how do you propose to accomodate the different mechanisms used > >>>>to create sockets in the java.net and java.nio packages? > >>>> > >>>>Regards, > >>>>Eoghan. > >>>> > >>>>Ann Dalton1 wrote: > >>>> > >>>>>In order to meet the interoperability compliance requirements, > >>>>>ORBs must include an IIOP implementation using TCP/IP plain text > >>>>>sockets. J2EE implementations are required to support CSIv2 and > >>>>>thus need additional control over the sockets an ORB creates. > >>>>>It may be necessary > >>>>>- to get the ORB to listen on additional sockets, of differing > >>>>> types > >>>>>- to get the ORB to connect to alternative sockets, of different > >>>>> types, for a given IOR > >>>>>- for information about these sockets to be included in object > >>>>> references exported by the ORB > >>>>>- for socket data to be available to request interceptors, e.g > >>>>> SSL certificates > >>>>> > >>>>>Portable IORInterceptors can be used to add this information as > >>>>>tagged components in the profiles within an IOR. > >>>>> > >>>>>A mechanism is required to modify the ORB's behaviour to allow > >>>>>it to handle different socket types, listen on additional sockets, > >>>>>connect to alternative sockets and make additional data available > >>>>>to interceptors. > >>>>> > >>>>>Since this is a J2EE requirement which needs speedy resolution, > >>>>>it seems appropriate to resolve it by the addition of Java > >>>>>specific APIs in the IDL to Java specification. For example, > >>>>> > >>>>>- a pluggable ORB socket factory could be introduced which would > >>>>> be used whenever the ORB needed to create a serverSocket or an > >>>>> outbound socket for a given IOR or end point > >>>>> > >>>>>- a means of registering such a socket factory would be required. > >>>>> Options for this include:- > >>>>> . adding an ORB method: this may cause problems in initialisation > >>>>> . adding a Java specific extension to the PI ORBInitInfo interface > >>>>> so that the registration would need to be called from the > >>>>> pre_init/post_init methods in an ORBInitializer: this ties the > >>>>> Socket Factory with PIs, but both are likely to be required > >>>>> for J2EE. > >>>>> > >>>>>- a means of specifying ports on which an ORB/POA should listen > >>>>> would be useful but this may be infeasible as part of this issue > >>>>> due to the variety of ORB/POA implementations. > >>>>> > >>>>>- the PI Client and ServerRequestInfo and IORInfo interfaces may > >>>>> need to be extended to support access to Connection related data > >>>>> > >>>>>Comments/thoughts would be appreciated before I draft a proposal to > >>>>>address this. > >> > >> > >>-- > >> ___________________ > >>/ Manfred R. Koethe \_____________________________________ > >> 88solutions Corp. E-Mail: koethe@88solutions.com > >> 37 Mague Avenue Tel: +1 (617) 916 5886 > >> Newton, MA 02465-1553 FAX: +1 (617) 916 5887 > >> U.S.A. > >>_____________________________"We make your business flow"_ > >> > > > > ************************************************************** > Edward Cobb, Vice President, Architecture & Standards > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > Tel: 408-570-8264 / Fax: 408-570-8914 / Mobile: 408-464-0733 > E-mail: ed.cobb@bea.com / Wireless: ecobb@palm.com > ************************************************************** -- Eoghan Glynn, Principal Engineer, IONA Technologies. "END 2 ANYWHERE" http://www.iona.com The IONA Building mailto:eglynn@iona.com Shelbourne Road tel :+353-1-6372439 Ballsbridge cell:+353-86-8175024 Dublin 4 Ireland X-Sender: ecobb@santa-clara.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 12 Apr 2002 09:05:45 -0700 To: Eoghan Glynn From: Edward Cobb Subject: Re: J2EE ORB Socket Factory API Cc: Andy Piper , "Manfred R. Koethe" , Ann Dalton1 , corba-rtf@omg.org, java-rtf@omg.org Eoghan, I'm less concerned about the solution (I'll leave that to Andy) than the principle that OMG should do this rather than the JCP. At 09:07 AM 4/12/2002 +0100, Eoghan Glynn wrote: Edward, Agreed that providing Java CSIv2 portability is good objective. My concern is that an inappropriately low-level approach (exposing an ORB socket factory) has been proposed to achieve this. Regards, Eoghan Edward Cobb wrote: > > I don't think the JCP is the right venue to address this problem. > Since OMG owns the core technology, there is a danger of diversion of you > go down that track. Much safer to keep it all together in OMG. > I agree with Jishnu. Long before there was a J2EE (some of us > remember that), it was an OMG objective to provide portability for Java > APIs as well as interoperability. The fact that the CSIv2 spec did not meet > that objective means that one of the Java RTFs gets to fix it. > > At 10:49 AM 4/11/2002 -0700, Andy Piper wrote: > >Just to add some datapoints. We currently already use both IBM's and Sun's > >proprietary mechanisms for doing this. It would be much better for us if > >it was standardized. Standard but optional would be much better IMO than > >just plain proprietary. I agree that making it mandatory imposes too many > >burdens on Orb implementations, and heaven knows quite enough of the > >implementation is specified already :) > > > >You could actually argue that this requirement is specific to J2SE > >implementations (of which IBM and Sun each have one). So maybe a JCP > >*would* be a better route for this discussion. > > > >Thanks > > > >andy > > > >At 10:52 AM 4/11/02 -0400, Manfred R. Koethe wrote: > >>Ann and Eoghan, > >> > >>First, I took the liberty to remove "issues" from the distribution > >>list (to giv Juergen a rest :-) ), but added the corba-rtf, since > >>this really needs their attention.... > >> > >>On the thechnical matters, I'm very concerned to standardize internal > >>interfaces vital to the ORB implementation. This would impose a > >>serious limitation and would be an obstacle for high-performance > >>implementations. Eoghan's idea to introduce a standardized *policy*, > >>which instructs the ORB on the desired behavior is IMHO the right > >>way to address this problem. > >> > >>Regards, > >> > >>Manfred > >> > >>Eoghan Glynn wrote: > >> > >>>Anne, > >>>I'm still very uneasy about the prospect of exposing and standardizing > >>>what are in my opinion fundamental ORB implementation details. > >>>On the java.nio front, the mechanisms used to create, monitor and > >>>read/write to a SocketChannel are fundamentally different to the > >>>java.net.Socket case. For example, an IIOP plugin written to use > >>>java.net.Socket would generally need to emulate async reads for the next > >>>incoming GIOP message via a synchronous read on a separate thread per > >>>connection. On the other hand, an IIOP plugin based on SocketChannels > >>>would generally use a single selector thread to monitor multiple > >>>connections for activity. These fundamentally different modes of > >>>operation cannot be reconciled simply by facading the channel behind an > >>>interface that mirrors java.net.Socket as you suggest. > >>>Given that we already have two different Java network I/O models, its > >>>possible there may be others in the future - constraining ORBs to use > >>>standardized SocketFactories would IMO act as a blocker to ORB vendors > >>>adopting new network I/O models such as java.nio. > >>>Limiting the standardized SocketFactory to IIOP does not necessarily > >>>limit the impact on an ORB implementation. For example, our ORB > >>>encapsulates the transport layer in a separate plugin that's used by > >>>IIOP, TLS, HTTP and other TCP-based protocols. > >>>Let me step back and ask why you're proposing to allow the application > >>>control socket creation? If its just intended to allow control over > >>>whether a normal or secure socket is created in order to disable/enable > >>>CSIv2, then surely standardized security policies would provide a much > >>>better mechanism than allowing application to directly control socket > >>>creation? > >>>Finally, I also see serious issues in allowing the application control > >>>the allocation of listen ports in a standardized way, as there are so > >>>many propreitary and vendor-specific mechanisms at work here, for > >>>example: > >>>- configuration of fixed well-known ports and port ranges > >>>- proxification of IORs to enable concentrators and firewalls > >>>- server replication, fault tolerance and load balancing straregies > >>>based on encoding multiple addresses in IORs (via multiple IIOP profiles > >>>and/or TAG_ALTERNATE_IIOP_ADDRESS components) > >>>- activation/location mechanisms based on forwarding agents re-directing > >>>clients to servers, where servers register addressing info upfront with > >>>the forwarding agent > >>>Regards, > >>>Eoghan. > >>>Ann Dalton1 wrote: > >>> > >>>>Eoghan, > >>>>Thanks for considering this. > >>>> > >>>>Yes, I had considered ORB implementations with separate Transport > >>>>plugins, especially since ours is one such. I should perhaps have made > >>>>it clearer that this proposal applies to the IIOP transport, rather > >>>>than the ORB per se. > >>>> > >>>>I'm seeking only to standardize the behaviour for IIOP as that is > >>>>mandated for CORBA interop compliance, and extensions to it are > >>>>required for any J2EE implementation. Any ORB that doesn't support > >>>>IIOP wouldn't support this extension to it. > >>>> > >>>>I had thought that introduction of a simple SocketFactory mechanism > >>>>would not impact any IIOP implementation greatly. Is this still a > >>>>concern in the light of the above? > >>>> > >>>>It seemed to me that a socket factory could be consistent with both > >>>>net and nio. I anticipate that the object created by the > >>>>ORBSocketFactory would be an ORBSocket, an instance of an interface > >>>>that mirrors java.net.Socket (or a subset thereof if we could agree > >>>>on one). The ORBSocket implementation could delegate to, or be a > >>>>subclass of, java.net.Socket, or not, and may or may not be > >>>>SocketChannel aware. > >>>>However, I haven't looked at nio in detail so would really appreciate > >>>>your thoughts on any problems or difficulties you foresee with that > >>>>approach. > >>>> > >>>>Many thanks, > >>>>Ann > >>>> > >>>> > >>>> Eoghan Glynn > >>>> To: Ann > >>>> Dalton1/UK/IBM@IBMGB > >>>> cc: java-rtf@omg.org, > >>>> issues@omg.org > >>>> 11/04/2002 11:04 Subject: Re: J2EE ORB > >>>> Socket Factory API > >>>> Please respond to > >>>> Eoghan Glynn > >>>> > >>>> > >>>> > >>>>Ann, > >>>> > >>>>Have you considered that there are ORB implementations where the ORB > >>>>core is completely unaware of the details of Socket/ServerSocket > >>>>creation and instead these are handled by separate transport plugins > >>>>(e.g. IIOP, TLS, multicast etc)? > >>>> > >>>>I don't see a strong case in your mail for standardizing the mechanisms > >>>>used to control the behaviour of these transport components. > >>>> > >>>>Its inevitable that different ORB implementations will have existing > >>>>proprietary mechanisms which differ radically, for example driven via > >>>>configuration, policies, or programmatically. It would be difficult to > >>>>reconcile these mechanisms to a single standard without favouring some > >>>>at the expense of others. > >>>> > >>>>Its also completely unclear how this mechanism would work for an ORB > >>>>that's not tightly bound to TCP-based transports. > >>>> > >>>>Finally how do you propose to accomodate the different mechanisms used > >>>>to create sockets in the java.net and java.nio packages? > >>>> > >>>>Regards, > >>>>Eoghan. > >>>> > >>>>Ann Dalton1 wrote: > >>>> > >>>>>In order to meet the interoperability compliance requirements, > >>>>>ORBs must include an IIOP implementation using TCP/IP plain text > >>>>>sockets. J2EE implementations are required to support CSIv2 and > >>>>>thus need additional control over the sockets an ORB creates. > >>>>>It may be necessary > >>>>>- to get the ORB to listen on additional sockets, of differing > >>>>> types > >>>>>- to get the ORB to connect to alternative sockets, of different > >>>>> types, for a given IOR > >>>>>- for information about these sockets to be included in object > >>>>> references exported by the ORB > >>>>>- for socket data to be available to request interceptors, e.g > >>>>> SSL certificates > >>>>> > >>>>>Portable IORInterceptors can be used to add this information as > >>>>>tagged components in the profiles within an IOR. > >>>>> > >>>>>A mechanism is required to modify the ORB's behaviour to allow > >>>>>it to handle different socket types, listen on additional sockets, > >>>>>connect to alternative sockets and make additional data available > >>>>>to interceptors. > >>>>> > >>>>>Since this is a J2EE requirement which needs speedy resolution, > >>>>>it seems appropriate to resolve it by the addition of Java > >>>>>specific APIs in the IDL to Java specification. For example, > >>>>> > >>>>>- a pluggable ORB socket factory could be introduced which would > >>>>> be used whenever the ORB needed to create a serverSocket or an > >>>>> outbound socket for a given IOR or end point > >>>>> > >>>>>- a means of registering such a socket factory would be required. > >>>>> Options for this include:- > >>>>> . adding an ORB method: this may cause problems in initialisation > >>>>> . adding a Java specific extension to the PI ORBInitInfo interface > >>>>> so that the registration would need to be called from the > >>>>> pre_init/post_init methods in an ORBInitializer: this ties the > >>>>> Socket Factory with PIs, but both are likely to be required > >>>>> for J2EE. > >>>>> > >>>>>- a means of specifying ports on which an ORB/POA should listen > >>>>> would be useful but this may be infeasible as part of this issue > >>>>> due to the variety of ORB/POA implementations. > >>>>> > >>>>>- the PI Client and ServerRequestInfo and IORInfo interfaces may > >>>>> need to be extended to support access to Connection related data > >>>>> > >>>>>Comments/thoughts would be appreciated before I draft a proposal to > >>>>>address this. > >> > >> > >>-- > >> ___________________ > >>/ Manfred R. Koethe \_____________________________________ > >> 88solutions Corp. E-Mail: koethe@88solutions.com > >> 37 Mague Avenue Tel: +1 (617) 916 5886 > >> Newton, MA 02465-1553 FAX: +1 (617) 916 5887 > >> U.S.A. > >>_____________________________"We make your business flow"_ > >> > > > > ************************************************************** > Edward Cobb, Vice President, Architecture & Standards > BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 > Tel: 408-570-8264 / Fax: 408-570-8914 / Mobile: 408-464-0733 > E-mail: ed.cobb@bea.com / Wireless: ecobb@palm.com > ************************************************************** -- Eoghan Glynn, Principal Engineer, IONA Technologies. "END 2 ANYWHERE" http://www.iona.com The IONA Building mailto:eglynn@iona.com Shelbourne Road tel :+353-1-6372439 Ballsbridge cell:+353-86-8175024 Dublin 4 Ireland ************************************************************** Edward Cobb, Vice President, Architecture & Standards BEA Systems, Inc., 2315 North First St., San Jose, CA 95131 Tel: 408-570-8264 / Fax: 408-570-8914 / Mobile: 408-464-0733 E-mail: ed.cobb@bea.com / Wireless: ecobb@palm.com ************************************************************** X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 12 Apr 2002 09:43:08 -0700 To: Edward Cobb , Eoghan Glynn From: Andy Piper Subject: Re: J2EE ORB Socket Factory API Cc: "Manfred R. Koethe" , Ann Dalton1 , corba-rtf@omg.org, java-rtf@omg.org At 09:05 AM 4/12/02 -0700, Edward Cobb wrote: Eoghan, I'm less concerned about the solution (I'll leave that to Andy) I was hoping to leave that to Ann :) than the principle that OMG should do this rather than the JCP. Point well taken andy Subject: Re: issue 5108 J2EE ORB Socket Factory API To: Andy Piper Cc: java-rtf@omg.org, Ken Cavanaugh X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Ann Dalton1" Date: Mon, 9 Dec 2002 11:27:35 +0000 X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a |January 7, 2002) at 09/12/2002 11:28:08 Andy, I'd like to get a resolution to this issue as it's a functional requirement of any J2EE implementation. But I think any proposal probably needs more consideration than we have time to give it in this round of the RTF. I'd be happy to work on it early next year if Ken's ok with leaving it open for now? Ann Andy Piper To: Ken Cavanaugh , java-rtf@omg.org cc: ken.cavanaugh@sun.com 19/11/2002 22:10 Subject: Re: Open issues and upcoming votes At 10:13 PM 11/13/2002 -0800, Ken Cavanaugh wrote: >5108 J2EE ORB Socket Factory API > This is IBM's issue on extending the set of portable APIs > to include a facility for pluggable socket factories. > It seems that we have had no luck finding a good portable > solution here, especially since Java has two different > incomptaible models for handling sockets. Would IBM > care to propose closing this no change? I am keen to see some positive resolution to this and am happy to work with IBM on it if they wish. andy Date: Mon, 9 Dec 2002 08:32:32 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: issue 5108 J2EE ORB Socket Factory API To: andyp@bea.com, ann_dalton@uk.ibm.com Cc: java-rtf@omg.org, Ken.Cavanaugh@sun.com X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc >Subject: Re: issue 5108 J2EE ORB Socket Factory API >To: Andy Piper >Cc: java-rtf@omg.org, Ken Cavanaugh >From: "Ann Dalton1" >X-MIMETrack: Serialize by Router on d06ml005/06/M/IBM(Release 5.0.9a >|January 7, 2002) at 09/12/2002 11:28:08 >MIME-Version: 1.0 > > >Andy, >I'd like to get a resolution to this issue as it's a functional >requirement of any J2EE implementation. But I think any proposal >probably needs more consideration than we have time to give it in >this round of the RTF. I'd be happy to work on it early next year >if Ken's ok with leaving it open for now? >Ann > Ok with me. Ken. X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 09 Dec 2002 09:27:39 -0800 To: "Ann Dalton1" From: Andy Piper Subject: Re: issue 5108 J2EE ORB Socket Factory API Cc: java-rtf@omg.org, Ken Cavanaugh At 11:27 AM 12/9/2002 +0000, Ann Dalton1 wrote: I'd like to get a resolution to this issue as it's a functional requirement of any J2EE implementation. But I think any proposal probably needs more consideration than we have time to give it in this round of the RTF. I'd be happy to work on it early next year if Ken's ok with leaving it open for now? I think my concern is that it is not left too late for a suitable J2SE release vehicle from Sun or IBM. It may already be too late for J2SE 1.5, I don't know what IBM's release schedule looks like on that score. andy Date: Mon, 9 Dec 2002 09:44:58 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: issue 5108 J2EE ORB Socket Factory API To: ann_dalton@uk.ibm.com, andyp@bea.com Cc: java-rtf@omg.org, Ken.Cavanaugh@sun.com X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc >X-Sender: andyp@san-francisco.beasys.com >To: "Ann Dalton1" >From: Andy Piper >Subject: Re: issue 5108 J2EE ORB Socket Factory API >Cc: java-rtf@omg.org, Ken Cavanaugh >Mime-Version: 1.0 > >At 11:27 AM 12/9/2002 +0000, Ann Dalton1 wrote: >>I'd like to get a resolution to this issue as it's a functional >>requirement of any J2EE implementation. But I think any proposal >>probably needs more consideration than we have time to give it in >>this round of the RTF. I'd be happy to work on it early next year >>if Ken's ok with leaving it open for now? > >I think my concern is that it is not left too late for a suitable >J2SE >release vehicle from Sun or IBM. It may already be too late for J2SE >1.5, I >don't know what IBM's release schedule looks like on that score. > The end of the current RTFs will probably make it into Sun's J2SE 1.5, but nothing later. However, the endorsed standards API does allow other vendors to incorporate later standards into their products, and I think the results of the next RTF's interim reports could be used in other vendor's J2SE 1.5 products. Ken.