Software Architectures: Chapter 8 Component Architectures

(1)

1.65 Software Architectures: Chapter 8 – Component Architectures

Overview

8.1 Components

8.2 Client-Side Component Architecture

8.3 Foundation for Server-Side Component Architecture 8.4 Server-Side Component Architecture

Enterprise JavaBeans

Disclaimer

Most of the content provided in this chapter is taken from the book “Mastering Enterprise JavaBeans and the Java 2 Platform”, Middleware Company, 2001 [Roman01].

(2)

Enterprise JavaBeans vs. JavaBeans

JavaBeans

• Are simply a way to give Java objects a portable interface (no explicit definition of an interface).

• This allows them to be manipulated as a unity with development tools and to be attached to other Beans, in order to create a complete application. • They can take part in an interactive

client / server system, but this is not obligatory.

• Usually used on the client-side.

Additionally, Enterprise JavaBeans... • Are server side components, that

communicate with remote clients, in order to offer a given functionality. • Are part of a client/server system by

definition.

• Normally don’t work without interaction from a client (the client can be a JavaBean, a Servlet or another, Java or non-Java object on the network). • Are composed of many individual

objects or JavaBeans.

• The reason for calling an application an Enterprise JavaBean is that it can run in an application server.

[Roman01]

Server-Side Requirements for Software

(1)

Remote method invocations: Logic that connects distributed clients and servers via a programming language interface (remote method invocation)

Load-balancing: Routing of client requests to different servers. If a server is overloaded, the requests shall be rerouted to another server.

Multithreading: A Server must be able to process multiple client requests concurrently (multithreading). On the other hand, application programming should not need to take concurrency into account.

Transactions: Consistent, concurrent access to data.

Transparent fail-over: If a server crashes clients must be rerouted to other servers without interruption of service.

Resource pooling. If a client is not currently using a server, the server’s resources can be returned to a pool and used by other clients.

Object lifecycle: Server-side objects need to be created or destroyed when client traffic increases or decreases.

(3)

Server-Side Requirements for Software

(2)

Security. Server and database access must be controlled. Tried and successful security breaches must be audited.

Back-end integration: Newly developed applications need to be able to persist their business data, but also existing legacy systems must be integrated.

Dynamic (hot) deployment: Perform software upgrades while the server is running. Message-oriented middleware: Certain types of requests should be message-based where the clients and servers are very loosely coupled. We need infrastructure to accommodate messaging.

[Roman01]

Server-Side Requirements for Software

(3)

The aforementioned services are classified as middleware services; services grouped together are called middleware. Note that middleware is a bridge between clients and server, is does not contain the applications per se.

Examples: CORBA ORB: provides a distributed access to objects, load-balancing, a transaction service, ...

The term Application Server has been coined to describe a software that provides middleware services and on which applications can be deployed.

The Enterprise JavaBeans specification defines an EJB server / EJB container (we will not differentiate between them). The Enterprise JavaBeans (containing application logic and data) run inside an EJB container that provides middleware services.

Transparent qualities of service not specified in the EJB specification include load-balancing, transparent fail-over, caching, clustering, and connection pooling algorithms

(4)

J2EE Server Client Machine

Application Client Container

Enterprise JavaBeans System

[Sun01] Browser Application Client Web Container Servlet JSP EJB Container Enterprise JavaBean Enterprise JavaBean Data base

Roles in an EJB Scenario

The Enterprise JavaBeans specification defines several roles of solution providers within an EJB application development and deployment scenario:

Bean Provider Application Assembler EJB Deployer

Server-Provider / Container Provider System Administrator

Container and Server Provider Persistence Manager Provider Tool Vendors

(5)

Roles in an EJB Scenario: Bean Provider

The bean provider supplies business components, or enterprise beans. Enterprise beans are not complete applications, but rather are deployable components that can be assembled into complete solutions. The bean provider could be an independent software vendor (ISV) selling components, or an internal department providing components to other departments.

Examples:

An example of a bean provider that ships reusable components is BEA, which sells the

WebLogic Commerce Server for building e-business applications. In the future,

traditional enterprise software vendors (such as sales force automation vendors, enterprise resource planning vendors, financial services vendors, and e-commerce vendors) will offer their software as enterprise beans or will provide connectors to their current technology.

[Roman01]

Roles in an EJB Scenario: Application Assembler

