Paul kindly pointed to a blog entry about WADL use in REST, (WADL definition is found here). The Blog entry was interesting to read.

I want to quickly explain that WADL is meant to describe the possible interactions with a Web Application. Thus, it has methods, but those are HTTP commads, and it also describes the query variables (like the fields in a form) that the method needs to send to the web application. Finally, it describes the expected response.

Now, in the blog I see some misconceptions. First, it relates SOAP and WSDL to XML-RPC. That may seem true due to actual use of those two, but SOAP is just a wrapper and WSDL does not enforce XML-RPC, using document/style it reassembles a simply document sending paradigm. By the way, XML-RPC and WS used to do RPC are two completely different things.

Second, the REST based Service concept is defined to encompass even static web pages. May REST style architecture handle resources in the web, and REST “style” Services are services implemented using the REST underlying paradigm. But Static pages are not Services.

Third, WADL is at implementation level of the HTTP call, thus it does not define the service, just what to call and what to expect in response. That is not bad, it is actually good, but then WADL describes an HTTP interaction, while WSDL describes a messaging interaction. Although not actually standardized, WSDL may allow you to send messages using a message queue, SMTP, or any other transport.

Now, I want to explain my vote. I’m not a WSDL lover, I think it may be improved. Still, I’m carefull to compare, it is not as easy. We cannot say WADL is a description document for REST based Services and WSDL for RPC based ones. Right?

I may want to go even further. I may say REST Style Services may actually make use of both! Yes, while WSDL describes your Service at message level, defining the document and port, and a WADL that makes clearer the HTTP interaction (since WSDL inly indicates you are using HTTP as a transport).

Again, what do you think?

William Martinez Pomares.

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

I just wrote an answer in TSS that I thought I could share here too. The basic idea everyone has about services is that they are to distribute logic, make remote calls, have loose coupling interfaces, and are resusable. And nothing is working as it is advertised. I will play the defendant part here.

“I see a repeating idea about SOA, services in particular, that doesn’t fit in what I have learned from my childhood as an architect. I will explain myself.

I recall the old Object oriented days when all the fuzz was about reusability. The idea was clear: separate the code into coherent and functional complete things. Then a problem was found: the interface. You could not reuse the thing because of the interface not being suitable, or requiring things not in the new problem domain.

Then a service came. It was the idea of having a business functionality (not an interface, not an object) able to accept messages and offer a business value. It has no reusability concept, the fuzz was actually about replacing fixed interfaces with a simple port. And somebody said: Let’s implement it with SOAP. And SOAP was Simple Object Access Protocol, an RPC oriented wrapping protocol used to access distributed objects. Wow. Wait a minute. Something is not working here. I know objects were supposed to accept messages. Nobody uses that. But a service is not an object. A service has no methods or parameters. Definitively, it has no response. There is no interface per se, just a port where you deliver your message.

Now, the message is not SOAP. SOAP is a wrapper. The real thing is in the body.

Once the service has read from the port the message content, it will now know what to do. And it may decide to send another message. As simple as that. But as difficult to grasp for an object programmer, that it was reduced to a YAMTCARO (Yet another method to call a remote object).

NOw, can somebody tell me why a service needs a method name to be called? SOAP had stubs in the client, to simulate the remote object as local. Services are not object, stubs have no place here. Makes no sense. You need a port object to stream your message. Simple.

Finally, since a service is just a port, and the service semantics (which are not technically describable) is hidden behind the service cloud. You can create a versioning system underneath the cloud, so old messages can still be accepted and new messages, that represent new business needs, be processed as required. Service cloud still as white as before. It may have a new port, but old ports may be still there.

Enterprise architects? Their job is to have one eye in the problem space, and the other in the solution space. They will work with business people to design services scope (business driven), and work with designers to technically create the structure of the cloud.

Hope this helps to understand why I say all that I say.”

William Martinez Pomares

Funny article in SOA Masters Class site. It explains the vision of SOA based in two variables: the Architecture involvement scope, and the Service concept scope.
Yep, there is a big difference when you see the Service concept as an exposed component, or as business functionality. Same for involving the architecture simply as a glue to interoperate disparate systems, or as a business driven structure.

Funny indeed!

William Martinez Pomares