Beans? Yes, please!

Posted by on

Now that we have landed our dreamed Job as a Developer, it's time to refresh some knowledge that we might have forgotten. Let's start with the basics: Beans!
Have you noticed that the Java logo is a cup of coffee? Where do you think that comes from? Well, take a guess. It's from the beans! In this case, JavaBeans!

What is a Java Bean?

According to the JavaBeans API specification:

A Java Bean is a reusable software component that can be manipulated visually in a builder tool.
Now, this is quite a broad term that covers from a single button in your IDE to a sophisticated browser or Database viewer. However, what is important about a bean is that it benefits from its visual properties. From the specification, we imply that it doesn't make sense to have a bean solely for functionality that is useful to programmers, without getting any benefit from visual manipulation. 

So consider for instance a class to send messages using SOAP and XML. The specification suggests that we should create two components: A class library to handle the messages and a bean to set the message or view the responses. Therefore, Beans communicate with internal libraries to enrich its functionality and; at the same time, class libraries gain visual properties through the use of Beans.

It is important to note that not all Beans are visible. There are also invisible Beans that do not have a visual interface. Now, this might be a little confusing. How come can there be invisible beans when it is stated in its definition that "they can be manipulated visually in a builder tool"? 

To understand the difference we have to refer to two different stages of the lifecycle of an app, namely:
  1. Design. The stage when you are building your app, probably using an IDE or any other builder that allows you to code your app.
  2. Runtime. It is a self-implied concept. Refers to the stage when your app is running and is responding to users' requests.
Here's the bottom-line: The definition expects all Beans to be manipulated visually in a builder tool. It is never mentioned that the final user has to be able to see them. In this way, all Beans must be visible during design time and maybe visible during runtime, but they are not obliged to. 
In particular, there are 5 features that must be supported by a Java Bean:
  1. Introspection. A builder can "see" inside the bean and understand how it works.
  2. Customization. Appearance and behavior should be customizable when using an app builder.
  3. Events. To connect beans!
  4. Properties. Beans should have a set of properties for customization and programmatic purposes.
  5. Persistence. Customized beans should be persisted and their state saved so that they can be reloaded later.

What about Enterprise Beans?

Enterprise beans are Java EE components that implement Enterprise JavaBeans (EJB) technology. 
Written in the Java programming language, an enterprise bean is a server-side component that encapsulates the business logic of an application.

According to the Java EE 7 Documentation, there are two types of EB:

Session Beans

A session bean encapsulates business logic that can be invoked programmatically by a client over local, remote, or web service client views. To access an application that is deployed on the server, the client invokes the session bean's methods. The session bean performs work for its client, shielding it from complexity by executing business tasks inside the server. There are three main subcategories of session beans:
Stateful Session Beans
The stateful session beans are called so because they store the state of the session at a given time. The state of an object consists of the values of its instance variables. These, in turn, represent the state of a unique client/bean session. A session bean is not shared; it can have only one client, in the same way, that an interactive session can have only one user. When the client terminates, its session bean appears to terminate and is no longer associated with the client. Therefore, the lifetime of a stateful session bean lasts as long as the user's session is active. 

Stateless Session Beans
These beans are similar to the stateful ones except for the fact that they do not store the state of the object. Their lifetime is reduced to the execution of a particular method. When a client invokes the methods of a stateless bean, the bean's instance variables may contain a state-specific to that client but only for the duration of the invocation. Except during method invocation, all instances of a stateless bean are equivalent, allowing the EJB container to assign an instance to any client. That is, the state of a stateless session bean should apply across all clients.

Singleton Session Beans
A singleton session bean is instantiated once per application and exists for the lifecycle of the application. As expected, Singleton Session Beans implement the singleton design pattern and are shared across and concurrently accessed by clients. Common applications of a Singleton Session Bean are: to initialize variables at the start of an app or to clean-up at shutdown time. 

Message -Driven Beans

A message-driven bean is an enterprise bean that allows Java EE applications to process messages asynchronously. This type of bean normally acts as a JMS message listener, which is similar to an event listener but receives JMS messages instead of events. The messages can be sent by any Java EE component (an application client, another enterprise bean, or a web component) or by a JMS application or system that does not use Java EE technology. Message Driven beans play an important role in asynchronous applications, for instance:
A real-world example is that of a web application that is used to place an order for a particular customer. As part of placing that order (and storing it in a database) you may wish to carry a number of additional tasks:
  • Store the order in some sort of third party back-end system (such as SAP)
  • Send an email to the customer to inform them their order has been placed
You don't need your user to wait until these tasks are completed. Therefore, you can inform your customer that his order has been placed through your web app and asynchronously implement an MDB to take care of these actions.

Other examples of the usage of MDB are:
  • Debug logging
  • Billing
  • Order Processing
  • Provisioning

A special type of beans: Entity Beans

According to the EJB Core Specification 3.2, there's an "optional" type of EJB: Entity Beans. Earlier versions of the EJB specification required support for this kind of beans, but from version 3.2, the support has been made optional.

An entity bean is a remote object that manages persistent data, performs complex business logic, potentially uses several dependent Java objects, and can be uniquely identified by a primary key.

A typical entity object complies with the following characteristics:
  1. Is part of a domain model, providing an objective view of data in the database.
  2. Can be long-lived (as long as there's data in the DB)
  3. The entity and its primary key can survive the crash of the EJB container. 
Hence, the main feature of an entity bean is that it handles persistence by communicating with the database whereas the other types of beans do not consider persistence at all. 

A short summary

Recapitulating what we have seen in this article:

 First, we covered the differences in the concept of Beans derived from two specifications: Java SE and Java EE. On one side, Java SE demands its Beans to gain benefits from visual properties whereas Java EE does not have this requirement. On the contrary, it seems that EJBs operate solely on the programmatic side by performing complex business logic.

Second, EJBs have a variety of forms and flavors. These are depicted in the following picture. Each EJB addresses a different set of problems and fits in different situations. It depends on the developer's skill to identify which bean is more appropriate to every situation.

Enterprise Java Beans Hierarchy. Source: Author. 

References

Accessed on 11.03.2019

[2] Oracle, "Enterprise beans". Available on: https://docs.oracle.com/javaee/7/tutorial/ejb-intro001.htm#GIPMB
Accessed on 11.03.2019

[3] Stackoverflow, "Real world use of JMS/message queues?". Available on: https://stackoverflow.com/questions/1035949/real-world-use-of-jms-message-queues
Accessed on 11.03.2019

Comments

Post a Comment