EJB Overview What is EJB EJB Roles EJB

EJB Overview What is EJB? EJB Roles EJB Architecture EJB Services Building an EJB Application EJB & CORBA Summary Enterprise Java Beans- page 1

EJB in the n-Tier System You Are Here Browser Client Applet Database Client Application Legacy Systems EJB Server Clients Application Data Enterprise Java Beans- page 2

What is EJB? Specification for component based distributed computing framework using Java technology. Enterprise Java. Beans Specification describes • roles and responsibilities for component-based software development of server-side applications. • an architecture including EJB Servers, Containers, and Beans. • a set of services including naming, transactions and security. • interoperability with database servers and CORBA applications. Enterprise Java Beans- page 3

EJB Roles Application Development and Deployment Bean Provider - Producer of enterprise beans. Application - Combines enterprise beans into Assembler larger deployable parts. Deployer - Deploys enterprise beans into a specific operational environment. Platform Provider - Container provider and server provider. System Admin. - Configuration and administration of infrastructure. Enterprise Java Beans- page 4

EJB Architecture The container is the platform. The component is your application. Picture provided by Sun Microsystems, Inc. Enterprise Java Beans- page 5

EJB Platform Provide naming service using JNDI Provide OMG/OTS compliant transaction service Container EJB Server Manage EJ Bean life cycle Make EJ Bean Interfaces Available with JNDI Provide basic security services Persistence Management (DBMS and other) Manage transaction context Enterprise Java Beans- page 6

EJB Platform Vendors Select EJB complaint platform for purchase (1. 0 or 1. 1). EJB Platform vendors supplement standard EJB with proprietary features. Current Vendors include • BEA Systems - Web. Logic • Bluestone - Sapphire/Web • IBM - Web. Sphere • Inprise - Application Server • Oracle - Oracle 8 i • Persistence - Power. Tier • Sun/Netscape alliance - reference implementation Enterprise Java Beans- page 7

EJB Application consists of multiple beans Beans are “portable” across containers Beans can be purchased or constructed Enterprise Java. Beans™ Component Enterprise Java Beans- page 8

Types of Enterprise Java. Beans Session Bean • Used for client interface • Not shared between clients • Two kinds of Session Bean: - stateless - common object identity - stateful - unique object identity Entity Bean • Maps to data in database or application • Shared between clients • Persistent state - container managed - access defined at deployment - bean managed - access defined as part of bean • Support optional in 1. 0 and mandatory in 1. 1 Enterprise Java Beans- page 9

Mixing Beans EJB applications use a combination of entity beans and session beans to implement business logic. Prefix. Bean Client Session Bean Entity Bean Echo. Service. Bean Database Suffix. Bean Application Server Enterprise Java Beans- page 10

EJB Client Interfaces Factory Interface Finder Interface EJB Home EJB Object Remote Interface Contains bean services seen by clients Enterprise Java Beans- page 11

EJB Architecture The purchased EJB server is the platform. The application consists of session and entity beans. Application interfaces are made available to clients at time of deployment. Picture provided by Sun Microsystems, Inc. Enterprise Java Beans- page 12

Deployment Bean + Deployment descriptor Deploy Platform Specific Implementation of Bean Deployment provides a mechanism for adapting a component for a specific runtime environment. Deployment is an intermediate step between coding a bean and executing a bean. By using a deployment descriptor, some attributes of the bean implementation are specified by the deployer, and implemented by the platform provider. Two kinds of information in a deployment descriptor • Enterprise beans’ structural information - can’t change • Application assembly information - can change Enterprise Java Beans- page 13

EJB Overview What is EJB? EJB Roles EJB Architecture EJB Services Building an EJB Application EJB & CORBA Summary Enterprise Java Beans- page 14

EJB Services Standard EJB services allow application developers to • focus on business logic rather than infrastructure • defer responsibility for common services to the EJB platform • create “portable” applications that can be reused • support a component marketplace Standard EJB services include • Persistence • Naming • Transactions • Security Enterprise Java Beans- page 15

Persistence EJB Definition “The data access protocol for transferring the state of the entity between the enterprise bean instance and the underlying database is referred to as object persistence. ” Two types of persistence • bean-managed - persistence logic implemented directly inside the enterprise bean class. • container-managed - persistence logic delegated to container. The underlying data source may be an existing application rather than a database. Enterprise Java Beans- page 16

