EJBs can serve as endpoints for SOAP based web services if hosted in a container with runtime and service support. New client applications can then be built using the published WSDL to access existing business logic. New remote clients can also continue to access business logic using RMI. Thus clients will have now a choice to use RMI or web services to access the business logic.

There are primarily four types of EJBs:

• Stateful session bean

  • the instance variables represent the state of a unique client/bean session.

• Stateless session bean

  • does not maintain a conversational state with the client. 

• Singleton session bean

  • instantiated once per application and exists for the lifecycle of the application. 

• Message-driven bean 

  • allows Java EE applications to process messages asynchronously. 

Important Note! Stateless Session EJBs and Singleton Session EJBs can be used as web service endpoints. Stateful Session EJB and Message-Driven EJB CANNOT be used as web service endpoints.

Example

Example: Creating a web service endpoint using a stateless session EJB

@Stateless (name = "MyEJB")

@WebService (name = "MyEJBPortType", serviceName = "MyEJBService", portName = "MyEJBPort")

public class MyClass{

}

The value for <ejb-link> for the above service in the webservices.xml will be MyEJB.

Role based access control

1. Role based access control for EJBs can be selected by:

   • Using method-permission element in ejb-jar.xml

   • Specifying security annotations like @RolesAllowed in the EJB class.

2. If a web service endpoint is based on the stateless session EJB and if role based access is specified in the deployment descriptor, then both the EJB and web service clients must be in the specified role.

Additional important points about using EJBs as endpoints for SOAP based web services

1. An EJB-based web service endpoint can use:

   • Java EE declarative security

   • Container-managed transactions

   • Dependency injection