× Home MicroServices WYSI!WYG Zen IDE AppServer JSP JDBC Pool EJB About Services
Backbutton Frameworks ©

Enterprise Java Beans

  • History of EJB

    EJB 1.0 - all Java Based; cumbersome

    EJB 2.0 - java based + xml ; tedious

    EJB 2.1 - Java Based + xml; slightly easier

    EJB 3.0 - Java Based + xml + annotation; easier

    EJB 3.1 - Java Based + xml + annotations; easiest

    Entity Bean dropped due to design flaw

    Source EJB presentation by a Sun Microsystems official J2EE/JEE course trainer.

  • JSP Engine with Bean is the simple way of doing things

    Servlet Engine with E-Bean was the complicated way of doing things until EJB 3.1

    @EJB is a JEE specification annotation , @Inject may not be a JEE specification annotation

  • General Comparison between Bean and EJB

    < jsp:useBean id= "instanceName" scope= "page | request | session | application"
    class= "packageName.className" type= "packageName.className"
    beanName="packageName.className | <%= expression >" >
    < /jsp:useBean >

    Bean with page or request scope behaves the same as stateless EJB

    Bean with session scope behaves the same as stateful EJB

    Bean with Application scope behaves the same as Singleton EJB

    I chose RMI compute Engine for further programmatic load balancing if needed

    An EJB could be a third Party remote API (credit card, hotel airline reservation) where the user has access to the interface but the implementation details are hidden, same as REST API.

  • I have read in an o'reilly book the difference between a Java Bean and an Enterprise Java Bean is that a "Bean is an intraprocess (tightly coupled) and Enterprise Java Bean is an interprocess (loosely coupled)". I understand the prefix intra to mean local as in intranet and internet. Although internet is stateless and loosely coupled while the intranet is tightly coupled and stateful. Perhaps the author meant a Bean is a tightly coupled local process and the Enterprise Java Bean is a loosely coupled remote process. To my understanding an EJB is loosely coupled because it has an Interface but is both local and remote object/instance, both stateful and stateless, container managed. A Bean is an object/instance therefore local local and tightly coupled but both stateful and stateless container managed object/instance. Looking at the code I found the author's descriptions both inaccurate and confusing.

    It was the same publisher o'reillys and I think it was the same author who wrote Java runs from top to bottom. This is true of procedural languages where you have processes but Java is object orientated therefore this is not true because Java is based on a class.

    I think objected Orientated defintions are different in the USA to that found in the UK.

    RMI Remote Method Invocation and Enterprise Java Beans make client calls using same method names lookup() meaning fetch remote object, connect or contact server.

  • When to Use EJBs 3.1 +

    Guaranteed Response time is required. You can use throttling of Resources thereby restricting volume of network activity and hardware usage to a particular EJB server.

    Scalability is required.

    Remoteness is Required - EJBs Sole purpose is provide a programming model to build managed and Distributed components in Java Platform.

    Distributed Transactions are required.

    Failover is required

    Component Security is required

    Possible use cases Banks, Airport, Multi-nationals, Stock Markets, third party remote access by providing a public interface whilst hiding the private implementation. The Interface, Object Orientated Concept of Secure by Design.

  • How Does EJB Clustering work

    Clustering allows you to run an application on several parallel servers while providing a single view to application clients. Load is distributed across many servers (a.k.a. cluster nodes), and even if one or more of the servers fail, the application is still accessible via the surviving cluster nodes.

    The multicast functionality is not just for servers to find each other in a cluster, it can also be used for EJB clients to discover a server. Multicast is the preferred way to broadcast the heartbeat of a network.

    The EJB clients do not need to use multicast to communicate with servers. Servers can use multicast to discover each other, but clients are still free to connect to servers in the network using the server's TCP address.