The application assembler is the overall application architect. He or she is responsible for understanding how various components fit together and writes the applications that use components. The application assembler is the consumer of the beans supplied by the bean provider.

The application assembler performs any or all of the following tasks:

Supply a user interface (perhaps Swing, Servlet/JSP, application/Applet, or web service wrapper).

Write new enterprise beans to solve some problems specific to your business problem.

Write the code that calls on components supplied by bean providers.

Write code that maps data between components supplied by bean providers. Components won’t magically work together to solve a business problem – especially if different vendors write the components.

An example of application assembler is a systems integrator, a consulting company, or an in-house programmer.

(6)

Roles in an EJB Scenario: EJB Deployer

After the application assembler builds the application, the application must then be

deployed (and go live) in a running operational environment. This includes:

Securing the deployment with a firewall.

Choosing the right hardware to provide the needed level of scalability. Providing redundant hardware for fault-tolerance.

Integrating with an LDAP server for security lists. Performance-tuning the system.

An EJB deployer is aware of specific operational environments and understands how to deploy beans within servers and how to customize the beans for a specific environment. The EJB deployer has the freedom to adapt the beans, as well as the containers and servers, to the environment in which the beans are to be deployed.

An EJB deployer could be a staff person, an outside consultant, or a vendor. An example deployer is Loudcloud, which offers hosting solutions for EJB deployments.

[Roman01]

Roles in an EJB Scenario: System Administrator

The system administrator oversees the stability of the operational solution. The system administrator is responsible for the upkeep and monitoring of the deployed system and may make use of runtime monitoring and management tools that the EJB server provides.

For example, a sophisticated EJB server might page a system administrator if a serious error occurs that requires immediate attention. Some EJB servers achieve this by developing hooks into professional monitoring products, such as Tivoli and Computer

Associates. Others are providing their own systems management by supporting the Java Management Extension (JMX).

NOTE: Monitoring of EJB deployments is not specified in the EJB specification.

(7)

Roles in an EJB Scenario: Container Provider

The container provider supplies an EJB container (the application server). This is the runtime environment in which beans live. The container supplies middleware to the beans, and manages them.

Examples:

Examples of EJB containers are BEA WebLogic, The Sun-Netscape-AOL alliance

iPlanet, IBM WebSphere, Oracle 9i Application Server, Persistence PowerTier, Brokat Gemstone/J, HP Bluestone, IONA iPortal, Inprise’s Inprise Application Server, and the jBoss open source code application server.

Complete lists are available at

http://java.sun.com/j2ee/compatibility.html http://www.javaskyline.com/serv.html

The server provider is the same as the container provider. The EJB specification has not yet differentiated these (and they may never do so).

Roles in an EJB Scenario: Persist. Mgr. Provider

The persistence manager provider is responsible for providing a persistence manager that plugs into an application server. The EJB components use the persistence manager to map business data into storage, such as mapping objects into relational databases. The persistence manager is chosen to persist business data to any storage type. Examples include legacy systems, flat file systems, relational databases, object databases, or a proprietary system.

The persistence manager provider may be the same as the container/server vendor, such as the case with IBM’s WebSphere that includes built-in persistence capabilities.

Examples:

Examples of persistence manager providers include WebGain’s TOPLink, Thought Inc’s

Cocobase.

(8)

Roles in an EJB Scenario: Tool Provider

To facilitate the component development process, there should be a standardized way to build, manage, and maintain components. In the EJB Scenario, there are several

Integrated Development Environments (IDEs) that help in rapidly building and debugging

components. Examples for IDEs:

NetBeans IDE, IBM’s VisualAge for Java, Inprise’s JBuilder, …

There are also tools that can be used to model components in UML. EJB code can then be auto-generated from the diagrams.

Examples of UML tools:

Borland Together/J, IBM Rational Rose, No Magic MagicDraw UML Further tools (not EJB-specific):

component organizers (Flashline, ComponentSource) testing tools (JUnit, RSW Software), and

build tools (Ant).

[Roman01]

Example of a UML ⇒ EJB tool

Example of UML diagrams supporting EJB.

(9)

Roles in an EJB Scenario: Summary

[Roman01]

Benefits of Solution Provider Role Specialization

Developers that create a Enterprise JavaBean component have a very different task compared to someone who creates an EJB-compatible server.

It frees the developer from implementing system details, transactions, threads, load balancing, persistence, etc.

