http://www.innoq.com/blog/st/ Thoughts on Architecture, REST and SOA, Model-Driven Development, and whatever else crosses my path en-us Copyright 2007 Sun, 25 Nov 2007 17:17:15 +0100 http://www.sixapart.com/movabletype/ http://www.rssboard.org/rss-specification Expect some weirdness around here while I play around with a MovableType update. http://www.innoq.com/blog/st/2007/11/blog-upgrade.html http://www.innoq.com/blog/st/2007/11/blog-upgrade.html Sun, 25 Nov 2007 17:17:15 +0100 this become available? Very cool.]]> http://www.innoq.com/blog/st/2007/11/google-music-search.html http://www.innoq.com/blog/st/2007/11/google-music-search.html Thu, 22 Nov 2007 23:28:42 +0100 Of course I got an iPhone pretty much immediately after it was released in Germany -- and the quick review is: I love it. There are lots of silly and annoying things: no cut&paste, no iChat (only a text message app that looks like it), no way to use the iPhone to get my laptop online, no way to sync without a cable (despite having Bluetooth), no way to search emails or contacts, no GPS, no way to use SMTP over SSL without an official certificate, no way to store passwords (including those for T-Mobile's hotspots, which is just ridiculous) ... All of this doesn't change my opinion for a second: I've owned, among others, pretty much every Nokia Communicator, an MDA and various other gadgets -- this is by far the best UI, the first time I have _really_ usable email, brilliant no-hassle headset integration, perfect synchronization (at least with a Mac), in summary: without a doubt the best smartphone in existence. If you have any chance, go get one. http://www.innoq.com/blog/st/2007/11/iphone.html http://www.innoq.com/blog/st/2007/11/iphone.html Apple and Mac OS X Sun, 18 Nov 2007 20:04:19 +0100 James Snell: > I think it is well established that HTTP Authentication needs a major kick in the ass and OpenID and OAuth may get us most of the way there. However, until I see RFC#’s attached to both I’m hardly going to consider them to be complete. I propose the creation of an IETF WG on Identity and Authentication. The WG would be chartered to produce two RFC’s covering each of the two areas. OpenID and OAuth could be used to seed the WG effort.]]> http://www.innoq.com/blog/st/2007/11/identity-authentication-and-ht.html http://www.innoq.com/blog/st/2007/11/identity-authentication-and-ht.html SOA, Web Services and REST Sat, 17 Nov 2007 22:42:07 +0100 Steve Vinoski: > Nowadays, all the distributed systems development I do is REST-oriented. I know from significant first-hand experience what both sides of the coin look like, and there’s no question that REST-oriented systems are easier and less expensive to develop, and far less costly to extend and manage. Like Dare said, anyone who thinks otherwise is either so emotionally or monetarily attached to WS-* that they can’t be objective, or they don’t actually write any code or build or maintain any actual systems. It’s no contest, really. Look, it's those guys who post this -- how am I supposed not to link to it? ;-)]]> http://www.innoq.com/blog/st/2007/11/dares-right-you-build-real-wor.html http://www.innoq.com/blog/st/2007/11/dares-right-you-build-real-wor.html SOA, Web Services and REST Sat, 17 Nov 2007 00:16:29 +0100 An excellent presentation by Dan Diephouse.]]> http://www.innoq.com/blog/st/2007/11/dan-diephouse-on-scalable-reli.html http://www.innoq.com/blog/st/2007/11/dan-diephouse-on-scalable-reli.html SOA, Web Services and REST Fri, 16 Nov 2007 22:47:25 +0100 Matt Raible reports from a talk by Don Brown about Struts2's REST support (via Mike Herrick).]]> http://www.innoq.com/blog/st/2007/11/struts2-and-rest.html http://www.innoq.com/blog/st/2007/11/struts2-and-rest.html Fri, 16 Nov 2007 20:38:37 +0100 company-internal events into a habit -- after all, they're one of the best things about innoQ (in my not exactly humble opinion). This time, we spent two days in a small town called Wesel, exchanging ideas, listening to various presentations, and discussing all sorts of technical and non-technical things. Our agenda included a presentation about the use of ILOG's JRules in the insurance industry, an only slightly esoteric presentation on semantics in communication, some communication theory (of the human kind), a look at Embedded JBoss, a session about model-to-model transformation with two more in-depth sessions on ATL (the Atlas Transformation Language) and openArchitectureWare's Xtend, and a nice experiment at the end: everyone had been asked before to prepare two slides for a 5 minutes max. presentation, and we ran a series of these "flash presentations" for close to 90 minutes -- a huge amount of triggers, as a start to some more detailed discussions among those interested in any of the topics. Did I mention that our "events" are one of my favorite aspects of innoQ? ;-)]]> http://www.innoq.com/blog/st/2007/11/innoq-event-200711.html http://www.innoq.com/blog/st/2007/11/innoq-event-200711.html Fri, 16 Nov 2007 20:19:15 +0100 Dare Obasanjo: > At this point I realize I’m flogging a dead horse. The folks I know from across the industry who have to build large scale Web services on the Web today at Google, Yahoo!, Facebook, Windows Live, Amazon, etc are using RESTful Web services. The only times I encounter someone with good things to say about WS-* is if it is their job to pimp these technologies or they have already “invested” in WS-* and want to defend that investment.]]> http://www.innoq.com/blog/st/2007/11/ws-is-to-rest-as-theory-is-to.html http://www.innoq.com/blog/st/2007/11/ws-is-to-rest-as-theory-is-to.html SOA, Web Services and REST Thu, 15 Nov 2007 23:27:44 +0100 Dino Chiesa: >Sidenote: speaking of multiple interfaces for the same resource, check out what Amazon did with SQS:  there is a REST interface, a SOAP interface (described in WSDL) and a QUERY interface.   The REST interface is bona-fide REST.  It uses HTTP verbs like (GET DELETE PUT POST), and the URI corresponds or maps to the resource in question, for example the queue you'd like to operate on.   In WCF, to build this sort of interface, you would use a [WebInvoke] attribute on your service interface.  The QUERY interface on the Amazon SQS resource is, like the REST interface, always based on HJTTP, but QUERY is different than REST in that QUERY is always an HTTP GET, and specifies the object and verb in the URI.

