InfoQ: Your blog post "S stands for Simple" has been linked to by literally every blogger in the SOA/WS community. Can you give us a little background on yourself? How much of what one can read in that post is based on personal opinion, in other words: have you been "SOAP guy" in the past?
Pete Lacey (PL): Yes, I have been SOAP Guy in the past, and am in fact SOA (note, no ‘P’) Guy now. I was introduced to web services late, when I started working for Systinet back in August 2002. I started there as an SE, but given its startup nature, the job was really all things technical and outward facing; that is, sales, marketing, and consulting. In the beginning the work was pretty low-level, down in the dirt with SOAP, WSDL, and UDDI. In that sense, I was SOAP Guy. Interestingly, my customers never played the role of the disenchanted developer, they never pushed back on the complexity of SOAP/WSDL or the abuse of HTTP or anything that tends to rile certain people’s feathers. Though they did gnash their teeth at the interop issues.
Today I work as a consultant for Burton Group in the Application Platform Strategies service. Though SOA is not all we do, it is one of the things we’re famous for, so I spend a lot of my time explaining to people what SOA is and how they might go about managing a SOA initiative. It may sound hypocritical, since I’m not a SOA proponent, to turn around and tell my customers how to go about it. But by the time I’m involved the SOA decision has often been made, and Burton Group does have a more sober perspective on the technology than most vendors do.
InfoQ: Can you briefly explain your position about SOAP and the WS-* specifications?
PL: Taking the SOAP 1.1 specification in isolation, my position on it is that it went too far. Had SOAP simply defined an envelope for XML message passing it would have been a small but interesting step forward. But the SOAP spec also defines an—admittedly optional—serialization mechanism; goes out of its way to be transport neutral, but then defines an HTTP binding that ignores the basic tenets of HTTP; and goes on to define a practice for using SOAP as an RPC mechanism. However, if one ignores the optional bits, SOAP itself isn’t that bad. The envelope design pattern can be useful—HTML uses it after all.
In contrast, I have nothing good to say about the WSDL 1.1 specification (I’m sticking with the 1.1 specs as those are still the WS-I recommended versions). It is overly complex, often ambiguous, and occasionally inconsistent. In practice, tool-generated WSDL documents are nightmarish to read and the source of half of all interoperability issues (and I’m not referring to any XML Schema components). It’s also my position that WSDL is being used as a crutch by web service vendors and developers, even though the functionality it provides should be wholly unnecessary.
InfoQ: Can you elaborate? Isn’t the “contract” described in WSDL the most important aspect of a service? Why do you deem this unnecessary?
PL: Well, I would say that the most important aspect of a service is the service itself. Also, today’s tools encourage—and some mandate—developing the service first and then generating the WSDL, and thus the WSDL isn’t a contract at all. But I understand the question, so here goes.
SOAP enthusiasts are aghast at the claim that WSDL is unnecessary, but it’s true. They claim that the server isn’t returning HTML for humans to read and interpret, it’s returning XML for machine to machine processing, and how can this work if the client machine doesn’t know what the server is sending. But I claim the client doesn’t “know” anything. It doesn’t know that the message is an invoice, only people know what an invoice is. It doesn’t know that the FirstName element isn’t likely to have the value “Tea Kettle” (barring very strange parents). All we can say it “knows” is the structure of the document and what datatypes the elements and attributes can hold.
But, WSDL proponents go on to say, what about code generation and data serialization? A crutch, I say, and not a very beneficial one. I’ve never cared for wizard driven development and code generators. They tend to demo well, but ultimately don’t produce maintainable code. Furthermore, this style of SOAP development reinforces the SOAP as RPC/distributed-component/serialized-object perspective and relegates XML to just another serialization framework. The generated code tends to be especially brittle, and breaks when the message returned changes in any way. For instance, if your client was happily consuming a message that looks like this:
Star Wars 1977
Why should it choke if the message changes to this:
Star Wars 1977 121
For similar reasons, the fact that SOAP messages are strongly typed also introduces a great deal of tight coupling between endpoints and inhibits the independent evolution of services and clients. Serialization also exposes the impedance mismatch between XSD and your programming language of choice (and what about dynamically typed languages?) and is the source of the other half of all interoperability problems. Finally, serialization techniques preclude the use of powerful, XML-centric tools like XPath and XSLT. You would be much better off processing a message manually and ignoring any notion of typed data.
Proponents also say that WSDL and XML Schema are useful for message validation, but if an XSD validator is even in the message path, no one turns it on, because it’s too computationally expensive, not completely implemented, and unable to perform all the validation required (e.g., date X should be no more than 30 days divergent from date Y).
All of this is not to say that a rigorous, machine-readable description of an XML message isn’t useful at development time and even runtime, it is. But the notion of assigning type to elements and attributes is unnecessary. After all, how many HTML forms have been processed successfully, and those are submitted as just name/value pairs. And even when a message description is available, using it to generate code that treats remote resources as local objects and messages as their serialization is counterproductive. XML is for representing structured information not serializing objects.
Ultimately, WSDL proponents will say, we simply need it; CORBA has IDL, RMI has Java interfaces, surely we need something. Well, no you don’t. Think about coding to a local API in a language like C/C++ that doesn’t allow for introspection. How do you make that work? You read the documentation! And this is true for ordinary Java development and web service development too. Real live human programmers are involved; reading the documentation, crafting messages as specified, and interpreting them as needed. It’s not like a programmer uses the first method that her IDE suggests, and simply drops properly typed nonsense into the argument list. There’s no doubt that having a machine readable description of a service can make your IDE do interesting tricks, but that’s a far cry from absolutely essential.
A final argument for not needing WSDL requires that we abandon the SOAP model of development in favor of REST styled development. We’ve already dispensed with the desire for message description, with REST we can also dispense with the portType, because all of the operations are well known. Similarly we don’t need the binding section anymore; the transport is always HTTP and messages are described by the Content-Type header. The service element is unneeded too, because the URL of a resource should be relatively static and well known, and if it changes you’ll get a redirect.
To dwell a bit more on XML Schema, I have to say that it is a deeply flawed specification. Not only is it notoriously complex and inconsistently implemented, it is fundamentally incapable of representing textual XML documents, as opposed to XML documents representing typed data. And even for representing data it leaves much to be desired. Burton Group is soon to publish a best practices document I wrote for creating interoperable, data-oriented schemas, but I can summarize it here: don’t use anonymous types, don’t use element groups, don’t use attribute groups, don’t use redefine, don’t use “any” elements, don’t use anyAttribute, don’t use anyType, don’t use lists, don’t use unions, don’t use substitution groups, and so on. So, not only is the ability to create typed instance documents of dubious value, XML Schema isn’t particularly good at doing it. If you want to use a schema language, use RelaxNG or Schematron instead.
InfoQ: What do you think of the XML Schema Patterns for Databinding spec? Does this address the same concerns as your report?
PL: Not really. I think the Patterns for Databinding is a noble effort and it takes an interesting approach. And down the road it may even help vendors converge on a usable subset of XML Schema. My document, though, is aimed at the user of today’s XSD-aware tooling. It goes much further than warning you away from the poorly supported aspects of XSD, but talks about namespace usage, versioning, RDDL, and much more. But even if the Patterns for Databinding effort ultimately results in XSD documents being 100% interoperable, you must remember that the problem—for web services, anyway—isn’t the inconsistent implementations of XML Schema, but the use of XML Schema at all.
InfoQ: What’s your opinion on UDDI, the third of the core web service specs?
PL: I find it grossly over-engineered, what with tModels and bindingTemplates and categoryBags. Succinctly, anything that requires a design pattern to achieve the predominate use case for which it’s deployed has failed. By that I’m referring to the best practice surrounding mapping a WSDL into UDDI. It’s the single most obvious task to which UDDI can be put, but UDDI can’t do it natively or easily. Even the relative success that Systinet (now HP) is enjoying with its registry is largely due to hiding as much of UDDI as possible.
InfoQ: And the rest of the WS stack: WS-Addressing, WS-Security, etc.?
PL: I won’t address all of the WS-* specs individually, and individually they are not all that bad. Collectively, though, wow! I mean, WOW!
The complexity of the web service framework (WSF) is mind numbing. The odds that even a small portion of it can be made to work in an interoperable fashion across multiple vendors is very slim. (Two very large software vendors recently told me that while they will eventually interoperate with the forthcoming Microsoft implementation of a number of the WSF specs, it will not be by coding to the standard, but to the Microsoft-specific implementation.) And the claim that your tooling will shield you from the underlying complexity is laughable; the complexity will leak through. This is not to mention the (now dwindling) vendor wars, the ungodly amount of time its taking to move these specifications forward, the dearth of implementations, and the “SOA fatigue” experienced by enterprises as they try and make a go of it.
To try and put a positive spin on the WSF, one can look on it as the XML-ification of a number of existing technologies. For instance:
Standard/Spec maps to
WS-Security SSL (partly)
WS-SecureConversation SSL (the rest)
WS-Trust Kerberos
WS-Addressing URLs
WS-ReliableMessaging MOM
WS-Addressing URLs
WS-Eventing/Notification More MOM
WS-Policy Configuration files
WS-Transaction XA
WS-Transfer HTTP
WSRP Portlets
WS-Management/WSDM SNMP
Now, of course, that mapping is not exact, but it’s interesting. If, in the past, someone had said, “I’m tired of having proprietary implementations of message-oriented middleware.” Or if they had said, “you know, using XML instead of opaque, binary protocols opens up some interesting possibilities,” then we would, quite possibly, have been on to something. I don’t think it would look like WS-Anything, since the WSF composes different messaging styles in the SOAP Header, rather than in a layer underneath the message. Nor would a single system try to be all things to all people. In this model, XML-based protocols would be as distinct as their current binary counterparts. Mind you, I’m not advocating such systems, only that I find the idea interesting. But, as Mark Pilgrim said, “Lots of luck with that.”
It's important to understand that my imaginary infrastructure and the current web service framework, suffer from the same problem: they can’t scale. And by that I don’t mean transactional scaling, e.g., how many messages can it process, but rather, to use Dan Pritchett’s terms, I mean operational scalability, deployability, developer productivity, and time to market. So, while web services and the components of the WSF can and have been made to work, these successes (in my experience) are narrowly scoped deployments with tightly bound endpoints that took an inordinate amount of time to develop while promising little in the way of interoperability and raising the barrier to entry way too high.
InfoQ: If I understand you correctly, you’re referring to scaling to Internet dimensions. But not everybody needs that, do they?
PL: It’s true that the WSF prohibits scaling to this level, but, no, that’s not what I’m talking about. Again, when I say “scaling” I’m referring to things like developer productivity; system management, maintenance, and evolvability; access to data and resources, etc. As I see it the WSF is so large and complex, and the participants so tightly coupled, that scaling to even enterprise levels is out of the question. I firmly believe that one can be every bit as successful today with web services as they have been in the past with CORBA. That is, you will be able to build working systems with some distributed components (although not without undue hardship). But you will not be able to use this technology to build a fully distributed enterprise architecture.
InfoQ: Do you think the philosophies of the different "camps" - SOAP/WS-* folks on one side, REST folks on the other - can be aligned somehow?
PL: No, but that’s okay. From a technology point of view SOAP and REST couldn’t be farther away from each other. In fact, the only relationship I can see between the two is that REST is embodied in HTTP and SOAP frequently tunnels over it. I might add that SOAP supports XML message passing (in principle) and REST can pass XML messages too, but as someone said recently (I can’t remember who), message passing is intrinsically uninteresting.
But if the question was “can the SOA and—what I guess we’re now calling—ROA camps be aligned?” that would be a more interesting question. The answer is still no, but it’s a more nuanced no.
The SOA camp claims that one can achieve enterprise (and some claim global) scalability using the WSF. I think this fails for two reasons: one is simply the complexity of the framework as already discussed. It has proven hard enough to get SOAP and WSDL based services to work and interoperate. It’s only going to get harder as the other pieces of the WSF come into play. Introduce any number of intermediaries into this mix, and you’re building on a house of cards. Also, no one gets to play unless they are a proficient, web service aware developer.
InfoQ: Tool vendors would disagree and point to their IDEs, which are claimed to make Web service development ridiculously easy.
PL: I think we’ve already covered how effective this development tooling actually is, but even accepting it for what it is, you’re still limited to just developers. Given that the value of web services is in the consumption, why aren’t they consumable by anyone? Why aren’t services made available to the sales guy with Excel, or the proto-geek in finance with a report writer, or the manager with a news aggregator, or the simply curious with a browser? Because SOAP, WSDL, and the WSF are way beyond any but the technically elite; the barrier to entry is too high. In contrast, anyone can retrieve the contents of a URL.
InfoQ: Let’s get back to the second reason for the alignment problem.
PL: The second reason is that web services are too tightly coupled. Each participant needs to know a great deal about each of the others: the service and operation names, the messages they exchange, the datatypes of the message elements, the security context, the messaging semantics, etc. Thusly are non-scalable (and again I don’t mean transactional scalability) systems designed. One could argue that WSDL and the WS-Policy family of specifications addresses all this, but that’s not what I mean. Whether the tool knows or the programmer knows, the point is that one side of the conversation possesses intimate knowledge of the other, and should either side change, everything breaks.
This is not to dismiss SOA altogether, just to take it down a peg. I don’t believe it can scale and it’s not a silver bullet, but, as I’ve said, it can be made to work if you introduce enough constraints. And such a system is likely to offer functionality that exceeds what can be had using traditional technologies. For instance, if reliable messaging is an absolute requirement of your design, and there are multiple actors, and you’re only exchanging XML messages, then using SOAP+WSA+WSRM, instead of, say, TIBCO Rendezvous, makes sense (once WSRM is finalized and enough interoperable implementations exist—see what I mean), as it allows for the introduction of generic intermediaries that can process and manipulate the messages in transit. Also, much of what is SOA is not technology focused. SOA proponents have a lot to say about process and governance, and much of that is transferable to any team building distributed architectures.
Furthermore, REST/ROA is not all encompassing (and to the best of my knowledge, no one claims it is). There are a number of legitimate enterprise use cases where REST styled systems don’t play, but these are fewer than one would imagine. It all boils down to choosing the best tool for the job.
InfoQ: What would be your advice to someone looking to implement an SOA today?
Read this.
Bookmark Digg+ , Reddit+ , del.icio.us+ Tags SOAP, Web services, WSDL, REST
31 commentsReply
Bold claims... no data by Steve Jones Posted Dec 12, 2006 6:24 AM
Re: Bold claims... no data by Dan Pritchett Posted Dec 12, 2006 8:20 AM
Re: Bold claims... no data by Peter Lacey Posted Dec 12, 2006 8:29 AM
Re: Bold claims... no data by Paul Fremantle Posted Dec 12, 2006 10:20 AM
Re: Bold claims... no data by Peter Lacey Posted Dec 12, 2006 10:50 AM
Re: Bold claims... no data by Eric Newcomer Posted Dec 20, 2006 2:39 PM
Re: Bold claims... no data by Jean-Jacques Dubray Posted Dec 12, 2006 11:15 AM
Re: Bold claims... no data by Peter Lacey Posted Dec 12, 2006 12:05 PM
Re: Bold claims... no data by Jean-Jacques Dubray Posted Dec 12, 2006 5:37 PM
Re: Bold claims... no data by Jim Thomas Posted Dec 12, 2006 6:10 PM
Bold claims everywhere by Stefan Tilkov Posted Dec 12, 2006 12:10 PM
Re: Bold claims everywhere by Jim Murphy Posted Dec 12, 2006 1:09 PM
Re: Bold claims everywhere by Stefan Tilkov Posted Dec 12, 2006 3:56 PM
Re: Bold claims... no data by Steve Jones Posted Dec 13, 2006 4:22 AM
WSDL + XSD -> Similar feelings, different conclusion by Aaron White Posted Dec 12, 2006 11:36 AM
Re: WSDL + XSD -> Similar feelings, different conclusion by Peter Lacey Posted Dec 12, 2006 12:21 PM
Re: WSDL + XSD -> Similar feelings, different conclusion by Aaron White Posted Dec 12, 2006 1:03 PM
The XML "example" by Steve Jones Posted Dec 13, 2006 4:31 AM
Re: The XML "example" by Jim Thomas Posted Dec 13, 2006 9:31 AM
Re: The XML "example" by Mark Baker Posted Dec 13, 2006 11:03 AM
Re: The XML "example" by Steve Jones Posted Dec 14, 2006 5:34 AM
Re: The XML "example" by Peter Lacey Posted Dec 13, 2006 11:06 AM
Re: The XML "example" by Steve Jones Posted Dec 14, 2006 5:36 AM
Re: The XML "example" by Stefan Tilkov Posted Dec 14, 2006 7:29 AM
Re: The XML "example" by Steve Jones Posted Dec 14, 2006 8:33 PM
Re: The XML "example" by Fergal Somers Posted Dec 17, 2006 4:35 AM
I'm getting tired of SOA == SOAP by Olaf Bergner Posted Dec 14, 2006 6:48 AM
Re: I'm getting tired of SOA == SOAP by Stefan Tilkov Posted Dec 14, 2006 7:33 AM
Re: I'm getting tired of SOA == SOAP by Olaf Bergner Posted Dec 14, 2006 8:18 AM
Re: I'm getting tired of SOA == SOAP by Stefan Tilkov Posted Dec 14, 2006 3:35 PM
Re: I'm getting tired of SOA == SOAP by Olaf Bergner Posted Dec 14, 2006 3:55 PM
Sort by date descending
Back to top
Bold claims... no data
Dec 12, 2006 6:24 AM by Steve Jones
"InfoQ: If I understand you correctly, you?re referring to scaling to Internet dimensions. But not everybody needs that, do they?
PL: It?s true that the WSF prohibits scaling to this level, but, no, that?s not what I?m talking about."
Any data on how WSF "prohibits" scaling to that level, I've seen an awful lot of bland claims like this recently but without the actual data to back it up. A pointer to the many massively successful REST commercial implementations and the many massive failures of WS would help.
Now personally I don't care two hoots which one wins, we just need _one_ that everyone agrees on, and I agree that SOA works no matter what the IT infrastructure is, but if REST is to actually win it would be nice to do it based on facts and examples rather than rhetoric.
Reply
Back to top
Re: Bold claims... no data
Dec 12, 2006 8:20 AM by Dan Pritchett
We don't just need _one_ that everyone agrees on. That's the reason we have these on going debates. Different problems, different solutions. REST isn't perfect for all problems, neither is SOAP.
I'd be more curious to see how many true WS large scale successes there are. People seem to be using the subset that lets them get their jobs done. Claiming a small subset of WS-* adoption as an overall WS win is a bit of hype as well.
Reply
Back to top
Re: Bold claims... no data
Dec 12, 2006 8:29 AM by Peter Lacey
Steve,
I know you won't find this argument legitimate, but here goes. Since REST is based on the exact same principles as the Web, and the Web has proven beyond all doubt to be Internet scalable, therefore REST must be Internet scalable. In contrast, since SOAP web services are modeled after distributed object systems, an architectural style that has proven to not scale beyond the enterprise (and I'm being generous), therefore SOAP web services can't scale to Internet dimensions. QED.
I admit that we are not tripping over RESTful web services, but then neither are we tripping over SOAP web services. I think the pessimism I and others exhibit around SOAP is based on how little progress has been made with SOAP WS despite the millions of dollars and thousands of man-hours invested. It's time for the other guy to have a shot. I'm betting he succeeds.
Reply
Back to top
Re: Bold claims... no data
Dec 12, 2006 10:20 AM by Paul Fremantle
This is a great argument Peter. Unfortunately its completely bogus. Most websites are not built according to REST principles. They scale well because many engineers work very hard to make them scale. And also you are looking at the websites that do scale. There are plenty that don't. That doesn't mean that REST doesn't scale.
Similarly there are plenty of SOAP services that scale. For example, I believe that eBay processes 40 million SOAP requests a day. I'd call that scaling. Similarly Yahoo Mail is based on SOAP calls and must be handling a similar number.
Finally, its wrong to sayt hat SOAP is modeled after distributed object systems. SOAP may have been designed as a replacement for those, but the SOAP1.2 and WS-I profile expunged all of those features. SOAP is just an XML messaging model and scales as much (or as little) as any messaging model does.
Reply
Back to top
Re: Bold claims... no data
Dec 12, 2006 10:50 AM by Peter Lacey
Paul,
I was very careful to make the distinction between transactional scaling and process scaling. I have absolutely no doubt that one can build SOAP-based systems that can process all the messages it needs to. Where SOAP web services fail to scale is along most of the other dimensions: developer productivity, operations, deployability, etc. In the context of Internet scaling I will add evolvability and reach. REST styled services are inherently available to anyone, they can evolve with minimal impact to the client, and they can be fully integrated into the Web as we know it. When I say that SOAP web services can't scale to the size of the Web, that is what I mean.
It may be true that SOAP has evolved on paper to being just another XML messaging system, but so long as the tooling (IDEs, platforms, intermediaries) continues to generate proxy objects, treat XML as a serialization mechanism, and pretend that the network doesn't exist, SOAP is still walking and talking like a distributed object system.
Reply
Back to top
Re: Bold claims... no data
Dec 12, 2006 11:15 AM by Jean-Jacques Dubray
+1, what has changed architecturely is the emergence of the "request" over the "method". Distributed systems are based on the premise of providing distributed access to "an object".
Web systems are built to process requests. The "thing" that processes request is a sometimes called/identified as a service.
More generally Peter, I think your entire argumentation is old and belong to this strange category of behavior of the software industry that I call "generalism". I have often noticed (and occasionally had to fight) that software engineers generalize way to easily the occurence of a particular pattern or concept. I don't know why. Physics from Newton to Einstein should have made it clear that generalization only applies to a "context", there is hardly any universal, except the arbitrary.
The question that is IMHO important what problem are we trying to solve (agree on that) and then decide what solution is best adapted to solve a particular problem without suffering from "generalism".
SOA is (painfully) creating a new application model where "distribution" is the norm, or rather "connectivity" is the norm rather than monolithism. Connectivity is different from distribution. The fact and the mater is today you can't build a system in isolation of its environment. The question is how you can do that? Building a monolithic system we know how to do, building a monolithic system that scales we also know how to do. Building connected systems is different. Sometimes, REST is just fine and applying a REST solution to a REST problem is a great architectural decision. Now can REST be used to build composite information systems? yes? good luck.
Now you can argue that the complexity (or poor design) of the WS-* stack is neither applicable to building this kind of systems, maybe. Having my name on a few standards does not bind me to a community that has most often discredited itself by its "individualism" than shined by stellar designs. But thinking that connected systems is a "simple" problem is naive and misleading. I would recommend that when you promote a solution, you also promote the context in which it is applicable. Of course, that is the hardest of both exercize. Ever hammered a screw?
JJ-
Reply
Back to top
WSDL + XSD -> Similar feelings, different conclusion
Dec 12, 2006 11:36 AM by Aaron White
Peter,
I enjoyed reading your criticisms of WSDL/XSD. I respectfully disagree with some of your conclusions. I work for a company called Mindreef, a Web services testing company, and co-authored our dynamic invoke forms. Clearly, such tooling benefits enormously from the WSDL/XSD...up to the point of types on the elements. Enums and booleans aside, the STRUCTURE of the message is far more important than writing greatly nuanced restrictions on element content. On this point, we agree.
I also agree that when authoring a Web service, manually processing the XML is the way to go, as it is more maintainable, and far more amenable to processing the constructs schema can specify, and being adapted to changing contracts over time
Taking the time to author the XSD gives testers and developers a contract to rally around, and enables tooling such as ours, enabling more rapid development, testing, prototyping, better human-documentation, and so on. Further, I believe toolkit generated clients are 'OK' (though should be re-architected in such a ways as to be robust in the face of changes, but we are uncovering these best-practices via these growing pains. Subtyping is nothing new, just being rediscovered. I agree that these problems do in fact come from the mismatch of XML documents to 'Objects')
Finally, XSD validation is useful for both developers, testers, and support staff to quickly highlight some of the most common interoperability problems, ensure corporate compliance, or compliance to XSD defined industry standards, etc...
Just because WSDL and XSD are gnarly, why throw the baby out with the bath-water?
- Aaron
Reply
Back to top
Re: Bold claims... no data
Dec 12, 2006 12:05 PM by Peter Lacey
Jean-Jacques,
I think your entire argumentation is old...
Don't I know it. I was just answering the questions that were asked, however.
To your main point: Neither I nor any REST proponent I'm aware of argues that REST is a suitable architecture for all needs, even all the needs commonly expressed in networked systems. Nor do I think that creating composite systems is a simple problem. But there's a difference between complex and hard, simple and easy. At all times we must strive for simplicity, even if that is hard to do.
Most of what I had to say was related to the complexity of SOAP and the web services framework, and how this complexity plus the tight coupling of the underlying architecture make for distributed applications that are difficult to develop, maintain, and interoperate with. It will work, it will even solve problems that REST ignores. But (IMHO) it will work only on a limited scale, even as its promoted as the foundation for a complete enterprise architecture. If your requirements are broad accessibility, integrating with existing Web infrastructure (not just caches etc., but the desktop solutions that are widely in use - try IM'ing a WS-Addressing endpoint reference to someone), extensible and evolvable systems, then a REST-styled architecture is where you should be leaning.
And as you and I agree, one should choose the right tool for the job.
Reply
Back to top
Bold claims everywhere
Dec 12, 2006 12:10 PM by Stefan Tilkov
Paul, I'll call your argument completeley bogus as well, just to be fair :-) There are likely more RESTful Web services than those based on SOAP 1.2, since most WS stacks still prefer SOAP 1.1. AFAIK, the WS-I Basic Profile 1.1 (and even 1.2? not sure) still embrace SOAP 1.1.
The Web is RESTful to a significant degree because it's a) largely read operations and b) uses lots and lots and lots of URIs (e.g. every book on Amazon has its own URI). True, the Web doesn't use PUT and DELETE much in practice, but I strongly estimate URIs are used RESTfully with POST and GET semantics about 1000 times more than they are being used as SOAP endpoints (on the Web, that is).
Reply
Back to top
Re: WSDL + XSD -> Similar feelings, different conclusion
Dec 12, 2006 12:21 PM by Peter Lacey
Aaron,
First, though I haven't used it in a while, I love SOAPscope. Good work.
From your comment, I think you're saying that just because WSDL and XSD are abused doesn't mean we shouldn't use them. If so, and in the context of SOAP services only, I agree. Sure, if there were a "better" WSDL, I would be happier. I can certainly see how tooling benefits from a service description.
Regarding message definitions, I think we're on the same page. As I said in the interview, there's a benefit to having a rigorous description of the information passed between systems. I just don't think XML Schema is up to the job, far better would be Relax or Schematron. And I also think that today's tools are making more brittle systems than necessary. But WSDL and XSD are the devils we're stuck with, so, if your developing SOAP services, try and keep your tooling in check and make the best of it. Shame, though.
Reply
Back to top
Re: WSDL + XSD -> Similar feelings, different conclusion
Dec 12, 2006 1:03 PM by Aaron White
They are definitely the devils we are stuck with, and it is a shame. I could liken it to the damage one can do in C if abused, and personally I wish were all coding in ML! But I do expect the WSDL/XSD adoption to go through some similar growing pains as the early web did w/ HTML/HTTP. Do we really use all the HTTP verbs , and for the ones we do use, do we use them in the way they were intended? We've 'evolved' into some simple common practices, and the web is humming along nicely. WSDL/XSD will go the same route.... Committee-ware doesn't bear fruit easy, but that might be the price of interoperability.
Reply
Back to top
Re: Bold claims everywhere
Dec 12, 2006 1:09 PM by Jim Murphy
1. The WS-I Basic Profile 2.0 will address SOAP 1.2 . From our experience nobody but Microsoft projects using WCF to WCF.
2. I've never met anyone who has implemented a real REST style service. Most web sites I've seen use a handful of urls often of evolving and gnarly format, tons of server state in session and DB, adding over plenty of poorly documented url params that really dictate the resource in question. I'm not knocking REST I've just never seen it done in the architectural purity that you would be led to belive.
Jim
Reply
Back to top
Re: Bold claims everywhere
Dec 12, 2006 3:56 PM by Stefan Tilkov
My favorite example (currently at least) is the Blinksale API.
Reply
Back to top
Re: Bold claims... no data
Dec 12, 2006 5:37 PM by Jean-Jacques Dubray
Peter:
if we agree, I would recommend that "put to rest" this now antiquated and rather stupid debate of "soap" vs "rest". It would be far more efficient to focus everybody's attention where each stack works best and what are the usage patterns for each technology in their own context.
The WS-* stack was developed in the most cahotic fashion. It deserved everybody's interest including the vendors and by far the interest of the customers/users. BPEL 2.0 is not out yet, how smart is that? who wins? WS-TX went through 3 iterations since 2001, who wins? Now the WS-* is what it is, could it be simpler? maybe, is it that bad? not to the point where it is not usable. SCA fixed one of the major issue in the stack.
Now, I think that the problem that you are really talking about is MDD. Is MDD the right approach in general or not? What the WS-* stack underlying metadata approach ignores is that it is MDD, and thus is creating a wave of metadata that needs to be managed to be effective (tools, repository, versioning, ...) of course you have to complain about how painful and complex this looks like. Again, anybody entering the SOA world without a metadata management strategy compatible with their infrastructure of choice would probably rapidly face a wall. That has nothing to do with the architecture of WS-* itself.
I have written several articles on the "SOA" stack, not just WS-* if you care to read one of them.
www.sap.info/index.php4?ACTION=noframe&url=...
you might appriciate the order behind the chaos.
JJ-
Reply
Back to top
Re: Bold claims... no data
Dec 12, 2006 6:10 PM by Jim Thomas
www.sap.info/index.php4?ACTION=noframe&url=...
I don't see much of anything in that article. Looks just like more fodder for the wolf tickets.
Reply
Back to top
Re: Bold claims... no data
Dec 13, 2006 4:22 AM by Steve Jones
Pete, I am tripping over SOAP web services. In the last two weeks alone I've been advising 3 different companies on how they work with external entities, in not one case did I suggest the use of WS-*, but in every case they had already selected it as it was the only solution that all parties agreed upon. Those 3 companies I dealt with are in total dealing with 15 external parties.
Saying that "its time for the other guys to have a shot" is classic IT ADD, WS has in terms of "prime time" been around for only 3 years now (I know when I did WS in 2001 I was a renegade maverick against the EAI crowd), and its completely bizarre to claim that in three years it hasn't progressed enough.
How about for a change IT doesn't go "oooh shiny string" and actually concentrates on getting ONE solution we all agree on for what is easily the least important part of a project these days, namely the actual shifting of XML docs from A to B to achieve a business goal. Its the goal that is important and the XML shifting that should be commoditised. It is not time to give the other guy a chance, its time for us to start focusing on real business value rather than our views of technical excellence.
And you are right :) I don't (as someone who has built quite a few commercial websites) consider "the Web" to be a REST reference :) I would say (and its at least true in the systems I've architected) that modelling WS systems around distributed objects is a bad move, you should be modelling them around distributed services and a service != an object.
Reply
Back to top
The XML "example"
Dec 13, 2006 4:31 AM by Steve Jones
"
Star Wars
1977
Why should it choke if it gets
Star Wars
1977
121
"
I'm confused if the Runtime field is optional and using an XML parser which marshalls/unmarshalls only the fields required... why would this break WSDL based services? If the XSD has changed to include the new non-mandatory field then the schema validation will pass. Your argument appears to be that XML parsers can't handle the addition of non-mandatory fields rather than an issue with WS-*.
That is a pretty easy problem to fix and I know that some of the XML marshalling stuff I've written back in the days using SAX and XPath would have handled this fine. And this is before you put mediation in, which makes even more complex changes solvable.
Of course it the field is mandatory and important then of course it should choke as a client that doesn't process that field might be doing something very very bad (e.g. if the extra field was "will get arrested if you watch this")
Not an issue... please move on.
Reply
Back to top
Re: The XML "example"
Dec 13, 2006 9:31 AM by Jim Thomas
I think it is an issue because it represents an additional layer to maintain. It may not cause the ground to shake (like the 1000's of specs in that poster ;)), but it represents a pro on one side and a con on the other.
Reply
Back to top
Re: The XML "example"
Dec 13, 2006 11:03 AM by Mark Baker
"If the XSD has changed to include the new non-mandatory field then the schema validation will pass"
What about software that hasn't yet been updated to this new schema? See;
www.coactus.com/blog/2006/12/validation-conside...
Reply
Back to top
Re: The XML "example"
Dec 13, 2006 11:06 AM by Peter Lacey
First, this is not a problem with SOAP per se, but a problem with the tooling. Many of the issues I raised can be avoided by keeping the tools in check. It's more work for the developer, but it pays off in the end.
The reason this change to the message tends to break client code is that the client was likely built from a schema that didn't include the
element. But now the service and the schema have been updated to include this field, it's even been made optional. But the client hasn't been rebuilt. So when it makes its getMovieInfo() request it gets back 3 elements when the serialization code and the generated proxy object were only expecting two. Result: blam! That's why I say that code generation and serialization techniques make clients and services too tightly coupled. Again, not a fault of SOAP, but the way it's commonly practiced.
Reply
Back to top
Re: The XML "example"
Dec 14, 2006 5:34 AM by Steve Jones
Doesn't that depend on how the schema association is done? If the generation is 100% static then there is an issue, if however the validation is done based on the schema referenced in the XML document then there will not be an issue.
Sure if the XML doc has changed so the structure doesn't match then there is an issue, but that is a different use case.
And I think we are going to agree to disagree on the validation point validation up front works for me.
Reply
Back to top
Re: The XML "example"
Dec 14, 2006 5:36 AM by Steve Jones
So your critisism is of the way that XML marshalling tools are built and with the short-cuts that tools vendors take. I'm not going to take issue with that, but it would be good to make that point and calling the tools vendors to account rather than throwing the baby out with the bath water.
Reply
Back to top
I'm getting tired of SOA == SOAP
Dec 14, 2006 6:48 AM by Olaf Bergner
While I do think that you have a valid point here, please refrain from spreading the nonsense of equating SOA with SOAP/Web Services. SOA is an architectural paradigm not tied to any specific technology. And that's where it value lies. Implicitly assuming that in order to implement an SOA you need to use SOAP/WS-* only serves to cloud its true nature and thus is actually dangerous.
Olaf
Reply
Back to top
Re: The XML "example"
Dec 14, 2006 7:29 AM by Stefan Tilkov
Steve, I claim all current WS stacks break with the XML example Pete gave. Schema validation is practically never done at runtime (it's usually deemed way too expensive), and 100% code generation is the norm. Sadly.
Reply
Back to top
Re: I'm getting tired of SOA == SOAP
Dec 14, 2006 7:33 AM by Stefan Tilkov
Olaf, while I understand your point, please don't accuse someone of actively "spreading nonsense". I'm not aware of any publicly available and accepted SOA definition that shows you are "right", only that there are many who share your view, as well as many who don't.
As to my personal opinion, I have seen large numbers of people who agree with you that SOA is an abstract style, and end up doing WS-* only anyway. YMMV.
Reply
Back to top
Re: I'm getting tired of SOA == SOAP
Dec 14, 2006 8:18 AM by Olaf Bergner
Agreed, the tone of my posting may have been a little harsh. Still, I maintain and will continue to do so that either explicitly or implicitly assuming that an SOA requires the adoption of SOAP/WS-* is not only simply not true but actually dangerous. Given the inherent complexity of SOA as an architectural style any such assumption that keeps you from choosing the technology that best fits your specific context may well cause your project to fail.
There is another, more general gripe I have with this equation: Prematurely choosing a specific implementation technology introduces artificial mental barriers which tend to keep you from concentrating on your specific problem domain and its unique qualities. Yet being able to "choose the right tool for the job at hand" is IMHO all the more important in an SOA, since these systems tend to be so complex.
Reply
Back to top
Re: I'm getting tired of SOA == SOAP
Dec 14, 2006 3:35 PM by Stefan Tilkov
Olaf, I understand your point. In my personal experience, though, technology decisions are often postponed far too long -- leading to more and meaningless discussions because they remain at a level that is way too high to be useful. I think we can agree that prematurely choosing a specific technology approach is not a good idea. I'd just like to add that to choose it too late is just as bad :-)
Reply
Back to top
Re: I'm getting tired of SOA == SOAP
Dec 14, 2006 3:55 PM by Olaf Bergner
Agreed, and I share your experiences -;
Cheers
Reply
Back to top
Re: The XML "example"
Dec 14, 2006 8:33 PM by Steve Jones
I'm not sure they all do, I'll have to go an check now :( But anyway the cost of validation is (IMO) pretty minimal (I remember doing Ada & Eiffel in the early 90s which did all this and more and it was okay. So the issue is the XML bindings as implemented (its not the WS stacks, its the generated code, hence the reason its the XML bindings). Picking this implementation issue as a criticism of WS-* when REST has so many holes (MIME types anyone?) is more than a bit rich.
Lets pick on the vendors (and people like Paul Fremantle :)) and the XML binding technologies, rather than the current implementation sets. This isn't exactly a hard case to solve... its probably just that they haven't had the use cases and real world scenarios to demand it...
Which sort of makes you think....
Reply
Back to top
Re: The XML "example"
Dec 17, 2006 4:35 AM by Fergal Somers
SOAP/WSDL and XML binding technology are different things. Whether to use an XML binding technology is an implementation decision.
- I can create WSDL/SOAP services that use them (e.g. JAX-B) or not (e.g. BPEL, DOM)
- I can create REST services that use them (e.g. JAX-B again) or not (e.g STaX/SAX/DOM).
Issues such as the requirement to support runtime validation or how you intend to support service versioning (both at the schema, semantic and implementation levels) may influence your decision on whether to use an XML binding technology or not. SOAP/WSDL currently doesn't push you one way or another.
Reply
Back to top
Re: Bold claims... no data
Dec 20, 2006 2:39 PM by Eric Newcomer
This is really an argument against the tools, not the specifications. Many have said this but I'll reiterate - do not throw the baby out with the bathwater. If the implementations of the specs are bad, let's fix them. In that context these debates are very valuable.
However once someone starts suggesting that we just throw it all away and start over again that isn't very constructive, since Web services do represent significant industry progress.
Reply
Exclusive Content
All Articles Presentations Interviews Minibooks
AOP Refactoring with Ramnivas Laddad
Ramnivas Laddad on using Aspects for refactoring cross-cutting concerns within classes to reduce boiler plate code and potential for mistakes, resource management and concurrency control.
Java, May 07, 2007, 3
The MOle Plugin
A comprehensive intro to the MOle, a plugin that provides insight into the inner workings of Ruby on Rails in realtime, as requests come in and get processed.
Ruby, May 05, 2007, 3
Per Kroll on Agility & Discipline, Distributed Dev, RUP Subsets
Per Kroll is responsible for developing and managing RUP at Rational. In the interview, Per shares insights on Agile practices for distributed development, and RUP subsets.
Agile, May 04, 2007,
Developing in a Service-oriented World
Gregor Hohpe takes a look at the architectural aspects of SOA, addressing issues such as the false sense of simplicity and the problems of established programming models.
SOA, May 03, 2007, 2
The Role of Testing and QA in Agile Software Development
Scott Ambler argues that agile testing practices have resulted in significantly higher quality software, and questions the role of traditional software testers and QA people on agile projects.
Agile, May 03, 2007, 3
The Challenges of Latency
In this article, eBay architect Dan Pritchett explains why global, large-scale architectures need to address latency, and what architectural patterns can be applied to deal with it.
SOA, May 02, 2007, 4
Windows Presentation Foundation: The Future of Windows
Ian Griffiths shows the key features of WPF such as XAML, composition, layout, animation, and data binding, while also showing why WPF differs so radically from Win32.
.NET, Apr 26, 2007,
WebWork (Struts 2) In Action
Patrick Lightbody overviews WebWork and the Struts merger, comparing to other web frameworks and explaining how to achieve rapid development with WebWork/Struts 2.
Java, Apr 25, 2007, 7
Older >