Hi William,

This stuff is fun isn't it :^) So let's see now. We've got SOAP/WSDL. We've got REST( The architectural style) and HTTP (a REST-like implementation), and now we've added WADL to the mix.

Amongst this heady cocktail we need to keep a grasp of why we need all this stuff in the first place (if at all!). I am reading the WSA. First impressions are that it is long on what a Web Service should be , but short on why. I'm still keeping an open mind though.

Let's cut through the acronyms and get back to first principles. What we are talking about is messaging. Messaging comes in two basic forms: synchronous and asynchronous. Both REST and WSDL document style are both synchronous messaging systems.

With messaging, beyond the connector and the transport, the most important thing is the message representation. Neither WSDL or SOAP or WADL say anything about the message representation. It is the representation that makes the message meaningful. It is also the representation that makes the message and the service extensible.

These two posts by Roger Voss basically sums up my view:

Building Effective Enterprise Distributed Software Systems
http://humbleblogger.blogspot.com/2006/08/building-effective-enterprise.html

Building Effective Enterprise Distributed Software Systems
http://humbleblogger.blogspot.com/2006/08/building-effective-enterprise.html

I had the same ha-ha moment Roger describes in his first post myself when using Tuxedo at a large Telecoms vendor. Tuxedo is a synchronous message based distributed infrastruture, with a sophisticated message representation language known as FML.

My view is that plain old HTTP is sufficient for "document style" web services, period. What we need to focus on in my view is the representation of the document itself (XML, JSON, FML, meta-data, etc). In this regard WSDL/SOAP/WADL etc is just noise IMO.

I'm still reading the WSA so I may change my mind. And like always, I'm open to being convinced otherwise :^).

Paul.

Hi William,

I've got a bit further with the WSA:
http://www.w3.org/TR/ws-arch

It reminds me of some of the "specs" that came out of the OMG back in the day :^). It strikes me as mostly a political document as it contains very little technical substance.

Section 3 where they talk about stakeholders is a little more interesting. Read section 3.1 and I think you will agree that they take a slightly confused stance on what "SOA" actually is. Personally I prefer your definition, but according to the WSA, CORBA distributed Objects is a valid SOA approach.

It all sounds like a political fudge to me.

Section 3.2 is even more interesting, where they talk about technologies. After saying that the WSA is technology neutral they then go on and present an "illustration" that describes the "usual" WS-* technology stack (SOAP, WSDL, Discovery, etc).

With regards to REST in section 3.1.3, the WSA acknowledges that REST is an alternative style that can be implemented using a subset of the HTTP protocol. It seems that the reason why the WSA subscribes to the idea of a WSD and message envolopes, headers etc is because of the requirements of service discovery. This idea is expanded on in section 3.5.1 and in the conclusion of the document it is claimed that this difference "clarifies the relationship between Web services and REST".

So the answer is simple, if you plan to register your service in some public registry and rely on automated service discovery then perhaps WSDL/SOAP and "Web Services" as defined by the WSA has some value. If you do not however then REST is perhaps the way to go. Relying soley on manual "service discovery", REST is definately a simpler approach.

Today, as I understand it around 100% of people doing "SOA" and "Web Services" fall into the later group. So I think I will be sticking with REST for a while yet. As for "autonomous service discovery" - well I'll believe that when I see it :^).

Paul.

Hi William,

I guess you’re busy, but our discussion has got me thinking. I've found another interesting article on the web about WSDL/SOAP/Web Services and REST:

http://www.infoq.com/news/2007/06/w3c-ws-web-of-services-report

W3C as produced a report on the suitability of WS-* for enterprise development. One line in the report jumped out at me:

"Stop writing specs and start writing code!"

This line sums it up for me. Perhaps "Service Discovery" is the future, but one thing is for sure, we will never know until we write some code and see what works in practice.

As it stands now WS-* is a stack of paper specs. In my experience evolving a working system through real-world feedback is a lot more productive then trying to design everything up front on paper.

Thanks for having the discussion. It as prompted me to better understand the motives behind WS-*. What I think I have learned is that the motives behind WS-* are more admirable then I first thought. I just don’t think that WS-* will succeed with the current approach.

