Propagating extra context information in remote EJB calls

[Jack Cai]

I want to propagate some context information in remote EJB calls, and
hopefully this can be done transparently, i.e., does not require code change
to existing applications. Is this possible?

I understand transaction and security context are already being propagated
as part of an EJB container impl. Can I just inject the extra data into the
security context for example to do the trick?

Appreciate some insight in this area!

-Jack

[Jacek Laskowski]

On Thu, Oct 29, 2009 at 9:16 AM, Jack Cai <greensight@...> wrote:
> I want to propagate some context information in remote EJB calls, and
> hopefully this can be done transparently, i.e., does not require code change
> to existing applications. Is this possible?

I don't know how it is in OpenEJB itself, but you can use AOP to do
the trick. Just intercept client calls on a client and add relevant
data to the stream. I believe you want to pass the additional data to
another set of remote methods so you could just route the calls to
remote business methods to their extended counterparts. I'm pretty
sure it doesn't sound well, but with such a general description I
couldn't come up with something more elegant :]

Jacek

--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl

[Jack Cai]

Thanks Jacek for the quick response!

What I want to do is like this -

1. At the client side, intercept the client call before it's sent out, and
attach some extra context information with the call;
2. At the server side, intercept the business method call before the method
is actually executed, so that I can retrieve the extra context information
coming with the call and set it into the server thread's context.

I need to transparently do this for all EJBs. I was hoping I could do the
trick only once in the code, instead of having to take care of all EJBs
(e.g., use AOP to specify to intecept each invidiual remote interface).

So in a word, I guess this is pretty much the same as how
transaction/security context gets propagated today. Does this make more
sense now?

-Jack

On Thu, Oct 29, 2009 at 4:29 PM, Jacek Laskowski <jacek@...>wrote:

> On Thu, Oct 29, 2009 at 9:16 AM, Jack Cai <greensight@...> wrote:
> > I want to propagate some context information in remote EJB calls, and
> > hopefully this can be done transparently, i.e., does not require code
> change
> > to existing applications. Is this possible?
>
> I don't know how it is in OpenEJB itself, but you can use AOP to do
> the trick. Just intercept client calls on a client and add relevant
> data to the stream. I believe you want to pass the additional data to
> another set of remote methods so you could just route the calls to
> remote business methods to their extended counterparts. I'm pretty
> sure it doesn't sound well, but with such a general description I
> couldn't come up with something more elegant :]
>
> Jacek
>
> --
> Jacek Laskowski
> Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
>

[Jacek Laskowski]

On Thu, Oct 29, 2009 at 10:16 AM, Jack Cai <greensight@...> wrote:

> 1. At the client side, intercept the client call before it's sent out, and
> attach some extra context information with the call;
> 2. At the server side, intercept the business method call before the method
> is actually executed, so that I can retrieve the extra context information
> coming with the call and set it into the server thread's context.
>
> I need to transparently do this for all EJBs. I was hoping I could do the
> trick only once in the code, instead of having to take care of all EJBs
> (e.g., use AOP to specify to intecept each invidiual remote interface).
>
> So in a word, I guess this is pretty much the same as how
> transaction/security context gets propagated today. Does this make more
> sense now?

Nope :] I still don't know what exactly you'd like to add to a call.
Yet, you're right that OpenEJB adds some additional data for security
and tx mgmt, but I don't think it was exposed for public consumption.

Jacek

--
Jacek Laskowski
Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl

[djencks]

AFAIK openejb does not propagate transaction context.  I thought about  
it for corba a long time ago but I have never found anyone who  
actually wants distributed transactions so never made the time to  
implement it.

With Corba I believe you can add client and server interceptors and  
tack whatever info you want onto the request, but I found it a  
difficult programming model to understand.

What context information do you want to transmit?

thanks
david jencks

On Oct 29, 2009, at 4:15 AM, Jacek Laskowski wrote:

