File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Web Services and the fly likes WebServices versus EJB Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "WebServices versus EJB" Watch "WebServices versus EJB" New topic

WebServices versus EJB

k j

Joined: Jan 29, 2004
Posts: 3
Hi all,

Ive been trying to get clear what the main differences between using WebServices against EJB. From my understanding both technologies can make RPC type calls (in different ways).

I know that SOA uses XML technology and can be thought of the middleware between e.g. .NET and Java, whereas EJB are Java objects that require Java code to call them.

Just some basic points on these differences would be good,

Peer Reynders

Joined: Aug 19, 2005
Posts: 2933
Welcome back to JavaRanch!

Please review the JavaRanch official policy on registered names and adjust your name accordingly. Your cooperation is appreciated.
Peer Reynders

Joined: Aug 19, 2005
Posts: 2933
First of all there is the intended level of granularity: Web services are more suitable to a larger granularity than stateless session beans.
SLB-local, home, endpoint interface

While Web Services are currently often used as an RPC mechanism they are actually not optimally suited to that task.
Because of their inherent coarse-grained nature the document-oriented exchange style is a better suited application to the technology.
Web services != RPC
Tech Talk: Ted Neward on Web Services and Security
� this is a message, and it�s in XML, because wanting to take your code and seamlessly turning it into objects and back again, � that�s just not going to work. It�s not going to happen.

Patterns and Strategies for Building Document-Based Web Services

Web services use HTTP/HTTPS which can pass through firewalls � EJB uses RMI/IIOP which can't (unless you don't mind increasing the attack surface of your firewall).
SOA is a much more complicated concept than you imply. You aren't doing SOA just because you are doing XML over HTTP.
SOA antipatterns

Web Services do not guarantee Java EE/.NET interoperability unless both sides adhere to a WSI Basic Profile. Also this interoperability is limited to messaging � there is no guarantee that an object on one side will have an equivalent representation on the other side (unless you define the mapping yourself on both ends).

All in all, there are more differences than there are commonalities.
  • Define a stateless session bean of large enough granularity and it may make sense to expose it as a web service endpoint (this is supported by J2EE 1.4).
  • Both stateless session beans and web services can be used as access points/an interface to remotely managed business logic. However considering the strengths and weaknesses of each technology the interfaces should be designed quite differently. Ideally a Web Service interface should be message based and less chatty than the SSB equivalent (though SSBs do benefit from a coarse-grained design).

  • [ June 27, 2006: Message edited by: Peer Reynders ]
    I agree. Here's the link:
    subject: WebServices versus EJB
    It's not a secret anymore!