EJB 2

EJB 2

• 2.
  WHAT IS EJB?? Enterprise JavaBeans (EJB) is a managed, server-side component architecture for modular construction of enterprise applications.  EJB is a server-side model that encapsulates the business logic of an application.  The EJB specification was originally developed in 1997 by IBM and later adopted by Sun Microsystems (EJB 1.0 and 1.1) in 1999.
• 3.
   The EJBarchitecture.  An EJB component is a reusable WORA.  The EJB architecture makes enterprise application (transaction management, security management, multithreading management)  The EJB architecture also supports WORA and portable solution.  manages the EJB component
• 5.
   enterprise beanis a distributed  lives in an EJB container  accessed by remote clients  enterprise beans on the same server  a remotely executable component  deployed on its server and it is self-descriptive
• 6.
   Remote interface Home interface  Client class  Server class  Deployment descriptor  JNDI(java naming and directory interface)
• 7.
   The beandeveloper is responsible for declaring the bean class' persistent fields as either Java primitive or serializable types. public class Address implements Serializable{ public String street; public String city; public String state; public String zip; }  Bean developer responsible for declaring the persistent fields in the bean class.  On an RDBMS primitive types(String, integer etc) map easily to their corresponding types  Tell the container through the deployment descriptor (DD). The <cmp-field> tags identify such fields.  Generally container tools allow you to map.
• 9.
   There isno standard way of mapping serializable objects to a relational database. Although the Address class has its own set of fields, the XML deployment descriptor doesn't provide a mechanism for mapping those fields to the database. In most cases it was expected that serializable objects such as Address would be persisted as a binary type, which is sometimes called a blob type, to a database table.  That problem is make worse as the entity bean's data schema grows in complexity.  For entity beans with a large schema problem grows. As an entity bean may have many dependent objects which in turn have dependent objects forming complex graphs.  Entity bean to Entity bean relationship support not adequate. Since it always uses the other EB’s primary key as a link. Relationships are not always based on the primary key.
• 10.
   New inEJB 2 1. Container managed Persistence 2. EJB Query Language 3. Message-Driven Beans 4. Local client view 5. Improved interoperability
• 11.
  i. The mostimportant changes in the specification are those made to container-managed persistence (CMP) and the introduction of a completely new bean type, the MessageDrivenBean. ii. When the bean is deployed, you will use persistent manager tools to generate a concrete implementation of the abstract bean class and its dependent object classes based on the XML deployment descriptor and the bean class. The concrete implementations will include the data access code that will actually read and write the bean's state to the database at runtime. At runtime, the container uses the subclasses generated by the persistence manager tools instead of the abstract classes defined by the bean provider.
• 12.
  Container Managed Persistence
• 13.
  • Allows youto define complex bean-to bean, bean to dependent object and dependent to dependent object relationships. • Done with the help of new “PERSISTENCE MGR” • Contract between container and Persistence Mgr. • Contract known as Abstract Schema has two parts  Additional XML tags in DD  Code idioms (Rules for coding the bean ) • The bean class is declared abstract and all persistent and relationship fields are accessed using abstract accessor and mutator methods whose signatures map to special elements in the DD