> On Thu, Oct 29, 2009 at 10:16 AM, Jack Cai <greensight@...>  
> wrote:
>
>> 1. At the client side, intercept the client call before it's sent  
>> out, and
>> attach some extra context information with the call;
>> 2. At the server side, intercept the business method call before  
>> the method
>> is actually executed, so that I can retrieve the extra context  
>> information
>> coming with the call and set it into the server thread's context.
>>
>> I need to transparently do this for all EJBs. I was hoping I could  
>> do the
>> trick only once in the code, instead of having to take care of all  
>> EJBs
>> (e.g., use AOP to specify to intecept each invidiual remote  
>> interface).
>>
>> So in a word, I guess this is pretty much the same as how
>> transaction/security context gets propagated today. Does this make  
>> more
>> sense now?
>
> Nope :] I still don't know what exactly you'd like to add to a call.
> Yet, you're right that OpenEJB adds some additional data for security
> and tx mgmt, but I don't think it was exposed for public consumption.
>
> Jacek
>
> --
> Jacek Laskowski
> Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl

[David Blevins]

On Oct 29, 2009, at 1:16 AM, Jack Cai wrote:

> I want to propagate some context information in remote EJB calls, and
> hopefully this can be done transparently, i.e., does not require  
> code change
> to existing applications. Is this possible?
>
> I understand transaction and security context are already being  
> propagated
> as part of an EJB container impl. Can I just inject the extra data  
> into the
> security context for example to do the trick?
>
> Appreciate some insight in this area!

The idea that comes to mind is modifying the HttpConnectionFactory to  
in some way set headers into the HttpURLConnection.  In the 3.1.x  
codebase it's actually possible to replace the HttpConnectionFactory  
on an existing client:

   http://mail-archives.apache.org/mod_mbox/openejb-users/200911.mbox/%3CB003CC7A-74F0-4E88-AB61-F8C7A80F7F3B@...%3E

On the server side if there was a Servlet like this:

   import org.apache.openejb.loader.SystemInstance;
   import org.apache.openejb.server.ServiceException;
   import org.apache.openejb.server.ejbd.EjbServer;

   import javax.servlet.ServletConfig;
   import javax.servlet.ServletException;
   import javax.servlet.ServletInputStream;
   import javax.servlet.ServletOutputStream;
   import javax.servlet.http.HttpServlet;
   import javax.servlet.http.HttpServletRequest;
   import javax.servlet.http.HttpServletResponse;
   import java.io.IOException;

   public class ServerServlet extends HttpServlet {
       private EjbServer ejbServer;

       public void init(ServletConfig config) {
           ejbServer =  
SystemInstance.get().getComponent(EjbServer.class);
       }

       protected void service(HttpServletRequest request,  
HttpServletResponse response) throws ServletException, IOException {
           ServletInputStream in = request.getInputStream();
           ServletOutputStream out = response.getOutputStream();
           try {
               ejbServer.service(in, out);
           } catch (ServiceException e) {
               throw new ServletException("ServerService error: " +  
ejbServer.getClass().getName() + " -- " + e.getMessage(), e);
           }
       }
   }


You could get the headers and put them on a ThreadLocal or something.

If the state is going to be the same on a per connection basis, then  
we can maybe make some standard way to put the headers in the  
connection URI and pull them out of that "params" map we create.

We'd need some more creativity to make it really nice and easy for  
people.  But this is a rough approach to get the ideas started.

-David

[Jack Cai]

Thanks David! I did try CORBA interceptors and it works well with RMI/IIOP
calls, exactly what I want. Unfortunately OpenEJB does not use the IIOP
library that comes with JDK, so intercepting IIOP calls cannot intercept
remote OpenEJB calls.

What I want to propagate is actually a simple ID string.

-Jack

On Fri, Nov 6, 2009 at 10:43 AM, David Jencks <david_jencks@...>wrote:

> AFAIK openejb does not propagate transaction context.  I thought about it
> for corba a long time ago but I have never found anyone who actually wants
> distributed transactions so never made the time to implement it.
>
> With Corba I believe you can add client and server interceptors and tack
> whatever info you want onto the request, but I found it a difficult
> programming model to understand.
>
> What context information do you want to transmit?
>
> thanks
> david jencks
>
>
> On Oct 29, 2009, at 4:15 AM, Jacek Laskowski wrote:
>
>  On Thu, Oct 29, 2009 at 10:16 AM, Jack Cai <greensight@...> wrote:
>>
>>  1. At the client side, intercept the client call before it's sent out,
>>> and
>>> attach some extra context information with the call;
>>> 2. At the server side, intercept the business method call before the
>>> method
>>> is actually executed, so that I can retrieve the extra context
>>> information
>>> coming with the call and set it into the server thread's context.
>>>
>>> I need to transparently do this for all EJBs. I was hoping I could do the
>>> trick only once in the code, instead of having to take care of all EJBs
>>> (e.g., use AOP to specify to intecept each invidiual remote interface).
>>>
>>> So in a word, I guess this is pretty much the same as how
>>> transaction/security context gets propagated today. Does this make more
>>> sense now?
>>>
>>
>> Nope :] I still don't know what exactly you'd like to add to a call.
>> Yet, you're right that OpenEJB adds some additional data for security
>> and tx mgmt, but I don't think it was exposed for public consumption.
>>
>> Jacek
>>
>> --
>> Jacek Laskowski
>> Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
>>
>
>

