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
Fundamentally Spring remoting is a Remote Procedure Call (RPC) feature which uses a communication protocol like RMI, HTTP or JMS, to inter-operate across multiple JVM’s. The plumbing involved in actually talking to one another using these protocols and other complexities are hidden away from the developer by employing a proxy object created by Spring.
In this Chapter, we will first go through the basic concepts in remoting and then go on to the support provided by Spring. We will then go on in detail to cover the various remoting technologies which Spring supports in detail.
This section provides standard definitions for the basic concepts and terminologies that will be used throughout to explain Spring remoting in detail.
Remote Procedure Call (RPC)
A remote procedure call (RPC) is an inter-process communication that allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction.
Remote Method Invocation (RMI)
Java Remote Method Invocation (Java RMI) enables the programmer to create distributed Java technology-based to Java technology-based applications, in which the methods of remote Java objects can be invoked from other Java virtual machines*, possibly on different hosts. RMI uses object serialization to marshal and unmarshal parameters and does not truncate types, supporting true object-oriented polymorphism.
Proxy patterns are key for gaining an understanding of Spring remoting. Figure 19-1 shows the UML diagram for the proxy software design pattern.
Figure 19-1. UML diagram of proxy software design pattern
In simple terms, a Proxy object is one through which we control access to the actual object on which the functionality lies. Based on the context in which these proxy objects are used, it can be categorized into three types:
Virtual Proxy – If you would like to control the creation of resource intensive objects in a lazy fashion (objects will be created only when the application actually uses it for the first time to do something), the heavy objects can be put inside the proxy objects and its creation can be controlled according to the requirement of your application.
Remote Proxy – Used to mask the complexity in communication mechanism between remote objects. Spring remoting uses this type of proxy for abstraction.
Access Proxy – Used to control the access to a sensitive object by wrapping it with a proxy.
Smart Proxy – If you would like to provide additional functionality to the existing object, smart proxies can be created to address this in your application.
The Proxy pattern is one of the most important design patterns because it provides an alternative to extending functionality in Java using inheritance. Another alternative is object composition, where an object (proxy, now you know) forwards method calls to an enclosed object (real subject).
Problems Faced Today
Most of the remoting mechanisms provide a layer of abstraction over the transport details used for communication in a distributed environment. This locks your code to a particular programming model. In present day of application development, locking to any model is not considered a right approach especially with frameworks like Spring being around which allows non-locking integration with other third party technologies and programming models.
In the case of using Java RMI (Remote Method Invocation), your service interface has to extend the java.rmi.Remote interface and your client is forced to catch the java.rmi.RemoteException exception class. This dependency of your code to Java RMI makes your code tightly couple with this programming model. It not only locks you in, but also clutters your business logic with the remoting infrastructure hurting the principle of separation of concerns.
Any enterprise application normally will be using many applications and services that function on different platforms. When the need arise for sharing the data or functions between these existing applications, the need for remoting could arise.
Integration will remain a high priority in coming years, according to Forrester analyst Ken Vollmer, as virtually all enterprise application delivery projects require significant integration among applications, internal data sources, external trading partners, and more and more frequently, external data resources.
To answer these challenges, the main goals on which Spring Remoting was built and the advantages it brings can be summarized as below:
Hide plumbing code as much as possible through abstraction—Spring Remoting hides a lot of plumbing code from the developer by the use of service providers in the server side and client proxy in the client side. Due to this the code becomes cleaner and more maintainable in the longer run. Clear separation of concerns and avoiding tangling and scattering of code.
Remoting capability by configuring and exposing services declaratively—Spring’s abstraction uses the configuration based approach for remoting. On the server side no code change is required at all and you have the power of exposing your existing services as remote services with ease. In the client side expose remote methods from existing code. You can then use Spring’s dependency injection to wire various objects into your remote objet with ease.
Support for multiple protocols and handling exceptions in a consistent way—Spring offers a consistent way of writing service exporters, and client FactoryBeans for various protocols represents the same approach and is also consistent across. It provides consistency and ease of adoption as the overall flow remains the same irrespective of remoting technology. In addition, due to this consistency, on the server side ,you have the provision of exposing the services using various protocols declaratively. In the client side it brings in easy swapping of various available protocols according to infrastructure and other considerations. It is also easy to switch between remote and local deployment by mere configuration change which is very handy during testing and actual deployment phase.
In the following sections, we will see whether Spring Framework was able to deliver their goals and in what way they allow extension to it following the Spring philosophy.
Security is one of the very important services which any application needs to have in a comprehensive manner taking care of all the essential parts in a very elegant and simple manner. Spring Security framework is used in several domains including government, banking and military applications. Although written in Java, due to its high adoption and success, its architecture is ported to other platforms such as Microsoft .NET and Python to name few.
Spring Security provides declarative security especially for Spring based application. Having said that it has appropriate extension points and pluggability built into it using which it can be even plugged and used with other standard frameworks available in the software industry. Spring Security provides enterprise level authentication and authorization services at the web request level and at the method invocation level for JEE based enterprise software applications.
Before diving deep into the Security and Spring Security in detail in this Chapter, there are certain terms in the Security world which should be understood in all aspects. This section aims to do just that and armor you with adequate concepts and terminologies which will be used throughout the Chapter.
Any user, system or a device which performs an action is called as a “Principal”. In simple terms in the case an application, anything which would like to interact with the application can be called as a “Principal”.
The process by which the application checks or validates if the interacting “Principal” is who or what it claims to be is called authentication. There are various ways by which authentication process can take place like basic, form, digest, etc.
The application does the process of authentication by challenging the principal. The challenge is usually a request by the application to get the principal to pass on valid credentials, usually a username/password combination already stored in a persistent store of any nature as the application please to be. There are various storage mechanisms by which to store the credentials and various authority details like a database, LDAP, etc.
After a principal is successfully authenticated, it still needs necessary access rights to perform an action on the application like creating a new record, viewing a page etc. This process makes sure that the principal has necessary access to perform the action.
Any resource or item in an application which requires appropriate access rights to perform action on it is called “Secured Item” or “Secured Resource”.
Spring Security related term and is used to refer to application-wide permissions/access rights granted to a principal.
It’s the Spring Security object which is responsible for holding authentication and other security related details.
It’s the Spring Security object which is responsible for providing access to the SecurityContext object. It uses various strategies like ThreadLocal, inherited ThreadLocal and Global to provide the SecurityContext object within an application.
Spring Security Motivation
Spring Security was developed keeping in mind certain considerations. These considerations have become the core motivation on which Spring Security thrives and competes. These motivations can be summarized as shown below:
Portability – Spring Security is portable across different containers both commercial and open-source alike in all aspects. Web application using Spring Security can be deployed as is in different containers and can also run in standalone environments. Non-portability in servlet specification security is overcome by Spring Security by not having container specific adapters and role mappings.
Flexibility – Spring Security supports almost all the common authentication mechanisms and also keeps adding new supports as new technologies arises making it up-to-date almost all the time. It also provides configurable storage options for user credentials and authorities. Being built on top of Spring, we can do all of these by mere configuration, making it simple and easy.
Extensibility – This is high level of extensibility which Spring Security provides in the form of how the principal is defined, where the authentication information stored, how authorization decisions made, where security constraints stored etc. making is highly customizable in nature according to various application requirements.
Separation of Concerns – one of the very important motivations on which Spring Security is built on is the level of separation of concerns it provides allowing business logic to completely decouple from the security code. Also security concerns like authentication and authorization is also decoupled from each other making it possible to change authentication process without affecting authorization.
Consistency – regardless of mechanisms followed to achieve both authentication and authorization, Spring Security keeps the consistency in all aspects.
Spring Security History
Spring Security was originally called Acegi Security created by Ben Alex in the year 2003. Version 1.0 got release in March 2003. Acegi Security provided declarative security and was extremely powerful and flexible in numerous aspects. Although it had advantages in many aspects it had a big inherent problem in having all configurations in XML making it really cumbersome and sometimes troublesome in various aspects.
In Spring Framework 2.0 version Acegi Security was adopted into it and was renamed as Spring Security. With advances in Spring Framework, came advances in Spring Security. Additional modules kept added on and with Spring namespace configurations slowly became easy and more manageable and paved way to configuration by convention. It applies security rules by extensive use of Servlet filters and Spring AOP. Although Spring Security is Spring-based, it can be used with non-Spring based web applications with ease.