Application developers can concentrate on the application logic and leave the data processing details to the system.

But it is always possible to make these basic services accessible to the developer Bean-managed persistence (application logic manages persistence)

Transactions managed by application logic Enforcing security restriction to application logic

NOTE: For the rest of the lecture, only the bean provider and application assembler roles will be adopted.

(10)

Web-Server

Enterprise JavaBeans Clients & Server Layers

Presentation Layer Application Layer Database Layer Entity Bean Session Bean

Msg-Driven Bean Session Bean

Entity Bean Msg-Driven Client C++ Client Java Application /

Java Applet JSP / Servlet

Browser Business Partner System

[Roman0

1]

Messaging CORBA/IIOP RMI/IIOP RMI/IIOP

HTTP SOAP, ebXML

Types of Enterprise JavaBeans

(1)

EJB 2.0 defines three different kinds of enterprise beans:

Session beans. Session beans model business processes. They perform actions. The action could be anything, such as adding numbers, accessing a database, calling a legacy system, or calling other enterprise beans. Examples include a pricing engine, a workflow engine, a catalog engine, a credit card authorizer, or a stock-trading engine. Message-driven beans. Message-driven beans are similar to session beans, in that they perform actions. The difference is that you can only call message-driven beans by sending messages to those beans. Examples of message-driven beans include message driven beans that receive stock trade messages, credit card authorization messages, or workflow messages. These message-driven beans might call other enterprise beans as well.

Entity beans. Entity beans model business data. They are data objects – that is, they are Java objects that cache database information. Examples include a product, an order, an employee, a credit card, or a stock. Session beans typically harness entity beans to achieve business goals, such as a stock-trading engine (session bean) that deals with stocks (entity beans). For more examples of this, see table on next slide.

(11)

Types of Enterprise JavaBeans

(2)

Bid, Item Auction Broker

Purchase Order Purchase Order Approval Router

Product Catalog Engine

Order, Line Item Order Entry System

DNA Strand DNA Sequencer

Credit Card Credit Card Authorizer

Bank Account Bank Teller (e.g., Money Transfer)

Entity Bean Session Bean / Message Bean

[Roman01] Examples on the following slides:

• AccountBean (manages a bank account)

• MoneyTransfererBean (moves money between two bank accounts transactionally)

Enterprise Beans: Implementation + Interfaces

(1)

Enterprise JavaBeans are defined by (at least) 2 interfaces and an implementation class:

The Home Interface is used to create and delete a bean or to get a bean (via its remote interface): AccountHome: AccountPK create (int accountId)

Account findByPrimaryKey (AccountPK pk) MoneyTransfererHome: MoneyTransferer create ()

The Remote Interface specifies the business methods of a single bean:

Account: void credit (double amount)

void debit (double amount) double getBalance ()

MoneyTransferer: void moveMoney (Account from, Account to, double amount)

The Bean Implementation Class: indirectly implements the remote interface and some methods of the home interface (create, remove)

AccountBean “implements” Account

(12)

Enterprise Beans: Implementation + Interfaces

(2)

1. The client uses the Home Interface to create a new bean or to retrieve an existing one (retrieving only makes sense for Entity Beans, see following slides). The bean is returned as an object that implements the Remote Interface.

2. The client invokes business methods on the Remote Interface.

3. The business logic residing in the bean implementation class is executed.

The EJB Object

(1)

When a client wants to use an instance of an enterprise bean class, the client never invokes the method directly on an actual bean instance. Rather, the invocation is

intercepted by the EJB container and then delegated to the bean instance. By

intercepting requests, the EJB container can automatically perform implicit middleware. The EJB container is acting as a layer of indirection between the client code and the bean. This layer of indirection manifests itself as a single network-aware object, called the EJB object.

(13)

The EJB Object

(2)

Middleware services performed by the EJB container:

Implicit distributed transaction management: EJB container provides a

transaction service – a low-level implementation of transaction management and

coordination. The transaction service must be exposed through the Java

Transaction API (JTA).

Implicit security: The Java 2 Platform, Standard Edition yields a robust security service that can authorize and authenticate users, securing deployments from unwanted visitors. EJB adds to this the notion of transparent security, allowing components to reap the benefits of a secure deployment without necessarily coding against a security API.