[Jack Cai]

Since I'm using the OpenEJB that comes with Geronimo, which port shall I
connect to if http protocol is used? Still 4201 where the EJB daemon is
listening? I did try setting the url to something like "http://hostname:4201"
but didn't work out. Are you suggesting that I shall write a servlet to
receive the client call and then forward to the openejb server?

-Jack


On Sat, Nov 7, 2009 at 4:17 AM, David Blevins <david.blevins@...>wrote:

> On Oct 29, 2009, at 1:16 AM, Jack Cai wrote:
>
>  I want to propagate some context information in remote EJB calls, and
>> hopefully this can be done transparently, i.e., does not require code
>> change
>> to existing applications. Is this possible?
>>
>> I understand transaction and security context are already being propagated
>> as part of an EJB container impl. Can I just inject the extra data into
>> the
>> security context for example to do the trick?
>>
>> Appreciate some insight in this area!
>>
>
> The idea that comes to mind is modifying the HttpConnectionFactory to in
> some way set headers into the HttpURLConnection.  In the 3.1.x codebase it's
> actually possible to replace the HttpConnectionFactory on an existing
> client:
>
>
> http://mail-archives.apache.org/mod_mbox/openejb-users/200911.mbox/%3CB003CC7A-74F0-4E88-AB61-F8C7A80F7F3B@...%3E
>
> On the server side if there was a Servlet like this:
>
>  import org.apache.openejb.loader.SystemInstance;
>  import org.apache.openejb.server.ServiceException;
>  import org.apache.openejb.server.ejbd.EjbServer;
>
>  import javax.servlet.ServletConfig;
>  import javax.servlet.ServletException;
>  import javax.servlet.ServletInputStream;
>  import javax.servlet.ServletOutputStream;
>  import javax.servlet.http.HttpServlet;
>  import javax.servlet.http.HttpServletRequest;
>  import javax.servlet.http.HttpServletResponse;
>  import java.io.IOException;
>
>  public class ServerServlet extends HttpServlet {
>      private EjbServer ejbServer;
>
>      public void init(ServletConfig config) {
>          ejbServer = SystemInstance.get().getComponent(EjbServer.class);
>      }
>
>      protected void service(HttpServletRequest request, HttpServletResponse
> response) throws ServletException, IOException {
>          ServletInputStream in = request.getInputStream();
>          ServletOutputStream out = response.getOutputStream();
>          try {
>              ejbServer.service(in, out);
>          } catch (ServiceException e) {
>              throw new ServletException("ServerService error: " +
> ejbServer.getClass().getName() + " -- " + e.getMessage(), e);
>          }
>      }
>  }
>
>
> You could get the headers and put them on a ThreadLocal or something.
>
> If the state is going to be the same on a per connection basis, then we can
> maybe make some standard way to put the headers in the connection URI and
> pull them out of that "params" map we create.
>
> We'd need some more creativity to make it really nice and easy for people.
>  But this is a rough approach to get the ideas started.
>
> -David
>
>
>
>
>
>
>

[David Blevins]

On Nov 10, 2009, at 7:36 AM, Jack Cai wrote:

> Are you suggesting that I shall write a servlet to
> receive the client call and then forward to the openejb server?

Right, exactly.  On the client side you'd point to the servlet address.

The servlet could be added to an existing webapp for now.  For the  
long term it would be really great to have a servlet like the one I  
posted as a standard part of the Geronimo integration.

This is the one we use in the Tomcat integration:

  http://svn.apache.org/repos/asf/openejb/trunk/openejb3/server/openejb-http/src/main/java/org/apache/openejb/server/httpd/ServerServlet.java

It doesn't do anything with the HTTP headers yet, but it could.

-David