incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darren Middleman" <>
Subject Re: Transport Security [was: Re: Full working orb?]
Date Thu, 20 Apr 2006 12:43:18 GMT
Hi Rick,

I was wondering if you could provide a bit more details on what it took to
get this working in the other ORBs?  One thing that caught my eye is that
you mentioned that the IBM ORB used a plugable transport and this was where
you implemented this functionality before.  I'm wondering if this could be
similar to the OCI framework that is included with the current ORB in
Yoko.   This framework has been used to create the IIOP transport, and in
the past for other transport plugins for UDP and IIOP over SSL/TLS.  It
might not be what you are describing but I thought I'd ask anyway.


On 4/20/06, Rick McGuire <> wrote:
> 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,, 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.
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message