Archived

This forum has been archived. Please start a new discussion on GitHub.

Exposing EJBs as Ice services

Hi,

With EJB 3.0, it's now possible to expose POJOs as WebServices by adding annotations to the class. For example:
@WebService
public interface Echo extends Remote {
   @WebMethod
   String echo(String e);
}

Would it be feasable to have a similar functionnality with Ice. In other word, if we consider the POJO as a starting point, how much effort would be needed to generate the Ice classes and automatically expose the generated Ice interface.

The idea there is to start with somethine like:
@IceService
public interface Echo extends Remote {
   @IceMethod
   String echo(String e);
}

And end up with an Ice servant, delegating the calls to the EJB.

Is this feasable, and would that make any sense?

Regards,
Cyrille

Comments

  • benoit
    benoit Rennes, France
    Hi Cyrille,

    Yes, it's certainly possible. You could write a custom Java annotation processing tool that would generate Slice interfaces for the annotated EJB services.

    To implement the servants to delegate to the EJB services, there are several options:
    • Also generate servant implementations with the custom annotation processing tool, those servants would delegate to the EJB services.
    • Implement a "blobject" servant. This servant would dispatch the requests of your Ice "EJB" services by delegating the requests to the EJB services. It could use Java reflection to figure out the methods exposed by your Ice services (and their signature).

    Doing this would certainly make sense if you have a large number of EJB services to expose as Ice services and if the burden of keeping both in sync is important. If you have only few, it's probably simpler to do the bridging "by hand".

    Cheers,
    Benoit.
  • Exposing EJBs as Ice services

    Hi Benoit,

    With EJB 3.0, the annotated class can be any class and does not need to inherit from any specific "EJB" stuff. If there were such a tool to expose EJBs as Ice services, would the annotated class need to inherit from an Ice class in the first place? In other words, would a delegate be mandatory. Idealy, we would like to avoid copies of objects as much as possible.

    I know this sounds a bit extreme but, could you think of a solution where the annoted class would be the Ice service itself, but with no inheritance from another Ice class? This way, this annotated class could also be exposed as a webservice for example.

    From my point, a delegate will definitely be needed but I your confirmation would certainly help filling up my lack of knowledge of Ice :).

    Regards,
    Cyrille
  • benoit
    benoit Rennes, France
    To expose the EJB interface as an Ice object, you have to implement an Ice servant that delegates the dispatched calls from Ice to this EJB interface. Here's an example of what could be generated for the Echo interface from your first post:
    • the annotation processing tool could generate the following slice:
      // Slice
      module EJBBridge {
           interface Echo {
                 string echo(string e);
           };
      };
      
    • it could also generate the following servant implementation that you would use to expose your service as an Ice object by registering a new servant instance with an Ice object adapter:
      // Java
      import EJBBridge.*;
      public class EchoI extends _EchoDisp {
           public EchoI(Echo serviceDelegate) {
                _serviceDelegate = serviceDelegate;
           }
           public String echo(String e) {
                return _serviceDelegate.echo(e);
           }
           final private Echo _serviceDelegate;
      };
      

    Is it this delegate servant object that you would like to avoid?

    Another possibility to implement this delegate servant would be to create a "generic" servant that is capable of dispatching calls to any of your EJB services using Java reflection and Ice blobjects. This could avoid having to create one servant per EJB service to delegate to. However there would be additional runtime overhead as reflection isn't as cheap as a direct call.

    Cheers,
    Benoit.
  • 2 cents from someone who was using EJBs and then moved to Ice, be aware before you go down the route of wrapping EJBs with Ice services, that you will not inherently have the benefit of the JavaEE container when accessing the Ice services. This is most prominent in the threading and transaction models. Though the situation may have improved, I never found a way to successfully tie Ice and the JavaEE server together. You might want to also read:
    Cheers,
    ~Josh
  • Exposing EJBs as Ice services

    Hi Benoit,

    Thank you for your answers and ideas for solutions to this issue.

    Would this functionnality be something that ZeroC would be happy to implement as a enhancement request, or do you think this is too specific to our own case?

    Regards,
    Cyrille
  • benoit
    benoit Rennes, France
    Hi Cyrille,

    We'll discuss it and get back to you.

    Cheers,
    Benoit.