Now we extend the Calculator Service example with an EJB access. This is a practice-relevant topic because Oracle SOA applications running on a SCA Container have to interact with existing EJBs. As the authors of the book “Understanding SCA” Jim Marino and Michael Rowley rightly point out that there are many enterprises which have mission-critical Java EE applications that will remain in production for years to come. The authors further describe SCA as schizophrenic in reference to EJBs. On the one hand, SCA offers a competing technology to EJB, but on the other, SCA extends EJB technology.
In order to extend the Calculator Service we implement a Stateless Session Bean EJB (SLSB) which offers two mathematical operations which we reuse on our Calculator SCA Composite. The EJB offers a square operation and the inverse square root operation.
Access on existing EJBs could be implemented on several ways on the Oracle SOA Suite platform. An easy way of integration would be to annotate the existing EJB with JAX-WS annotations and offer the EJB methods as Web Service operations (assumed that the EJB is implemented on the 3.x EJB standard). On this integration scenario a WS Adapter would be placed on the “External References” swim lane of the SCA Composite.
Another way of integration would be the usage of the EJB Service Adapter. This approach is working well if the EJB is based on the 3.x specification. EJB 2.x access has problems to interact with the EJB Service Adapter based on my experiences. Anyway, if a Spring Bean should talk to an EJB the EJB Service Adapter seems to be unnecessary overhead. The Spring Bean could act as EJB Client in an easy way.
Spring makes it much easier to access EJBs. Additionally, using Spring Beans to access services provided by EJBs allows the implementation of those services to later transparently be switched between local EJB, remote EJB, or POJO (plain java object) variants, without the client code client code having to be changed.
Spring is working with EJB proxy objects for accessing local or remote SLSBs. The configuration of the proxy is shown on the following Spring Bean context file.
The EJBCalculator bean definition creates a proxy for the EJB, which implements the business method interface. The EJB local home is cached on startup, so there’s only a single JNDI lookup. Each time the EJB is invoked, the proxy invokes the create() method on the local EJB and invokes the corresponding business method on the EJB. The ICalculatorServiceBean definition sets the ejbCalculator property to this proxy.
Access on local SLSBs are realized with LocalStatelessSessionProxyFactoryBean proxies and access on remote SLSB are implemented with SimpleRemoteStatelessSessionProxyFactoryBean proxies (commented out on the given context snippet). Read also on the Spring Framework documentation the chapter about EJB Integration.
It’s important to take the matching JNDI binding name. The right jndiName setting on the Spring Bean context file could be taken from the JNDI Tree view of WebLogic.
If the JNDI Name is not matching the right EJB binding name you will not be able to deploy the SCA Composite. A Exception “NameNotFoundException” will stop your deployment.
On the next step the new “square” and “squareRoot” operations have to be added on the Calculator WSDL.
Put the EJBCalculator JAR on the SCA Composite lib folder (\SCA-INF\lib) and define the dependency (Project Properties -> Libraries and Classpath -> Add JAR/Directory). Rewire the WS Adapter with the Spring Bean CalculatorServiceComponent. This will cause a re-generation of the Calculator Service Interface classes.
Add the setter method for the EJBCalculator business interface class on the CalculatorServiceImpl class.
Last step is the implementation of the “square” and “squareRoot” methods which reuse the existing SLSB EJB by a fast local EJB call.
Finally test the new Calculator Service operations (I’m using SOAPUI).
The source code is available as 7-zip here.
That’s it. We created the access on an SLSB EJB and reuse existing operations with a Spring Bean on the Oracle SCA Container.