Chapter 3. Enterprise Java Beans

The Reverend, Jesse Jackson said, "I am not a perfect servant. I am a public servant. In 1999, Enterprise Java Beans (EJBs) first appeared in the J2EE 1.0 specification. There were these heavyweight EJB components that ran inside an EJB container. EJBs were the original endpoints of the Java enterprise platform. The basic idea was that a client application would remotely make calls to a remote EJB endpoint in order to do some unit of work. The architecture was decidedly pre-cloud computing and client server. J2EE EJBs were either stateless or stateful; they could also be entity beans; and finally there was a concept of endpoints designed for sending and receiving data inside message-oriented systems, which are called Message Driven Beans (MDBs). MDBs were also part of the J2EE ecosystem. MDBs are covered in Chapter 9, Java Message Service 2.0.

In Chapter 2, Context and Dependency Injection we talked about Context and Dependency Injection and managed beans that are tied to a contextual scope. The CDI container managed CDI beans. EJBs are managed by an EJB container, and unlike CDI managed beans there is no contextual scope associated with them at all. EJBs have their own lifecycle that is tied to the deployment of the application inside the server. EJB, CDI, and the JPA specifications rely heavily on annotations for strong type checking with the Java compiler.

EJB are endpoints for an invocation call from an EJB client. The communication between the EJB client and server takes place on a defined protocol; it can be local calls between components running inside the same Java Virtual Machine (JVM), or it can be distributed remote calls across to another JVM over the network.

EJB protocols

The local protocol is equivalent to calling a function on the JVM call frame stack. So it is just like invoking a function and therefore it is the fastest.

The network protocol is called RMI-IIOP and originally it was designed for distributed communication between Java EJB applications and other non-Java systems. IIOP stands for Internet Inter-ORB Protocol, which is a protocol that delivers Common Object Request Broker Architecture (CORBA)to the Java platform. IIOP is a much older technology sanctioned for distributed communication of software that supports cross platform systems. RMI stands for Remote Method Invocation, and this is the standard Java technology to send messages, serializable Java objects from one JVM to another, across a network. Therefore the term RMI-IIOP stands for RMI over IIOP.

Criticism of EJB

CORBA is a much earlier communication and object data specification created by the Object Management Group (OMG) in the late 1990's, which was originally designed to allow software components written in different languages and running on different platforms to work together. Actually, CORBA was superseded in the twenty first century by the popularity of Service Oriented Architecture (SOA). The idea of using XML Web Services and invocation remote service function by sending and receiving data using SOAP and other protocols.

The point of this preamble is the EJB ,which in the beginning of the twenty first century was based on some fairly old standards. There are not many businesses that develop with CORBA nowadays, because of the poor implementations of the standard which could be incompatible yet were deemed certifiable; the standard process was mired in politics and different ulterior business motives. By the time CORBA and OMG organizations got their act together, the world had moved on to Representational State Transfer (REST) systems and orchestration through Web Services.

Business users of the earlier J2EE specification found that RMI-IIOP, historically, was painfully slow and there was a performance penalty; this was because the early EJB specifications only allowed RMI-IIOP. In J2EE 1.2 release, the idea of local interface was created to address this penalty. A local interface is close in performance to a method call. Behind the scenes a call to EJB is happening through a proxy.

With all this legacy technology, no wonder developers and architects were put off EJB for building agile enterprise applications. Eventually the expert group did realize there were issues with J2EE.

Simplification of EJB

The breakthrough for Enterprise Java Beans came in EJB 3.0 (JSR-220), which was a radical departure from the J2EE specification and was delivered in Java EE 5. The EJB specification was simplified substantially; the focus was on the idea of ease-of-development, which was achieved through the heavy reliance on annotations. The use of annotations brought much sought after affordance to the programming of Java EE applications. The influence of the movement and worldwide interest in Ruby on Rails was also felt through the idea of convention over configuration that practiced a less verbose code, and lesser dependence on XML configuration files.

Gavin King, the creator of Hibernate, was a firm believer in the EJB 3.0 specification. Many features of Hibernate found their way into the EJB entity bean specification as the Java Persistence API. Entity beans and JPA are covered in a subsequent chapter.

Tip

You only learn one thing about EJBs in Java EE 7: that they are lightweight POJO, which can come and go. Stateless EJBs are the simplest endpoints that you can reach in Java EE. Stateful EJBs have a higher price because of the their implicit connection with the client.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.142.199.181