1 / 46

Lecture 7

Lecture 7. Enterprise JavaBeans: Architecture and Goals. What are Enterprise JavaBeans . EJB is a semi-automated server-side component management architecture that facilitates the deployment of enterprise-class distributed object applications in Java. server-side

varley
Download Presentation

Lecture 7

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture 7 Enterprise JavaBeans: Architecture and Goals

  2. What are Enterprise JavaBeans • EJB is a semi-automated server-side component management architecture that facilitates the deployment of enterprise-class distributed object applications in Java. • server-side • highly-available enterprise (24x7) • components • encapsulated (self-contained) • portability • object model (inheritance, polymorphism, interface/implementation disjunction) • reusability • automated management • Persistence (distributed 2-Phase Commit Transactions) • Security • Load balanced/fault tolerant • deployment • enterprise distributed object applications • Java language

  3. Foundations • EBJ Technology is built on other key J2EE and OMG foundations: • RMI objects • JNDI naming and location • Does for Novell’s NDS and LDAP access what JDBC did for Sybase and Oracle DBMS acccess • Remote method exposure • JDBC • JTS/JTA • CORBA IIOP

  4. What’s J2EE all about? • J2EE is a specification • Vendor independent • Platform independent (portable) • API consistency • Test suite • Reference implementation

  5. J2EE Technologies(EJB as a canton in a larger confederacy) • RMI and RMI-IIOP • Java Naming and Directory Interface (JNDI) • JDBC • Java Transaction API (JTA) and Java Transaction Service (JTS) • Java Messaging Service (JMS) • Java Servlet API (JSDK) • Java Server Pages (JSP) • Java IDL (CORBA) • JavaMail API • Extensible Markup Language (XML) • Enterprise Java Beans (EJB)

  6. Stated Goals of EJB • “The EJB architecture will be the standard component architecture for building distributed object-oriented business applications in the Java Programming Language.” Sun EJB Specification 1.1 • “Application developers will not have to understand low-level transaction and state management details, multi-threading, connection pooling and other complex low-level APIs.” ibid. • “EJBs will follow the Write Once, Run Anywhere philosophy of the Java Programming Language. An EJB can be developed once, and then deployed on multiple platforms without recompilation or source code modification.” ibid.

  7. Stated Goals of EJB • “The EJB architecture will address the development, deployment, and runtime aspects of an enterprise application’s life cycle.” ibid. • “The EJB architecture will provide interoperability between enterprise Beans and non-Java programming language applications.” ibid. • “The EJB architecture will be compatible with the CORBA protocols.” ibid.

  8. What benefits does the EJB Architecture Provide? • Component Transaction Monitor • Distributed Transaction/2 Phase monitoring • Generic Naming and Implicit component location • clients do not have to know the specific location of a component to use it • Security • Automated User Authentication via Access Control Lists

  9. What benefits does the EJB Architecture Provide? • Persistence • Implicit persisting, activation and deactivation • Implicit component life cycle management • Implicit distributed transaction management • Distributed 2-Phase commit (Begin,End,Commit,Rollback) • Load Balancing/Transparent Failover • Resource Pooling • Multi-client support • Metadata Management • Declarative Specification

  10. Server Architecture

  11. Client-Server Interaction

  12. Component Characteristics • An enterprise bean contains business logic that operates on the enterprise’s data. • An enterprise bean’s instances are created and managed at runtime by a Container. • An enterprise bean can be customized by the customer at deployment time by editing the bean’s metadata • Client access is indirect--it always is via the Container • The EJB can be deployed in any compliant Container

  13. EJB Topology • An EJB may implement: • an object that represents a stateless (highly available) service • a calculation algorithm (insurance, finance, trading, etc.) • a lookup service • a security manager that validates a user and returns a token • pooled resource • Stateless Session Bean

  14. EJB Topology • An EJB may implement: • an object that represents a conversational session with a particular client (contradistinguished from HTTP protocol) • Extension of client business functionality on the server side • avoids Fat clients and 2-tier scenarios • Typically will handle database operations on behalf of the client • automated instance passivation and activation • pooled resource • Stateful Session Bean

  15. EJB Topology • An EJB may implement: • a high-level abstraction that represents a business entity that encapsulates business state and is accessible by multiple clients • a “Customer” object • a “Contract” object in futures trading • a “Policy” object in insurance • Entity Bean

  16. EJB Topology • An EJB may implement: • a middleware observer that listens for certain events in the system, and acts as a consumer of events it is interested in • a “logger” object • a “trade validator” object in futures trading • a “claim processor” object in insurance • Message-Driven Bean

  17. Session Objects • execute some business logic on behalf of a single client • can be transaction enabled • does not directly represent data in a database, but can access one • are generally short-lived • are removed when the Container crashes (client must reconnect) • participate in a Container’s scalable runtime environment, executing concurrently with multiple instances

  18. Entity Objects • provide a class (object-encapsulated) view of data in a database • allow keyed, shared access from multiple simultaneous clients • are generally long-lived • along with their primary keys and remote references survive the crash of the Container

  19. Implementing an EJB Object • Home Interface • The Client’s way of creating a local reference to a server • Defines a single create(…) method • Remote Interface (think CORBA IDL) • This interface defines the client semantics for the bean • Here is where you declare the methods your bean will implement

  20. Implementing an EJB Object • Bean Implementation (think CORBA Impl) • Here is where you implement the methods in the Remote Interface. • Similar to a CORBA implementation implementing an IDL interface, the Bean implementation implements the Remote Interface’s declared methods.

  21. Implementing an EJB Object • The Bean implementation also defines callback methods that the Container will use to communicate with the bean. These include: • ejbPassivate() • ejbActivate() • ejbCreate() • ejbRemove() • ejbLoad(): entity • ejbStore(): entity • ejbFindByPrimaryKey(Primary key): entity

  22. General Security • 2 Levels of security that clients must pass in EJB: • client authentication • verifies the client is indeed whom he claims to be • username/password authentication • after authentication, given a security identity for the rest of the session • client authorization • grants permission to a security identity to perform certain operations • occurs during an EJB method call • supports both declarative (container-based) and programmatic authorization

  23. General Security • Security Roles • Security Roles are collections of client identities, such as “general user”, “privileged user”, “system administrator”, etc. • Every Security Role can be assigned method permissions, which grant certain roles the rights to access some defined group of methods on a home or remote interface • Roles are defined in the deployment descriptor

  24. General Security • Declarative Authorization (in deployment descriptor) • modifySystemProperties [administrator] • searchData [everyone] • Programmatic Authorization (based on java.security.Principal and SessionContext) • isCallerInRole(securityRole) - checks to see that the current user (per the EntityContext) is a member of a role • getCallerPrincipal() - returns the secure name of the client user

  25. Session Bean Persistence • Stateful Session Bean Passivation and Activation • Since Stateful SessionBeans cannot be shared but are client-specific, their resources are limited and can, under load, be persisted to permanent storage and later recalled into memory • Passivation is the process whereby a stateful session bean’s non-transient conversational state is serialized to permanent storage. After the container has passivated the state, ejbPassivate() is called to allow the Bean to release any database or socket connections, etc.

  26. Session Bean Persistence • Stateful Session Bean Passivation and Activation • Activation is the process where the persisted state of a bean is deserialized due to client access on the persisted bean. The state is restored and ejbActivate() is called to notify the bean that it should re-establish connections, handles, etc. • Passivation is performed according to a Least Recently Used (LRU) strategy. The bean whose last client access was farthest back in time is the first to be passivated.

  27. Container-Managed Persistence • The container implicitly performs all database operations on behalf of the CMP entity bean • Primary Key class must be serializable • Object-Relational database mapping is done declaratively in the deployment descriptor • Programmer generally writes little if any direct JDBC connection code (but is free to if he wishes)

  28. Container-Managed Persistence • finder functions are described in the deployment descriptor (ejb-jar.xml): • <query> • <query-method> • <method-name>findAccount</method-name> • <method-params> • <method-param>double</method-param> • </method-params> • </query-method> • <ejb-ql> • <![CDATA[SELECT OBJECT(a) FROM AccountBean AS a WHERE a.balance = ?1]] • > • </ejb-ql> • </query>

  29. Entity Bean Persistence • Bean-Managed Persistence • Bean developer, not the container, provides all data access logic • Developer implements callbacks such as ejbFind…(), ejbCreate(), ejbActivate(), ejbLoad(), ejbStore(), ejbPassivate(), ejbRemove() • Developer uses JDBC or SQL/J to interact with the database

  30. Distributed Transaction Support • JDBC provides default non-distributed transaction support with autocommit • This is insufficient when dealing with distributed components which may severally be involved in a single transaction • ACID Properties (Atomic, Consistent, Isolated, Durable)

  31. Distributed Transaction Support • Only flat transactions are supported currently in EJB, not nested transactions • Multiple database can be updated automatically in a single transaction • Transactions can be handled either declaratively or programmatically • Programmatically handled requires programmer to issue Begin, End, Commit, Rollback • Declaratively handled requires the EJBObject (container) to issue transaction boundaries on behalf of the implementation

  32. Distributed Transaction Support • EJB Transaction Attribute Values (set in Deployment Descriptor): • TX_BEAN_MANAGED: bean is programmatically handling all transaction boundaries • TXN_NOT_SUPPORTED: bean operates outside of any particular transactional context • TXN_REQUIRED: bean must always run within the context of a transaction • TXN_REQUIRES_NEW: bean must always have its own new transaction created, current transaction, if any, is suspended • TXN_SUPPORTS: bean only runs in a transaction if one is already present • TXN_MANDATORY: bean must run in a transaction, and that transaction must already be present and active (javax.ejb.TransactionRequired exception)

  33. Distributed Transaction Support • EJB Isolation Levels (set in Deployment Descriptor) • TRANSACTION_READ_UNCOMMITTED (no protection from dirty reads, repeatable reads, etc.) • TRANSACTION_READ_COMMITED (eliminates dirty reads, reading uncommited data) • TRANSACTION_REPEATABLE_READ (eliminates changing data during updates) • TRANSACTION_SERIALIZABLE (eliminates dirty reads, unrepeatable reads, and phantom (new) reads)

  34. Resource Management/Load Balancing Mechanisms • Instance pooling in EJB Servers reduces the number of component instances needed overall, by allowing clients to share components individually or collectively • Pooling also reduces the frequency of component creation and removal • Each instance of a component in a pool is equivalent, but some may have higher priority due to access algorithms (LRU, Round-Robin) • New instances can be created and added to the pool, and other instances can be checked in and out for usage by clients • Pool management is handled intelligently by the container • Database ConnectionPools are supported and user-defined

  35. Resource Management/Load Balancing Mechanisms • EJB Servers/Containers provide Instance Swapping • Stateless SessionBeans can easily be swapped for client access because they maintain no client-specific state, they are truly equivalent, and one will work as well as another • Entity beans can also be swapped through the interaction of the container and the setEntityContext() and unsetEntityContext() methods • EJB Servers/Containers provide management through activation and passivation

  36. Failover Management • Stateless Session Beans: On failure, bean is automatically reinstantiated in a different server process • Stateful Session Beans: On failure, manual reconfiguration on another machine is required • Entity Beans: On failure, Client application reacts to RemoteException by reinvoking findByPrimaryKey, which will automatically map to other supporting groups

  37. Metadata Management • Deployment Descriptors allow EJB containers to supply run-time middleware services (persistence, transaction, security, etc.) to a generic EJB, thus relieving the EJB from having to hard-code this support into the bean itself • Entries in a Deployment Descriptor cumulatively make up the bean’s metadata

  38. Metadata Management • A bean’s metadata may also include bean-specific properties that are become Java properties, that are available to a bean at runtime • With EJB 1.0, you had to write a single deployment descriptor for each bean, and that DD had to be a serializable Java class, based on a plain text file description, and a manifest file was needed to describe all the deployment descriptors in an ejb-jar file • With EJB 1.1, you need only write a single deployment descriptor for each ejb-jar file, and this descriptor is written in XML. Since there is now only one deployment descriptor, manifest files are no longer needed

  39. Deployment Description Overview • Specify Home Interface • Specify Remote Interface • Specify Bean implementation class • Specify Bean type (session or entity) • Specify the JNDI name for the home interface for Clients to use • Transaction support definition

  40. Deployment Description Overview • Transaction isolation level definition • Access Control Lists (ACLs) and attributes • Session Timeout (session beans only) • Database member-Class attribute mapping (container-managed entity beans only) • Reentrancy information (entity beans only) • Primary Key class (entity beans only) • Environment specifics

  41. Abstracting Capabilities of the Container • Multithreading • Resource Pooling • Scaling • Distributed naming and location • Container is responsible for make the home interfaces of its deployed beans available via JNDI • Automatic persistence • Bean-Managed Persistence • Container-Managed Persistence • Transaction handling • Distributed Transaction Management

  42. Responsibilities of the Container for Session Beans • Making the home interfaces of deployed beans available via JNDI • Implementing the home interface of each installed EJB (EJBHome) • home interface allows a client to create a new session object (factory method) • home interface allows for the removal of a session object • Implementing the remote interface of each installed EJB (EJBObject) • remote interface allows clients to make business method calls on a session objects

  43. Responsibilities of the Container for Session Beans • Implementing Handle (support) classes for the Home and Remote interfaces • Implementing the EJBMetaData class • Must ensure that only one thread can be executing an instance at any time (session objects are serialized, single-client servants)

  44. Responsibilities of the Container for Entity Beans • Making the home interfaces of deployed beans available via JNDI • Implementing the home interface of each installed EJB (EJBHome) • home interface allows a client to create a new session object (factory method) • home interface allows for the removal of a session object • Implementing the remote interface of each installed EJB (EJBObject) • remote interface allows clients to make business method calls on a session objects

  45. Responsibilities of the Container for Entity Beans • Implementing Handle (support) classes for the Home and Remote interfaces • Implementing the EJBMetaData class • Must ensure that reentrant rules are followed (intra-transactional legal loopback, illegal concurrent call) • Implementation of robust (long-lived) object references. A client should be able to use an object reference across a server crash and restart

  46. BEA Weblogic Enterprise (WLE) • WLE combines an ORB and OLTP functionality within ATMI (Application-to-Transaction Manager Interface), CORBA and EJB • CORBA and EJB objects share the same transaction, security, configuration, and monitoring infrastructure • Native IIOP communication between RMI, EJB, CORBA Java/C++, and Tuxedo ATMI (Xopen XATMI compliant) • WLE Domain Offerings: • CORBA • EJB • ATMI • Security • TP Monitor • Web Server & Servlet Engine • RMI • HTML/JSP

More Related