Bean-Managed Persistence Entity. Bean SQL code persistence logic + Deploy Bean • SQL code • persistence logic Deployment Descriptor persistence-type Enterprise bean provider writes database access calls (using JDBC or SQLJ) directly in the entity bean. Entity bean is tied to the data source in which the entity is stored. More portable across EJB platforms than containermanaged entity bean. Enterprise Java Beans- page 17

Container-Managed Persistence Entity. Bean + Deployment Descriptor persistence-type cmp-fields Deploy Bean • generated SQL code • generated persistence logic Data access components (like JSBC and SQLJ calls) are generated at deployment time by container tool. Entity bean is independent from the data source in which the entity is stored. Less development effort for bean provider. Enterprise Java Beans- page 18

Name Service - Deployment Descriptor Deploy bean home name Benefits • EJB server has built-in name server. • Service name of bean is assigned at deployment time, not compile time. • Some EJB servers support enterprise bean replication. Enterprise Java Beans- page 19

Name Service - Lookup My. Client Context ct= get. Initial. Context(…) ct. lookup(“Echo. Service”) Runtime Benefits • JNDI allows clients to use one interface for locating CORBA, LDAP, NDS, and file objects. • Allows management of enterprise wide services using naming hierarchy. Enterprise Java Beans- page 20

Transactions Benefits • EJB applications can defer transaction logic to EJB server and container. • Distributed transactions. Picture provided by Sun Microsystems, Inc. Enterprise Java Beans- page 21

Security Deployment Descriptor Deploy Generated Bean Code • security logic security roles. . . Benefits • Permissions specified for each bean service at deployment time. • Builds on security of JDK. Detailed discussion by Robert Seacord. Enterprise Java Beans- page 22

Building an EJB Application How do we build an EJB application? Client Database Application Server Enterprise Java Beans- page 23

