Friday, November 21, 2008

two new (free) SOA books

Two new SOA books have just come out recently. Both are available as free PDFs (after registration):

  • An Implementor’s Guide to Service Oriented Architecture: Seven vendor representatives offer their views on the constituting parts of SOA and best practices. The aspects they examine are service design, registries and repositories, ESBs, runtime management, organizational structures and capability development (team, training). I especially enjoyed the ESB section by Hub Vandervoort of Progress. Hub details different mediation requirements that enterprises have today. He then goes on to demonstrate how these can be addressed with different infrastructure choices, such as ESB.

  • SOA Adoption for Dummies (courtesy of Software AG): The author liken SOA adoption to a space journey: keep the pointy end of the rocket up until you reach weightlessness. I quite like the view on ESB presented in this book - ESB is only one of a kind of SOA intermediation infrastructure - and it doesn't sit in between consumers and providers tying everything together. Rather it exposes services of different size, smell and colour in a homogeneous fashion to the consumer layer.

    Some SOA nerds may squirm after reading the ESB sections in this chapter. If you’re one of them, you may be inclined to have a near-religious belief in the classical view of ESB. In the classical view, an ESB is a critical piece of SOA infrastructure that sits between service providers and consumers. The services themselves are not hosted on the bus. We also strongly believe in the need for such infrastructure and address it in the later section “Understanding Service Mediation,” but we don’t believe that only products with an ESB label have a special right to be that piece of infrastructure.
I also like the following statement on the need for an intermediation layer in an SOA in order to increase flexibility and loose coupling:
    In order to achieve maximum flexibility in your SOA, service consumers should never connect directly to the service implementations in the service-enablement layer. Instead, they should connect to the service interface hosted in a separate service-mediation layer.

No comments: