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

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