Step 1: Create Interfaces EJB Server Specifies the life cycle interfaces public interface Account. Home extends EJBHome{ public create(…) public find. By. Primary. Key(. . ) Home I/F Client Specifies the interface provided to bean clients public interface Account extends EJBObject{ public get. Name(…) public set. Name(…) Database Remote I/F EJB specification This is generated You write this Enterprise Java Beans- page 24

Step 2: Create Implementation EJB Server Home I/F Client Entity. Bean implements Account Implements bean interfaces public class Account. Bean implements Entity. Bean { Remote I/F public void ejb. Activate(. . . ) {………} public void ejb. Passivate(…) {………. } public get. Name(…) {……. . } public set. Name(…) {……. . } Database EJB specification This is generated You write this Enterprise Java Beans- page 25

Step 3: Deployment Descriptor EJB Server Home I/F Client Entity. Bean “Tells” the container how to deploy the bean (how to do DBMS access, transactions, security, naming, etc. ) implements Account Database Remote I/F Deployment descriptor EJB specification This is generated You write this Enterprise Java Beans- page 26

Step 4: Deploy EJB Server Home obj Client implements Entity. Bean Home I/F implements Account Database delegates Remote obj implements Remote I/F Deployment descriptor EJB specification This is generated You write this Enterprise Java Beans- page 27

Entity Bean Inheritance - 1 Java. rmi. Remote EJBMeta. Data Java. io. Serializable EJBObject EJBHome JDK Enterprise. Bean EJB Spec Entity. Bean Provider (Wombat) Container Provider (Acme) Produced by Acme tools Extends or implements interface Extends implementation, code generation or delegation Enterprise Java Beans- page 28

Entity Bean Inheritance - 2 Java. rmi. Remote EJBMeta. Data Java. io. Serializable EJBObject EJBHome Account. Home JDK Enterprise. Bean EJB Spec Entity. Bean Account. Bean Provider (Wombat) Container Provider (Acme) Produced by Acme tools Extends or implements interface Extends implementation, code generation or delegation Enterprise Java Beans- page 29

Entity Bean Inheritance - 3 Java. rmi. Remote EJBMeta. Data Java. io. Serializable EJBObject EJBHome Account. Home Acme. Meta. Data JDK Enterprise. Bean EJB Spec Entity. Bean Account Acme. Home Bean Account. Bean Provider (Wombat) Acme. Remote Acme. Bean Container Provider (Acme) Acme. Account. Home Acme. Remote. Account Acme. Account. Meta. Data Produced by Acme. Account. Bean tools Extends or implements interface Extends implementation, code generation or delegation Enterprise Java Beans- page 30

EJB & CORBA EJB and CORBA are complimentary standards. EJB uses CORBA for • Enabling non-Java clients to access EJB applications. • Interoperability for EJB environments that include systems from multiple vendors. EJB-to-CORBA mapping (separate specification) • Mapping of EJB interfaces to RMI-IIOP. • Propagating transaction context. • Propagating security context. • Interoperable naming service. Enterprise Java Beans- page 31

Summary The EJB architecture simplifies distributed application development by • providing pre-integrated solution framework • separating the business logic from distributed system services • providing standard services, including naming, transactions, and security • managing life cycle functions Enterprise Java Beans- page 32

EJB Security Management Enterprise Java Beans - page 33

Security Management Overview The enterprise bean class provider should not hard-code security policies and mechanisms into the business methods • allows appropriate deployment for the operational environment of the enterprise The application assembler may define • security roles for an application - semantic grouping of permissions • method permissions for each security role - permission to invoke a specified group of methods Enterprise Java Beans- page 34

Security Management Overview - 2 System Admins Deployer Application Assembler Bean Provider Method Permissions Users Security Roles E J B Groups Enterprise Java Beans- page 35

Bean Provider’s Responsibilities The bean provider should not implement security mechanisms or security policies in the enterprise beans’ business methods • rely instead on the security mechanisms provided by the EJB Container It is possible, however, to programmatically access a Caller’s Security Context. . . Enterprise Java Beans- page 36

Programmatically Accessing a Caller’s Security Context Two methods allow the bean provider to access security information about the enterprise bean’s caller • get. Caller. Principal • is. Caller. In. Role In general, security management should be enforced by the container • the security API should is used infrequently Enterprise Java Beans- page 37

Declaring Security Roles Security roles are declared in the deployment descriptor. . . <enterprise-beans> <entity> <ejb-name>Wombat. Payroll</ejb-name> <ejb-class>com. wombat. Payroll. Bean</ejb-class> <security-role-ref> <description> This security role should be assigned to the employees allowed to update employees’ salaries. </description> <role-name>payroll</role-name> </security-role-ref> </entity> </enterprise-beans> … Enterprise Java Beans- page 38

Application Assembler’s Responsibilities Define security roles in the deployment descriptor <security-role> <role-name> employee <description> allow employees to access their own data Specify the methods of the remote and home interface that each security role is allowed to invoke <method-permission> <role-name> employee <ejb-name> Wombat. Payroll <method-name> get. Employee. Info Link declared security role references to security roles <role-link> payroll-department (add to bean description) Enterprise Java Beans- page 39

Deployer’s Responsibilities Ensures that an application is secure after it has been deployed in the operational environment Assigns principals and/or groups of principals used for managing security in the operational environment to defined security roles • not specified in the EJB architecture! • specific to that operational environment Can use the security view defined in the deployment descriptor merely as “hints” Enterprise Java Beans- page 40

EJB Container Provider’s Responsibilities The EJB container provides the implementation of the security infrastructure A security domain can be implemented, managed, and administered by the EJB Server • e. g. , the EJB Server may store X 509 certificates The EJB specification does not define the scope of the security domain • the scope may be defined by the boundaries of the application, EJB Server, operating system, network, or enterprise Enterprise Java Beans- page 41

System Administrator’s Responsibilities Typically responsible for • creating a new user account • adding a user to a user group • removing a user from a user group • removing or freezing a user account Security domain administration is beyond the scope of the EJB specification. . . Enterprise Java Beans- page 42

Proceed with Caution… EJB Server Vendor EIS re u c EJB Specification Sec e s n I ure Threats Enterprise Java Beans- page 43

Summary The EJB architecture does not specify how an enterprise should implement its security architecture • assignment of security roles to the operational environment’s security concepts is specific to the operational environment • identification and authentication left to EJB Server vendor’s Security will be vendor specific for some time • no plans to address problem in EJB 2. 0 Enterprise Java Beans- page 44

EJB Transactions Enterprise Java Beans - page 45

Distributed Transactions EJB allows application developers to write applications that atomically update data in multiple databases • may be distributed across multiple sites • sites may use EJB Servers from different vendors The enterprise Bean Provider and the client application programmer are not exposed to the complexity of distributed transactions. Enterprise Java Beans- page 46

ACID Properties Atomicity. In a transaction involving two or more discrete pieces of information, either all of the pieces are committed or none are. Consistency. A transaction either creates a new and valid state of data, or, if any failure occurs, returns all data to its state before the transaction was started. Isolation. A transaction in process and not yet committed must remain isolated from any other transaction. Durability. Committed data is saved by the system such that, even in the event of a failure and system restart, the data is available in its correct state. Enterprise Java Beans- page 47

Programmatic vs. Declarative Transaction Demarcation Bean-managed transaction demarcation • enterprise bean code demarcates transactions using javax. transaction. User. Transaction • accesses between User. Transaction. begin and User. Transaction. commit calls are part of a transaction Container-managed transaction demarcation • container demarcates transactions per instructions provided by the Application Assembler in the deployment descriptor Enterprise Java Beans- page 48

Container-Managed Transaction Demarcation Not. Supported - container invokes enterprise Bean method with an unspecified transaction context Required - container invokes enterprise Bean method with a valid transaction context Supports • If the client calls with a transaction context, same as Required • If the client calls without a transaction context, same as Not. Supported Enterprise Java Beans- page 49

Container-Managed Transaction Demarcation - 2 Requires. New - container invokes enterprise Bean method with a new transaction context Mandatory - container invokes enterprise Bean method with the client’s transaction context Never - container invokes an enterprise Bean method without a transaction context • client is required to call without a transaction context Enterprise Java Beans- page 50

Isolation Levels Describes the degree to which access to a resource manager by a transaction is isolated from other concurrently executing transactions Part of the EJB 1. 0 specification -- has been eliminated in EJB 1. 1! • API for managing an isolation level is resourcemanager specific • bean provider may specify the same or different isolation levels for each resource manager Enterprise Java Beans- page 51

Updates to Multiple Databases Server X Client DB A Y DB B DB C • Multiple databases • Single transaction Enterprise Java Beans- page 52

Updates to Multiple Databases in Same Transaction client EJB Server X Y DB A DB B Enterprise Java Beans- page 53

Updates to Multiples Databases on Multiple Servers EJB Server client begin X DB commit Y TP EJB Server Enterprise Java Beans- page 54

Two-Phase Commit (2 PC) JDBC 1. 2 does not support XA two phase commit • impossible for an EJB server using JDBC 1. 2 to directly support for distributed transactions Distributed transactions requires the existence of database drivers that support XA 2 PC • in most cases, developers are relying on the vendor to provide database drivers Enterprise Java Beans- page 55

Relationship to JTA and JTS Java Transaction API (JTA) Java Transaction Service (JTS) Enterprise Java Beans- page 56

Java Transaction API (JTA) Enterprise Java Beans- page 57

Java Transaction API (JTA) JTA specifies the interfaces between a transaction manager and the other parties involved in a distributed transaction processing system • application programs • resource managers • application server Enterprise Java Beans- page 58

Java Transaction Service (JTS) Java binding of the CORBA Object Transaction Service (OTS) 1. 1 specification Provides transaction interoperability using the standard IIOP protocol for transaction propagation between servers Intended for vendors who implement transaction processing infrastructure for enterprise middleware • may be used by an EJB Server vendor as the underlying transaction manager Enterprise Java Beans- page 59

EJB Relationship to JTA and JTS Does not require the EJB Container to support the JTS interfaces Requires that the EJB Container support the javax. transaction. User. Transaction interface defined in JTA Does not require support for • JTA resource manager (XAResource) • application server interfaces Enterprise Java Beans- page 60

Summary Transaction-based systems can be implemented simply using EJB Transactions are not simple -- transaction behavior is affected by choice of • session bean or entity bean • stateful or stateless session bean • bean-managed vs. container-managed transaction demarcation • transaction attributes • lots more stuff! Enterprise Java Beans- page 61

Integration of Legacy Software in EJB Enterprise Java Beans - page 62

Agenda Types of legacy systems Integrating legacy business logic Integrating legacy data Enterprise Java Beans- page 63

Types of “Legacy” Infrastructures Data • Mainframes • Non-relational databases • File systems. . . Systems: Data + Logic (Niklaus Wirth) • TP monitors, COBOL systems • ERP systems • CORBA and COM servers Enterprise Java Beans- page 64

Integrating Legacy Business Logic Keep and leverage investment Access old system through a new interface (Internet…). Substitute the old code in an incremental way - eliminating big-bang approach Enterprise Java Beans- page 65

Traditional Approaches Legacy System Function 1 Function 2 Screen IT manager commits suicide. New, pretty and Internet aware System Internet server Big- Bang Conversion N ve CGI coamtim. extension Script Screen Scrap ping Terminal em HTML ulation… Enterprise Java Beans- page 66

Traditional Approaches : Advantages & Problems Screen scrapping and terminal emulation • fast and “cheap” • plenty of support tools • the new system is as inflexible and hard to maintain as the old one • it is just a “make up” Big bang conversion • definitive solution • plenty of liberated IT resources are needed • the EIS must not be vital, a period of adaptation to the new system must be admissible Enterprise Java Beans- page 67

Application Server Approaches Legacy System Function 1 Message. Service Native comm. Broker Function 2 Native comm. Screen Wrapped functionality EJB Server Internet server Function 2 bean Applet Adapter CGI or Servlets Function 1 bean HTML Enterprise Java Beans- page 68

Adapter Strategy: Details Workflow model. If it involves more than one function then NOT_SUPPORTED Wrapper of Function 1 If The COBOL system enables rolling a function then NEW_REQUIRED Workflow 1 Stateful Session Func. 2 Stateless Session Text only COBOL system Function 1 Function 2 EJB server Func. 1 Stateless Session Green screen terminal Adapter Stateless Session no state between functions Communication: error control, connection pooling, timing. . . NOT_SUPPORTED Enterprise Java Beans- page 69

Application Server Approaches : Advantages & Problems Sometimes it is very difficult to divide the old monolithic system into discrete functions. Legacy interfaces can be very hard to use. Text based communication, for example, is error prone. Step by step approach. Very good “effort / added-value” relation. Straightforward approach with well defined steps. Enterprise Java Beans- page 70

Integrating Legacy Data: Why? Cannot migrate the data • legacy systems may still use it. Don’t want to replicate data for coherence and maintenance. Data needs to be accessed from EJB applications • preferably in a transparent way, I. e. through Entity beans. Enterprise Java Beans- page 71

Legacy Data II: Present Approach JDBC ve Nati ss Acce JDBC Driver XA JDBC-ODBC Mainframes, Bridge Relational DB, File systems, Native ODBC OO databases. Access Entity “Regular” Bean Container Transaction Manager Driver Na Ac tive ce ss Native Access Custom Resource Manager EJB Server “Specialized” Entity Container XA CUSTOM Bean Enterprise Java Beans- page 72

Legacy Data III: Future Approach Database Transaction Processor ERP Native Access Entity Bean Container Connector EJB Server Connector Transactions Native Access Connector Security Standard interfaces Resource management Enterprise Java Beans- page 73

Connectors Java SM Community Process Initiated • expert group being formed Schedule for specification release not yet defined • not expected until at least 2000 • implementations will follow For more information contact: Rahul Sharma, Member of Technical Staff Sun Microsystems, Inc. Rahul. Sharma@sun. com Enterprise Java Beans- page 74

Connectors: Advantages Standard connection EIS resources and application servers. No more proprietary and non-portable solutions like specialized containers. Only covers the system level interfaces. Application level interfaces are still vendor specific. Enterprise Java Beans- page 75

Conclusions Application servers in general, and EJB in particular, are powerful and smart ways to integrate legacy systems in modern EIS. Every legacy integration effort includes risks. It is a difficult task that requires a great deal of expertise. Other options like big-bang migration or screen scraping are more expensive or do not fully solve the problem. Enterprise Java Beans- page 76

Portability in EJB Enterprise Java Beans - page 77

Implementation vs. Standard (MTS vs. EJB) Implementation • Over-specification: every function, interface and behavior is defined • Single vendor Standard • Under-specification: different grades of imprecision - compatibility test suites and reference implementations can help portability • Multi-vendor environment brings competence and innovation Enterprise Java Beans- page 78

Portability Is Not EJB’s Only Target Product differentiation Portability Compatibility With existing servers Enterprise Java Beans- page 79

EJB Development Process 1 Enterprise Bean Provider Specialized E. Beans 2 Application Assembler Component Market G E. ene Be ric an s Set of assembled E. Beans Deployed application Deployed E. Beans 3 Application template Market EJB Deployer Server & container E. Beans EJB Platform Provider Enterprise Java Beans- page 80

When Portability is Important Component vendors that want a broad-based market for their components. Application assemblers that want a large market of pre-built components for reuse. Application server providers that want to expand the number of third-party components available for their platforms. Enterprise Java Beans- page 81

When Portability is Not Important Enterprises that make a strategic decision to use a particular EJB server to take advantage of proprietary features. Organizations that custom develop beans to meet non-negotiable requirements or to differentiate their application. Application server providers that want to offer nonstandard extensions as a business strategy. Enterprise Java Beans- page 82

Basic Structure of an Enterprise Bean EJB Server-Container Contract EJB Container Client JNDI. . . Portability Related Enterprise Bean EB-Client Contract EB-Container • Home • Remote interface • Bean • DD Contract Enterprise Java Beans- page 83

The Enterprise Bean Contracts Source Code • API definition • Programming practices, rules and prohibitions Deployment descriptor • XML based syntax • Defined set of attributes Life cycle, transactional behavior…. Enterprise Java Beans- page 84

Source Code Incompatibility Different flavors of JPE APIs • JDK 1. 1 vs. 1. 2 • RMI-CORBA mapping Additional and proprietary APIs • XML • Security Semantic differences • Objects passed by value • JNDI Enterprise Java Beans- page 85

Deployment Descriptor Incompatibility Syntactic differences have disappeared with EJB 1. 1’s XML-based descriptor. There is a “standard core” set of deployment descriptor attributes. Different servers additional attributes to control specific capabilities • difficult to use only standard attributes • Compatibility problems in deployment descriptors can affect the source code Enterprise Java Beans- page 86

Conclusions Are EJB applications portable? • we could say that it is possible to make portable EJB applications, but it requires some workarounds and developer guidelines. Portability will increase with future releases of the standard • the holes in the standard will be gradually filled • EJB servers will more closely meet the standard • test suites and reference implementation will be soon released. Enterprise Java Beans- page 87

Conclusions -2 Portability in EJB is an inversion. • Making portable EJB applications is harder than using proprietary capabilities. • Is it worth the effort in your case? Enterprise Java Beans- page 88

EJB Summary and Conclusions Enterprise Java Beans - page 89

EJB Summary EJB server implementations lag behind proprietary application servers in • support for distributed transactions • security EJB supports development of “Write Once, Run Anywhere. TM” Java applications • issues exist porting between EJB servers Enterprise Java Beans- page 90

What are the Alternatives? Microsoft Transaction Server (MTS) Vendor suites • database vendors (I. e. , Oracle, Sybase) • transaction manager (I. e. , BEA Tuxedo) • Web vendors (I. e. , Netscape) Custom integration of Java technologies Enterprise Resource Planning (I. e. , SAP, People. Soft, Baan, IBM San Francisco) Enterprise Java Beans- page 91

Microsoft Transaction Server (MTS) Microsoft proprietary solution • only runs on Windows NT • based on the Component Object Model (COM) • interfaces to broad range of databases • Active directory, security and clustering extensions added in Windows 2000 Efficient, low-cost solution on Microsoft platform • “feel the power of the dark side of the force” Enterprise Java Beans- page 92

Vendor Suites Application servers that do not adhere to an EJB specification • application programming language usually C++ but may also be Java • typically provides support for distributed transactions, security, failover, replication • database, transactions, Web vendors have different strengths Allows the development of large, complex enterprise systems • risk of vendor lock Enterprise Java Beans- page 93

Custom Integration Best-of-breed integration of components • control own architecture • allows flexibility in selection of components that meet specific requirements • components can be incrementally upgraded Greater degree of control and flexibility but • requires greater expertise in infrastructure technologies • greater investment in time and $$$ • integrating products from different vendors can be problematic Enterprise Java Beans- page 94

Enterprise Resource Planning (ERP) Vertically integrated domain-specific frameworks • includes business processes • often difficult to integrate with legacy systems • usually does not consist of the latest and greatest technologies Offers business solution • may require the adoption of business processes • trades flexibility for complete solution Enterprise Java Beans- page 95

Conclusion EJB can be used to build scalable, platformneutral, multi-tier applications, but only if you avoid product-specific features EJB is still rapidly evolving -- look for stability elsewhere EJB is the keystone of Sun’s Java 2 Enterprise Edition Enterprise Java Beans- page 96