That's a good question about centralizations vs. decentralization of services within SOA. Decentralization isn't a requirement for SOA, but certainly it becomes more feasible when adopting the principles of SOA. For example, if you can successfully build stateless, interoperable (i.e., typically SOAP or RESTful), loosely-coupled services, you then have great flexibility as to where those services reside. They could reside all on a single app server, for small environments, or be distributed throughout the cloud. Of course, decentralization brings with it some management complications, but tools such as Nagios or Hyperic can help monitor the uptime of the services (and Esper, the complex event processor covered in the book, can help identify any unusual activity or behavior).
As for the question about my experience, I've been solutions architect primarily within the
Java enterprise software world for a good part of the past decade. My initial experience with SOA began using commercial products offered by vendors such as Fiorano, Progress and CapeClear. However, I soon had come to the realization that many of the emerging open source products at that time had a lot of equivalent capabilities. Further, as open source products matured, their user base soon greatly exceeded those of the commercial vendors. Such a community of users helped greatly improve the open source alternatives, so much so that I found them to be far more stable and well-supported than their commercial cousins (well supported by forums, mailing lists, and often the sponsoring companies support offerings). As commercial vendors have now either been swallowed up by Oracle or gone out of business (like CapeClear), I think it's become apparent that the open source approach really is, in many respects, less risky. This is particular true when working with popular open source products such as those covered in my book -- they have a large community of users you can tap into.
Hope that answers your questions!
jeff
).
