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

I a recent comment, Paul mentions he is not familiar with the Document Style concept. This is a great opportunity to touch the theme and clarify some ideas about WSDL and the WSA idea of a service.

WSDL is meant to describe the service definition and interaction models. WSDL defines:

• The Service’s visible endpoint. That is, the address where the port of the service leaves.
• The Binding. That is, which transport to use and how.
• The Operations. Each operation with a name and a message flow (a named message inbound or outbound).
• The Messages. Each named message has a number of named parts that conform the payload.
• The Parts. Each one is defined either by indicating the primitive type or a schema defined xml.
• The Schema. A Types section that is defined using an XML schemas.

Using the above sections, we can define the service by indicating the port, the available operations, which message flow each operation has, and what is the structure of each message.

With the WSDL, the client is able to know how to construct the message and where to send it. So far so good for our service notion.

The problem comes when WSA came out with the style/encoding idea. SOAP was originally created to access Objects remotely (Simple Object Access Protocol). Here is the story.

Those were the times when RPC was the idea of remote access. So, SOAP was created a requirement for the body of the message. It had to be constructed with a fixed structure, where the root element’s name should be the same as the method name. The children elements should be one per parameter, and each one containing the type as an attribute. That structure was known as the encoding.

Pages: 1 · 2 · 3

Based on several comments and articles I've read, I tend to think that SOA and Web Services are being misunderstood. Maybe I’m the one that is wrong, but just in case I will try to explain here what I understand. I guess the first thing to do is to define what a service is.

Base on the Web Service Architecture specification, a service is “… an abstract resource that represents a capability of performing tasks that represents a coherent functionality from the point of view of provider entities and requester entities.”

I want to point out the fact that a service is a “resource”, it can perform some tasks, and it represents functionality. A service has an ID that will let us find it in the networking cloud. It has a description and it has an interface. That interface “… is the abstract boundary that a service exposes. It defines the types of messages and the message exchange patterns that are involved in interacting with the service, together with any conditions implied by those messages.”

Let’s put it in other words. A Service is a coherent functionality offered by a web resource. To communicate with it, you use its interface. It will accept messages interchanged in a predefined pattern.

But there is an important fact: “To be used, a service must be realized by a concrete provider agent.”, WSA spec says. In other words, a service is an abstract model of a resource. That functionality is to be realized by a concrete agent, may it be software or hardware. Let think of it as a functional cloud, accessed by messages delivered to a port.

An Example may help.

Pages: 1 · 2