EJB Vs WebService? Performance point of view

Question

Well We have situation to decide now. I thought stackoverflow is best place to discuss.

Background:

We have 2 JVMs Enterprise Application server and one applicat

Answer 1

It doesn't have to be one or the other. You can have all your business logic in EJBs, and also provide a web service facade to access the EJB. Also remember that there are different types of web service architectures. SOAP is what most people think of when they hear "web service", but you might also want to look at JAX-RS.

Sending data as XML over HTTP is horribly inefficient. On the other hand, it gives you much more flexibility on the client side. Web services can be consumed from just about any platform or programming language.

Answer 2

If by "Web Services" you mean SOAP web services, EJBs should be faster no matter how you do it.

Pros:

• Java serialization is faster that XML Web Services
• Serializing and parsing XML uses more memory than straight serialization, EJBs save memory
• EJBs are expressed in straight Java interfaces and value objects. For Web Services, you might have to add a mapping layer such as XmlBeans or JAXB.
• Most EJB protocols lets you easily reuse the TCP/IP connections between calls

Cons:

• Doing a proper design first XML message definition will decouple the client and server
• It is easier to change the message formats given that extra layer of indirection
• EJB implementations have historically been huge and slow, as in bigger than Web Service stacks (but newer EJB implementations like Apache OpenEJB are small, lightweight and embeddable)

But if you don't need distributed transaction handling, just use RMI. It has the pros but none of the cons of EJBs. It's been around for ages, but it still works just dandy.