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 ]