Just done with Service Oriented Architecture with Java by Binildas Ca, Malhar Barai and Vincenzo Caselli. It's a good hands on type of book, lots of examples using Java. The book also does a good job of laying out service definitions and contrasting styles of architecture. I really liked their practical examples of hybrid contract design which is something we do. The one thing I didn't agree with was the contrast between EAI and SOA styles of architecture. But that's okay I usually don't agree with people's interpretation of EAI. It's not a big book so it's fairly quick to go through.
The other book that just arrived is Web Service Contract Design and Versioning by Thomas Erl and a slew of others. This book gets down into the details of contract design which is long overdue. I just got it so it will be a while before I can get through the whole thing. It's a really big book.
2 comments:
Hello Mark,
Could you please let us know what exactly you disagreed on? Will try to clarify in the next edition.
Thanks
Malhar Barai(Co-author)
Malhar,
As I said in the review, very nice job on the book. The section on case studies where you contrast EAI and SOA I didn't quite get completely. EAI like SOA is a style of architecture and not a system. True you can buy a platform for EAI implementations but that is separate from the architecture much like SOA.
The key points I had issues with:
-Proprietary Architecture: If you buy a proprietary system to implement your EAI I guess that is kind of true, however the same can be said for SOA. The physical implementation of a service can be done with a standards based public interface using web services but the underlying implementation can be proprietary (and often is).
-Messaging Bottlenecks: Really didn't understand this one. Not sure what messaging systems you are use to but the ones I use run circles around anything http enabled like web services.
-Tight Coupling: Principals behind EAI are designed to eliminate the tight coupling. Businesses are not tied together via hubs and adapters but rather through abstracted messages and common data models much like SOA. Yes EAI has an adapter concept but that's for the last mile and SOA based services can and do use similar technology for the last mile as well(unless the vendor has provided a "standards based interface".
-Non-Flexible Architecture: Again EAI is designed to get rid of this problem. System don't know about each other if done correctly.
-Manpower: Don't disagree with that however good service designers are pretty hard to come by as well although books like yours will help hopefully.
Overall I think a lot of issues with interface design in the SOA world have a lot in common with interface design in the EAI world. If done incorrectly the problems you point out with EAI also exist with SOA. Abstraction, reuse and loose coupling are not default settings.
Post a Comment