A REAL service definition

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.

Service: Loan service.

Functionality: Actually, the service is able to process loan requests, payments, notifies due loans and you can ask for a loan status.

How is it done?: There are four document types, each one has a particular schema: LoanRequest (input), LoanInfoRequest(input/output), LoanNotification (output) and LoanPaymentNote(input). Any input XML document may be sent to a port located in www.willyloans.com/loanport or to the email loanport at willyloans.com. There, an XML processor will determine the schema type, and send the actual data to the loan analysis department, to the loan payments subsystem, or to the loan service desk system. You can guess what each system does, and what each document may contain.
You can create four WSDL if you want. All pointing to the same address. Just make them document style.

Note that the service doesn’t reassemble an object. It has no methods or attributes, just functionality. You don’t call it (although pure objects are supposed to receive messages), and they may not have a response (although they can send a message back, or the same modified message).

Mainstream is actually building web services from the actual implementation. Instead of creating a service that is realized using exiting classes and systems, developers are simply exposing their methods and objects. They are using an RPC model instead of messaging. They are architecturing a distributed object system instead of services.
This leads to several myths and perceptions that make tool vendors offer what developers want, and none is working towards a truly service development.

I will check on those myths in future posts.

William Martinez Pomares

Reference and other comments: A REAL service definition