Thanks for your explanations and I hope you found this discussion as useful as I have.

Regards,

Paul.

Hi Again.
Yes, I was out cold busy, so I was away from
the blog for several days.

Basically, the report is very nice, althought not very deterministic. What I rescue from it is the note about the vendors influence. Here:

"Web services specifications include many concepts from the Web architecture and were originally designed to work well with Web technologies. However, the Web services specifications also included concepts and designs to work well with existing enterprise middleware technologies such as RPCs and MOMs, and the implementations of Web services have tended to gravitate toward those concepts and designs rather than toward the more Web friendly parts of the specifications. This is perhaps because implementations have in large part been done by the vendors of those existing technologies. It was noted that many implementations of Web services have created extensions or compatibility layers to the existing systems (e.g. in the Java world where Web services were implemented using API extensions of J2EE rather than system level APIs).

Web applications, on the other hand, can be integrated with enterprise applications using raw XML and hand coding of the XML processing. This results in the ultimate loose coupling and provides the most benefit for portability and interoperability, but it places more of the burden for handling the abstraction onto the developer. This tends also to be more like the way the Web works. However, as the presenters from Yahoo noted, developers often object to the additional work involved in raw XML processing, and ask for code generation tools like those available from Web services vendors."

At the end, I feel attracted towards the mixing of both worlds, the problem is the real world is based on vendors understanding of the specs. So, simply put, the problem is not in the specs, but in the implementations.

Lastly, I see everyone is talking about HTTP services. But WS "natural" communication is through messages, thus a message queue seems the normal way to go. hummm.

I will comment more about this report, is vey nice you pointed to it.

Thanks Paul!.

BTW. WSDL/SOAP is not just for service discovery. WSDL is just description, and SOAP is an extensible shell for controlling messages. All that is standardized, so security does not become a nightmare when implemented at the core.

William.

Hi William,

"At the end, I feel attracted towards the mixing of both worlds, the problem is the real world is based on vendors understanding of the specs"

Mixing? What like oil and water? The question is who do the specs serve? The developer community or the vendor community?

BTW. The standard HTTP application protocol provides a description of the service request in a kind. For example your network caching will be different for a GET then it would for a POST. The difference is that with HTTP this info is provided "out of band". With WSD etc the network infrastructure has to peak into the message itself (the WSDL) to get meta info.

I can think of a way of doing the same that would be Restful. For example why not by convention have a well known URI which represents the public name of the service? Similar to namespaces in XML. A GET at the URI would return the WSD for that service.

It seems to me that if the goals of the WSA were soley technical that they could have been achieved by extending the Web in a RESTful way (the web is RESTful by default). Instead they have attempted to replace the Web with XML/RPC centric technologies.

To me the reasons why this as occured are clear. And for me it is also clear that they will fail.

Paul.

Hi William,

Some more links. This site provides a detailed discussion of the issues I mentioned in my last post:

http://bitworking.org/news/

It's all from a REST perspective. In particular I found these two articles useful:

http://bitworking.org/news/125/REST-and-WS

And to see how to do "Web Services" Restfully:

http://bitworking.org/news/201/RESTify-DayTrader

Your point that it is all about messaging is spot on! So with a message the real issue is the formatting (representation). This is where developers need help and need standards. Take a look at FML (Tuxedo) developed in COBOL and C in the mid-eighties and you will see that the problem is not new, and that it can be solved elegantly.

Modern self describing message formats are things like JSON, XML-Schema, YAML etc. So my point is that we need tools to better support these formats. Fortunately the open source community have already stepped up to the plate :^).

The fact that the vendors have a bunch of XML/RPC tools for sale is just too bad!