• 14.
  public abstract EmployeeBeanimplements javax.ejb.EntityBean { // instance fields EntityContext ejbContext; // container-managed persistent fields public abstract void setIdentity(int identity); public abstract int getIdentity(); public abstract void setFirstName(String firstName); public abstract String getFirstName(); public abstract void setLastName(String lastName); public abstract String getLastName(); // container-managed relationship fields public abstract void setContactInfo(ContactInfo info); public abstract ContactInfo getContactInfo(); ... }
• 15.
  • They formrelationships with entity beans • live and die along with the entity bean • only visible to the bean class and not the client • Bean class must have additional methods to expose dependent objects to the client since they are not suitable remote arguments.
• 16.
   A dependentobject ( class)……….. public abstract class ContactInfo { // home address info public abstract void setStreet(String street); public abstract String getStreet(); public abstract void setState(String state); public abstract String getState(); public abstract void setZip(String zip); public abstract String getZip(); public abstract void setHomePhone(String phone); public abstract String getHomePhone(); // work address info public abstract void setWorkPhone(String phone); public abstract String getWorkPhone(); public abstract void setEMail(String email); public abstract String getEMail(); ... }
• 17.
   Formerly developerprovided a description of what the finder methods should do . Deployer provided the actual query according to the target Application Server. Advantages of EJB QL ◦ Query need be developed and tested only once ( not at each new environment) ◦ Developer can do it .More suited for the purpose.
• 18.
   Integration ofEJB with Java Message Service (JMS). Container on arrival of a JMS message invokes a “message-driven bean”. Need not create a separate front-end for messages.  The Message Driven Bean is used among others to provide a high level ease-of-use abstraction for the lower level JMS (Java Message Service) specification  Message Driven Beans can support other messaging protocols.Such protocols may be asynchronous but can also be synchronous.  Examples  Sending a configuration update to multiple nodes might be done by sending a JMS message to a 'message topic' and could be handled by a Message Driven Bean  Submitting a job to a work cluster might be done by sending a JMS message to a 'message queue' and could also be handled by a Message Driven Bean,  the Quartz scheduler can be handled by a Message Driven Bean; when a Quartz trigger fires, the MDB is automatically invoked.
• 19.
   An MDBcomponent works in the following way: 1. The container registers this MDB component with JMS. 2. The JMS registers all JMS destinations (Topic for broadcasting or Queue for PTP) with Java Naming and Directory Interface(JNDI). 3. The EJB container instantiates this MDB component. 4. The client looks up the destination with the MDB. 5. The client sends a message to the destination. 6. The EJB container selects the corresponding MDB to consume the message.
• 20.
  WORKING:
• 21.
   Unlike theremote client view, the local client view of a bean is location dependent.  Local client view access to an enterprise bean requires both the local client and the enterprise bean that provides the local client view to be in the same JVM.  Local interfaces and local home interfaces provide support for lightweight access from enterprise beans that are local clients. Session and entity beans can be tightly coupled with their clients, allowing access without the overhead typically associated with remote method calls. The local client view consists of two interfaces:  Local interface: The local interface is a lightweight version of the remote interface, but for local clients. It includes business logic methods that can be called by a local client.  Local home interface: The local home interface specifies the methods used by local clients for locating, creating, and removing instances of enterprise bean classes.
• 22.
   protocol basedon RMI/IIOP and CORBA to allow J2EE applications on different app servers to interact without bean developer intervention
• 23.
   The standardcomponent architecture for building distributed object-oriented business applications in Java.  Make it possible to build distributed applications by combining components developed using tools from different vendors.  Make it easy to write (enterprise) applications: Application developers will not have to understand low-level transaction and state management details, multi-threading, connection pooling, and other complex low-level APIs.  Will follow the "Write Once, Run Anywhere" philosophy of Java.  Address the development, deployment, and runtime aspects of an enterprise application’s life cycle.  Define the contracts that enable tools from multiple vendors to develop and deploy components that can interoperate at runtime.  Compatible with existing server platforms  Compatible with other Java APIs.  Compatible with the CORBA protocols (RMI-IIOP).
• 24.
   Complex schemasinvolving relationships among entity beans and dependent objects can be depicted with the help of persistence manager.Closer to intuition and better database design and use.  Business methods in the home interface provide option for better design by isolating business logic completely within the entity.  Entity beans can communicate using JMS at the business logic level itself --one more for better design .  New EJB QL makes standardized query possible and relives deployer.Helps in correct creation of finder method queries.  Tightened some unresolved issues of 1.1
• 25.
   Implement alot of artifacts such as home interfaces , callback methods, remote interfaces  Use only one business interface per EJB bean  Follow a lot of conventions when building enterprise beans such as using RMI conventions, using specific base interfaces  Abide to a different scheme when developing EJBs compared to developing regular Java classes and interfaces  Configure beans and applications with giant XML based deployment descriptors  Introduce dependencies to the environment  Deal with the complexities of persistence  Manually introduce tracing, logging and other homegrown  methods to test components  Manually locate and use beans as clients
• 26.
   Use Meta-Data Use Dependency Injection  Reducing the number of artifacts developersmust provide  Configuration by exception  Reducing environmental dependencies  Simplification of EJB types  Getting rid of many interfaces  Simplification of persistence  Improved testing outside of the container
• 27.
   Using POJOs(Plain Old Java Object) and POJIs (Plain Old Java Interface)  Business Interface as Java interface  No more home interface  Using metadata annotations for configuration of EJB Type, Local/Remote, Transactions, Security  Minimize the bean-specific configuration requirements  The deployment descriptor can also be used to specify a bean as message-driven.
• 28.
   The beanclass now serves as the main programming artifact  Home interfaces have disappeared @Stateful public class ShoppingCartBean implements ShoppingCart { public int add(long item){…} public void remove(int id){…} } public interface ShoppingCart { public int add(long item); public void remove(int id); }  Bean class methods may throw application exceptions  They should not throw java.rmi.RemoteException
• 29.
  • Implement plainJava business interfaces  Do not provide a homeinterface • Comprise an implementation class annotated with@Stateless • Callbacks defined @PostConstruct, @PreDestroy andexecuted in unspecified security, transaction context • Interceptors might be applied • Dependency Injection before first business method execution
• 31.
   Empowers developersdue to more possibilities  Increases productivity by reducing required artifacts, configuration by  exception, dependency injection, annotations  Much easier to handle through POJOs and POJIs  Developers might use deployment descriptor or annotations or both  Extensibility of container using callback concept
• 32.
   EJB 1.0provides the basic functionality of Enterprise beans but has some flaws to cover up those flaws EJB 2 was introduced  Enterprise Java Bean 2.0 embodies some fantastic changes from the previous specification. The new CMP model is far more flexible than the previous model, allowing entities to model complex object graphs while providing for more portability across containers and the new MessageDrivenBean  EJB 2 had many dependences like home interface must implement EJBHome in order to provide services in order to reduce dependency EJB 3 was introduced.