Big thanks to everyone who came to Manchester Geek Night last week to hear me shamelessly plug my forthcoming book. The slides are now online, for your perusal at a more leisurely pace (and perhaps with slightly less invective).
What will the title of the book be, or ISBN?
I've been looking for it on Amazon, but without luck, and they often show books long in advance.
regards,
Jan
Hello Jan,
The only place on the Internet that our book is visible is within our SVN repository :-)
Right now we're about 3/4 way through a first draft, and hope to be complete in the next few months. Our working title is "GET /Connected"
Jim
Hi Jim,
Thanks for the talk, which I much enjoyed. Your plug may have been of limited use since I didn't actually get the title of the book until I re-read the slideshow. ;-)
One thing I am still curious about is REST when you need to integrate existing legacy systems (which is more often than not the typical SOA scenario - at least, in the literature it seems to be). For instance, we currently have multiple existing green-screen systems in different businesses within one global organisation. These systems produce csv-ish output which needs to be parsed and transformed into the canonical XML format expected by our service. The load on our service can be peaky, and so it's been implemented asynchronously. In this case I struggle to see how you can avoid having some sort of middleware for transformation, routing and correlation. And if you need that middleware, isn't it just semantics whether you call it an ESB or not? What would be the guerilla SOA solution to this problem?
Hello Simon,
If you need infrastructure to do transforms and so on, then hide it behind your service interface (whether it is a WS-* or Web service isn't important in this case). This isn't semantics, unless you consider encapsulation a matter of semantics :-)
In some situations the Web deals with peak-y loads really well, especially where those peaks are on read-mostly or shareable information.
The Guerrilla SOA solution to this problem (in short) would be to engage in a skirmish to create a facade around your service and help clients migrate to it using consumer-driven contracts.
But having a service interface which accepts a number of formats and transforms them internally seems less encapsulated than putting those transformations closer to the producers of the formats and keeping the actual service endpoint "clean". The clients in question can't be made to migrate to the service contract because these are legacy systems that can't change.
You know ... you really didn't get to plug your book enough. Cheers for doing the talk. I guess I'd seen quite a bit of it at the IoD before, but was still good. Was good to re-emphasise REST. I back in work and there's methods that arn't atypically RESFful now, and it feels wrong. Maybe I should get the book when it's out. Til next time....