Ok, I totally agree but in one thing. Mixing is not about oil and water. That is where everyone fails to notice. Bad thing is SOAP was an original RPC oriented thing. Good thing is SOAP can be used for non-RPC things, since it is just a wrapper with an extensible part. So, from where I see it, REST and WS are not antagonistic things. One is strongly based in Web and HTTP, the other tries to define standard wrappings and artifacts to abstract away complexity from the message sending. One relies on freedom, the other on extensibility. Rest says: I need to do a get of a document. The other say: I have a standard document format, that allows a payload that is whatever you may want. Rest says: I need to use Get and Post, the other says I support HTTP... and SNMP and whatever other protocol you may want. Rest says: I use document messaging, the other says I support messaging as documents, sadly I also support RPC and developers are eager to use that so vendors produce that. Speaking of which, Open source has not done anything good either. Jax-RPC, or Axis for instance. Axis has a sample for attachement messages that use 3 lines for RPC style, and 20+ lines for document messaging, plus supporting classes. So open source is also biting the RPC trade. Not good. I'm not a defendant of WS, but I fell bad to waste all that work and reinvent the wheel. What do you think?= William

Hi Wadmin,

I'm not William, and I don't want people to tire of what I've got to say. Funnily we are all in broad agreement. I respect your view, I guess I just don't see the benefit of mixing.

Please explain.

Hi Paul.

Sorry for the confusion. Wadmin is actually me getting to answer in the wrong user :-P.

The main idea is simple: I may hate RPC used for services, but I see some use of a standard wrapping for messages, and a high level description of services. We can get rid of the fat, I'm happy to point out where to cut.

As Yahoo and Amazon folks mention in their conferences, most people will use their REST based WS simply because they are simple to use. Although it requires manually coding the message parsing, they find it easier to use the RPC/Encoded cousin. But I bet that if I publish those same things using Document/literal, and I send an example of the SOAP message to developers, they will perfectly do the work as REST.

Now, what enterprise guys fear is that we create services whose spec and definition is told on the phone. That is, if developers dies, nobody knows how to work with the message if it changes. So, they want a way to describe the message using a description language. They will ask for it. And then somebody will create one to use in REST and voila! We have another WSDL. I would say: we need to keep an eye of what Axis, and other vendors are proclaiming RESTfull WS they support, it may be just another RPC without SOAP.

William.

Hi William,

OK. So you like the idea of a " service description" in XML. So what is wrong with this:


GET ../service/description


?

The advantage of the WSDL tools are code generation and RPC as I understand it. For "document/literal" you still need to format your message and the tools do not help. Also your message is constrained to XML formats because it needs to exist in the body of the WSDL.

So where is the benefit?

Hi Again.

Yes, I think the service description is a must, and that one should be machine readable. Actually you are right with the example. The

"GET ../service/description" is perfectly fine. If we all agree to use the same URI, then it can be a de facto standard. The same result is obtained by issuing:

GET http://domain/service/endpoint?WSDL

You are also right about the need to manually parse the document, although at least its schema is detailed in the WSDL. Same is required for any other format.

Thus, my main point is: we have WSDL, do not throw it away just because its bad name, let see if it can be used :-)

William.

Hi William,


OK. So we've got:


GET ../service/description


But, let's asume that I'm no that interested in a service description. What happens when a client requests one?

RESPONSE: Http Error 404 File not found.


So The description becomes optional. This is my point, why not extend the web rather then replace it? Demoting HTTP to the role of transport make no sense to me. HTTP is an application protocol. TCP is the web transport.

I think you are saying well we've got the WS-* specs so why not try and make them work?

What I'm saying is, forget the specs and stick to what works.

Time will tell, some people are using WS-*, but a growing number of people are busy creating web mashups using http.

Both work, and has you have pointed out, both can be message based. I guess it just comes down to design instincts.

I'm a strong believer in YAGNI (you ain't gonna need it) and iterative, exploratory design. I like to keep things simple, and extend as needed. I avoid built in complexity at the outset that doesn't add immediate value.

There will be use-cases where RPC is the ideal design choice. There will also be use cases where WSDL/SOAP-document/literal is ideal. But for many plain old HTTP is simplest, extensible and does the job.

The simplest thing that can possibly work? :^)


You're an Architect, I'm a Programmer. Is it surprising that we see things differently?:^).

Thanks for the chat.

P.

Thanks to you, Paul!.

Yes, architect-designer-programmer shouldn't think different, but I guess that's the way it is. I use to think generalities, you know.

I expect to read you in other chat about another rich discussion. A pleasure.

William.