A Service Mythology

Through all these years, the service concept has been a confusing one. At the edge of Service Era, even before the service name was coined, services existed and were implemented using the tools at hand, and the tools helped to define the concept. I mean Services in all their presentations, those including SOA and Web Services, REST and CORBA, etc.

Today, after all this time, hundreds of articles, papers and news had been written explaining all facets of Services. Yet, many of them presented conceptual differences, and in the community’s mind a mix of myths started to grow.

The following is a list of myths I’ve encountered to be still present nowadays. Some are innocuous, some others are not. Furthermore, some may not be considered myths at all for all people, since their opinions may differ from mine. Anyway, here they are.

Myth 1: SOA = Web Services.
More that a myth, this is a general confusion enforced by tool vendors. Why? Because of selling SOA ready tools that offered Web Services construction, so conceptually having SOA was simply achieved by having Web Services
.
Reality: A Service is a bunch of functionality that is cohesively integrated into a locatable resource and accessed through a port using messages. (No, it’s not an object).

SOA is an architecture style that simply indicates the use of Services (special functional units) in the architecture. That is, you can have several very different architectures that are SOAs, with the common characteristic of having services in them.

Web Services Architecture is a special architecture that defines the description, interaction and messaging definition for a service that uses the web to communicate. Note that the service concept is part of both things, but Services are not limited to be Web Services. Web Services is just a way to create services. And Services may not use that architecture, nor be implemented trough the web.

Myth 2: Web Services = RPC.
SOAP (Simple Object Access Protocol) was born to make remote objects accessible through web. Its initial goals were clear: allow to encode a method call through web using XML. Later on, the service definition and concepts were improved, not limiting it to remote object method invocation but to a messaging system (even SOAP acronym changed to Service Oriented Architecture Protocol), but the “traditional” way of doing things kept implementing the services as simple remote method calls. In other words, a simple RPC.

The Service concept states the communication should be using messages, and those are all one way. If you want a request-response behavior, you need two messages: one in-one out. So, at the end, the services concept accepts RPC, but services are not RPC.

Martin Fowler states that difference in the book "Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (The Addison-Wesley Signature Series) by Gregor Hohpe and Bobby Woolf", when he writes about integration by sharing. RPC is good to share functionality, but services will help to share functionality and data, and they are the less coupled form of integration.

Myth 3: Web Services as Methods exposed.
There are two ways to create a Web Service: starting from a service definition (usually in XML-WSDL, also called a contract), or starting from code (that is, an Object). Of course, developers tend to start by writing the code and, after that, see how that fits into the overall picture. This second option has a side effect: It makes developers think that a service is just an object’s functionality that is exposed to the web. That is not true.

The functionality that makes up a Service is more related to the business side of the story. When an entity wants to offer a service, it will define a contract for clients to access that functionality, and that contract is business oriented, not implementation driven. A service functionality may be implemented by a method, a complete object, a set of objects working together or even a full system application. All that implementation nature is encapsulated, so the service user does not know how is everything achieved. It is more concerned of “what” that functionality is, the more coarse grained and implementation neutral the better. So, a service is far more than a method, or any functionality, exposed.

Myth 4: SOA as a product.
The SOA solution does not come in a box. It is true special tools are required to build the solution, but SOA construction is more an architectural task than a technology one.

First, the business side comes into play to define the business service to be offered. Then it’s the architect’s job is to decide how that service is going to be supported, and make everything fit in the architecture. Then it is the implementers job to make use of Service technology to make all happen.

Remember, a box shouldn’t drive your business.

Myth 5: Services as Implementation.
This follows up the above discussion. A service is not defined based on how it is implemented. A service is defined based on the functionality it offers, and the cohesion it has.

In other words, just by creating an object with a method, and managing to expose that method to the web, I’m not creating a service. I may be exposing a method, but nothing more. If I define a functionality set, create a business oriented, technology neutral contract, and at the end I implement that using an exposed method, I may be creating services.

Myth 6: Services = Process.
Here is another subtle one. Services are often defined as the process they perform. It is a dangerous way of looking at it, since the process to achieved something may change between implementers.

Let me explain. If I define a service saying this one decrements or increments the temperature to fit a certain threshold, I’m defining it based on the process it performs. Thus, any other way to keep us cool may represent a different service. I may simply say the service keep us cool. I don’t know how it does achieve the coolness, but I do know how I’ll feel.

Myth 7: Services for Distribution.
I often hear people saying services are to build distributed systems. That is some partially true, and much partially wrong

A distributed system has the benefit of processing things in the right place, keep things closer, and make all organized. The problem they face is the cost of having its parts separated, distributed. Services, at least the web one, are expensive, and should not be used if the same effect is achieved by other distribution techniques.

Services indeed, are for business definitions. You can have a distributed system that has its parts linked by highly coupled, fast performing communication channels. Those links are the solution to the distributed implementation. Since services are not about implementation, they don’t fit in.

Now, if what you have is two different systems running in different platforms, the problem you face is not distribution, but integration. Using services, two systems may integrate and interoperate without needing to know anything about the other’s implementation details.

In a shell: a service may be used to integrate, to interoperate, and in a very much lesser degree, to distribute (unless you are distributing in the same process!).

Myth 8: Services are Stateless.
I like this one, and I know many people may contradict what I’m going to say: Services doesn’t need to be stateless.

Many people read about REST and they read about resources and how they are stateless. But in fact, it is the communication the one who should be stateless. Mapping that to services, we know that communication should be stateless, and communication happens in one message transmission.

Now, when implementing Web Services it was required to use stateless artifacts, like EJBs and Servlets, to provide scalability. But read above, services are not simply their implementations, thus they may no need to share their characteristics. A Service may have a state, and it may need to “remember” a client. Why? Because the Service is not the implementation, but the functionality the entity wants to offer. Being stateless is a restriction or feature of technology, not of business functionality.

Let’s see my favorite example. A Loan Service is a set of operations that allow me to request a loan, to request information about loans, to request information about my pending request, and to notify me when there is a result for it. If you think of it, the service may be implemented using an stateless session EJB, but it needs to recall my case through time. Look here, the business functionality may not be stateless, but the implementation is. And we already learned they are separate things.

Finally, the confusion may come from REST. Although pages and resources are stateless in the web, the stateless part of the service may be its actual description.

From this list, I may have a very angry group that thinks I’m wrong. It may be a start for a happy discussion. Nevertheless, it may serve to spot the semantic mismatch about services that lives in the myriad of text out there.