Implicit resource management and component life cycle: The EJB container implicitly manages resources for enterprise beans, such as threads, sockets, and database connections. The life cycle of the enterprise beans themselves are also managed, allowing for the enterprise bean instances to be reused by the EJB container as necessary (pooling).

[Roman01]

The EJB Object

(3)

Implicit persistence: Persistence is a requirement of any deployment that requires permanent storage. EJB offers assistance here by automatically saving persistent object data to an underlying storage and retrieving that data at a later time.

Implicit remote accessibility: Enterprise bean classes can’t be called across the network directly because an enterprise bean class is not network-enabled. The EJB container handles networking by wrapping the bean in a network-enabled object. The network-enabled object receives calls from clients and delegates these calls to instances of the bean class. This saves the bean provider from having to worry about networking issues (the container provides networking as a free service). EJB products thus automatically convert stand-alone, network-less components into distributed, network-aware ones.

Implicit multi-client support: EJB containers automatically handle concurrent requests from clients. EJB containers provide built-in thread support, instantiating multiple instances of components as necessary and pushing one thread through each instance. This way, the bean provider does not need to worry about writing thread-safe code.

(14)

The EJB Object

(4)

Implicit component location transparency: Clients of components are decoupled from the specific component location.

Implicit monitoring: The EJB container can track which methods are invoked, display a real-time usage graph on a system administrator’s user interface, gather data for intelligent load balancing, and more. Although there is no requirement for an EJB container to perform these tasks, high-end EJB containers will perform these tasks at the point of interception.

[Roman01]

Enterprise Beans: General Lifecycle

When the method create() is invoked, the bean is instantiated, the context is set and the callback method ejbCreate() (see next slide) is called on the bean (allows to pass parameters given in create()). The bean is then ready to be used (state ready). An existing bean that is currently not needed can be passivated, i.e. temporarily removed from memory. Its state is then stored and its memory freed. A passivated bean can be (re-)activated.

When the method remove() is invoked on a bean that is in the ready state, the callback method ejbRemove() is called and the bean is then destroyed.

The ejbX() methods are called management callback methods, because they are invoked by the EJB container to notify the bean of a state change.

(15)

Enterprise Beans: The EJB Container “Glue”

(1)

Modus operandi:

The client calls the create() and remove() methods. These calls are intercepted by the EJB container (via EJB object).

After applying middleware services, the calls are delegated as ejbCreate() and ejbRemove() to the bean.

This requires that the create() method and the ejbCreate() methods have the same parameter lists. Furthermore, the bean remote interface (defining the business methods) and the bean home interface are remote interfaces (i.e., their methods throw RemoteExceptions), but the bean implementation class is NOT a remote object, therefore its methods do not throw

RemoteExceptions. Consequences:

The bean implementation class cannot implement the bean remote interface and the create() method by implementing the interfaces. Rather, the business methods are mapped by name. Consistency therefore cannot be enforced by the java compiler but has to be provided by

either the development tools (synchronizing methods and parameters) or has to be checked at deployment time. Æ Verifier tool.

Enterprise Beans: The EJB Container “Glue”

(2)

MoneyTransferer: Session Bean and Interfaces

Account:

(16)

Session Beans

Session Beans encompass the business process logic of business applications. A session bean is a (relatively) short-lived component, it has the lifetime equivalent of a

session or of the client code invoking methods. Session beans are nonpersistent, i.e.,

they are not saved to permanent storage. Session beans may perform database operations, but the session bean itself is not a persistent object.

Serialized method invocations:

A session bean is never used concurrently (one client may call one method at a time). This frees the bean developer from taking concurrency issues into account (access to variables). The concurrency is handled by the EJB container (by instantiating several session beans when needed).

Example:

A product search engine.

[Sun01]

Stateful and Stateless Session Beans

Session Beans can be stateless or stateful:

A stateful session bean has a state that may reflect previous operations. Technically, a stateful session bean has attributes whose state is kept between method invocations.

A stateless session has no conversational state (between method invocations). It therefore has no attributes relevant for client interaction (but may contain other attributes).

Session Beans make use of entity beans and other session beans.

Example of a stateful and a stateless session bean:

A stateful search engine delegates searches to a stateless search engine and keeps previous search expressions of the user.

(17)

Stateless Session Beans: Lifecycle

Stateless session beans need not be passivated and (re-)activated, as they hold no state. Therefore, it is inexpensive to pool stateless session beans.

Stateless Session Bean Lifecycle [Sun01]

