Last week I read a book covering SOA (Service Oriented Architecture). I thought I'd share some thoughts with you. "
Understanding Enterprise SOA" (Manning Publications), is written by Eric Pulier en Hugh Taylor. The target audience for this book are managers and technical architects.
Working with web services,
SOAP and mashups with
Google maps or
flickr, I was anxious to learn more about the architectural part of setting up an SOA in applications. Using webservices is one thing, but designing them in an application environment (which usually contains more than one service component) is another. Maybe because of my technical background I was hoping to get some more insight in how you design SOA applications from a functional analyst and technical architect point of view, but as it turns out, the book is more useful for managers than for technical guys.
The book starts with explaining the basic tool set for making a SOA application. Subjects such as
Web services,
SOAP,
WSDL,
UDDI are explained very well. To be able to see the business advantages the book starts explaining some general concepts like open standards, loose coupling, remote procedures and platform independent communication. Although SOA has been a hot topic for the past 2 years, it is also good to learn about how this way of thinking evolved from many other and comparable concepts like
RPC and
EDI that have been around for many years.
The best thing about this book is that it has incorporated a case study of 2 assurance firms merging to one. This case is mentioned in each chapter in a chronological way. The book ends with some chapters on how the SOA implementation worked out at the assurance company. The case study makes the SOA concept more visible and the book more interesting to read.
Some subjects in the book caught my attention: Security and SOAP interceptors.
When using an SOA in a back-office application security is an important subject to think about. Web services are open and usable to everyone who is able to see them. Web services can relatively easy be intercepted and rerouted. The person using a web service cannot natively be tracked or authenticated. An unsecured SOA is also vunerable to DoS attacks.
One possible solution is to work with a SOAP interceptor. A SOAP interceptor is placed in the path of the SOAP messages and is able to authenticate and authorize messages. It can also monitor SOAP activity to prevent flooding. Other security measures which might be used in SOA environments are the Application Proxy, Security Assertion Markup Language (
SAML), Certificates and keys and XML encryption. The concepts of the subjects are all very well explained.
In my opinion the book is very interesting for managers and technicians who are new to the subject. For my next book I will be looking more into analyzing and modeling a Service Oriented Architecture.
P.S. for those interested in SOA in PHP environments, it's a topic on next week's
PHP Business Seminar (Dutch).
Ibuildings Blogs
