Disclaimer: The chapter have been written with figures sourced from various on-line materials. I haven’t been bale to attribute these figures with source. Really apologize for this. In case anyone has any issues in me using the figures and content, please drop an email to me at tomcyjohnatgmail.com. I will make sure that the details are either attributed or the image/content removed from my blog post. Thanks in advance.
Spring Framework’s web application support is through two sub-projects namely Spring MVC and Spring Web Flow.
Spring Framework has its own MVC based web application framework in the form of Spring MVC. They conceived and developed its web framework to address some of the deficiencies and poor design consideration in other popular framework available in the market. One of the main deficiencies identified was the lack of separation of concerns like proper separation between the presentation and request handling layer and between request handling layer and the model layer. Similar to Struts, Spring MVC is a request-based web application framework. Spring MVC makes sure that all the interfaces are tightly coupled with the core Servlet API’s rather than the Spring API’s.
Spring Web Flow is one of the sub-project which aims at providing the infrastructure for developing and running web application. It tries to aid web application developers in defining appropriate navigation rules, manage navigation and conversational state as well as facilitating high level reuse and modularization.
Spring MVC as well as Spring Web Flow is a very huge topic to cover in one Chapter. There are books written only on these topics. I would cover some basic concepts of both Spring MVC and Spring Web Flow in this Chapter. The first part of this Chapter makes you walk through Spring MVC and the second part of this Chapter walks through Spring Web Flow. I will try to cover basic detail of both frameworks so that you will get a heads up on these and can start off developing using these.
Spring MVC allows you to build extensible, robust and loosely coupled MVC-based web application. With the use of the famous Model-View-Controller pattern, it inherently brings separation of the various layers in a typical web application namely business, presentation and navigation in a clear way.
We have covered MVC pattern in detail in this book, but just to refresh your mind, the responsibility of Model is to encapsulate the application data, the responsibility of View is to render the response to the user with the help from the Model object and the responsibility of Controller is to receive the request from the end user and transfer it to the back-end services which will populate the Model objects and sends the view object to the user.
Figure 14-1. Spring MVC’s fit in an enterprise application containing other layers
Spring Batch is the first Java based lightweight, comprehensive framework for batch processing. Being built on top of the Spring Framework, it gives all the advantages of productive, POJO-based development approach.
Spring Batch is a lightweight, comprehensive batch framework designed to enable the development of robust batch applications vital for the daily operations of enterprise systems. Spring Batch builds upon the productivity, POJO-based development approach, and general ease of use capabilities people have come to know from the Spring Framework, while making it easy for developers to access and leverage more advanced enterprise services when necessary.
– Spring batch documentation (http://static.springsource.org/spring-batch/)
In this Chapter, we will cover Spring Batch in a comprehensive manner and aims at letting you use it in your enterprise application with less effort. The initial sections will introduce you to the core concepts on which Spring Batch is build and then later on delve deep into the various concepts in details along with appropriate code snippets.
Batch and Offline Processing
You would have heard these terms batch and offline processing for quite some time now and every time you have such requirement in your application you sit in front of the computer and start something fresh and code from scratch to realize this. With Spring Batch you now have a framework using which you can do these in a much better and cleaner manner. Before going through Spring Batch in detail, I would like to spend sometime explaining the usual business case which Spring Batch tries to achieve. Primary among these are batch and offline processing.
Batch applications needs to process high volume of business critical transactional data in an efficient manner. A typical batch program does the following:
Reads a large amount of data from database, file or queue as the case may be.
Processes the data according to the business requirement in an efficient manner.
Writes back the modified/processed data to database, file or queue as the case may be.
Batch is a group of similar or identical items and the pseudo code for this can be shown in Figure 23-1 below.
Figure 23-1. Pseudocode for a typical Batch
In most modern day applications there requires capability processing client request in offline manner. Offline processing differs from online/real-time processing with respect to the following aspects as outlined below:
Processing of processes which are long-running and which occurs beyond usual office hours
Non-interactive in nature and often requires appropriate logic capable of handling errors and taking necessary actions like restart in some cases and so forth.
Processing of processes which have large amount of data not fitting into a single transaction.
Some of the common examples of batch and offline processing are as given below, so that you can understand the use of Spring Batch and appreciate what it delivers out-of-box for you.
Large scale output jobs which need to run on a timely manner. For example; sales report spanning whole month or even whole year.
Import/export handling of data. For example; ETL (Extract-Transform-Load) jobs, data synchronization jobs etc.
Various close of business jobs. For example; sales report spanning a day, business level reporting etc.
The lack of standard, reusable batch architecture has resulted in the proliferation of many one-off, in-house solutions developed within client enterprise IT functions.
– Spring batch documentation (http://static.springsource.org/spring-batch/)
Why a framework?
So why would you need a framework for implementing batch? Why can’t we use a “for loop” for doing such batch jobs? We need to have a framework which addresses not only running a bunch of code in a loop fashion but also to have other features/capabilities/business scenarios as listed below (as detailed in Spring Batch documentation):
Commit batch processes periodically; Capability of committing the processed data at times due to various business reasons.
Staged, enterprise message-driven processing
Concurrent batch processing; parallel processing of a job
Massively parallel batch processing
Sequential processing of dependent steps with extensions to workflow-driven batches
Manual or scheduled restart after failure
Whole batch transaction: for cases with a small batch size or existing stored procedure s/scripts
Any modern application does not live in isolation. To realize the business requirements it has to communicate with customers of varied types and other applications in variety of ways. Application integration lets your application do this and in modern day applications, this is crucial for any application. Spring Integration aids in application integration that lets applications share data and services with each other making it connect with varied kind of users.
The Spring Integration is an open-source; simple integration framework that leverages the capabilities of widely adopted Spring Framework making application integration easy and simpler to implement.
This Chapter will help you start with Spring Integration and will aid you in achieving the various integration requirement in your application. I am sure after reading through this Chapter you will have one more weapon up your sleeves which you can use and reap benefits from its high level of integration capabilities.
Spring Integration Goals and Principles
Spring Integration is motivated by the following goals:
Provide a simple model for implementing complex enterprise integration solutions.
Facilitate asynchronous, message-driven behavior within a Spring-based application.
Promote intuitive, incremental adoption for existing Spring users.
Spring Integration is guided by the following principles:
Components should be loosely coupled for modularity and testability.
The framework should enforce separation of concerns between business logic and integration logic.
Extension points should be abstract in nature but within well-defined boundaries to promote reuse and portability.
The goals and principles of Spring Integration is as quoted in the Spring Integration Reference Manual.
Spring Integration Benefits
Spring Integration benefits can be summarized as follows:
Loose coupling between components – brings about development of small and focused components that caters to specific role and responsibility. This eases testing and promotes reuse largely.
Helps to separate integration and processing logic – Spring Integration pitches-in, handling message routing, transformation etc. and eases the application developer from this. Due to high level of configuration based integration style, easily processing can be switched between synchronous and asynchronous with no change in the code that is handy in this ever-changing business application scenario.
Promotes Event-driven architecture – No hard coded process flows and capability to easily change and expend these flows according to application requirement. Single word that can be used is adaptability.
Enterprise Integration Pattern (EIP)
Enterprise Integration Patterns is a book by Gregor Hohpe and Bobby Woolf and describes a number of design patterns for the use of enterprise application integration and message-oriented middleware. Enterprise Integration Patterns can be implemented without coding using Spring Integration or Apache Camel.
Enterprise application integration is an integration framework composed of a collection of technologies and services, which form a middleware to enable integration of systems and applications across the enterprise.
Spring Integration brings the power of Dependency Injection (DI) that Spring Framework is well known for and EIP patterns implementation together to nicely manage the resources and lets you focus on business logic rather than messaging infrastructure code.
Spring Integration Namespaces
For easing the various integration style configurations, Spring Integration has dedicated namespaces for each of them. Table 22-1 gives details of Spring Integration namespace in a tabular form for easy reading and understanding.
Defines the configuration elements for Spring Integration’s HttpInvoker adapters. NOTE: The http-invoker support is deprecated as of 2.0.x. It is recommended to use the REST-based HTTP adapters instead.
Concurrent programming and management of threads in general are necessary because the world of web programming is essentially concurrent because multiple clients can access in the time. Asynchronous programming promotes using the same thread to process multiple requests, sequentially, but with no request blocking the thread.
Spring has supported task scheduling and asynchronous method execution from its earliest releases. Spring 3.0 has made this easier by allowing you to declaratively do this by using XML and annotation-based programming.
This chapter initially looks into the various concepts dealing with concurrency and then looks into Java support for doing this. Later on it looks into how Spring Framework can support doing this in your application.
Terms and Concepts
The following concepts and terms that will be used throughout the chapter :
Concurrency Concurrency is a system property in which several computations are executing simultaneously, and potentially interacting with each other. Concurrency is a built in feature of the Java language and platform.
Process A process is a flow sequence that runs independently and isolated from other processes. It cannot have access to data in other processes.
Thread A thread is a single, sequential flow of control within a program. A thread can be called as a lightweight process which has access to shared data. The Java Virtual Machine allows an application to have multiple threads of execution running concurrently. Every thread has a priority. Threads with higher priority are executed in preference to threads with lower priority. When code running in some thread creates a new Thread object, the new thread has its priority initially set equal to the priority of the creating thread.
Task A task is a basic unit of programming. In our sample application, downloading the cargo utilization report of the first hundred customers represents a simple task.
Multithreading Multithreading is the ability of a program to manage its use by more than one thread at the same time and to even handle multiple requests, without having to have multiple copies of the program running. Each execution of the program is kept track of as a thread with a separate identity.
Multitasking Multitasking is the ability of a program to allow a thread to perform more than one task at a time. The program can keep track of where you are in these tasks and go from one to the other without losing information. Being able to do multitasking doesn’t mean that an unlimited number of tasks can be performed at the same time. Each task consumes system storage and other resources and as more tasks are started, the system may slow down or begin to run out of storage.
Serial Processing Serial processing is strictly sequential, without overlap of the successive processing times on objects or distinct subsystems. In a standard type of serial system, each object takes the same average amount of time to process and the next object begins processing only when the previous one is completed.
Parallel Processing Parallel processing signifies simultaneous processing on several objects or subsystems at the same time, although processing may finish on different objects at different times. Parallelism is a term typically used to describe executions that physically execute simultaneously with the goal of solving a problem in less time or solving a larger problem in the same time. Parallelism differs from concurrency and actually exploits concurrency. The advantages of parallel processing are faster execution time and higher throughput. The disadvantages are that there are additional hardware and power requirements.
Task Scheduling This is another form of concurrency in action, wherein a piece of work can be scheduled to run once or repeatedly at an interval for various application use cases. In our sample application a task schedule can be created for sending periodic mails to the entire customer in the system giving details of their cargo loyalty points.
Note: Scheduling is needed if you want your application to automate the repetition of a task at specific intervals or particular date. In any modern application its common to have scheduling requirements, and the Spring Framework brings a level of abstraction to this as well. Spring has good support for scheduling and, as shown later in this chapter, it also supports using other third party scheduling services, such as Quartz.
Liveness Liveness defines a concurrent application’s ability to execute in a timely manner. There are various kinds of liveness problems that can occur in your application, namely deadlock, starvation and livelock.
Deadlock An application that allows concurrency is prone to a deadlock condition in which all the threads are waiting for an event that other threads in the same set have to cause. For example, if thread A waits for a lock on object C, which thread B holds, and thread B waits for a lock on object D, which is held by thread A, these two threads are locked and cannot continue further, resulting in deadlock.
Starvation Starvation describes a situation where a thread is unable to gain regular access to shared resources and is unable to make progress by itself. This happens when shared resources are made unavailable for long periods by other “greedy” threads.
Livelock A thread often acts in response to the action of another thread. If the other thread’s action is also a response to the action of another thread, then livelock may result. As with deadlock, livelocked threads are unable to make further progress, but unlike deadlock they are not blocked. They are simply too busy responding to each other to resume with their own work.
Currency Support by Java
Concurrency is a built in feature of the Java language and platform. Java has a predefined class java.lang.Thread which provides the mechanism by which threads are created. However to avoid all threads having to be child classes of Thread, it also uses a standard interface java.lang.Runnable. Any class which wishes to express concurrent execution can implement Runnable interface and provide the run method. Threads do not begin their execution until the start method in the Thread class is called. Listing 20-1 shows creating a thread by extending Thread class and Listing 20-2 shows creating of thread by implementing the Runnable interface.
Listing 20-1. Creating thread by extending Thread class
// This method is called when the thread runs
// Create and start the thread
Listing 20-2. Creating thread by implementing Runnable interface
// This method is called when the thread runs
// Create the object with the run() method
// Create the thread supplying it with the runnable object
Messaging is a method of communication between software components or applications. Messaging enables distributed communication that is “loosely coupled” (decoupled). A component sends a message to a destination, and the recipient can retrieve the message from the destination. The important thing here is that, the sender and the receiver do not have to be available at the same time in order to communicate with each other.
Java Message Service (JMS) defines a standard way for Java applications to create and exchange messages through a Message Oriented Middleware (MOM).
Messaging is one of the key components in any modern day application development. In this Chapter we will initially cover messaging concepts in some detail. Later on we will cover JMS and its components in detail. We will then deep-dive into the support provided by Spring in applying messaging to your application. We will then go through the transaction support by JMS and again what Spring has to offer in this space. Finally, the Chapter concludes with a discussion of Spring’s support in achieving global transactions in your application.
Messaging in General
Messaging systems are used to build highly reliable, scalable, and flexible distributed applications. A messaging system allows separate, uncoupled applications to reliably do the communication asynchronously. The messaging system architecture generally replaces the client/server model with a peer-to-peer relationship between individual components, where each peer can send and receive messages to and from other peers.
Messaging systems provide a host of powerful advantages over other, more conventional distributed computing models. Primarily, they encourage “loose coupling” between message consumers and message producers. Other advantages of messaging systems include high scalability, easy integration with other heterogeneous networks, and reliability due to lack of a single point of failure.
Messaging is another integration style as detailed in Chapter 6. Systems exchange messages within each other using a component known as a broker, which provides the necessary guarantee and services while using messaging along with capability of interfacing with other interfaces like JMS driver, AMQP (Advanced Message Queuing Protocol), Stomp (Simple Text Oriented Message Protocol), XMPP (Extensible Messaging and Presence Protocol) etc. These interfaces are often referred to as Message Oriented Middleware (MOM) and are available as commercial and open source products in the market. Figure 18-1 shows a diagram of a MOM-based messaging system.
Figure 18-1. Messaging using MOM
Message-oriented middleware (MOM) is software or hardware infrastructure supporting sending and receiving messages between distributed systems. MOM allows application modules to be distributed over heterogeneous platforms and reduces the complexity of developing applications that span multiple operating systems and network protocols, such as the following:
Simple (or Streaming) Text Orientated Messaging Protocol (STOMP) provides an interoperable wire format so that STOMP clients can communicate with any STOMP message broker to provide easy and widespread messaging interoperability among many languages, platforms and brokers.
Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol for message-oriented middleware. It’s a binary, application layer protocol, designed to efficiently support a wide variety of messaging applications and communication patterns.
Extensible Messaging and Presence Protocol (XMPP) is an open-standard communications protocol for message-oriented middleware based on XML (Extensible Markup Language). The protocol was originally named Jabber, and was developed by the Jabber open-source community.
Advantages of Messaging
The main advantages of using messaging as an integration technology in your application can be summarized as below:
Platform Independence – one of the biggest advantages which messaging integration style brings onto table is communication and integration of heterogeneous platforms. Using messaging it is possible to integrate applications and systems which are implemented in completely different platforms. Even though we have many ways of integrating heterogeneous platforms like RPC-based, common database etc., only messaging truly provides a decoupled way of interaction between such disparate systems.
Network location Independence -messaging also provides capability of connections applications and systems in completely different networks with ease.
Architecture Flexibility and Agility – this very important advantage of messaging is achieved through level of abstraction and decoupling capabilities. Because of decoupled components, these can be replaced with a more capable component at a later stage with ease giving application flexibility and agility to changing business scenarios. In a typical messaging environment, the various components like producers, consumers and client components doesn’t need to know which programming language or platform these are written for, where they are located and even the protocol they used to communicate. These details are all abstracted away, making it more flexible from the architecture point of view.
Reduce system bottleneck – asynchronous nature of messaging is the key in avoiding system bottlenecks. Since messaging architecture gives your application asynchronous nature, your receivers need not keep up with the rate of requests coming in reducing the system bottlenecks. In a synchronous environment, your application would have resulted in system bottlenecks if the number of requests exceeds a particular amount which the consumer can consume and process.
Using traditional RPC-based technologies, there is a synchronous communication between a client and a server component. Also, communication between many to many can over a period of time turn into a mesh of one to one communication between various components as shown in Figure 18-2 below. This meshing can be troublesome from the application maintainability point of view.
Figure 18-2. Traditional RPC-based application component interaction
On the other hand using a messaging style of integration allows adding a mediation layer between one or more consumers and one or more producers. This result in clear communication between various components which has a clear interface with other components interacts, making it easy to swap the various components according to application requirement. Figure 18-3 shows message-based component interaction.
Figure 18-3. Using messaging-based application component interaction