Can we access EJB beans over JNDI using a Java Callout?

I have a backend built in Java with functionality exposed via EJBs. Is there any way to use a Java Callout to interact with the EJB bean from within an Api Proxy by making a JNDI call? Or do I have to build a thin Api layer which will "api-fy" the backend and act as a mediator between the EJB layer and the Apigee layer?

Solved Solved
1 2 478
1 ACCEPTED SOLUTION

Thanks @sriki77. FYI, I was able to invoke the EJBs via the Java Callout policy. However, I too believe that having a separate thin api layer is a better alternative mainly because of these 3 reasons (in addition to the points mentioned by you):

  1. Avoid Coupling: Invoking EJBs via JavaCallouts would increase coupling between Apigee and the backend (despite this complexity being encapsulated in a jar).
  2. Architectural Freedom: The architecture of the thin api layer would be totally under your control. However once you start invoking EJBs from your Java Callouts you would mostly end up having a separate class (implementing com.apigee.flow.execution.spi.Execution) for each such operation leading to class proliferation and an inelegant design.
  3. Easier Debugging: It's relatively easier to debug a separate api layer than a jar being used in the Java Callout policy.

View solution in original post

2 REPLIES 2

Not applicable

Hmmm..interesting. I think you can try

- you should package the jndi jars with the callout.

- However, some of th JNDI require the same version of java and also same make (i mean you may need for example - IBM JDK on both client and server) So watchout for the same

- Also Transport security is something you should think of - since EJB might be more accessible to the world than before.

- Somehow, i tend to think having a HTTP based API - servlet shield EJB as a better approach.

Thanks @sriki77. FYI, I was able to invoke the EJBs via the Java Callout policy. However, I too believe that having a separate thin api layer is a better alternative mainly because of these 3 reasons (in addition to the points mentioned by you):

  1. Avoid Coupling: Invoking EJBs via JavaCallouts would increase coupling between Apigee and the backend (despite this complexity being encapsulated in a jar).
  2. Architectural Freedom: The architecture of the thin api layer would be totally under your control. However once you start invoking EJBs from your Java Callouts you would mostly end up having a separate class (implementing com.apigee.flow.execution.spi.Execution) for each such operation leading to class proliferation and an inelegant design.
  3. Easier Debugging: It's relatively easier to debug a separate api layer than a jar being used in the Java Callout policy.