340 likes | 549 Views
Enterprise JavaBeans. Introduction and architecture. The beginning - Applets. One reason the Java initially gained popularity was its support for downloadable Java programs known as applets Java applets were first introduced in 1995
E N D
Enterprise JavaBeans Introduction and architecture
The beginning - Applets • One reason the Java initially gained popularity was its support for downloadable Java programs known as applets • Java applets were first introduced in 1995 • Applet executes only on the "client" platform environment of a system
Java on the server • Recognizing the potential for Java as a server language in Web environments, Sun Microsystems wrote the Java Servlet specification • Java servlet specification was finalized in 1997 • Servlets are Java programs designed to run on Web server machines
Servlets • Java servlets are best suited as a middle tier component connecting front-end Web requests with back-end data resources • However, servlets alone do not provide a sufficient model for true enterprise computing
Presentation tier Business logic tier Data tier Three-tier architecture • Emerged in the 1990s to overcome the limitations of the two-tier architecture • The middle tier supports application server software, a functional extension of the Web server
Advantages of multi-tier model • Scalability • Better re-use • Improved data integrity • Improved security • Reduced distribution • Improved availability • Hidden database structure
Java Platform Enterprise Edition • Java EE technology aims to extend the reach of the Java platform to large-scale server environments • Industry standard for developing portable, robust, scalable, distributed and securemulti-tier server-side Java applications • The Enterprise JavaBeans specification is one of the several Java APIs in the Java EE
Enterprise JavaBeans • EJB is a server-side component that encapsulates the business logic of an application • Standard way to implement the 'business' code typically found in enterprise applications
Motivation • Solutions to common problems are often repeatedly re-implemented by programmers • EJB were intended to handle such common concerns as: • persistence • transactional integrity • security in a standard way, leaving programmers free to concentrate on the particular problem
EJB goals • To be the standard component architecture for building distributed object-oriented business applications • To make it easy to write applications: developers will not have to understand • low-level transaction and state management details • multi-threading • resource pooling • and other complex low-level APIs
EJB goals • To follow the "Write Once, Run Anywhere" philosophy of the Java programming language • EJB can be developed once and then deployed on multiple platforms without recompilation or source code modification • To address the development, deployment, and run-time aspects of an enterprise application's life cycle
EJB goals • To define the contracts that enable tools from multiple vendors to develop and deploy components that can interoperate at run time • To provide interoperability between EJBs and non-Java programming language applications • To be compatible with • existing server platforms • other Java programming language APIs • CORBA (Common Object Request Broker Architecture)
Benefits of using EJBs • EJBs make it simpler to write applications • EJB container is charged with the task of making system services available to EJB components • Component portability • A simple, elegant component container model • Java server components can be developed once and deployed in any EJB-compliant server • Architecture independence • Independent of any specific platform, proprietary protocol, or middleware infrastructure
Benefits of using EJBs • Built-in support for typical enterprise-level system services: • distributed objects • transactions • database • security • global naming • Developer productivity • Standardization and automation of complex infrastructure services • Developers can create complex applications by focusing on business logic rather than environmental issues
EJB history • The EJB specification was originally developed in 1997 by IBM and later adopted by Sun Microsystems • EJB 1.1 ( J2EE 1.2 ), 1999 • Session beans (stateless & stateful), Entity Beans • Remote interface • EJB 2.0 ( J2EE 1.3 ), 2001 • Message-Driven Beans • Entity 2.x and EJB QL • Local and Remote interfaces
Adoption and criticism • Enterprise JavaBeans were quickly adopted by large companies • Problems were quick to appear and the reputation of EJBs began to suffer • APIs of the standard were too complex and counter-intuitive • required interfaces • checked exceptions • deployment descriptors
Adoption and criticism • Businesses found that using EJBs to encapsulate business logic brought a performance penalty • Original specification only allowed for remote method invocation • Long development cycle • Tools made it easy to create and use EJBs by automating most of the repetitive tasks... • But tools did not make it easier to learn how to use the technology!
EJB history • EJB 2.1 ( J2EE 1.4 ) 2003 • EJB Timer Service • EJB Web Service Endpoints • Minor EJB QL enhancements • Reinventing EJBs • The functionality delivered by simpler frameworks like Spring and Hibernate was more useful to enterprise applications • EJB 3.0 specification was a radical departure from its predecessors
EJB 2 vs. EJB 3 EJB history • EJB 3.0 ( JavaEE 5.0 ) 2006 • Many improvements to its predecessor! • Metadata annotations configuration by exception • A higher degree of control over bean persistence • Much more simplified programming model for developing EJBs
Overview – EJB in JavaEE http://java.sun.com/javaee/5/docs/tutorial/doc/bnabo.html
Types of EJBs • There are actually three kinds of EJBs: • session beans • entity beans • message-driven beans • Session beans • Implement the business logic of an application • Can be Stateless or Stateful • Entity beans • Are persisted in some data store
Session and Entity beans • In a typical scenario, the UI calls the methods of the session beans. Session beans can call other session beans and entity beans.
EJB 2: classes and interfaces • To implement an EJB, one needs to define: • Remote interface • Defines the business methods a bean presents to the outside world • Home interface • Defines the bean's life cycle methods: create, remove, find • Bean class • Actually implements the bean's business methods
Example: EJB 2 implementation public interface TestSessionBean extendsjavax.ejb.EJBObject{ public String sayHello() throws java.rmi.RemoteException; } public interface TestSessionBeanHome extendsjavax.ejb.EJBHome{ public TestSessionBean create() throws javax.ejb.CreateException, java.rmi.RemoteException; }
Example: EJB 2 implementation public class MyTestSessionBean implements SessionBean{ public void ejbCreate() throws CreateException { } public void setSessionContext(SessionContext aContext) throws EJBException { } public void ejbActivate() throws EJBException { } public void ejbPassivate() throws EJBException {} public void ejbRemove() throws EJBException {} public String sayHello(){ String msg="Hello! I am Session Bean"; System.out.println(msg); return msg; } }
Example: EJB 3 implementation @Remote public interface TestSessionBean { public String sayHello(); } @Stateless public class MyTestSessionBean implements TestSessionBean { public String sayHello(){ String msg="Hello! I am Session Bean"; System.out.println(msg); return msg; } }
EJB server and container • The EJB server provides an environment that supports the execution of applications developed using EJBs • An EJB server manages and coordinates the allocation of resources to the applications • The EJB server must provide one or more EJB containers • An EJB container manages the enterprise beans contained within it
EJB container • For each enterprise bean, the container is responsible for • registering the object • providing a remote interface for the object • creating and destroying object instances • checking security for the object • managing the active state for the object • coordinating distributed transactions • (optionally) manage all persistent data within the object
Packaging Java EE applications • A Java EE application is delivered in an Enterprise Archive (EAR) file • An EAR file contains Java EE modules and deployment descriptors
EJB module • An EJB module is used to assemble one or more EJBs into a single deployable unit • An EJB module is stored in a standard Java archive (JAR) file • Directory structure:
Creating directory structure with Maven • Execute a command: mvn archetype:create -DgroupId=lv.webkursi.ejb -DartifactId =java-eim-demo-ejb-jboss -DarchetypeArtifactId =maven-archetype-j2ee-simple • Develop EJBs in /ejbs/ folder
References • Enterprise JavaBeans Technology http://java.sun.com/products/ejb/ • The history and goals of EJB architecture http://www.ibm.com/developerworks/java/library/j-what-are-ejbs/part1/ • EJB 3.0 in a nutshellhttp://www.javaworld.com/javaworld/jw-08-2004/jw-0809-ejb.html
References • Spring Vs. EJB 3.0http://www.onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html • Getting Started with EJB 3.0 http://www.devx.com/Java/Article/30045/0/page/1