Latest News from Herbjorn Wilhelmsen

The Case for Single-Purpose Services

Mon, 14 Sep 2009 17:30:00 EDT

Justifying the extra investment for developing a single-purpose service – a service expected to solve only one large business problem - instead of putting the single-purpose logic inside a non-service-oriented application can be challenging. Reuse, the most popular motivation for creating services, will not apply. So where's the business case? Acceptable justifications can include: enabling support for multiple providers, isolating logic from change, centralizing IT-support for a given business process, service composition optimization, and separation of concerns. Although performance is commonly referenced as a reason to not create services, that line of thought is not always valid. With the help of patterns referenced from the recently published SOA Design Patterns book [REF-1] and the soapatterns.org site [REF-17], this article will delve into these issues as we explore the case for the single-purpose service.

SOA Pattern of the Week (#5): Service Decomposition

Tue, 07 Apr 2009 08:45:00 EDT

A service inventory is a living body of services that individually will need the freedom to evolve independently over time. What we learned when documenting the SOA design pattern catalog is that there are patterns that emerged not only at design-time but also during this post-implementation evolutionary stage in a service’s lifecycle.

SOA Pattern of the Week (#4): Service Normalization

Fri, 27 Feb 2009 11:30:00 EST

Like data normalization, the Service Normalization pattern is intent on reducing redundancy and waste in order to avoid the governance burden associated with having to maintain and synchronize similar or duplicate bodies of service logic. When designing data architectures, you can easily end up with different databases or even different database tables containing the same or similar data.

SOA Pattern of the Week (#3): Domain Inventory

Mon, 16 Feb 2009 10:30:00 EST

The internationally acclaimed book "SOA Design Patterns" (Erl et al., ISBN: 0136135161, Prentice Hall, 2009) documents a catalog of 85 patterns and is the latest title in the “Prentice Hall Service-Oriented Computing Series from Thomas Erl” (www.soabooks.com). Thomas Erl, the world’s top-selling SOA author, spearheaded the community effort behind the creation of SOA Design Patterns. In development for over three years, the catalog has been subjected to comprehensive reviews by hundreds of industry professionals, employed by many of the world’s leading technology companies. This book was released in coordination with the launch of www.soapatterns.org, a community site dedicated to the on-going development and expansion of the SOA patterns catalog. The "SOA Pattern of the Week" article series is comprised of original content and insights provided to you courtesy of the authors and contributors of the SOA Design Patterns book and the SOAPatterns.org community site. Each article provides a summarized description (600-800 words) of one pattern with some new insights to complement and build upon the content in the book.

SOA Pattern of the Week (#1): Service Façade

Wed, 11 Feb 2009 11:54:00 EST

One of the fundamental goals when designing service-oriented solutions is to attain a reduced degree of coupling between services, thereby increasing the freedom and flexibility with which services can be individually evolved. Achieving the right level of coupling “looseness” is most often considered a design issue that revolves around the service contract and the consumer programs that form dependencies upon it.

SOA Pattern of the Week (#2): Non-Agnostic Context

Wed, 28 Jan 2009 16:20:00 EST

Should a service only be considered a service if it's reusable? The answer to this question, as asserted by this pattern, is a firm "no." While agnostic services (services providing multi-purpose logic with reuse potential, as per the Agnostic Context pattern), receive the most attention during service modeling and design phases, it can often be short-sighted to focus only on agnostic service logic.