Stateful Session Beans: Lifecycle

Stateful session beans must be stored after passivation and reloaded before activation.

Passivation: Before removing a stateful session bean, the container invokes the ejbPassivate() method to announce that the bean is to be persisted. The bean shall close database connections. The container might store the bean’s state, e.g., using Java serialization. Activation: The EJB container

creates a session bean by deserializing its persisted state. It then invokes ejbActivate() to allow the bean to reopen database connections, etc.

Compared to stateless session beans, it is expensive to pool stateful session beans.

Stateful Session Bean Lifecycle

(18)

Entity Beans

Entity Beans encompass the persistent data of business

applications. On one hand, entity beans correspond and are

mapped to database table entries. Therefore, they comprise the

primary key concept. On the other hand, entity beans are

beans (objects), i.e. they encapsulate data and provide access methods for manipulation. As with database data, entity beans may be shared by multiple clients. The EJB container provides transaction management to control access.

Example: The AccountBean (see right). It defines a bank account having the private attributes

int id (primary key) double balance and access methods

void credit (double amount) void debit (double amount) double getBalance ()

Entity Beans: Lifecycle

Creation and deletion:

Entity beans can be created and removed using create() and remove() methods. Calling the remove() method deletes the bean’s content from the database.

Retrieval:

(Existing) entity beans are retrieved with finder methods ( findByPrimaryKey(),

findByX()). A primary key-based finder

method is required, other find methods can be provided optionally.

(19)

Entity Beans: Persistence

The EJB specification defines two models to persist an entity bean’s state:

Manual mapping (Bean Managed Persistence, BMP): The developer has to provide methods in the entity bean that store and retrieve the bean’s state in a database table.

+ manual optimization possible - coding is “boring to death” - coding is error-prone

Mapping done by the container (Container Managed Persistence, CMP): The container uses Java reflection to identify all attributes (all public attributes) and handles storage and retrieval of entity beans in the database (see persistence manager).

+ “stupid work” is automated + error-free

- performance of CMP is very poor in many implementations

- requires that all attributes to be persisted must be public (breaking the concept of information hiding)

CMP is the recommended persistence model.

Entity Beans: Relationships

Entity Beans are

used by session beans (obvious for storing business process data) and related to other entity-beans (table relationships in a database).

Example of entity bean relationship:

A customer may have several accounts. In database terminology, the account has a foreign key to the customer.

Entity Beans relationship is implemented differently with BMP and with CMP: In BMP, the Account bean keeps a foreign key attribute identifying the customer

bean.

(20)

Message-Driven Beans

(1)

A Message-Driven Bean is a enterprise bean that allows J2EE applications to process messages asynchronously. It acts as a JMS message listener, which is similar to an event listener except that it receives messages instead of events. The messages may be sent by any J2EE component – an application client, another enterprise bean, or a Web component – or by a JMS application or system that does not use J2EE technology.

Message-driven beans typically contain message-oriented logic, such as logic to receive a stock trade message and call a session bean that knows how to perform stock trading.

Differences Between Message-Driven Beans and Session and Entity Beans Clients do not access message-driven beans through interfaces. A message-driven

bean has only a bean class.

Session beans and entity beans allow sending and receiving JMS messages synchronously (blocking), but not asynchronously.

(beans are not allowed to start threads)

[Sun01]

Message-Driven Beans

(2)

Message-driven beans resemble stateless session beans in several aspects: A message-driven bean’s instances retain no data or conversational state for a

specific client.

All instances of a message-driven bean are equivalent, allowing the EJB container to assign a message to any message-driven bean instance. The container can pool these instances to allow streams of messages to be processed concurrently. Therefore, a single message-driven bean can process messages from multiple

clients.

A message-driven bean must implement the MessageDrivenBean and MessageListener interfaces and therefore implement the onMessage() method. When the queue receives a message, the EJB container invokes the onMessage() method of the message-driven bean.

(21)

Message-Driven Beans: Message Dispatching

(1)

When a message arrives, the container calls the message-driven bean's onMessage() method to process the message. The onMessage() method normally casts the message to one of the five JMS message types and handles it in accordance with the application's business logic. The onMessage() method may invoke a session or entity bean to process the information in the message or to store it in a database.

A message is delivered to a message-driven bean within a transaction context, so that all operations within the onMessage() method are part of a single transaction. If message processing is rolled back, the message will be redelivered.

