How to expose EJB as a web service??

[raka sinha]

Hi
My current application architecture is as follows

Frontend- Weblogic portal
Backend - EJB with Stored proceedure deployed in BEA Weblogic 7.0.

My customer now wants to move from vendor specific app server to open source framework.also they want to remove RMI.

We have currently 250 methodis in EJB?

How should I decide that what all methods that can be exposed as a web service? How many number of service I should plan?


Can any one give me the solution for how to approach this architecture.How to write specific wrapper class for EJB and what all design consideration I have to look for.
Also if you have any links then please let me know.

Thanks in advance.

[Roger Chung-Wee]

I don't understand the requirement to "move from vendor specific app server". Every Java application server is an implementation of several specifications, and every EJB application deployed to a server will need to have an application-specific configuration to work.

If the requirement is to cut costs by moving from an expensive EJB server to a lower-cost server (there is no such thing as a free server), then by all means migrate your EJB applications.

I would caution against thinking too much about building a web service at this stage as you must first do the migration. Once you have done this, and if the web service still makes sense (which very possibly it would not), then you can use BEA-supplied Ant tasks to generate a web service from the EAR file.

[Jeanne Boyarsky]

Originally posted by raka sinha:
We have currently 250 methodis in EJB?

I can't imagine that you want to expose 250 methods as a webservice. Before exposing anything, think about who will be calling it and what specifically, should be exposed.

[Roger Chung-Wee]

I think that it usually best if the EJB methods which are exposed to a client are coarse-grained. Consider a MoneyTransferBean which manages the transfer of funds. What I like to see is a single coarse-grained method, let's call it transfer(), exposed to the client. Behind the scenes, there may be other fine-grained methods such as withdraw(), deposit(), createAuditLog(), etc, which actually do the work but which the client has no need to see.

So Jeanne is right to question exposing 250 methods to the client. What you need to do is declare only the relevant methods in your Remote interfaces, and make the appropriate changes to your EJB classes.

On a related point: if your services are highly transactional, it may be a good idea to implement a stateless session bean as a session facade. The reason is that should you later build a Web service, then this will make it easier to reuse such a bean as a Web service endpoint which can process SOAP messages as RPC calls.