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
     object.

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, com.ibm, 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.

Rick


-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.



Reply via email to