Tourist Information

According to The Open Group:

  • Service-Oriented Architecture (SOA) is an architectural style that supports service-orientation.
  • Service-orientation is a way of thinking in terms of services and service-based development and the outcomes of services.
  • A Service:
    • Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports)
    • Is self-contained
    • May be composed of other services
    • Is a “black box” to consumers of the service

Well lets say that is very academic of them, and I do appretiate it. But at the same time is very broad, so lets try to make is a little less broad. I see it as representation of a set of actions something or someone can do, that are self-contained, reusable, autonomous, composable, granular, etc.

Given such definition, you could think about anything around you (including your self) that does things as services, e.g. your phone, your bank, a pen drive, etc.

The first 2 examples are complex services that are composed of multiple smaller services, for instance your phone, makes and receives calls which depend on a carrier service, also it allows you to use different apps, or something as simple as the gyroscope. Now the "pen drive", is a much simpler example, it does basically 2 operations "Store" and "Delete", and does not depend in any other smaller service which makes it very re-usable and independant.

But wait, isn't that the a similar definition to what classes and objects are? Well yes, they do share lots of things since Services are the natural evolution of such ideas.


Lego Blocks

So services will share much of the same and extend it quite a bit, so a service should be:

  • Self-Contained: Consumers should not be aware, or need to be aware of what is happening under the covers, this is a necessary fact in order to make it autonomous, loosely coupled.
  • Reusable: It should allow anything else to consume it, independently of others.
  • Discoverable: Consumers should be able to find the service when it makes it self available, that means that it is also location transparent (Wish cellphones where like that, along with the car keys).
  • Composable: Consumers should be able to use multiple services together where each has its purpose, but the whole, makes a new bigger service.
  • Granular: In order to keep it simple, and adhere to all the other requirements, the service should focus on as few as possible functions. Like the "pen drive" .

Think of services a little lego pieces, that allow you to put together anything you need, then take it apart and building something else.



Testing for some comes as a concern, but I believe that by applying proper design to each service allows you to test the functionaliyt (Unit Test), and later on you could also do integrations testing when necessary, but if the service is granular enough unit test will do a great impact and minimize the need of other tests.

Later on the life of the service updates will happen and with that might come new versions, which could greatly impact consumers, but once again granularity come into play and the more granular the service is, the less impact it may cause due to the simplicity of its functions. e. g. the pen drive, writes and deletes data, if you change the entire system bellow it, as long as the interface remainst the same, the impact will be zero to the consumers.

But the biggest concern is that a lot of what makes a service cool, requires lots of wirework, plumbing, and tools.

Discoverability for instance, how would a service make it self available and allow others to find and use it correctly?

There are many different ways to achieve that, you could right a registry, where the service signs in, and let it know what actions it has, how to properly execute each one of them, and where to find it.

In order to minimize work its a good idea to define contracts that each of the services should adhere to. If everyone talks in the same language using the same set of rules it is much easier to evolve the system, with less wireing and plumbing. Contracts could be viewed as patterns and conventions which usually minimize code.