As promised I will try to show you how to build SOA services using an practical example. (a very trivial example but it will do). So here's your mission if you choose to except it:
As an employee of company X I would like to see a list of all X:s employees to find role, department, email, image etc for my colleagues.
Like almost any assignment this is no green field project so we have the following systems present.
- A HR system for handling employees and their roles, salaries etc.
- A CMS system that runs the corporate intranet
One of early misconceptions of SOA, was that Service == Web Service (this is luckily starting to go away). If you still believe that you'll get a SOA just by using web-services the solution should be obvious: Just wrap a web services around the HR system and call that service when users request the employee list. Hey, didn't that CMS vendor mention that their software was "SOA ready" because they had a web-service API so the CMS system is already part of our SOA
With this naive approach you'll get Service Oriented Integration (SOI), while this is not all that bad it's not building the agile and reusable architecture that the business think they'll get.
The upcoming posts will highlight the shortcomings of the above approach so we'll leave it for now.
That said, lets see how we can translate these requirements to well designed services in our company's SOA. To do that we must answer the question:
What defines a good service?
Bill Poole has the best definition I've seen so far:
Ok, so good service should:
- Align with the business
- Expose process centric interfaces
- Mainly communicate using pub/sub messaging
- Maintain data locally (decentralized data)
Lets start with the first one, "Services should align with business". It's easy to understand why it's good that Services align with the business but perhaps not so easy to figure out how to achieve it.
It's my experience that services align well with business when you model them around business-capabilities. Business-capabilities focuses on what a business does to reach its objectives (its capabilities), instead of how it does it (its business processes).
In our example the business needs the capability to "manage our human resources" and "communicate internal company information to employees". One of the benefits of modelling services around capabilities is that capabilities is relatively stable over time. I can imaging that even before IT was invented the same capabilities where needed by our business.
Changing software is costly so modelling our services around things that are fairly stable reduces the need for change == lower costs for maintenance.
Another important aspect is to design services with the correct granularity. Correctly grained services usually coincide with traditional departments, e.g. Billing Service, Shipping Service etc. So if you have services that has functionality that spans more than one department it's usually a sign that you have too coarse grained services. On the other hand if you have a lot of services with functionality from the same department you might have too fine grained services.
With the above guidelines in mind we decide to introduce the following two services:
- The Human Resources Service (HR-Service)
- The "Inform and collaborate with our employees" Service.
The latter will require be a lot of typing :) so lets refactor this one to Intranet-Service. This narrows the scope of the service a bit but I think the concept of using some kind of "intranet" to collaborate with employees is fairly stable so it will do for now.
So now we've hopefully aligned our services with the business and thereby satisfied the first requirement.
My next post will focus on the other three requirements of "a good service". As we'll see these requirements highly affects how our services communicate with each other.