• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (23)

1 localhost commented Permalink

Thanks for the link, Bobby.After posting my piece, a colleague gave me another good analogy, which agrees with your descriptions above:A VCR and a TV bought in the same country are [i]interoperable[/i]; you just connect them together. But a VCR bought in the US and a TV bought in the UK may need the services of an NTSC/PAL converter in order to [i]integrate[/i] them.

2 localhost commented Permalink

My response; http://www.markbaker.ca/2002/09/Blog/2006/02/06#2006-02-wsdl-and-interopIntegration isn't an option in the case described there either, because you're looking at an O(N^2) (worst case, if you wanted to build, say, a Web services spider) or O(NlogN) (typical case) integration complexity.Service-specific interfaces just don't scale. It's why the Web is an *improvement* upon old-style service architectures like CORBA, DCOM, RMI, and yes, even Web services.

3 localhost commented Permalink

Mark: Thanks for your comment. But I'm not sure I get your point.Yes, the consumer and provider need to agree upon the WSDL. The two parts need to agree on the interface. What specs define mostly is interfaces, what the APIs are and how they behave. Designing service interfaces is very important and very tricky, but they make a huge difference in how useful your services are over the long run. I think we're violently agreeing.Beyond that, you say "Service-specific interfaces just don't scale." Hmm, compared to what? Have you seen something that's better? What should people do instead?

4 localhost commented Permalink

Thanks for your prompt response, Bobby.> Yes, the consumer and provider need to agree upon the WSDL.> The two parts need to agree on the interface. What specs> define mostly is interfaces, what the APIs are and how they> behave. Designing service interfaces is very important and> very tricky, but they make a huge difference in how useful> your services are over the long run. I think we're violently > agreeing.It seems we agree that well defined interfaces are important. But I'm saying much more than that...> Beyond that, you say "Service-specific interfaces just don't> scale." Hmm, compared to what? Have you seen something> that's better? What should people do instead?Compared to generic interfaces, where all services in a system expose the same interface. This is an extreme in loose coupling. I argue it's the only way to truly decouple interface and implementation. It's also the only way that we know how to build large (Internet) scale systems, like email, instant messaging, and the Web.My recommendation would be for people to reuse the Web for most (practically all) of what Web services is trying to achieve.

5 localhost commented Permalink

Hi Mark,I read your blob postings but there didn't seem to be a way to comment so I'll hijack Bobby's forum here :-)Can you give a concrete example of what you're proposing please? What scenarios are you trying to solve that would be made easier were all the interfaces to be the same?If we tried an analogy with programming (e.g. in Java), is this not the same as saying we should declare all our methods to take (and return) a free-form string? Does this not just move the problem one layer down the stack?Forgive me if I've misunderstood your point; I'm keen to ensure I understand what you're saying.

6 localhost commented Permalink

Hi Richard,> Can you give a concrete example of what you're proposing> please? What scenarios are you trying to solve that would be> made easier were all the interfaces to be the same?The canonical example is a search engine. Imagine a world of services that expose operations such as getStockQuote, getWeatherReport, getCarDescription, getThis, getThat... (the Web services, SOA vision, AIUI). In order for a search engine to be able to get at all the data behind those operations, it needs to be upgraded to support each and every one of those operations, as well as any other that might be used for now and forever.In contrast, if every service simply exposed the same "get" (i.e. HTTP GET) operation, then that problem vanishes; any client can get data from any service.Obviously, using both approaches, there's also the equivalent problem of understanding the data once the client has got it. But I'm just talking about the actually exchange of the data, not its processing.See also; http://lists.xml.org/archives/xml-dev/200503/msg00468.html> If we tried an analogy with programming (e.g. in Java), is> this not the same as saying we should declare all our> methods to take (and return) a free-form string? Does this> not just move the problem one layer down the stack?Actually, no, it's more like ensuring that the only operations you use are those on java.lang.Object, or that could conceivably be defined on java.lang.Object. So getStockQuote() doesn't make sense because some objects aren't stock quotes, but toString() does because all objects can represent themselves with a string.P.S. should I be insulted that you called my weblog a "blob"? 8-)

7 localhost commented Permalink

> OK - let's assume that for now (although I reserve the right> to disagree :-) ). So, we're left with a discussion of the> invocationOops, perhaps a miscommunication, but by "processing/data" I just meant what data formats were supported, since agreeing on the API gives you the "invocation" part.> In the "all the interfaces are the same" case, surely the> provider still has to give you the same information? You> need to know what information to send and you need to know> what it will give back and you need to know how to tell it> that you want it to perform a specific service for you.Not exactly. You need less information with a constrained interface. Consider ...A Web services client that wants to know the current time needs to know two things in addition to the assumed pervasive SOAP/WSDL infrastructure; the identity of the current time service, and the meaning of the (say) getCurrentTime operation.A Web client that wants to know the current time needs to know *just one* thing in addition to the assumed pervasive HTTP infrastructure; the identity of the current time service.Follow?Using GET instead of getCurrentTime, getThis, getThat, ... is an architectural improvement brought about by generalizing the interface and maximizing its reuse. Just as getTime is more reusable than getCurrentTime - because it's more general and so can be used for retrieving more than just the current time - so "get"(GET) is more reusable than both of them. See also;http://www.coactus.com/blog/2005/11/on-interface-and-implementation-and-reuse/> In the absence of WSDL (which, to my mind, is the> important thing), how to you describe the services you're> providing? Can you feed it into a tool?The services are all described with RFC 2616. It tells you the operations that can be invoked are GET, PUT, POST, and others, and what those operations mean.> Again: same qualification applies - I want you to tell me> what I've misunderstood... I'm still in the discovery> phase; I'm still not 100% sure I've understood your> position :-)Understood. Thanks for your patience and willingness to hear me out.

