The book covers the following open source products, and focuses on how they can be integrated together to form a complete "OpenSOA Platform":
Composite Services/Framework - Apache Tuscany
BPM - JBoss jBPM
ESB/Web Service Mediation - Apache Synapse
Business Rules - JBoss Rules/Drools
Complex Event Processing - Esper
Unit Testing - soapUI
Apart from some knowledge in webservices, I have very little or no background knowledge on the above products. Do you think, the book will still help me understanding the role each technology product plays in implementing SOA, will it help me in understanding the basics of the above listed products?
Also, I see that you have not mentioned web services separately as an opensource product to implement SOA, can you explain that to us.
One vague question in my mind. Is the Web Evolution(Web 2.0, Web 3.0) just because of SOA. I think SOA will be there in all future versions of Web...( did it start with Web 2.0.. ).
This is what I read somewhere..
Web 2.0 = read/write web : people can put their own content
Web 3.0 = semantic web : web applications understand what you want
Web 4.0 = telepatic web : no interface needed, you just think it and know the answer
Web 5.0 = army web: you don’t think, the web thinks for you.
Web 6.0 = android web: robots have taken over the world and humans are now slaves.
Good observation -- you're right, I don't specifically cover web services framework, per se, such as Metro (JAX-WS) or Apache CFX. Instead, that is where Apache Tuscany comes into play. It is an implementation of the Service Component Architecture (SCA), and it provides the ability expose services through a variety of bindings, including SOAP, REST, RSS/ATOM, RMI, EJB and some others. What is novel about the approach is that, when you build the service, you don't specify or include any protocol specific code. Instead, that is done declaratively through some XML files (i.e., that is how you specify which binding to expose your service). I really prefer this approach, as I think it brings great flexibility.
Thank you Jeff..Can you please answer the following questions as well.
1. Does SOA also mean decentralization of system/resources (This question was asked by a rancher in a recent post to you..if the answer is yes, can you give us an example)
2. Do we need to have prior experience with SOA products in order to understand your book "Open Source SOA".
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.
Sorry, I had mistaken what your second question was :-(. No, I don't really assume the reader has much familiarity or background with SOA. In fact, the first chapter attempts to give the reader the general principles and benefits surrounding SOA. That said, I do assume that the reader is familiar with Java and XML, with some understanding of web services in general (though a .NET C# or Ruby developer could probably follow right along). The book is really less on the theory side and more on the implementation side, so there are lots of codes samples etc.
Good that your book has implementation details. It is hard to find books with implementation details now-a-days. I see most of the people talks about theory and it would be tough for a reader to try out each and every tool/framework practically without having any jumpstart.