The Spring Framework is incredibly popular for developing huge scale applications. When you build an ecommerce website that may have 50,000 users on it at any given time the scope of the application you are developing changes. This type of site rapidly outgrows the conventional 3 tier architecture (web server/ app server/ database server). The ‘website’ is no longer a basic war file being deployed to Tomcat. You have a data center, with a small server farm. Load balancers, application clusters, message queuing, ‘cloud computing’, micro services. The Spring Framework was not only built for this type of application environment, it prospers in it.
Environments
When you start developing enterprise class applications, you will have to support several deployment environments. You’re no longer going to be testing code on your laptop, then deploying it to the production server. Often in the enterprise, as a developer you won’t even have access to the production environment. Companies which need to comply with policies such as SOX, PCI and/or SAS-70 will certainly have specialized groups which will handle code deployments to their testing (QA/UAT) and production environments. This is known as segregation of duties. A very common business practice. From my personal experience it is more rigid in huge financial business than it remains in retail organizations. Less so in smaller companies due to the fact that they merely do not have the resources to support specialized IT personnels.
More modern development cultures will certainly be performing CI builds and automated deployments. Teams on the bleeding edge of modern software development may even be doing constant deployments.
Each of these environments will certainly have its own setup requirements. As the scope of your application grows, chances are the individuality of each environment will certainly grow too. The Spring Framework has some outstanding tools which are utilized to handle the complexities of contemporary enterprise application development. Initially, let’s consider some typical challenges in the types of environments you will have to support in a huge enterprise application.
Local Development
This is your development environment, running from your laptop. This is an area most of the companies absolutely fail at. Your code should be able to run in your area, without the have to connect to other servers in the enterprise. Preferably, you need to be able to run the code on an airplane at 30,000 without a wi-fi connection.
This indicates:
- You can not use an external database. You’re not going to use the Oracle development database.
No interaction with other web services. - No JMS (MQ Series, Active MQ, Oracle AQ, etc).
- Your build artifacts have to be in your area cached (hey there Maven, Ivy!!).
The Grails group does an outstanding job of supporting a local development environment of of the box. When you run Grails in dev mode, it will immediately create an in memory H2 database. Hibernate is made use of to generate the database tables based on your domain classes.
Continuous Integration
Continuous Integration servers can be challenging little monsters to set up for because of the various types of testing software they accomodate. You might have a project the produces a JAR file, which only has unit tests which will zip right along. You might have integration tests, like Grails does, which bring up an embedded Tomcat instance an H2 in-memory database. Your tests may even carry out practical tests using something like Spock and Geb to communicate with the embedded Tomcat circumstances. Its also not unusual for CI servers to have automated deployment jobs– to another specialized environment.
Each of these scenarios is likely to drive unique configuration requires into your application.
Development
Some companies choose to have a development environment. This is normally a production like server environment that the development group has control over. When you deploy into this environment, you will need to set up the application to connect with servers within that environment.
QA/ UAT
QA or “Quality Assurance” and UAT “User Acceptance Testing” are environments for non-developer resources to test the software. In some organizations you might have both QA and UAT, or you might have one or the other. If you have both, chances are the organization has official QA Engineers which deal with the QA Environment, and Business Analysts which work with the UAT environment. These environments are often managed by a configuration management team. Occasionally developers will have access to the environment, but typically they will certainly not.
Pre-Production or Stage
Pre-Production or Stage (Staging) is an application environment that deals with all the production services and supporting databases. This is an environment that permits the deployment of application code, but restricts the access to that code. For a website, you might see an unique url or access restricted to certain IPs, or throttled by load balancers.
This environment is not as typical, however some companies use it. Facebook deploys code something along this line.
Production
Production is the environment you end users will certainly utilize. This is the primary transactional environment and the one your business partners want to keep operational at all times.
You can see each of these environments will certainly have its own unique requirements. You’re going to have various database servers, different database variations, typically various database vendors. You’ll have various supporting services. For instance in an ecommerce website, you might have a payment gateway. In dev, it might be a mock, in test you might be using a testing entrance provided by your payments carrier, and after that a different payment gateway for production.
Spring Framework Multi-Environment Support
The Spring Framework was developed from the ground up to support the obstacles of supporting complex enterprise environments. You have a number of fully grown functions in the Spring Framework to use in supporting the difficulties of enterprise class applications.
The Spring Framework has outstanding support of externalizing properties. “Properties” are easy string values which are externalized from your application. In the Spring Framework homes can be set the following methods:.
- In a traditional properties file. This is generally kept in the resources folder and is often called ‘application.properties’. It is by convention to use <filename>. homes.
- Using Operating System Environment variables. Java can check out values set in the Operating System as environment variables. I’ve used this in the past for things like database settings, which worked out well. When setup, it was successfully ‘drag and drop’ for the support personnel.
- Command line variables. When beginning any Java application, you have the opportunity to pass command line variables into the program. This is a handy method making your build artifact portable. One word of care, when analyzing running processes on a system, you can in some cases see the command line information which started the process. So this solution might not be the very best alternative for password strings.
The Spring Framework Support has a variety of choices for sourcing in property values. One method is using the Spring Expression Language (SpEL).
Dependency Injection
Changing property values is terrific for things like connecting to a various database server. But typically in enterprise class applications you will require behavioral modifications which are beyond simple property changes. One of the core functions of the Spring Framework is the support of Dependency Injection. When you end up being familiar with development with Dependency Injection with in the Spring Framework, you will see how your code ends up being more modular. Your classes will naturally stick to the Single Responsibility Principle. If you’re doing Dependency Injection against Interfaces, it ends up being very simple to exchange out parts.
Let’s state you have an application which needs to send a JMS message on an occasion such as a customer purchase. This may trigger an email to the customer about their order, and the data warehouse group may desire the purchase information for their analytics. For your system tests and your integration tests, you might be using Mockito to offer a mock. In your deployed environments you might be using the business standard of MQSeries for messaging. However what about doing CI builds? An embedded instance of ActiveMQ simply might be best solution.
So, in summary, this example has:
- A Mockito Mock object;
- 3 various MQ Series configurations;
- And embedded ActiveMQ.
The MQSeries setups are easy to handle with property settings. The only thing changing right here are the connection specifications. This is the perfect use case for externalized homes.
For your system tests, if you want to keep them real system tests, you’ll have to manage the dependency injection yourself. Testing structures such as Mocktio and Spock make this easy to do.
If you’re carrying out integration tests a simple method to handle the Spring Context is through configuration composition. But you might wish to prefer using Spring Profiles instead.
Setup Composition
Unskilled Spring developers will place all their setup into single xml files or configuration plans. This is typically an error given that it limits your setup choices. In our example, all our setup alternatives could be supported through configuration composition. You would need to position each configuration into a different xml file, or configuration package. Then selectivity import it into a parent setup. You generally import the setup you wish to use into a parent setup, then pack the moms and dad into your Spring Context at run time. This is still an incredibly popular strategy to use for testing where it is really simple to specify the Spring context to use at runtime.
For a long period of time this was the only option Spring developers needed to use. In Spring 3.1, Profiles were presented to assist handle different configurations. As you’ll see in the next area this a really powerful feature of Spring.
Spring Framework Profiles
Spring Profiles is a really effective feature presented in Spring Framework 3.1. Profiles permit you to define Spring Beans and define when they should be packed into the context.
If you do not mark your Spring Been with a profile, it will certainly constantly be loaded into the Spring Context.
When you do mark your Spring Bean with a profile, then that profile has to be set to active for that bean to be loaded into the Spring Context. This makes management of the environment easy, considering that you can simply mark the various alternatives with the suitable profile, then when you set that profile option to active, Spring will wire up the proper Spring Beans into your application.
There is one unique profile that is rather poorly documented, however very good to use. And that is the default profile. When you mark a Spring Bean using default, this bean is loaded into the context just if no other profile has been set to active. If it there is an active profile, Spring will certainly try to find a bean matching that profile first.
Conclusion
As an application developer, the Spring Framework offers you a lot of choices on how you can compose your application. If you’re made use of to smaller scale development, the wide variety of setup alternatives in the Spring Framework will probably appear like overkill to you. Why would you need such versatility? Right? No, Wrong. When developing applications in the enterprise you are going to be challenged with supporting the requirements of various environments. You are not simply developing code on your laptop. Not is the production environment the only environment you have to be concerned with. In a large enterprise you will certainly need to support multiple environments, with different setups and different needs. The Spring Framework has developed throughout the years to support the challenging needs of enterprise application development. It’s no wonder that the Spring Framework is the most popular framework to use for developing enterprise class Java applications.