8 localhost commented Permalink

Thanks for taking the time to reply, Mark.With respect to my typo, I think I'll trademark it; I quite like the idea of starting a weblob and calling myself a blobber :-)I've read through a lot of the discussion you linked to and I can kind of see where you're going but I'm not yet convinced it helps solve the kinds of problems my clients are facing in any significant manner.In the post you linked to, you gave the example of a service that provided three operations. Then they add an extra operation.The key claim you seem to be making is that you need to modify the client in order to be able to call this operation in the strongly-typed world but that you don't need to make any changes in order to call it in the 'REST' world since it's still just a GET, but with different parameters.That may well be true. But then what? [i]Calling[/i] a service isn't the hard part. It's knowing what data to send and what to do with the data you get back that's the hard part.If you're just showing it to a user (or you're writing a very specialised app such as a search engine where your raison d'etre is to figure out how to understand any kind of information) then there's no problem and you may well have a good argument.But in the general machine-to-machine case (where my clients struggle), I don't see how this approach has really bought us anything at all.Indeed, one may argue that by removing the explicit interface, we've made it harder to write tooling to simplify automation of the mundane aspects and we've made it harder to document what we're doing.In other words, I think the problem is in this statement:[i]"Obviously, using both approaches, there's also the equivalent problem of understanding the data once the client has got it. But I'm just talking about the actually exchange of the data, not its processing."[/i]In my opinion, the exchange of data isn't the hard problem; the processing is the hard part.I can tell from your link that this is a heated debate so I'm very keen to ensure I completely understand what you're proposing. So, please do correct me if I've misrepresented you.Cheers,Richard

9 localhost commented Permalink

Richard -> In my opinion, the exchange of data isn't the hard problem; the processing is the hard part.Well, reasonable people might disagree about the relative difficulty of those two things, but luckily we don't need to get into that because [i]the processing/data part of the problem is equivalent in both cases[/i].

10 localhost commented Permalink

[i]Well, reasonable people might disagree about the relative difficulty of those two things, but luckily we don't need to get into that because the processing/data part of the problem is equivalent in both cases.[/i]OK - let's assume that for now (although I reserve the right to disagree :-) ). So, we're left with a discussion of the invocation.In the SOAP/WSDL/WS-* case, a provider says: "I can do X. If you want me to do it, here's how you get in touch with me. This is the information you must give me. This is what I'll give in return". One of the great advantages of WSDL is that you can feed a WSDL to a tool and it can take care of all the gunk - you just need to populate the appropriate fields in some object somewhere, for example.In the "all the interfaces are the same" case, surely the provider still has to give you the same information? You need to know what information to send and you need to know what it will give back and you need to know how to tell it that you want it to perform a specific service for you.In the absence of WSDL (which, to my mind, is the important thing), how to you describe the services you're providing? Can you feed it into a tool?Again: same qualification applies - I want you to tell me what I've misunderstood... I'm still in the discovery phase; I'm still not 100% sure I've understood your position :-)

11 localhost commented Permalink

Thanks for the detailed response, Mark; I've just addressed some of your points to keep the discussion manageable.[i]Oops, perhaps a miscommunication, but by "processing/data" I just meant what data formats were supported, since agreeing on the API gives you the "invocation" part.[/i]This is the part I don't see. How do I know how to use the GET method to have someone give me the current time? What do I do with what they give me back? Where to they tell me the information I need to know? How do I tell them I want the *current* time as opposed to the time of JFK's death (adjusted for Pacific time)?More realistically, how do I use the GET method to transfer money between two of my bank accounts? How do I know what information to send?If the bank offers the ability to execute a share trade, how does it tell me how I invoke it?How do I invoke this without changing my client?In other words, you must either be saying WSDL is unnecessary or that you have an alternative. I'm still not clear which it is :-)

12 localhost commented Permalink

