DayOne

Well-Architected by Design: Using Scenarios to Ship Better Code

Enterprise Java Beans

  • EJB architecture: is a component architecture for the development and deployment of component-based distributed business applications.
    An application written using the Enterprise JavaBeans architecture is

    1. Scalable
    2. Transactional
    3. Multi-user secure
  • General Restrictions of EJB: EJB development places some restrictions on the developers for better component management and easier service. The restrictions include the following
    1. An enterprise bean must not use read/write static fields. Therefore, we recommend that all static fields in the enterprise bean class are declared as final.
    2. An enterprise bean must not use thread synchronization primitives to synchronize execution of multiple instances.
    3. An enterprise bean must not use the AWT functionality to attempt to output information to a display, or to input information from a keyboard.
    4. An enterprise bean must not use the java.io package to attempt to access files and directories in the file system.
    5. An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicasting.
    6. The enterprise bean must not attempt to query a class to obtain information about the declared members that are not otherwise accessible to the enterprise bean because of the security rules of the Java language.
    7. The enterprise bean must not attempt to create a class loader, obtain the current class loader, set the context class loader, set the security manager, create a new security manager, stop the JVM, or change the input, output, and error streams.
    8. The enterprise bean must not attempt to set the socket factory used by ServerSocket, Socket, or the stream handler factory used by URL.
    9. The enterprise bean must not attempt to manage threads.
    10. The enterprise bean must not attempt to directly read or write a file descriptor.
    11. The enterprise bean must not attempt to obtain the security policy information for a particular code source.
    12. The enterprise bean must not attempt to load a native library.
    13. The enterprise bean must not attempt to gain access to packages and classes that the usual rules of the Java programming language make unavailable to the enterprise bean.
    14. The enterprise bean must not attempt to define a class in a package.
    15. The enterprise bean must not attempt to access or modify the security configuration objects (Policy, Security, Provider, Signer, and Identity).
    16. The enterprise bean must not attempt to use the subclass and object substitution features of the Java serialization protocol.
    17. The enterprise bean must not attempt to pass this as an argument or method result. The enterprise bean must instead pass the result of SessionContext.getEJBObject or EntityContext.getEJBObject
  • Enterprise Java Beans
    1. EJB architecture is component architecture for the development and deployment of component based distributed business applications.
    2. EJB is a standard server side component model for component transaction monitors.
    3. The EJB will run in an ejb container in an application server. The container tales responsible for the system level issues.
    4. EJB components are designed to encapsulate business logic & to protect the application developer from having to worry about system level issues. Those issues include
      • Transactions
      • Security
      • Scalability
      • Concurrency
      • Communication
      • Resource management
      • Persistence
      • Error handling
      • Operating environment independence
  • Key Concepts of using Enterprise beans
    • EJBs are found/created by using an object factory that is inherited from CORBA.
    • EJBs are accessed through a simple Java interface, the remote interface.
    • EJBs use RMI-IIOP.
    • There are standards ways for building persistent EJBs, both through vendor-provided frameworks (CMP) & through a user-developed persistence mechanism (BMP).
    • There is a standard transaction model for EJBs offered through the Java Transaction API (JTA).
    • EJBs are built upon a security model that allows the person deploying the EJB to determine what access should be generated to whom at an EJB or method level.
    • An EJB is a component that implements business logic in a distributed enterprise application.
  • Java Beans vs Enterprise Java Beans
    Java Beans Enterprise Java Beans
    Is component model for java Are strongly associated with services frame work
    Each bean has properties, methods, & events. No event model
    Bean customization is done at assembly time by using properties. Customization is done at runtime by using a deployment descriptor.
    Do not require a special container. Do require an EJB container, in which they are deployed.
    Container exists inside a JVM (Java Virtual Machine). Container should provide all the services defined by the framework and it must reside within an enterprise java server.
  • Session Beans vs Entity Beans
    Session Beans Entity Beans
    Are only used by a single user at a time. Are shared by multiple clients.
    Never include permanent data, but provide access to data. When you have permanent business data that you want to access as a distributed component.
    Cannot be persisted, they never include permanent data but provide access to data. Can be persisted, they contain permanent data and data related business logic.
  • Session Beans
    A session bean encapsulates typically business processes and may contain a conversational state associated with a particular client.
    These states are not stored in a permanent data source and will not survive a server failure, unlike the data in an entity bean.
    Session beans implement business logic, business rules, and workflow.
    Session beans are non-persistent enterprise beans.
    A session bean is intended for the use of single client.
  • Stateful Session Bean vs Stateless Session Bean
    Stateful Session Beans Stateless Session Beans
    Can retain state between method invocations Cannot retain state between methods.
    Can service business process than span multiple methods or transactions. Typically used for single request, single method invocation.
    Can be aware of any client history. Anonymous method provider, not aware of any client history or state.
    Example: Shopping Cart Example: Calculator
  • Entity Beans
    Entity beans are used to represent permanent data and provide associated methods to manipulate that data.
    In the most common case, the permanent data is stored in a data source, such as a relational or object database.
    In more complex situations, the permanent data can result from the invocation of an application, stored procedure, or even the execution of a CICS transaction.
    In most cases, an entity bean must be accessed in some transactional manner.
    Instances of an entity bean are unique, and multiple users can access them.
  • Container Managed Persistence vs Bean Managed Persistence
    Container Managed Persistence Bean Managed Persistence
    For scalability, use a CMP entity bean. Is inappropriate for large applications.
    Don’t provide better portability than BMP. Provide better portability than CMPs because less container generated code is used.
    Bean can define independently of the database. Is not a database independent
    Easier to map java primitives to relational data types. More work to define a bean.
    Complex queries might not be possible with the basic EJB QL for CMPs. Complex queries may be possible with the basic EJB QL for CMPs.
    If relationships (CMR) between entity beans have to be established, then CMPs may be necessary. No CMR (Container Managed Relationships)
  • Message Driven Bean (MDB) Message-driven beans are used for the processing of asynchronous JMS messages within J2EE-based applications. The are invoked by the container on the arrival of a message. The most important properties of message-driven beans are:
    1. They have no identity to the client, but execute anonymously.
    2. They are completely managed by the EJB container.
    3. They are not exposed directly to the EJB client.
    4. They are stateless, in that they do not maintain any state on behalf of a client.
    5. They must implement javax.jms.MessageListener in addition to javax.ejb.MessageDrivenBean.
    6. They have no home or component interfaces.
  • Lifecycle of Message Driven Bean
    1. The EJB Container performs several tasks at the beginning of the life cycle
    2. Creates a message consumer (a QueueReceiver or TopicSubscriber) to receive the messages.
    3. Associates the bean with a destination and connection factory at deployment.
    4. Registers the message listener and the message acknowledgement mode.
    5. The lifecycle of an MDB depends on the lifespan of the EJB Server in which it is deployed.
    6. As MDBs are stateless, bean instances are typically pooled by the EJB Server and retrieved by the Container when a message becomes available on the topic or queue.
  • Structure of Message Driven Bean
    1. It has no home or remote interfaces, and is only a bean class.
    2. It resembles a stateless session bean – that is, it has short-lived instances and does not retain state for a client.
    3. A client interacts with the MDB in the same way it interacts with a JMS application or JMS server.
    4. Through the MDB, the EJB 2.0 Container sets itself up as a listener for asynchronous invocation and directly invokes the bean (no interfaces), which then behaves like an enterprise bean.
    5. All instances of a particular MDB type are equivalent as they are not directly visible to the client and maintain no conversational state. This means that the Container can pool instances to enhance scalability.
  • Best Practices of Message Driven Bean
    1. Do delegate business logic to another handler.
    2. Do consider making the MDB a request/reply controller.
    3. Do not attempt to maintain state with MDBs.
    4. Do not have a message process depend on another message being processed.
    5. Do watch the size of the message payload
    6. Do consider using XML-based messages for inter-application integration
    7. Do not use for real long-running transactions
    8. Be aware of poison messages: Because MDBs are EJBs, they have many of the capabilities available to enterprise beans, such as transactional support.
  • Java Data Objects vs Entity Beans
    Java Data Objects Entity Beans
    Provide a standard way to persist your domain model yes yes
    Encapsulate the persistence mechanism yes yes
    Be distributed objects, callable from anywhere no more stupid long deployment descriptors, no more JNDI lookups to find a simple domain model class they use distributed network calls, even though most people wrap them with session beans
    Be transaction aware objects no more brainless gets and sets to for details objects, etc add transactional overhead and require transactional deployment descriptor settings, again even though most people wrap them with session beans
  • Enterprise Java Server (EJS)
    • EJS is that part of the application server that hosts EJB containers.
    • It can host one or multiple containers.
    • Containers are transparent to the client – there is no client API to manipulate the container, and there is no way for a client to tell in which container an enterprise bean is deployed.
    • EJS provides the runtime environment for one or more EJB containers
    • Enterprise servers manage low-level system resources, allocating resources to the containers, as they are needed.
  • EJB Container
    • A system that functions as a runtime environment for enterprise beans by providing all the primary services that are needed for bean management.
    • All the services are well defined within the framework. The framework is implemented through the bean callback methods.
    • The EJB container houses the enterprise beans and makes them available to clients.
    • The container is also responsible for managing the persistence of a bean by synchronizing the state of the bean instance in memory with the respective record in the data source.
    • The EJB container provides a security domain to enterprise beans. The container is responsible for enforcing the security policies defined at the deployment time whenever there is a method call.
  • Container – Managed Transactions
    • Transactions are a safe conduit to have multiple components take part in distributed object operational activities.
    • The EJB container handles the transaction operations as well as the coordinating activities between the transactions.
    • Currently only FLAT & Distributed transactions are supported but not nested transactions.
  • Bean Class
    • An enterprise bean class contains the implementation details of the component.
    • All the business methods are defined in this class.
    • The class implementation for session beans is very different from the implementation for entity beans.
    • A session bean class contains business logic that can be used for computing prices or transferring funds from one account to another.
    • For entity beans, an enterprise bean class typically implements all the methods required for manipulating the bean persistent fields.
    • It also contains the callback methods used by the container to manage the life cycle of a bean instance.
  • Remote Interface
    Is used by an EJB client to gain access to the capabilities of the bean. This is where the business methods are defined. The component interface is called the EJB object..
    When a client wants to use an instance of an enterprise bean class, the client never invokes the method directly on the actual bean instance. The main reason is that bean classes cannot be called across the network directly, because they are not network enabled. The client uses instead the remote interface to invoke the business methods defined in the bean class. This interface is known as the EJB Object.
    Typical methods in the remote interface are: Getter & Setter methods to manipulate individual fields of the bean.
    Business methods that manipulate multiple fields.
  • Home Interface
    Is used by an EJB client to gain access to the bean. Contains the bean life-cycle methods of create, find, or remove. The home interface is called the EJB home.
    Client use EJB Objects and never beans directly. Therefore, there must be a way for the clients to acquire references to EJB Objects. The home interface is used for this purpose. This interface contains methods that allow the client to create, find, & remove instances of the bean. The home interface for session bean does not have any finder methods, because session beans are not persistent objects. This interface is know as the EJB home.
    Typical methods in the home interface are :
    Create: one or more with different sets of parameters.
    FindByPrimaryKey: retrieve one instance.
    Remove: one instance
    Custom finder methods: find by other criteria, one or multiple instances.
  • Stateless Session Bean
    Session beans are business logic beans that implement the tasks or workflow of a system, and provide coordination of those activities between other beans. Sometimes session beans act as a facade that hides an entity bean from its client.
    Stateless session beans do not maintain conversational state with a client. They are pooled instances reused by the container to service multiple clients. A stateless session bean holds conversations that span a single method call, which is the same as saying they have no conversational state. After each method call on a stateless session bean, the container releases the bean back into the pool and the bean instance becomes available so that it can serve a new request. This bean has no client memory of the previous method invocation. Even if the same client invokes another method on this same EJBObject, there is no guarantee that the exact same bean instance will be used.
    Stateless session beans do not participate in activation and passivation, but must still implement the activate and passivate callback methods.

    • Advantages
      1. Simplifying the code to handle connection pooling, transactions & security, a key advantage gained when using stateless session EJBs is that the business logic can be moved out of (distributed from) the client or server components. This ability can be important for security purposes.
      2. It is possible to efficiently load balance them across multiple application servers and achieve a high degree of scalability.
    • Dis Advantages
      1. Can be quite expensive even when the client and server are co-deployed.
      2. EJBs is that the need to find a HOME in the JNDI context, narrow it to the specific home interface type, and create the remote interface prior to using it, adds complexity to the client programming model.
      3. Is the increased complexity in testing, debugging, deployment, and administration.
  • Stateful Session Bean
    Session beans are business logic beans that implement the tasks or workflow of a system, and provide coordination of those activities between other beans. Sometimes session beans act as a facade that hides an entity bean from its client.
    Stateful session beans maintain conversational state with a client. They must belong to one and only one client, in fact, concurrent access to the same stateful session bean will result in exceptions being thrown by the container. They are not pooled instances to be reused by the container, because the container must keep that one instance servicing the same client for the length of the conversation.

    • Advantages
      1. Is that the methods map more closely to the transitions associated with the business process model than those of the stateless session EJB or business logic access bean.
      2. It can be reduce the number of calls to the back end by caching frequently used data as part of its state.
    • Dis Advantages
      1. Is that there are very few quality of service guarantees with respect to the ACID properties you might expect when working with components.
      2. Related to the quality of service guaranteed for stateful session EJBs is that the container does not rollback the state if the overall transaction fails.
  • CMP Entity Bean
    Entity beans that delegate their persistence to their EJB container are called container-managed persistence (CMP) entity beans. we do not have to code any database access directly into our entity beans; we let the container do it for us. The only thing we must provide are the abstract data-to-object mappings that map the fields in our bean to a database, and the abstract methods that correlate to those fields. The container knows that data is to be persisted because the mappings are defined in the deployment descriptor, and during deployment, the JDBC code to perform the operations is generated by the container.

    1. An abstract persistence schema: This enables CMP mappings to be done in an abstract way for all vendor tools.
    2. EJB QL: A standardized query language for finding and locating beans. Although it is not actually SQL, it is an SQL-like language that supports a subset of SQL functions.
    3. Container-managed relationships (CMR): Standardized how beans are related to other beans, and supports the relationship types of one-to-one, one-to-many, and many-to-many. Is actually also included as a part of the abstract persistence schema.
    4. Advantages
      Is that persistence and transactions are completely transparent to the business logic methods.
      Once all the access beans are converted, we could re-implement the stateless session bean to drop session synchronization with having to touch the business logic.
    5. Disadvantages
      Trust the container implementation to provide persistence in an efficient manner.
  • BMP Entity Bean
    Entity beans that manage their own persistence are called bean-managed persistence (BMP) entity beans. The EJB developer manages the persistent state of the bean by coding database calls, or any type of access to permanent storage, directly into the bean class. This puts the responsibility on the developer to properly manage the persistence of the bean.

    • Advantages
      1. Business object logic much simpler to write, but also much easier to migrate to CMPs later.
      2. BMP method implementations can be discarded and the entity EJBs can simply be redeployed, without having to change either the business logic methods or the client code.
    • Dis Advantages
      1. Persistence logic can be relatively complicated to implement efficiently.
      2. Data source dependency: It is difficult to isolate the bean from a specific data source (unlike CMP, which allows you to switch from one DB to another and eventually from vendor to vendor).
  • Session bean design & construction best practices These are guidelines, rather than rules, so let your experience guide in these matters.
    1. Do not store conversational state in stateless session beans.
    2. Use ejbCreate to initialize non-conversational stateless variables.
    3. Release open resources on stateless ejbRemove.
    4. Do not implement logic in stateless bean ejbPassivate and ejbActivate.
    5. Do set transient and other non-serializable fields for passivation.
    6. Validate state in stateful beans.
    7. Ensure your stateful bean use case logic calls ejbRemove.
    8. Watch out for unspecified transactional context methods.
    9. Be aware to manually synchronize session state with transactions.
    10. Do not call a session bean from multiple clients.
    11. Reentrancy: Ensure that your beans do not call each other’s methods in cycles.
    12. Exception handling.
    13. Keep the beans relatively short lived.
    14. Coarse-grained vs. fine-grained objects: Session beans should be coarse-grained business processes.
    15. Session façade: The EJB session facade pattern provides a stable, high-level gateway to the server-side components. An EJB session façade hides the entity bean interfaces to the clients.
    16. Caching of EJB homes: We have seen one way that we are caching EJB homes in our session bean create methods.
  • Transaction: A transaction is a sequence of operations that must all complete successfully, or leave system in the state it had before the transaction started. A single database server cannot handle global transactions.
    • Declarative TX (CMP):
      1. Is specified in the XML deployment descriptor; no specific coding is required.
      2. Declarative transactions are managed exclusively by the container in entity EJBs, and by the container with support from the developer in session EJBs.
    • Programmatic TX (BMP):
      1. If bean-managed, programmatic transactions are specified for a session bean, then the bean developer controls all aspects of transaction management.
    • Using JDBC TX: Support for transactions is built into JDBC, so coding bean-managed transactions for a single database is straightforward
      connection.setAutoCommit(false);
      try {
      // process code
      connection.commit(); // success: commit all
      } catch (Exception e) {
      connection.rollback(); // failure: roll back
      }
      JDBC transaction are simple to use, but are limited to being confined to a single database
    • Using JTA TX: The EJB container provides each session EJB instance with an instance of javax.transaction.UserTransaction, which provides access to the Java Transaction Service (JTS).
      UserTransaction userTx = sessionContext.getUserTransaction();
      try {
      userTransaction.begin();
      Connection c1 = …; // get conn to 1st datasource
      // business code
      c1.close();
      Connection c2 = …; // get conn to 1st datasource
      // bussines code
      c2.close();
      userTransaction.commit();
      } catch (Exception e) {
      userTransaction.rollback();
      }
  • Transaction Attributes Transactions can be defined at several different levels and in several different ways
    TX_REQUIRED Methods executed within a transaction.
    Commit at end of method.
    Well Suited for EJB Sessions.
    TX_MANDATORY Client of this EJB must create a transaction in which this method operates, otherwise an error.
    Well suited for EJB Entity.
    TX_REQUIRES_NEW Methods executed within a transaction
    A new transaction is generated regardless.
    Commit at end of method.
    TX_SUPPORTS Transactions optional.
    TX_NOT_SUPPORTED Transactions not supported.
    If provided, ignored.
    TX_BEAN_MANAGED Code in the EJB responsible for explicit transaction control.
  • Problems of concurrent Transactions: Data that can possibly be accessed across concurrent transactions can be subject to the following problems that are sometimes also referred to as isolation problems:
    • Dirty Read: Occurs when an application reads data from a database that has not been committed to permanent storage:
      User A modifies a row. User B reads the same row before user A commits.
      User A performs a rollback. User B has read data that has never existed.
    • No repeatable Read: Occurs when data has been changed between two consecutive reads of the same data:
      User A reads a row but does not commit. User B modifies or deletes the same row and then commits. User A rereads the row and finds it has changed (or it has been deleted).
    • Phantom Read: Occurs when new data is inserted into a table between two read operations:
      User A uses a search condition to read a set of rows but does not commit. User B inserts one or more rows that satisfy this search condition, then commits. User A rereads the rows using the search condition and discovers rows that were not present before.
  • Isolation Levels: Provides a degree of control of the effects one transaction can have on another.
    TRANSACTION_SERIALIZABLE Strongest level of isolation.
    All rows locked for duration of transaction.
    Can produce deadlocks.
    TRANSACTION_REPEATABLE_READ Usually suitable for all but mist critical operations
    Always reads same data during
    Transaction.
    Phantom records possible
    TRANSCATION_READ_COMMITED Can’t read uncommitted data by another transaction, but non-repeatable reads.
    Phantom records possible
    TRANSCATION_READ_UNCOMMITED Can read uncommitted data by another transaction, but non-repeatable reads.
    Phantom records possible
  • Isolation levels & possible problems: The value NO indicates that the problem does not occur; YES indicates that the problem may occur.
    Isolation Level Dirty read No repeatable read Phantom read
    TRANSACTION_SERIALIZABLE NO NO NO
    TRANSACTION_REPEATABLE_READ NO NO YES
    TRANSCATION_READ_COMMITED NO YES YES
    TRANSCATION_READ_UNCOMMITED YES YES YES
  • ACID Properties Basic properties of transactions can be summarized as
    1. Atomic: If a transaction is interrupted, all previous steps within that transaction are undone (rolled back). If all activities execute without an error, the transaction completes and all data changes are committed.
    2. Consistent: The state of objects and / or the state of tables within a database move from one consistent state to another consistent state. Consistency refers to the integrity of the underlying data store.
    3. Isolated: what happens within one transaction should not affect or be visible within another transaction. Any intermediate states are transparent to other transactions, allowing multiple transactions to execute serially.
    4. Durable: The effects of a transaction are persistent. If a failure occurs, the data can be recovered by using transactional logs.
    1. Session Façade
      Acts as a mediator between business objects, decoupling their APIs from one another.
      Is a higher-level business component that contains and centralizes complex interactions between lower-level business components.
      Fine-grained access through remote interfaces is inadvisable because it increases network traffic and quality.
    2. EJB 1.0
      Features: EJB 1.0 introduced the following features:
      Enterprise bean instances are created and managed at runtime by a container.
      An enterprise bean can be customized at deployment time by editing its environment properties.
      Client access is mediated by the container and the EJB server on which the enterprise bean is deployed.
      Flexible component model.
      Support for component distributions and security.
      Stateless and stateful session beans are defined and must be supported.
      Container-managed persistence and bean-managed persistence entity beans are defined and are not mandatory in this version.
      For transaction support, either the original javax.jts package or the new javax.transaction package can be used.
      Limitations:
      Entity bean support is not mandatory.
      Java RMI-IIOP support is not mandatory, which defies interoperability with other heterogeneous components.
      The deployment descriptor is not available in text format.
      Requires a separate deployment file for each enterprise bean, causing large applications composed of many beans to slow down.
      Interoperability between containers is not defined.
      No standard container API.
    3. EJB 1.1
      Differences over 1.0
      Entity bean support, both container- and bean-managed persistence, is required.
      Java RMI-IIOP argument and reference types must be supported. That is, the client API must support the Java RMI-IIOP programming model for portability, but the underlying communication protocol can be anything.
      The javax.ejb.deployment package has been dropped in favor of an XML-based deployment descriptor.
      Declarative security authorization (access control) is now more role driven.
      Isolation levels are now managed explicitly through JDBC (BMP), the database or other vendor-specific mechanisms.
      The bean-container contract has been enhanced to include a default JNDI context for accessing properties and resources, for example, JDBC and JMS.
      The basic EJB roles have been expanded and redefined to better separate responsibilities involved in the development, deployment, and hosting of enterprise beans.
      Allows using java.lang.String as a primary key type.
      Allows a session bean instance to be removed upon a timeout while the instance is in the passivated state.
      Allows enterprise beans to read system properties.The EJB 1.0 enterprise bean code has to be changed or recompiled to run in an EJB 1.1 container, in the following situations:
      An enterprise bean that uses the javax.jts.UserTransaction interface needs to be modified to use the new javax.transaction.UserTransaction.
      An enterprise bean written to the EJB 1.0 specification has to be modified to use the getCallerPrincipal() and isCallerInRole(String roleName) methods instead of the deprecated getCallerIdentity() and isCallerInRole(Identity) methods to work in all EJB 1.1 containers.
      An enterprise bean with container-managed persistence written to the EJB 1.0 specification has to be recompiled to work with all EJB 1.1 compliant containers, because the required return value of ejbCreate(…) in EJB 1.1 is different from its value in EJB 1.0.
      An entity bean in EJB 1.0, whose finders do not define the FinderException in the methods’ throws clauses, must be changed. EJB 1.1 requires that all finders define the FinderException.
      In EJB 1.1, an entity bean must not use the UserTransaction interface.
      The enterprise bean in EJB 1.0 uses the UserTransaction interface and implements the SessionSynchronization interface at the same time, which is not allowed in EJB 1.1.

      Limitations
      Data modeling capability is very simple.
      Mapping of the CMP beans to the database schema is outside of the specification.
      Relationships and inheritance are not supported.
      Specification of finder methods is not in the specification.

    4. EJB 2.0
      The most important changes in the specification are those made to container-managed persistence (CMP) and the introduction of a completely new bean type, the message-driven bean.
      New features supported in EJB 2.0
      Integration of EJB with JMS.
      Message-driven beans.
      Implement additional business methods in the home interface that are not specific for bean instance.
      EJB query language (EJB QL), which enables searches based on the object schema instead of data schema.Changes in EJB 2.0
      The new CMP component model is radically different from the old CMP model, because it introduces an entirely new participant, the persistence manager.
      There is a completely new way of defining container-managed fields, as well as relationships with other beans and dependent objects.
      The introduction of message-driven beans provides a component model for the enterprise beans acting as JMS clients, allowing them to be deployed in the rich and robust environment of the EJB container system.

      Limitations
      Inheritance is not supported.
      The mapping of entity beans to relational databases is vendor specific.

    5. Client ComparisonThe different ways of accessing enterprise beans from a client application (a servlet for examples),
      1. Direct Access: This is the straightforward way for a client to access an enterprise bean. The home of the bean should be cached in a static variable and be initialized in the init method of the servlet. This gives good performance. However, the result of each method invocation performed by the client is a remote call. Even if the client is a servlet running in the same application server as the EJB container (same JVM), all the method calls are routed through the TCP/IP stack. Of course, this has an impact on the performance of the application.
        Advantages
        Fast to code
        No need to create extra components
        No extra load generated on the client or server side
        The enterprise bean implementation is not modified
        Disadvantages
        Poor performance
        Requires EJB programming in the client code
        The client developer has to know how to use EJBs
      2. Access Beans: This is a better way to access enterprise beans. The home is cached in the access bean, and for data classes the properties of the bean are cached as well. This improves the performance by eliminating many remote calls. However, the developer should always be careful when using the local cache of the bean properties, because the bean’s data may have been updated in the meantime by another application.
        The number of the remote method calls over the network is decreased greatly, as the access beans perform all the get or set methods in a single call. However, this requires the modification of the enterprise bean implementation, because getter/setter methods for the data class are added to the bean.
        Advantages
        Very good performance
        Simple to use
        The client developer uses EJBs in the same manner as JavaBeans
        Disadvantages
        Extra components have to be created
        The enterprise bean implementation is modified
        Restrictive design that does not allow use of other models
        You have to use access beans for all the beans in an application
      3. Façade Beans: Facade beans are an alternative approach to access beans. It is applicable when accessing entity beans. The entity bean is accessed via a stateless session bean that caches the home and provides access to all the properties of the bean in a single method. This also does not require the modification of the bean class, as required when using access beans.
        The performance is also very good here, since the number of the remote method calls is limited. Actually, all the method calls between the facade bean and the entity bean are made locally (through the local pipes), since both of them are in the same container.
        However, the facade approach requires the creation of a session bean for each set of entity beans we access in one application. This requires more development time and system resources on the application server, because more beans are running in the container. Additionally, the client code is not as simple as when using access beans, because a session bean instance must be used for each method call.
        However, the code here can be simplified by using an external Java class (a JavaBean) that retrieves and caches the home interface in a class variable instead. This increases the performance and enables code reuse, simplifying the development of all the facade beans that are needed for the entity beans.
        Advantages
        Very good performance
        Open design to other models
        The enterprise bean implementation is not modified
        Disadvantages
        Extra development time
        More load in the EJB container
        Requires EJB programming in the client code
      Client Type Yes, When No, When
      Direct Access Simple EJB model is used.
      Performance is not critical.      		 Entity bean contains many properties.
      Access Beans Simple & fast development is desirable.
      The application server has limited system resources.
      ” Java wrapper is used for accessing session beans.      		 More complex design model is required.
      Clustered environment with many application servers is used.
      Façade Beans Scalability is critical.
      Open design is applied.
      Better overall performance is required.      		 Client has to access session beans.
      Development time is critical.
    6. WebSphere EJB WebSphere’s EJB support can provide this kind of highly scalable, highly available system. It does this by utilizing the following features:
      Object caching and pooling: WAS automatically pools enterprise beans at the server level, reducing the amount of time spent in object creation and garbage collection. This results in more processing cycles being available to do real work.
      Workload optimization at server: WAS Network Deployment features EJB server cluster management. Using Network Deployment you can create server groups that span nodes. A setup using multiple nodes improves availability and prevents a single point of failure in the application server.
      Cloning supports automatic failover: With several clones available to handle requests, it is more likely that failures will not damage throughput and reliability.
      No changes to the server-side code are necessary to take advantage of this kind of scalability.

EJB architecture: is a component architecture for the development and deployment of component-based distributed business applications. An application written using the Enterprise JavaBeans architecture is Scalable Transactional Multi-user secure General Restrictions of EJB: EJB development places some restrictions on the developers for better component management and easier service. The restrictions include the following An enterprise…

Previous Post
Next Post

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Posts

Recent Comments

Archives

Categories