<?xml version="1.0"?>
<rss version="2.0">
<channel>
  <title>Coding the Architecture - webservices tag</title>
  <link>http://www.codingthearchitecture.com/tags/webservices/</link>
  <description>Software architecture for developers</description>
  <language>en</language>
  <copyright>Coding the Architecture</copyright>
  <lastBuildDate>Mon, 21 May 2012 09:41:00 GMT</lastBuildDate>
  <generator>Pebble (http://pebble.sourceforge.net)</generator>
  <docs>http://backend.userland.com/rss</docs>
  
  
  <item>
    <title>Book Review - Understanding Enterprise SOA</title>
    <link>http://www.codingthearchitecture.com/2006/05/02/book_review_understanding_enterprise_soa.html</link>
    
      
        <description>
          &lt;p&gt;
If ever there was an overused three-letter acronym, SOA would be it. Sadly few people that use the acronym actually
understand what it really means. Managers think that it is the answer to &lt;i&gt;all&lt;/i&gt; of their problems (&#034;Let&#039;s just
get one of those SOA things in&#034;), and developers assume that it is &lt;i&gt;just&lt;/i&gt; exposing everything as web services
willy nilly. This book aims to cut through the hype and get to the truth behind the acronym.
&lt;/p&gt;
&lt;p&gt;
Initially it seems that the book is targeted towards management types, but it soon becomes apparent that there is
plenty in there for the technologists amongst us. Sure, there are no implementation examples, but this means that
the book is able to concentrate on the real issues behind SOA rather than the Hello World examples that so many books
turn to.
&lt;/p&gt;
&lt;p&gt;
The book is told as the story of the IT sprawl that is Titan Insurance. Titan face the same problem as a lot of large
IT organisations in that they have a lot of disparate systems that all need to work together to be effective. The
book presents the case for creating an SOA based on Web services standards to achieve the integration, and presents
many compelling arguments as the why this is the right way to go. The use of a recurring example through the book
helps to give good context to the explanations which is something that is missing from so many IT books at this
level.
&lt;/p&gt;
&lt;p&gt;
As an architect trying to sell the SOA dream, this book presents &#034;ready-canned&#034; arguments that you can use, and
plenty of technical information to back it up. This book explores both the technical and organisational issues behind
SOA and is not afraid to highlight the parts of the puzzle that are not quite ready for the prime-time yet, and
preempts most of the questions that people will typically ask you about SOA.
&lt;/p&gt;
&lt;p&gt;
Rarely is an IT book a compelling read, but some how this book manages to be just that. I believe that I gained
something from each and every chapter in this book. I think that the primary thing that I have learnt from this book is that employing an SOA is a great way to reduce coupling between systems (be they legacy or not) and also a good way to avoid the vendor lock-in associated with other EAI techniques. I also learnt that there is a fair way to go in some areas before this is an &#034;easy&#034; way to go, mainly regarding security.
&lt;/p&gt;
&lt;p&gt;
&lt;h3&gt;Conclusion&lt;/h3&gt;
If you are a developer looking to understand the nuts and bolts of web-services, then this book is certainly not for
you. If, however, you are a looking to understand the hype behind SOA and to be able to have a reasoned argument for
or against it&#039;s adoption, then you should give this book a read.
&lt;/p&gt;
        </description>
      
      
    
    
    
    <comments>http://www.codingthearchitecture.com/2006/05/02/book_review_understanding_enterprise_soa.html#comments</comments>
    <guid isPermaLink="true">http://www.codingthearchitecture.com/2006/05/02/book_review_understanding_enterprise_soa.html</guid>
    <pubDate>Tue, 02 May 2006 15:31:40 GMT</pubDate>
  </item>
  
  </channel>
</rss>

