Jeff Davis' SOA Ruminations
Author of Open Source SOA (http://www.manning.com/davis/)
Open Source SOA. June 2009.
My book Open Source SOA, was published June 2009 by Manning Publications. It is a practitioners guide for how to build a SOA platform using entirely open source products.
-
Open Source SOA hits the press!
Posted on May 18th, 2009 1 commentAfter what seems like an enormous journey, my book Open Source SOA
has finally been sent to the press. From what I’ve been told, it should be generally available on June 2nd, 2009 (released to coincide with the JavaOne.conference). Of course, if you just want an electronic copy, that can be purchased directly from Manning Publications.
Bonus Chapter 13
I am still working on completing the bonus chapter 13, which covers Registries. This was delayed a bit due to awaiting the release of the 2.0 Registry product by WSO2. This chapter, when completed (probably in the first week of June), will be available for download on this site.I look forward to everyone’s comments and feedback!
Thanks,
jeff
-
Sun's Disappointing Cloud Announcement
Posted on March 18th, 2009 1 commentSun today announced some specifics about its new cloud initiative, and I must say, I was pretty disappointed, particularly in the details about their API. Apparently they are supporting only “RESTful” APIs, thus effectively limiting their audience to non-enterprise customers. Why do I say this? If you’re using products like BizTalk, or any of the multitude of ESBs out there, you know that working with SOAP-based APIs is a FAR more straightforward proposition. In many cases, the tooling will simply suck in a WSDL, and a graphical mapper makes developing the interface touch points very simply. Of course, testing is far easier as well using SOAP-based APIs, since open source tools like soapUI are so elegant and simple to work with. Not to mention, of course, if you’re using any BPEL for orchestration, you’re out of luck with REST.
Quite frankly, it baffles the hell out of me why anyone now would develop a greenfield API and not plan on supporting a multitude of protocols “out-of-the-box”. For example, if you use Apache Tuscany, you get automatic support for REST, SOAP, JMS, JSON, RSS without having to write any protocol-specific code whatsoever. You develop your components using any multitude of languages, and then declaratively, in XML, define how you want to expose them as services.
Instead, what Sun has done is effectively alienate a good part of the possible user community, and instead focus on non-enterprise users who use scripting languages such as PHP, Ruby and the like (nothing against scripting languages, as I use them all the time myself, such as Groovy). I just can’t envision why you wouldn’t support multiple protocols from the get-go.
I must say, Amazon has shown a lot more enterprise savviness than Sun — who’d have thunk!
If you want to learn more about Tuscany, the official website is obviously a great place to start, or simply buy my book!