Most Read This Week
Component Models in Java | Part 1
Component-oriented programming is a preferred solution to address the increasing complexity in developing software applications
Mar. 22, 2013 09:00 AM
A component is a reusable software entity. A component is a deployable piece of software that can be independently developed and maintained. In the previous article -Componentizing a Monolithic Application in Java, we discussed the need for componentizing applications to get the benefits of reusability and modularity. We also looked at how an E-Store application can be componentized using a simple component model developed by the authors using a factory whiteboard pattern and a simple repository.
In Part 1 of this article we will try to understand various component models in Java and provide a brief comparison of the features provided by them. Traditionally to explain component-based software engineering (CBSE) principles, popular component frameworks like CORBA, DCOM and JavaBeans are used. Instead of this traditional approach, this article will focus on the latest and widely adopted component models and frameworks specific to Java platform such as Enterprise JavaBeans Component Model (EJB), OSGi Component Model (OSGi), Spring Component Model (spring) and Component Model using Service Component Architecture (SCA).
In this article, first an introduction of component is given and types of components are explained and then the four component models are discussed in brief. At the end, a summary of the four component models is given.
Components can be classified into different types depending on where and how they are used. We try to classify the components into the following types based on their usage in N-tier architecture.
There are several models and frameworks available to develop each type of component. The focus of this article is on the business components; we will try to understand how the business components can be developed using the following standardized, matured and popularly used component models:
The objective is to give an introduction of these component models from the perspective of component principles and to understand the features provided by each of them. This article does not delve much into the details of the component models.
Enterprise JavaBeans Component Model
An Enterprise JavaBeans component is a combination of an interface referred to as business interface and a class (POJO) containing the implementation for the interface referred to as EJB component.
Stateless session bean represents the business component which has no conversational state with the client. Stateless session bean components are not shared between clients. They are used for single method request/response communication between client and the component.
Stateful session bean is a business component that contains the conversational state for a single client. The conversational state of the component is maintained ONLY for a single client.
Singleton session bean is a new type of business component introduced from the recent specification of EJB. This is a business component which is shared between clients and supports concurrent access.
Message driven beans are business components that are designed to consume messages from messaging systems like Java Message Service (JMS). Message driven beans enable asynchronous communication and they get activated upon message arrival.
The types of beans are identified using metadata annotation in the source code or through the XML deployment descriptor. All the types of EJB components are POJO based and the following annotations are used:
Like any other component model, the EJB beans are not instantiated directly using the ‘new' operator. For accessing EJB components, dependency injection is used for getting a reference to the component deployed in the container. Dependency injection is based on the principles of ‘Inversion of Control.' The idea is to avoid the direct creation of objects using a ‘new' operator on the server-side Java. Dependency injection for EJB components is provided with the help of metadata annotation @EJB. The annotation @EJB specifies a reference to the business interface. When this annotation is used, the container will provide a reference of the component to the clients. A local client for EJB simply uses the @EJB to get a reference to the component.
A remote client for EJB, where injection is not possible has an alternate way of accessing EJB components. They have to use JNDI (Java Naming and Directory Interface) API for locating the components in the container with a string name usually called as JNDI name. The container will provide the reference of the component which will be used by the clients.
A Message Driven Bean can't be accessed by clients directly because they are asynchronous message listeners. This is a type of EJB component that is activated by the arrival of a message in a message destination. So clients cannot invoke any of the methods in the message driven bean.
Example to Understand EJB Component Model
Note: For benefit of those readers who read our earlier article on Componentizing Monolithic Application in Java, this is the same ShoppingCart component discussed in the article with little modifications. For simplicity, only a single component - Cart is used for demonstration purposes in this article.
Figure 1 - EJB Component Model - Cart Component Example
The business interface of the component in EJB model is a remote interface called ‘CartBeanRemote'.
The business interface is implemented as a Stateful session EJB component ‘CartBean' because the component has to maintain the conversational state across method invocations for the client.
The Stateful session bean is accessed by the client using a dependency injection @EJB annotation. The client need not create an object of the bean; rather the container will give the reference of the bean instance. Since this is a Stateful session bean, the bean maintains the conversational state of this client. The EJB component is stored internally in the container with a global JNDI name which by default is the name of the business interface-cartBeanRemote. Optionally the JNDI name can be specified as part of the @Stateful annotation. The container will look up internally for the bean with the global JNDI name (cartBeanRemote in this case) and a reference is injected into the business interface which is used by the client. The client is as simple as shown below.
An alternative to the dependency injection as mentioned earlier, the JNDI API can be used to locate the business interface and the bean can be accessed using that. This is how the standardized EJB component Model simplifies the development, deployment and accessing of the components which is really a complex task without the model.
Spring Component Model
Spring is popular because of its support for Inversion of Control (IoC) features in the form of a Dependency Injection. As discussed earlier, dependency injection is the simplest form of representation of dependency between two classes without creating an object of the class using ‘new' operator. Dependency injection is the heart of the Spring framework. Apart from dependency injection, Spring framework provides support for AOP (Aspect Oriented Programming) as well. Spring framework provides the required APIs for development and deployment of the components.
Spring is slightly different component model from others in the fact that there is no concept of interface available directly to expose component methods. The component itself is used directly, without violating the component principles. Spring framework comprises of Spring Beans (the ‘Component') which is a POJO which is deployed and instantiated in a container called Spring Container which instantiates the bean components using a configuration file -XML file.
Spring Container is built on the principles of IoC. The container uses dependency injection to manage the components deployed in them. The components are referred as Spring beans. The Spring container is of two types:
The Spring BeanFactory container is the simplest container, an implementation of the Factory design pattern that provides the basic support for dependency injection and is defined by an interface called ‘BeanFactory' interface in the Spring API. Spring ApplicationContext container is an enhanced one which includes all the functionality provided by the BeanFactory container and provides additional features required for enterprise functionality. Hence for simple, lightweight applications, BeanFactory container is used whereas ApplicationContext container is the most preferred one.
The ApplicationContext container is advanced and is used for loading the bean definitions from the configuration file. This container provides several ways to load the configuration file. It allows loading XML file from a file system through FileSystemXmlApplicationContext, from the CLASSPATH using ClassPathXmlApplicationContext and from a web application through WebXmlApplicationContext. These contexts are crucial in instantiation of a bean.
If Singleton, only one single instance of the bean is created per Spring container. The single instance is cached and used for subsequent requests. If Prototype, instances can be created in any number based on the requests. By default, the spring bean is Singleton in nature. The type of the bean to be instantiated is decided by the entry in the configuration XML file.
However the XML-based configuration file is commonly used. The XML file contains the configuration metadata that is used by the container for creating a bean instance, managing bean's lifecycle methods and bean's dependencies. Some of the important metadata that goes as part of the configuration file are listed below:
Example to Understand Spring Component Model
Figure 2 - Spring Component Model - Cart Component Example
The CartBean is a POJO with the same methods discussed earlier. The spring bean need not implement any interfaces.
The configuration file which is an XML file for the CartBean is referred as ‘Beans.xml'. The XML file is placed under the source folder of the project. As mentioned earlier, the XML file is used for uniquely identifying beans and creation of objects. When the Spring application is loaded in the memory, the XML file is read first and the container uses this configuration file to create all the required beans and assigns id as per the tags present the configuration file. The XML file used in this example is mentioned below. The ‘CartBean' is assigned a unique id ‘cartBean'. Every bean is loaded and identified using the <bean> tag in the XML file and this tag can have child tags like <property>.
<?xml version="1.0" encoding="UTF-8"?>
To access the CartBean, the id of the bean and the context should be available for the client programs. First, the client tries to create an application context appropriately (File or ClassPath or Web). In this example, the client uses ClassPathXmlApplicationContext API that helps in loading the ‘Beans.xml' from the CLASSPATH (the XML file must be available in the CLASSPATH) and based on the information available in the configuration file, the container takes the responsibility of creating and initializing the beans, cartBean in this case. The context plays an important role to get the reference of the bean since there is no interface. The bean reference is obtained using getBean() method of the context object.
Thus, Spring framework provides a simplified way to create components with the help of Spring factory, configuration XML file and the Spring container. Developing components has really become easy with the help of the Spring framework.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters