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.

Pages: 1 · 2 · 3