> This is the part I don't see. How do I know how to use the> GET method to have someone give me the current time?Because GET is the only method available to you that means "give me the current value associated with this name". So if you've got the name (URL) of the current time, and you want to know the current time, GET will give it to you.It's the same way that if you're given an integer pointer (say, "p") in the C language, that you know to evaluate *p to find out the value of that integer. It's assumed. Implicit.> What do> I do with what they give me back?You'd do the same thing as if you got the data via the getCurrentTime() method. It might even be the same data.> Where to they tell me the> information I need to know?Not sure what you mean.> How do I tell them I want the> *current* time as opposed to the time of JFK's death> (adjusted for Pacific time)?Just make sure you're using the right kind of service that provides that kind of information. That's usually done when you discover the service. e.g. in the Web case, you might discover the current time service via some previous data that you've retrieved;Using Web services, you might have a single service with multiple get*() operations which returns those two kinds of times you mentioned above. But the Web model requires that each of those two data sources becomes its own service so that you can use GET to get at each.If you don't mind, I'll avoid answering your banking example questions because it's a much more complex scenario than simple data retrieval and therefore much less useful as a tool for explaining the advantages of Web based services. I'll be happy to revisit that later, once we've made progress on the advantages of Web based data retrieval.

13 localhost commented Permalink

Oops, I guess I need to escape markup. The example document snippet that could be used to discover the current time service is (crossing my fingers);&ltCurrentTime xlink:href="http://example.org/adsfjlakdf"/>

14 localhost commented Permalink

Couple of thoughts:- One of the questions brought up here is "where are the crisp interface definitions for REST services". There is no language like WSDL to define them. Instead, you do it the old fashioned way. Documentation. Here's an example: http://www.flickr.com/services/api/flickr.tags.getListUser.html Sure, it's not perfect. But for some reason, a lot of people are happy with it, even when given the opportunity of using WSDL instead of REST, as we all know: http://www-128.ibm.com/developerworks/blogs/dw_blog_comments.jspa?blog=392&entry=93145- As a colleague mentioned to me this week, Web Services are not a way to do distributed objects (thank you Arthur!). You're sending XML documents over a wire. There's little OO here; and though you can do it (extending schemas or whatever) it should probably be avoided because it makes the description of the XML (in your flavorite schema language) even more complex than schema already is. It's already inscrutable.- with WSDL, you are basically forced to use tools to gen code for you. This gets in the way. Always. Especially while you are developing/evolving/iterating your web services. On the other hand, if you're doing REST, there are is no code genned, because there are no tools, so you basically write this mapping layer yourself. Typically these aren't rocket science. And since you wrote the code instead of some code genning tool, it might even be understandable and debuggable!- as a side effect of dealing with code-genned stubs, your interfaces are brittle; if you'd like to slightly modify a 'method' by taking an additional parameter, or maybe allowing an existing one to not be sent, you can't. If you're writing the mapping layer yourself, you can. This is especially useful at development time when the service definitions might be changing on a daily basis, so that you can continue to allow 'old' clients talk to 'new' servers, or vice versa.- with WSDL, once the data you are sending over your service becomes suitably complex that it can't easily be mapped into your programming language, you are in the same boat as REST in terms of dealing with reading/writing the 'payload' XML. And then you are really screwed on the Java side, as there is no standard for how to provide this data to the generated stubs; each implementation can (and in practice does!) provide 'proprietary' interfaces for this. This becomes WORSE than REST, because now you need to write separate glue for the stubs for each implementation of the runtime you want to support.- REST services have an advantage that simple ones, that just, say, GET something, can be executed by the most rudimentary HTTP capable tools, including web browsers, curl, wget, and every popular programming language out there . (hint for Java programmers: Apache Jakarta's Commons HttpClient library, while non-trivial to use, provides a lot of great function over what you get with just the standard Java libraries). With WSDL, there's simply no way to issue a request in a browser, and issuing requests via command-line or scripting tools is clumsy.- As REST services expose HTTP at it's lowest levels, if you like, you can build in support for things like cookies, if-modified-since, ETags, redirects, etc. There is no standard for any of this stuff in the WSDL universe. All that nice plumbing, that is used to make your app scalable, is hidden from you.- My one experience with using WSDL based services, cross-language, with a PHP client talking to a Java server, didn't work. Trying two different PHP WSDL stacks. The problem was a difference in the interpretation of XML namespace rules. In the end, I generated the XML wad that the Java server wanted, by hand, and talked directly to the Java HTTP server with PHP http-level functions. Which is what I'd end up doing with REST, only the XML would have been easier to deal with.In the end, I see WSDL and as an interesting approach that doesn't scale with complexity. Great for building toys, although for the toy service I tried to use in the previous bullet (and it was an unrealistically simple service), it didn't even 'scale' to that!

15 localhost commented Permalink

That's good feedback pmuellr. It seems based on your personal experiences, which is always valuable to share. FWIW though, while my arguments are backed up by personal experience, I don't present them in those terms; I try to present them in architectural terms. In essence, I'm trying to explain the technical reasons *why* WSDL/SOA is overly complex and *why* REST is quantitatively simpler.I will just add that I don't agree with all that you say. Saying that REST has no tooling is simply incorrect. There is an *abundance* of very mature, reliable, and performant tools out there today. More than SOAP in fact.Also, the Flickr "REST API" documentation isn't the analogue of a WSDL document; the HTTP specification is. The Flickr docs are the discovery mechanism, like a registry in SOA terms. Well, that's perhaps not 100% true because Flickr doesn't use media types properly. But if they fixed that, it would be exactly as I described.

Add a Comment Add a Comment