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

Hi All!

Very excited that I’m writing my very first post in the blog.
And since this is an Architecturing blog, I thought I could point it to a very interesting discussion held at The Server Side.

The article presented here is about the complexity generated when using SOA, compared to the same complexity history of CORBA times. Although the idea is nice, most of the participants show a problem of understanding what SOA really is.

System Integrator Technology? CORBA with a new acronym? A new distributed approach to organize business logic? Simple EJB, SOAP and other technologies follow up, with nothing new? No several times.

As I mentioned in my responses there, SOA is based on the service Metaphor, which is placed in the problem domain, problem space, where business organization rules and not technology trends. SOA now is a patched, almost like a stovepipe architecture, solution for integration, and like that it sells.

Later I will write a little bit more about the Service metaphor. That is not for RPC developers, I’m sure.

William Martinez Pomares