text:  Dec 04, 2006 09:00 AM
  The practice of "separating concerns" is a critically important tool for software architects, as it helps us introduce loose coupling where we need it in the systems we design. Unfortunately, it seems we're not as collectively proficient with that practice as we need to be, at least in the context of Web services and SOA.
  Adobe® Rich Internet Application Project Portal
  Comprehensive Threat Protection for REST, SOA, and Web 2.0 Applications
  Business Benefits of Open Source SOA
  SOAsocial.com - See what the SOA community is Talking About
  Ebook: Scaling Agile with C/ALM
  If we are attempting to separate concern A from concern B, then we are seeking a design that provides that variations in A do not induce or require a corresponding change in B (and usually, the converse). If we manage to successfully separate those concerns, then we say that they are "decoupled", for obvious reasons. As a simple example, a car's side view mirror controls are decoupled from its accelerator, permitting us to adjust our mirrors without fear that the car will speed up or slow down.
  In IT, in particular distributed systems, we often talk about the importance of the "separation of interface from implementation". Well, actually, we tend not to talk about it as much in recent years, since it seems to have become a law of the land; assumed desirable in the general case. Web services have certainly claimed to take it to heart with WSDL, the idea there being that clients implementations are authored to the platform/language/protocol/OS-independent description of the service, rather than to the service implementation. Definitely a good idea, of course. But does it really separate the concerns in the way we discussed above? Let's have a closer look ...
  We can test WSDL's capacity to separate interface from implementation by asking the following question; can the implementation of a WSDL-described service vary arbitrarily without requiring a corresponding change in the interface? The answer is clearly no, as for any given WSDL document, it's quite trivial to identify a change in the implementation that would require a change in the interface. For example, if our interface included an operation for retrieving real time stock quotes - say, getRealtimeStockQuote() - then a change to an implementation of that operation to return delayed stock quotes would necessitate a change in the interface because clients would be assuming quotes were realtime, as that is what "getRealtimeStockQuote" would be documented to mean.
  So, in fact, WSDL does *not* separate implementation from interface. Surprising, isn't it?
  The billion dollar question then, is how *can* these concerns be separated? Obviously another kind of interface/service description language can't help us, since none of the reasons that the test above failed had anything to do with any specific feature of WSDL; CORBA's IDL would have faired just as badly, as would DCOM, Java RMI, etc. No, we need to look higher up in the stack.
  We observed in the stock quote example above, that getRealtimeStockQuote() couldn't be used as part of an interface to both a realtime and delayed stock quote service implementation. The reason was simply that the operation is specific to realtime quotes. Had the operation been a more *general* one like getStockQuote(), then it could have accomodated that change in implementation by representing the *type* of stock quote in the data that is returned. And from this we learn a very important lesson; the more generic the operation, the more the concerns of interface and implementation are separated, and the more decoupled the message sender and receiver become.
  But how far can we go with this generalization exercise? How much loose coupling can we hope to gain? Well, if getStockQuote() is more general than getRealtimeStockQuote(), wouldn't a simple get() operation be more general still, even *maximally* general; that such an operation would be implementable by any service which provided data to clients that asked for it?
  The Web provides us such an operation (HTTP GET), and it has indeed been implemented by an extremely large and diverse set of services over the past 15 years. The sooner we as an industry collectively realize this, the sooner we can all get to work on building out the Web as the embodiment of the SOA vision.!
  Mark
  You specifically define an interface to mean real time, and then say you can't change it to mean delayed. That's like me saying that GET isn't flexible enough because I can't make it mean POST!.
  I'd argue that swapping implementations in the manner you describe would be a mistake.
  Effectively what you are saying in this article is that we would get maximum flexibility if all of our interfaces were:
  public interface rest {
  java.lang.Object get();
  java.lang.Object post(java.lang.Object arg);
  java.lang.Object put(java.lang.Object arg);
  void delete();
  }
  Unfortunately years of programming experience shows that defining the right interface rather than the most generic is actually a useful activity. Hence why people like generics, because they can actually use types and not just have everything an untyped object.
  I actually like REST as a model - I think it has its uses, but this article hasn't improved my opinion of it I'm afraid!
  . " Paul - who's to say the data can't declare that it's a value taken 20 minutes ago? No need to change the interface to accomodate that use case. "I actually like REST as a model - I think it has its uses, but this article hasn't improved my opinion of it I'm afraid!" The intent was to show how REST separates interface from implementation, while SOA/WS doesn't. Are you saying you disagree? If so, what part of my argument do you disagree with? You say that swapping implementations can be harmful, but as I say above, if the data declares how it's different, then wouldn't that address that issue? Anyhow, please be specific with your reasoning for why my claim is incorrect. Thanks.
  You say that swapping implementations can be harmful, but as I say above, if the data declares how it's different, then wouldn't that address that issue?
  What if you don't want to parse the data to determine if the data is real time or not real time? What if you can't parse the data because the overhead is unacceptable or significantly increases the complexity of the consumer?
  -Noah
  Paul, I don't think Mark is arguing for "untyped" interfaces -- just for leaving out as much information from the operation name as possible and moving it to the data instead.
  Even with a Web services-based approach, there don't seem to be many alternatives to actually looking at the data. In the popular document-literal-wrapped SOAP style, the "method" is determined by looking at the outermost XML element ...
  "I actually like REST as a model - I think it has its uses, but this article hasn't improved my opinion of it I'm afraid!"
  This article has NOTHING to do with REST, please don't let it ruin your opinion.
  REST would replace the SOAP or WS- implementation with a URL allowing you to get your stock quotes via an GET /api/getStockQuote/?ticker=AAPL request rather than all the extra XML markup mumbo-jumbo.
  I have no idea what this guy is talking about apparently he things your URL should be reduced to GET /api/get/?ticker=AAPL, because then your service could start returning news instead of stock quotes, without breaking the interface?
  He seems to forget that the interface has two parts, what goes in and what comes out, and if you're going to break what comes out, you're correct in breaking the interface in the process (for example, changing getRealtimeQuote to getQuote) as this lets the consumer of your API know something different is going to come out of getQuote.
  Now, if you're output all along has had the age of the data, you shouldn't have called it getRealtimeQuote in the first place, as the quotes aren't necessarily realtime, but rather each quote specifies it's age. If you need to support returning only realtime quotes, that has to be specified somewhere and to my mind calling getRealtimeQuote(blah) makes a lot more sense than calling get("Realtime","Quote","ReturnXML","UsingThisImplementation","you don't really need this variable, but we needed to support growth without breaking the interface")
  Both REST and WS-blah can define horrible interfaces that make the client's life miserable. The real key point of REST is that the request itself contains the information about what you want to do, rather than having to read the whole message worth of information that was sent in, just to see that someone wanted a stock quote, and then start looking up that information.
  Sorry Matt, but you're missing the point. REST doesn't put the operation name in the URI. REST *requires* that the operation name be generic to all resources. So it's not "GET /api/getStockQuote/?ticker=AAPL", it's "GET /api/stockQuote/?ticker=AAPL". And if you think that difference is insignificant, then you're not looking closely enough 8-) And P.S. this article has everything to do with REST, and specifically why it's an improvement on SOA for large scale, evolvable systems.
  Matt - I think we're talking about the addition of, say, a single attribute (delay="20") to an XML document. The overhead would be miniscule.
  Oops, sorry, I meant Noah.
  The point of the article is that since in REST all operations are done through a limited set of verbs, more (or all?) of the semantics are moved to the data going in and out. And this would make the service easier to change. Did I understood it correctly? But how so, precisely? The idea is that the representation format could be extended and existing clients should remain oblivious to the change? That could happen if clients were required to ignore data elements that they don't understand (if the clients were written with common X/RM tools they could break, but this is beside the point.) So this article is not just about REST on the general sense, but about REST applications with "loosely typed" data formats. Am I completely off the mark?
  The article didn't talk about data so much, but yes, the point is that the more general the operations, the more latitude the implementation has to change. To your second paragraph, the scenario isn't that you would evolve current software and data in this manner, it's that you start out using it. But your observations about ignoring unknown extensions is a good one.. Am I getting closer? :-).
  I think that's an excellent summary!
  So, in fact, WSDL does *not* separate implementation from interface.
  You're confusing implementation with semantics. You are aiming for interfaces that do not make technically explicit their semantics.
  Of course the semantics of WSDL is very thin; there's the message pattern, some schema and an operation name.
  You are saying that if you remove the operation name you're more flexible; so you can change it at will. But then your dependency just moves to your documentation and only appears during testing...
  My impression is that REST leads to resource oriented services. Maybe that's ok for internet available services.
  I don't think that resource oriented services are the most interesting services within enterprises; they are too low-level. Within enterprises you want to be able to express preconditions and effects. I don't think that's possible with REST style services.
  To be fair that's not possible with WSDL as it is either. But new standards in the space of semantic services are proposing new standards that will be able to fill that gap.
  In other words: the trick is to specify only essential features in interfaces. Maybe the fact that data is realtime is not essential maybe it is. But the 'inflexibility' that remains (either designtime with static typing or runtime with duckie typing) is the solidity that makes the contract between client and provider explicit.
  Btw I had to laugh at the rest{ } interface...
  Just wondering something ... out loud. If you are collapsing the interface to be more generic to separate concerns - are you not adding a degree of coupling? In other words - if I change something behind the interface won't my QA group scream "full regression test!" because the interface is so generic? I am a big fan of 'Parnas' who I believe was the gentleman who coined the term Separation of Concerns back in the 70s - but I am wondering if we are looking at this in a very idealistic manner.
  Effectively what you are saying in this article is that we would get maximum flexibility if all of our interfaces were:
  public interface rest { java.lang.Object get(); java.lang.Object post(java.lang.Object arg); java.lang.Object put(java.lang.Object arg); void delete(); }. Hi Paul, This is exactly what Mark is saying, and it is not such a novel idea. True OO languages rely on messages between objects. So it is the data (message selector) that determines which method (implementation) is selected. So a given object could be sent the message realTimeStockQuote or delayedStockQuote and if either of these messages are not supported (implemented) then the receiving object would respond with DoesNotUnderstand. Not that different to an HTTP Error 404, Page Not Found.
  Unfortunately years of programming experience shows that defining the right interface rather than the most generic is actually a useful activity. Hence why people like generics, because they can actually use types and not just have everything an untyped object.Yes you've got it. Years or C++ confusion has lead to the coupling of Class (implementation) with the idea of Type (interface). A virtual function call is not a message send, and a Class is not a Type. So yes we need to think of objects as untyped (duck typed). When you do then you see that what Mark is saying makes sense. We do not what to leak the implementation into the interface. So WSDL/IDL etc that declare the message selectors upfront are brittle because they do not seperate these concerns. If you choose to add a new method such as stockQuoteInPoundSterling then the implication is that you've changed the interface, when in truth for delayedStockQuote and realTimeStockQuote the interface has stayed the same, the class (implementation) has been extended that's all. So the original messages should still work. It took me a while to understand this, but think it through and you will see that Mark (and Alan Kay BTW) is right. Paul. Hi Paul, This is e
  Hi Stefan, Agreed. I do not want to stretch the anolgy too far, but duck typing leaves out the message selector as part of the static interface to an object. All objects can recieve any message. The message selector becomes part of the data. So by analogy, what Mark is suggesting is relevant to objects too. Paul.
  I don't know if I'd go so far as "impossible". Everything's possible with enough money 8-) Also, REST's benefits are not dependent on having a "small fixed number of verbs" either; it's the *generality* of verbs that matters. There are other standardized and perfectly RESTful verbs that aren't GET, PUT, POST, or DELETE. See this list (scroll down to "Methods"). Not all of those are uniform (which REST requires) though; for example PROPFIND and PROPPATCH are unique to properties rather than resources in general. Ditto for the MK* methods plus some others.
  Thanks for your comment, Joost. You write; "You are aiming for interfaces that do not make technically explicit their semantics." Sort of, yes. I'm encouraging hiding as much of the specifics of what the service does (its implementation) as possible behind the interface. So instead of a single interface which has getFoo() and getBar() operations, I suggest making that two separately identifiable services with the same get() operation. I claim that such an interface better separates interface from implementation, because I can throw it in front of any other implementation which returns data.
  Jason - well first of all, I'm advocating this approach be used when designing new systems. If you've got an existing system, there are obviously going to be lots of issues evolving it towards REST, and that will require best practices that I didn't get into in this article. But of course if you have some existing client that works with an existing service, and then you go and change that service interface (or its data), then the client will need regression. But if you consider two alternative architectures for solving the same problem, one which uses a specific interface, and the other which uses a generic interface, then the latter will have *less* degrees of coupling than the former because its use of the interface constraint separates two concerns which are not separated in the other architecture. And yes, praise be to Parnas; AFAIK, the first to really think of software architecture in a principled way ... although it took Perry & Wolf to create a complete framework for the study of software architecture.
  Mark, The point I'm trying to make is that the semantic coupling is an inherent one because of the contract between client and provider. If you remove any trace of this coupling from your syntactis, as you propose, the coupling still exists but is just not that easy to spot. In other words; for any meaningful service you can't just change unilaterally the service your providing: this may break your client. groetjes, Joost
  Joost, Let me try and explain this one if I may. I agree that the semantic coupling is inherent. The issue though is when the coupling occurs. With the interface Mark describes the coupling (or binding) occurs at runtime rather then at compile time. Binding at runtime, or late-binding is inherently more flexible. Should the implementation change after compile time, then with late binding your clients still work, but with early binding they are likely to break. For instance if a website adds a new page, and now supports an additional URL, should all the clients that have links to the old pages break? Has the website chnaged? Infact the old "index page" interface has not changed (GET Index.html), and exisitng clients should see a link to the new page which they can choose to GET aswell (GET new.html). This is what Mark is talking about. For me, it only made sense when I saw the analogy with messaging systems in general, that have reduced coupling compared to RPC, and in particular message based OO systems like in Smalltalk. Sometimes less is more, which is why "interfaces" like WSDL and IDL have been shown to be brittle and less flexible over the years. Paul.
  Paul,
  You say
  Binding at runtime, or late-binding is inherently more flexible. Should the implementation change after compile time, then with late binding your clients still work, but with early binding they are likely to break
  That isn't true; should the implementation change after compiletime, then with late binding your clients may not work either. It's just that you won't find out at compiletime.
  There is a contract between client and provider, with or without REST, and if you change an essential part of this contract the client will 'break'. Maybe without compile errors or doesNotUnderstand messages, but still.
  I object to your example of websites and pages. I claim that this is a circular proof because the claim that the inherent language of services is isomorf to the language of websites and pages is in itself the claim that REST makes.
  I think a REST approach to services leads to the definition of resource- (or data-) oriented services. The REST vocabulary of GET, PUT, DELETE, etc. is basically the vocabulary of CRUD.
  CRUD services are not very valuable to enterprises and are too fine grained. A high level business process definition should not directly be manipulating data/resources but should use coarse grained services that provide large chunks of business value.
  A counter example: I want to provide to another company in my value chain the service 'Confirm transport'. Business logic states that transports can only be requested through the step of a making a reservation. The service thus has the precondition that the transport is planned and the effect that the transport is confirmed. What REST/CRUD keyword does this map to? "CREATE confirmation"? "UPDATE transport"? The fact is that REST does not provide a meaningful concept for transactions.
  If I were to extrapolate the flexibility argument that REST makes I'd say that the vocabulary of REST is to brittle: what if I want to change the POST 'implementation' to a DELETE 'implementation' without changing the clients?
  So the most flexible vocabulary is composed of two words: SEND and RECEIVE. that's not where these are not relevant to high-level enterprise services. The java equivalent being
  public interface MostFlexibleInterface{
  java.lang.Object send(java.lang.Object);
  }
  Effectively you're descending in the protocol layers when you're using a REST based service definition. In my view higher 'protocol layers' are needed in the service space to increase the level of abstraction.
  Of course these higher abstractions should be the right ones and do not necessarily need be statically typed.
  (delete "that's not where these are not relevant to high-level enterprise services." damn those small text areas. )
  Joost, IMO equating REST with CRUD is tempting, but misleading. GET/PUT/POST/DELETE don't map to CRUD, and they're neither very useful nor supposed to be very useful for interacting with a "DB layer". In your example, the "reservation" could be the resource being created. Doing a POST to /reservations might not only return a reference-able URI, it might lead to a whole bunch of DB entities being created (who knows). When you model your solution in a service-oriented way, your abstractions are services; when you model in a resource-oriented way, your abstractions are resources. The models are *very* different, but can definitely be used to address the same problem domain.
  If I were to extrapolate the flexibility argument that REST makes I'd say that the vocabulary of REST is to brittle: what if I want to change the POST 'implementation' to a DELETE 'implementation' without changing the clients?
  That's perfectly fine, nothing breaks. Using POST, the client has no visibility into what the server may or may not do with the data the client sends it; any action the server might take is fine.
  It's also perfectly fine if GET on a URI returns an XML document one moment, and a PNG image the next, because the expectation of the client is defined by GET, and that includes the fact that the response to GET will be self-descriptive and therefore not require knowledge of past interactions to establish context for the interpretation of that response.
  We're talking about complete separation of implementation from interface, and loose coupling up the wazoo here.
  Hi Joost, I had difficulty with this too, and it took awhile for Marks explanantions to sink in. First of all I had to forget all I thought I knew about objects and interfaces. The interesting phrase in Marks response is self describing. So the reason why I mentioned "GET index.html" as an example is because the href links in the index page are self describing, they tell you the resources available to you on this website. The resources can change but the interface remains the same. This is achieved by narrowing the interface/connector to something that can be uniform across all websites. Likewise with the JMS SendMessage interface, it is applicable to any service listening on a JMS queue. Likewise again with the send byte code(s) in Smalltalk. All of these interfaces/connectors are narrow, and gain flexibility by communicating additonal semantics in the data. All these interfaces are also (possibly) self describing. For instance you can send a message to a Smalltalk object to find out what messages it understands, this is a uniform part of the mesaging interface. WSDL/IDL etc result in server specific interfaces/connectors. They do not self describe dynamicaLLY, the description of the interface is fixed. This fixed semantics is what limits the flexibility over time. I'm sure that you have experienced having to redistribute client stubs each and everytime you make a benign change to a CORBA interface. As I understand it WSDL is equally as brittle. Paul.
  Guys,
  Let me start by saying that I think this was an interesting discussion.
  Stefan,
  Yes, I was provoking a bit with the CRUD equation. But just a little...
  The models are *very* different, but can definitely be used to address the same problem domain. That's true; but the abstractions do matter.
  Mark,
  We're talking about complete separation of implementation from interface, and loose coupling up the wazoo here.My point is that this is not a desirable thing and IMO you're not separating what you think you are separting.
  Paul,
  The interesting phrase in Marks response is self describing.I don't agree; I think REST is less self describing, or it is describing the wrong things.
  Guys, I'm trying to get my analists and developers to leave the mindset of system X sends data Y to system Z because that leads to muddled thinking with unclear responsibilities and little separation of concerns. I want them to think in terms of a client who has to fulfill certain terms while the provider has to fulfill the specified outcome. I want them to have a clear picture wether a "send confirmation" message means a notification of the event or a request to confirm. When the message has been rejected; has the confirmation taken place? REST doesn't tell you squat and thus is not self describing but self obfuscating I'd say.
  Using REST to do service based integration is similar to saying "I don't need no new fangled high faluting Smalltalk to do OO, I can dost do OO in good old C."
  Yes you can, and you can even do it in assembly.
  Ok, I get the impression I'm not convincing you guys and you are, I must say, not convincing me.
  So let me say thanks for the exchange of ideas and groetjes uit Nederland,
  Joost
  My point is that this is not a desirable thing and IMO you're not separating what you think you are separting.
  Hmm. The litmus test for whether concerns were separated, was whether one could be varied without affecting the other.
  If we use GET, then the implementation behind it can vary widely before GET no longer makes sense. That passes the litmus test. If we stick with getStockQuote, then the implementation can't be varied very much before the interface needs to change. That fails the litmus test.
  I think it's really that easy. You brought up a bunch of other issues, but none of them affect the test. Please tell me what's wrong with that test.
  Hi Mark, Your argument is very intriguing and I thank you for posting it. My question is not about your argument so much but more about words - you say that by making the service capabilitity more generic, that it increases the loose-coupling. Most people I think would agree that be making it more generic, that increases the Reusability - since the service now can be used for many more functions... not just getting real time stock quotes, but any stock quotes for example. As most people agree reusability is usually one of the major goals of SOA... but how is doing what you proposed actually increasing loose-coupling? Perhaps these terms are just closely related - by increasing the reusability of a service capability, you automatically decouple it from its underlying service provider?
  I was a little surprised to see the focus on putting things like the delay time of the stock quote in the message; it presumes a lot of things that are, today, unrealistic. For example, it presumes that the schema designer has the foresight to correctly structure their schema to account for such a thing, or to leave an appropriate extensibility point for them in the future. This is currently really, really hard to do in the most prevalent tools for XML; schema for JSON is only now emerging, and RDF's tools are appropriate for academia, not industry. Writing a schema needs to be easy and needs to default to doing the right thing. It also presumes that the consumer is going to be looking for the information about the quotes' delay in the response. Few developers have the discipline or time to always check all of these conditions, and so you're setting them up to fail. Furthermore, since we're trying to be so generic, they basically have to parse, understand and take into account *every* part of the message to process it, or they'll be caught by some extension radically changing its meaning. Let's not even talk about performance. So, this is all fine in theory, but in day to day use, you're only setting traps and unrealistic expectations for my developers. Let's say you have the tooling to create the schema, and you also are able to guarantee that consumers will take the time to understand and apply it. Even then, just pushing such things down into the body is bad practice. Consider; if you add a "this is a delayed quote" extension, it's a backwards-incompatible change, so you'll need to version your namespace (assuming you're using XML). Old clients who don't understand that namespace will be broken if you update to it, so what are you to do? I think this is why information like that needs to be in the URI. Putting it in the URI means that the client is explicitly asking for the delayed version, and so they know what they're getting. That way, you don't need a special extension in your XML for how delayed the quote is, but if you did (e.g., you wanted to be able to persist the message), you could add it without fear of breaking clients who don't understand the new namespace -- because they asked for it. It also pushes the versioning problem into URIs, which are frankly a lot easier to deal with than versioning message formats. BTW, one of the reasons the Web as practised doesn't see these problems as much is because it's based on standard formats with well-understood semantics and ubiquitous tooling. Most of the problems I've stumbled across using HTTP for services are a result of hand-rolled formats; using a standard, controlled format (like Atom, which I think hits the 80% case for HTTP services nicely) makes it more reasonable.
  The getRealtimeStockQuote() example is all about embedding expected behavior in a method name. This is right inline with OO examples that demonstrate how drawCircle(Circle), drawRectangle(Rectangle) and drawElipse(Elipse) etc can be done with draw(Shape) instead. This is all fine and well when the behavior can be focused into a parameter type. But draw(Shape) may not be the ultimate signature because there may be other parameterizations such as draw(Screen,Shape) or draw(Orientation,Shape) and other parameterizations. What the REST proponents are suggesting is that if you just define draw() as the operation, and pass all the arguments in as data, none of which are explicitly required, then you allow the implementation of draw() to be changed to accept anything "new", without requiring clients to specify these additional arguments to remain compatible with the new implementation. The use of document/structured messages, such as XML, which can allow varied content, as the only parameter, allows more/less information to be specified by each client to control what the "service" actually does. What I do with Jini services, is just add additional interfaces to specify the additional method(s) required to support a specific client's needs. This provides the same level of functionality. It's really nothing new or different from what others do in other languages and platforms. There seem to be a large number of developers teething/teethed on the web and only/mostly using HTTP. Those with experience mostly/only using HTTP may not recognize these other mechanisms or know/understand the history of software systems in this regard. To me, it's not amazing to see some of the excitement over the concepts of REST, because, they are about valid software development ideas. But, the lack of rigidity in interface specification, is a big issue for me. When I'm developing software, I need to be able to test without being connected to the environment I will deploy in. Not being able to generate service stubs either by hand, or by tooling to evaluate my client is a big deal. Sure, some of it I can stub off. But, I've not been excited by much of what people call "REST", considering most of the things that revolve around RESTful today are really features of the HTTP protocol and specific server implementation features. I blogged about this last week at
  Nice post Mark, but I think you're reading way way too much into my simple examples which I believe serve the purpose intended in the context of the example, but nothing more. I'm also not talking about evolving an existing system, but building two comparable systems, one using getRealtimeStockQuote, one using GET, and comparing them (a couple other commentors made the same assumption, which suggests I could have been clearer about this). I agree completely about the evolutionary problems about the delay being backwards-incompatible. Regarding schemas, I think they're evil; an anathema to evolvable data formats in the general case. But the details will have to wait for another article ...
  Well, maybe, but if that's the case I can't help but feeling it's a bit of a straw-man argument. Of course GET is more generic, but it's useless without a URI, where you put what you've taken out of GetRealtimeStockQuote. It's not that I disagree with what you're saying (as you should know ;), but I don't see how this line of argument is going to convince someone to steer away from WSDL, RPC and application-specific messages; it brings up more questions than it answers. WRT Schemas -- I agree for XML Schema; do you extend that to *all* schemas?
  The URI could be the same, Mark. Perhaps I should have described the invariants too. 8-/ Re schemas, pretty much, yes. If validity is defined as a function of time, then independent evolvability will be lost; having new software send documents it believes are valid to old software which disagrees, won't work. Speaking of failing to separate concerns ...