[Sun01]

Message-Driven Beans: Message Dispatching (2)

Excerpt from a message-driven bean:

private transient MessageDrivenContext mdc ;

public void setMessageDrivenContext (MessageDrivenContext mdc) { this.mdc = mdc ;

}// setMessageDrivenContext

public void onMessage (Message inMessage) { try {

if (inMessage instanceof TextMessage) {

TextMessage msg = (TextMessage)inMessage ; System.out.println ("Message: " + msg.getText ()) ; // here: get Session Bean and forward message

} else

System.out.println ("Wrong type!") ; } catch (JMSException e) { mdc.setRollbackOnly () ; } catch (Throwable t) { t.printStackTrace () ; } }// onMessage

rollback ⇒ message will be sent again in case an error occurred during rollback

forward message to a session bean

(22)

Message-Driven Beans: Lifecycle

[Sun01]

Clients: Locating Beans

(1)

As mentioned before, the EJB architecture provides location transparency (clients do not know the beans’ location).

Question: How do bean clients (Servlets, JSP pages, client applications, ...) locate beans?

General answer: In distributed systems, components are located using a naming

service.

EJB-specific answer: EJB makes use of the Java Naming and Directory Interface

(JNDI) to expose and retrieve enterprise beans.

Exposure of references:

(Container-specific) EJBObjects that implement the home interfaces are bound to JNDI names (defined in descriptors).

(23)

Clients: Locating Beans

(2)

Retrieval of references:

With JNDI, references are retrieved using JNDI contexts. The received object-references must be narrowed (comparable to CORBA references).

public static AccountHome getAccountHome () throws NamingException

{

InitialContext context = new InitialContext () ; Object objref = context.lookup ("AccountHome") ;

return (AccountHome)PortableRemoteObject.narrow (objref,

AccountHome.class) ; }// getAccountHome

Clients: Locating Beans: Helper Class

(1)

public final class EJBGetter {

public static AccountHome getAccountHome () throws NamingException

{

InitialContext context = new InitialContext(); Object objref = context.lookup ("AccountHome") ; return (AccountHome)PortableRemoteObject

.narrow (objref, AccountHome.class) ; }// getAccountHome

public static Account getAccount (int accountId) throws Exception

{

return getAccountHome ()

.findByPrimaryKey (new AccountPK (accountId)) ; }// getAccount

...

[Sun01] The following helper class provides static methods to retrieve Session and Entity Beans.

(24)

Clients: Locating Beans: Helper Class

(2)

...

public static MoneyTransfererHome getMoneyTransfererHome () throws NamingException

{

InitialContext context = new InitialContext () ; Object objref = context.lookup ("MoneyTransfererHome") ; return (MoneyTransfererHome)PortableRemoteObject

.narrow (objref, MoneyTransfererHome.class) ; }// getMoneyTransfererHome

public static MoneyTransferer getMoneyTransferer () throws Exception

{

return getMoneyTransfererHome ().create () ; }// getMoneyTransferer

}// EJBGetter

[Sun01]

Clients: Sample Servlet using Enterprise Beans

public class MoneyTransferServlet extends HttpServlet

{

public void doPost (HttpServletRequest request, HttpServletResponse response) throws ServletException

{ try {

String fromAccountId = request.getParameter ("fromAccountId") ; String toAccountId = request.getParameter ("toAccountId") ;

double amount = Double.parseDouble(request.getParameter("amount")) ; Account from = EJBGetter.getAccount (fromAccountId) ;

Account to = EJBGetter.getAccount (toAccountId) ;

MoneyTransferer transferer = EJBGetter.getMoneyTransferer () ; transferer.moveMoney (from, to, amount ) ;

}

catch (Exception exc) {

throw new ServletException (exc) ; }

}// doPost

}// MoneyTransferServlet

Too simple error-handling!

(25)

Enterprise JavaBeans as a Standard

Intended as the standard for Java-based Client/Server applications:

EJB intends to be the standard for enterprise-wide applications that are built Java. EJB components that are Java classes, can be inserted without renewed compiling

on any other EJB compatible server (an advantage that platform-specific solutions cannot offer).

EJB is compatible with other Java APIs and uses them, can interoperate with non-Java applications, and its compatibility with CORBA is increasing.

Competitors of EJB: Web Services

Microsoft .NET platform CORBA