A RESTFull WSDL?
June 7th, 2007
A RESTFull WSDL?
Written by: William Martinez
Published on June 7th, 2007 @ 04:25:35 pm , using 791 words, 3046 views
Published on June 7th, 2007 @ 04:25:35 pm , using 791 words, 3046 views
Posted in Articles
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.
PermalinkTrackback address for this post
4 comments
Hi William,
Thanks for the explanation. WSDL allows four types of messages then? I googled and came up with the same. What I didn't know though was that this "design choice", was predicated upon the use of "SOAP" as a transport. Why? Why SOAP?
In my last post I said question the spec, so I will do so. So why four ways? You suggest that we should all use the "document/literal" approach, so why the other three?
I will suggest that there are other agendas at play in these specs then purely technical ones :^)
By far the most popular WS-* approach is the RPC style which like you say, even when you indicate otherwise, some tools still insist on interpreting the first line of your document as an operation (procedure call).
IMO a standard is meant to promote best practice. In doing so a standard should constrain the design choices available. In this regard, the WS-* specs offer no constraints, just confusion.
For example if you are using a document style, then there are a limited number of generic "operations" you can perform on a document. A spec that specified these operations as part of a generic protocol would go a long way in guiding developers towards best practice. Also to promote runtime extensibility, documents should be self descriptive. Again a good spec would have defined a generic meta-protocol for describing documents.
As is, the WS-* specs are "unconstrained", and what really matters in practice IMO are the WS-* tools. From what you have said the tools focus on SOAP and RPC, which for me is no surprise. SOAP and RPC compliment the existing encumbent technology base (programming languages, ORBs, middle-ware platforms, etc) and in so doing satisfy the commercial goals of a number of vested interests.
In my opinion what is needed for true SOA is a runtime extensible service orientated architecture. You have illustrated away this can be achieved with WSDL/SOAP, but there are other simpler "purpose built" ways IMO. REST as you mention is one of them, and REST doesn't require SOAP.
This discussion can take two paths in my view. We can explore alternative SOA visions and contrast them with WS-*, or we could explore the political issues that make WS-* what it is today.
It's your blog so the choice is yours :^)
Paul.
Thanks for the explanation. WSDL allows four types of messages then? I googled and came up with the same. What I didn't know though was that this "design choice", was predicated upon the use of "SOAP" as a transport. Why? Why SOAP?
In my last post I said question the spec, so I will do so. So why four ways? You suggest that we should all use the "document/literal" approach, so why the other three?
I will suggest that there are other agendas at play in these specs then purely technical ones :^)
By far the most popular WS-* approach is the RPC style which like you say, even when you indicate otherwise, some tools still insist on interpreting the first line of your document as an operation (procedure call).
IMO a standard is meant to promote best practice. In doing so a standard should constrain the design choices available. In this regard, the WS-* specs offer no constraints, just confusion.
For example if you are using a document style, then there are a limited number of generic "operations" you can perform on a document. A spec that specified these operations as part of a generic protocol would go a long way in guiding developers towards best practice. Also to promote runtime extensibility, documents should be self descriptive. Again a good spec would have defined a generic meta-protocol for describing documents.
As is, the WS-* specs are "unconstrained", and what really matters in practice IMO are the WS-* tools. From what you have said the tools focus on SOAP and RPC, which for me is no surprise. SOAP and RPC compliment the existing encumbent technology base (programming languages, ORBs, middle-ware platforms, etc) and in so doing satisfy the commercial goals of a number of vested interests.
In my opinion what is needed for true SOA is a runtime extensible service orientated architecture. You have illustrated away this can be achieved with WSDL/SOAP, but there are other simpler "purpose built" ways IMO. REST as you mention is one of them, and REST doesn't require SOAP.
This discussion can take two paths in my view. We can explore alternative SOA visions and contrast them with WS-*, or we could explore the political issues that make WS-* what it is today.
It's your blog so the choice is yours :^)
Paul.
06/09/07 @ 03:56
Comment from: William Martinez [Member] 
Hi Again.
I wanted to clarify a couple of lines, with the rest I agree plenty.
There are four possible combinations to create your messages: RPC/Encoded, RPC/Literal, Document/Encoded, Document/Literal. The first one is the original and the most constrained, and so banned due to interoperability problems and cost. The third one (Document/Encoded) makes no sense, since “encoded” means the parameters follow a predefined structure, and document has no parameters. Thus, the third one is not implemented anywhere.
That leaves us with RPC/Literal (the one for legacy programmers), and Document/Literal (the one for the right way to do WS). The problem is the tools, even when using document/literal, mask the document to simulate RPC. That is a business need, since lazy developers want to keep thinking in objects and methods and it is too hard for them to think on messages and documents.
Now about Rest. SOAP is not more that a wrapper for a message. The real payload is in the body, and it may be whatever you want. Apart from the body, you have headers, that are optional, and you can use them to send along metadata. That’s it. You can now ask me why SOAP is called a Protocol, and I would answer: I don’t have a clue. It is not more that a simple wrapper structure.
Under this view, we can still think of a SOAP wrapped message as a message we all agree the external look. The payload is a private thing.
WSDL. Is it necessary? At least I recognize a couple of things we may need. For REST, we still need to agree about where the service is (the port address), the message flow, and most important the payload structure. WSDL gives that, and it is used only in the “handshaking”. It is like having two REST resources, one is the document that describes the service, and the service it self. The WSDL is that describing document, and you obtained it using a simple GET. The service is then known, a correct message constructed, and POSTed to the port address given by WSDL. Thus, I see REST not an antagonist to SOAP/WSDL, but those two may add some framework to REST. At the end of the day, REST is a way of work, not a technology, and it may adopt WSDL/REST as a couple of tools to make life easier. But first, we must get rid of RPC tools.... and RPC thinking.
William
I wanted to clarify a couple of lines, with the rest I agree plenty.
There are four possible combinations to create your messages: RPC/Encoded, RPC/Literal, Document/Encoded, Document/Literal. The first one is the original and the most constrained, and so banned due to interoperability problems and cost. The third one (Document/Encoded) makes no sense, since “encoded” means the parameters follow a predefined structure, and document has no parameters. Thus, the third one is not implemented anywhere.
That leaves us with RPC/Literal (the one for legacy programmers), and Document/Literal (the one for the right way to do WS). The problem is the tools, even when using document/literal, mask the document to simulate RPC. That is a business need, since lazy developers want to keep thinking in objects and methods and it is too hard for them to think on messages and documents.
Now about Rest. SOAP is not more that a wrapper for a message. The real payload is in the body, and it may be whatever you want. Apart from the body, you have headers, that are optional, and you can use them to send along metadata. That’s it. You can now ask me why SOAP is called a Protocol, and I would answer: I don’t have a clue. It is not more that a simple wrapper structure.
Under this view, we can still think of a SOAP wrapped message as a message we all agree the external look. The payload is a private thing.
WSDL. Is it necessary? At least I recognize a couple of things we may need. For REST, we still need to agree about where the service is (the port address), the message flow, and most important the payload structure. WSDL gives that, and it is used only in the “handshaking”. It is like having two REST resources, one is the document that describes the service, and the service it self. The WSDL is that describing document, and you obtained it using a simple GET. The service is then known, a correct message constructed, and POSTed to the port address given by WSDL. Thus, I see REST not an antagonist to SOAP/WSDL, but those two may add some framework to REST. At the end of the day, REST is a way of work, not a technology, and it may adopt WSDL/REST as a couple of tools to make life easier. But first, we must get rid of RPC tools.... and RPC thinking.
William
06/09/07 @ 19:10
Hi William,
Firstly I must thank you for giving me a deeper insight into WS_*. You speak of WSA which is a new term to me. I will be looking into this deeper.
We both agree about the limits of RPC. I had written SOAP off, but you seem to see value in the whole WSDL/SOAP thing.
Thanks to you I will suspend judgment and look into WS-* some more. I will be following your blog closely.
Thanks Paul.
Firstly I must thank you for giving me a deeper insight into WS_*. You speak of WSA which is a new term to me. I will be looking into this deeper.
We both agree about the limits of RPC. I had written SOAP off, but you seem to see value in the whole WSDL/SOAP thing.
Thanks to you I will suspend judgment and look into WS-* some more. I will be following your blog closely.
Thanks Paul.
06/10/07 @ 03:18
Hi William,
I'd thought you'd find this article interesting:
Does REST Need WADL?
http://www.artima.com/forums/flat.jsp?forum=276&thread=207471
Have fun!
Paul.
I'd thought you'd find this article interesting:
Does REST Need WADL?
http://www.artima.com/forums/flat.jsp?forum=276&thread=207471
Have fun!
Paul.
06/10/07 @ 16:41
Comment feed for this post
