There’s a lot to be said for moving to a Service Oriented Architecture (SOA), but what is it, how do you do it and how do you migrate away from existing systems…
I don’t want to get bogged down in the technical details of governance or specific technology, but rather provide an overview of what SOA is about and how you might go about migrating to a Service Oriented Architecture.
Firstly, a bit of background…
Many of the applications we’ve created traditionally, tend to require a User Interface, some business logic and some data. Typically, these have been tightly grouped together as a single system for the business to use. As new applications are developed that also require access to the same data, we have often accessed it directly from the new applications. If they require the same or similar business logic, we have either recreated it or accessed the routines directly. Over time, a web of connections has evolved which has resulted in a very rigid architecture and we now find it hard to replace any individual system without effecting lots of other systems.
In fact, we’ve effectively created one huge system that requires serious bits of kit to run it. To remove our reliance on big tin, we need to split the system up and move it onto commodity hardware. We can then start to consider doing funky things like moving it to the cloud and so on.
So how does SOA help with this?
When creating a Service Oriented Architecture we try to model the business. Rather than thinking in terms of applications, we think of:
- Business processes, such as “opening a customer account”,
- Business events, like “customer account created”
- Business entities, like “a customer account”.
Each of these is made into a standalone service that deals with that particular thing and nothing else. So, for example, a customer account service would deal with managing customer accounts. Any other system that wanted to access customer account information, would go via the service.
This enables us to move the customer account data and the maintenance applications to a new location.
As the service models the business rather than being system specific, it is more stable and can be re-used by other systems easily. Another key point is that our systems become event rather than batch driven, which means we can operate in near real time and keep our systems running 24 7. We obviously still have applications – but these are reduced to UI layers that float on a sea of services and are more easily replaceable
OK Great – but what is a service?
Services, or web services to be precise, are just standalone pieces of software without a user interface. The thing that makes them special, is that you communicate with them using open web-based protocols. This means that any system can talk to any other system, regardless of technology. This usually helps a great deal at companies that have incumbent legacy systems as they have many different technologies in use and web services will help hide that fact from their applications.
So what does SOA look like?
There are many ways to skin the SOA cat, but a good place to start is to identify the classifications of web service that should cover all your needs, for example:
These manage the storage and retrieval of business entities, for example, order, customer or product. They tend to create, read, update and delete entities (CRUD). In addition, they often have a find capability too.
These allow for the broadcast of business events, for example, when a customer sends a contact us enquiry from a website. They are usually asynchronous and there may be multiple subscribers listening for the event.
In the case of a Contact Us request, there might be a Customer Comments system subscriber and a Customer Relationship Manager subscriber.
These perform small business processing tasks, for example, perform credit check. The tasks are usually short lived and may require the coordination of several other services
These manage whole business processes that typically take some time to complete, for example, new product induction. They usually provide an overarching, coordinating and orchestrating role over multiple services.
These satisfy the need for fundamental cross cutting concerns to be dealt with, for example, logging and identify management. They are often highly re-usable.
For each of these services, you can start to identify a number of business capabilities. These are the operations that the service can do, for example, Update Product, Send Email, Perform Credit Check, Notify Brochure Request.
The service capabilities and the messages that they handle are described in a contract. These provide the framework on which the service and its clients are built and are derived from the business analysis of the problem being solved. Over time, a model is built up of the business rather than the various systems that enable it.
It is the combined services, capabilities and contracts that will contribute to a catalog of functionality that you can make available as a company Application Programming Interface, the Company’s API.
…and what is the Company API?
Once you’ve established a catalog of service capabilities, you can publish it as the company API. This describes the capabilities and how to utilise them.
When requirements for a new application come in, you’ll be able to select the capabilities that are required, build a UI and then wire them together to create the required system whether it be a mobile app, a web app or a standalone thick application.
This is obviously much quicker than building the system from scratch and also means you can replace the UI easily. You can even publish parts of the API externally to either trusted partners or publicly, which will enable 3rd parties, suppliers and customers to create their own applications hooking in to your back office using the same simple technology that powers the Internet.
So how do you create services?
Again, there are many ways to do this, this is just one suggestion…
- The process starts with business analysis. Process maps will help identify the business process that need to be modelled, the business events that are occur and the entities they use. As potential services are identified they are recorded
- A SOA governance board meets to discuss the opportunities and either agree a service is required or grant a waiver.
- Capabilities are determined and recorded into the web service inventory, which will eventually become the company API
- Contracts are created and committed to source control.
- Any infrastructure requirements are requested
- Engineers use the contracts to build out the service implementation and deploy it onto the infrastructure
- The services are wrapped in multiple layers of automated tests and are continuously deployed, so as engineering work is completed, the services move through the various environments and into production
…and what technologies do you use?
Because the important thing about SOA is that the contracts are modelled on the business and these are kept separate from the actual code that implements the service, it actually doesn’t matter so much what technology you use. However, for the purposes of consistency, you might want to standardise on languages and frameworks so that any engineering team can pick up any service. However, the contracts do give you the flexibility to switch your technology choices in the future should you wish.
An example (open source) web services stack
- Code the services in Java
- Deploying them onto Tomcat servers.
- Use JSON for the messages
- Build the services to be RESTful.
- Apache CXF as a web services framework
- Apache Camel as a routing and mediation engine
- Apache ActiveMQ as message broker.
- jUnit for unit testing
- Cucumber for integration tests.
I deliberately haven’t mentioned an Enterprise Service Bus here…to find out why, check out Does My Bus Look Big In This
…and how do you deploy them?
However you like, but one suggestion is:
- As code is committed to source control, a CI tool picks it up, compiles it, unit tests it and deploys it.
- Automated acceptance tests run against it and then the service can progress through the environments to production.
- Each service is deployed onto multiple (Tomcat) servers and is load balanced.
- The (Tomcat) servers are sized (Eg very small, small, medium, large or extra large) and to scale the service you can either increase the server size to scale vertically or increase the number of servers that the service is on to scale horizontally.
So what now?
Get building services and migrate your existing systems one by one onto your new Service Oriented Architecture!