incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <>
Subject Re: Transport Security [was: Re: Full working orb?]
Date Thu, 20 Apr 2006 10:15:00 GMT
Dain Sundstrom wrote:
> If we can get an agreement here and implement it as the defacto 
> standard, I think we will all be better off.
And certainly much faster to get something implemented.  There's not a 
whole lot really required by Geronimo for this to work.  The code used 
by Geronimo to interface with the Sun ORB (or the WAS CE product to 
interface with the IBM ORB) required the following hooks:

   1. A callback to make the decision on what type of transport is
      required (two decision points, one for client access, one for
      server listeners).
   2. A callback to create the actual socket (for both ORBs, this
      callback uses the information derived at the first callback).
   3.  Access to connection context information inside of the
      interceptors.  For both ORBs, this is made available by casting
      the request info object into an implementation-specific extended

Both the IBM ORB and the Sun ORB implement their mechanisms via suitable 
base classes and interfaces, but unfortunately all of the classes 
involved using vendor specific package names (com.sun,, etc.).  
That's one of the interesting difficulties about trying to create a 
defacto standard here.  Ideally, these should be org.omg.* package 
names, but that can really only be done through the OMG process.


> -dain
> On Apr 19, 2006, at 2:56 AM, Andy Piper wrote:
>> At 10:18 AM 4/14/2006,
>>> Maybe we can get IONA and IBM to agree here :)  I can attempt to 
>>> push it through IBM (and maybe Andy can try BEA).
>> My personal opinion is that this should go through the JCP. The 
>> reason the original proposal failed was because it was defined in IDL 
>> in order to be supportable on any ORB (i.e. non-Java) and there were 
>> issues with the way this worked. I think this is really a Java 
>> specific problem and therefore should be solved in a java-specific 
>> way. Unfortunately I think protocol dictates that this go through the 
>> OMG ....
>> Another alternative is to sneak it in via the Java-IDL spec which 
>> already has Java-specific APIs. I suspect this would also be a breach 
>> of protocol :(
>> andy
>> _______________________________________________________________________
>> Notice:  This email message, together with any attachments, may contain
>> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
>> entities,  that may be confidential,  proprietary,  copyrighted  and/or
>> legally privileged, and is intended solely for the use of the individual
>> or entity named in this message. If you are not the intended recipient,
>> and have received this message in error, please immediately return this
>> by email and then delete it.

View raw message