Example:

The QUERY request to create a queue:

GET /?Action=CreateQueue&QueueName=Foo HTTP/1.1
Host: queue.amazonaws.com
 
The REST request to create a queue:

POST /?QueueName=Foo HTTP/1.1
Host: queue.amazonaws.com

Some people confuse or conflate REST with HTTP QUERY, but Amazon certainly does not. It doesn't help matters that there is no widely accepted or adopted name for the HTTP QUERY services interface. Amazon calls it HTTP QUERY or justr QUERY but as far as I am aware, that name is not widely used by other systems who expose similarly architected interfaces. How about "Abomination"? ;-)]]> http://www.innoq.com/blog/st/2007/11/soap-rest-whichever-you-choose.html http://www.innoq.com/blog/st/2007/11/soap-rest-whichever-you-choose.html SOA, Web Services and REST Wed, 14 Nov 2007 11:31:29 +0100 Stu Charlton: > WS-* is where CORBA was circa 1997: it will be used to implement some good systems, but there will also be some high profile failures. A number of the specs will likely never be adopted by the mainstream (see WS-CDL, WS-Eventing), though some will definitely improve some ridiculous vendor interoperability disputes (e.g. WS-TX, WS-RM). Plenty of pundits (now bloggers) sing of its imminent triumph (channelling Orfali, Harkey and Edwards), but overall, the framework will not help solve the problem that was used to sell its adoption in the first place: increased agility, reuse, and visibility in IT. I think many WS-* tools actively *hinder* an SOA architect from achieving these goals.]]> http://www.innoq.com/blog/st/2007/11/ws-and-corba.html http://www.innoq.com/blog/st/2007/11/ws-and-corba.html SOA, Web Services and REST Tue, 13 Nov 2007 17:15:39 +0100 A while ago, I criticized GData's batch mode: >Anytime you find yourself adding words like “operation” to your representation, you’ve violated one of the core RESTful HTTP principles, which is that the intent should be communicated using the HTTP verb. Erik Johnson wrote up a reply on his blog: >I’m a big fan of ROA, but I’m worried that ROA fundamentalism will create a quagmire (shared by SOA) where all advice seems to be about what *not* to do. ROA makes it easy to bind the HTTP verb with your intent, but it doesn’t require you to do so. If I define a format for a message that can contain multiple “intentions” and then expose POST endpoint for processing messages, have I broken some Law of ROA? I don’t think so.
I think Erik is right in that we should maybe focus more on what to do instead of what not to do. But first, let me explain my problem with the GData approach in more detail: One of the constraints of REST is the uniform interface, and HTTP mainly implements this constraint with its four common verbs - GET, PUT, POST, DELETE. Each of these have meaning beyond "move bytes from here to there": A GET is safe and idempotent, PUT and DELETE are idempotent, there are no guarantees about POST. What I don't like about the GData batch approach is that it uses POST to send a request body that contains sections with "operation='delete'", "operation='insert'" and so on -- i.e., it mixes up the meaning of the verbs with an overridden meaning in the content. I would like an approach much better that used DELETE, PUT and POST to update a collection resource, possibly with some query string added, to achieve the same, i.e. in some pseudo-syntax (I'm too lazy to lookup GData query format): PUT /entries?month=June ... (with DELETE working the same way), and a POST to the collection root (e.g. entries) to add a number of entries in one step. (Of course this is pretty simplified -- there are still a lot of issues left to resolve, such as the correct response and response codes.) This way, it would no longer be possible to insert, delete and update a lot of entries in a single step -- you'd have to make it three steps, which doesn't seem a big deal from my point of view, and would ensure that you could do the DELETEs and PUTs idempotently. But I haven't tried this out, so in the end it may turn out that Erik is right -- the use of POST yields no guarantees, so maybe (at least in this particular respect) the GData approach might be the more pragmatic choice (and not as bad as I initially thought).]]> http://www.innoq.com/blog/st/2007/11/poking-at-roa.html http://www.innoq.com/blog/st/2007/11/poking-at-roa.html SOA, Web Services and REST Tue, 13 Nov 2007 10:09:16 +0100 Jean-Jacques (JJ) Dubray, a long-time SOA and BPM expert and one of my co-editors at InfoQ, has posted quite a bit about REST -- and his posts are definitely not favorable. I don't really know why, but some of them seem to express the belief that a) there's some serious hype going on about REST and RESTful HTTP, b) it's obvious that both REST and WS-*-style SOA have their place, c) that the RESTafarians (including me), despite knowing better, claim REST is a silver bullet that should be used for everything, and d) and have set out on some sort of crusade against SOA. (If I have paraphrases JJ's recent posts strongly remind me of those of [a certain other gentleman](http://www.scripting.com/) who somehow expects everybody of having hidden agendas and secret motives for doing what they do, instead of doing what they actually believe. I find this somewhat annoying, to say the least. But I have a lot of respect for JJ -- so I'm writing this to try to move the discussion towards more rational ground. First of all -- i.e., addressing (a) -- I disagree there is a hype around REST. "Huh?" I hear you cry - "is this guy serious?" - Yes, I am, because in fact it's a tiny minority that knows anything about REST at all. When I go to conferences (QCon excepted), visit customers, talk to business partners or other consultants, 95% of them have never even heard about REST, RESTful HTTP, or some debate about Web services. In contrast, virtually all of them -- definitely more than 90% -- know about web services. And while some of the vendors have talked about their REST support, this pretty obviously seems to be to ensure the alpha geeks don't turn to other solutions -- I have seen no vendor or analyst throw any marketing dollars behind REST (yet -- this may of course change anytime soon). _Don't confuse the blog echo chamber with reality_. As to (b), it's not at all obvious that WS-* and REST both have their place, at least not from a technical standpoint, and provided what you're trying to achieve is actually what SOA promises: modularization, loose coupling, evolvability, scalability etc. It seems that most of the WS-* proponents who have spent some time looking at REST, listened to the arguments of the REST proponents but never actually tried it out now take this point of view: REST is suited for simple data-access scenarios, while you need WS-* if you want to do "real" business services. _Bullshit._ I am strongly convinced that when you look at architectural merits only, every time you convert even a well-designed web services system to the RESTful alternative, you end up with a better system. It would be nice -- from a diplomacy point of view -- if we could all agree that both alternatives are reasonable, and that the real question is to find the right criteria of when to apply which. But I refuse to agree to such an assertion if I honestly don't believe there are any cases where WS-* is the better choice (exceptions not motivated by architecture follow). We (the RESTafarians) are not stubborn zealots. We're just _right_. Sorry :-) Of course this was just a little polemic. I actually _do_ believe there are a lot of reasons to choose WS-* -- but almost _none_ of them are technical. They are political (e.g. a company may already have spent millions on some WS-* infrastructure), related to costs (switching from existing transactional solutions to REST might require more effort than switching to WS-*), and in some very rare cases -- notably security -- related to stuff that's actually missing from the existing RESTful HTTP tooling. I actually get slightly mad with regards to (c) (we're out to destroy SOA because we're evil!). This is so silly I wouldn't waste time replying, but -- as I said before -- I like and respect JJ, so I'll address this point, too. Right now, I doubt that anyone in the REST camp actually profits from arguing that RESTful HTTP is superior. Most of the time, you just get blank stares; sometimes, people get interested before turning back to the crap they get fed by the vendors. Only very, very rarely someone listens and understands the arguments *and* is actually able to spend some money to have this explored further (i.e. pay for some consulting). It's much, much easier to go with mainstream, WS-* style SOA if you're a consultant. And if you make money through reselling commercial products (or alternatively, through referral fees), choosing REST is absolutely counter-productive. I'm convinced that my company could make _more_ money right now if we simply stuck with the WS-* story. But we don't make choices for business reasons only (otherwise we'd probably do SAP customizing), but also because we believe we're delivering good results if we actually believe in what we sell. And you may call me naïve, but I actually believe that the better solution will win in the long run -- which means that we'll be able to reference existing, successful customer projects based on the Web's architecture when others only start to deal with the WS-* legacy they're responsible for.]]> http://www.innoq.com/blog/st/2007/11/restafarian-soa-killers.html http://www.innoq.com/blog/st/2007/11/restafarian-soa-killers.html SOA, Web Services and REST Mon, 12 Nov 2007 17:38:53 +0100 "About" page for the right one.]]> http://www.innoq.com/blog/st/2007/11/phone-number-change.html http://www.innoq.com/blog/st/2007/11/phone-number-change.html Private Mon, 12 Nov 2007 10:38:44 +0100 InfoQ, 2. insulting WSDL 1.1 (and WSDL 2.0) as well as its creator Sanjiva Weerawarana who was sitting in the row just behind me 3. creating fits of laughter, esp. for Steve Vinoski (who was sitting next to me) 4. presenting some really great technical content. Initially, Jim talked about his view that MEST-style Web services are actually very useful, and that it's the RPC concepts induced by WSDL that turn Web services into a mess. Then he spent some time assaulting both URL-RPC-style and POX-style HTTP misuses, although he found something positive in both -- specifically, the fact that they're dead simple to use. After a brief overview of the REST style, he showed an example of the use of hypermedia to drive the application's state. This was easily the most entertaining talk of the track, and I think it was a great way to conclude the day.]]> http://www.innoq.com/blog/st/2007/11/qcon-sf-jim-webber-a-couple-of.html http://www.innoq.com/blog/st/2007/11/qcon-sf-jim-webber-a-couple-of.html Mon, 12 Nov 2007 07:53:59 +0100