Herbjorn Wilhelmsen

Subscribe to Herbjorn Wilhelmsen: eMailAlertsEmail Alerts
Get Herbjorn Wilhelmsen: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Top Stories by Herbjorn Wilhelmsen

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. There is one common scenario that repeatedly surfaced in many projects: When we model and design services during early stages of SOA adoption we are constrained by current infrastructure and technology. These constraints require that we limit the size of service compositions and the extent of cross-service message exchanges. As a result, each service encompasses more logic and is coarser grained. Our infrastructure improves over time (because of new platform upgrades or new funding for better hardware, etc.). Our existing service comp... (more)

The Case for Single-Purpose Services

Introduction Services are useful, but they come with a price tag. The cost of developing a service is higher than the cost of developing a traditional (non-service-oriented) application, primarily due to the extra work and infrastructure required. Another common concern when creating and consuming services is the possibility of a performance hit. Together these issues hint that even if you've decided to wholeheartedly adopt SOA, you may not want or need to move all your functionality into services. This is where the application Service Encapsulation becomes a focal point as we ne... (more)

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

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. However, for the service architect there are opportunities to establish intermediate layers of abstraction within the service implementation that further foster reduced... (more)

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

Enterprise-wide harmonization is a desirable and ideal target state that fully supports pretty much everything SOA and service-orientation stand for. For those that have achieved such a state, bless your standardized hearts. You have accomplished something that has eluded many others. However, not attaining this state does not mean you cannot successfully adopt SOA. In some circles it has become common to view an SOA initiative as an all-or-nothing proposition that demands an uncompromising commitment to an enterprise-wide transformation effort. For those that subscribe to this vi... (more)

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

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." You can see it introduces the Pattern on our publisher page. When designing data architectures, you can easily end up with different databases or even different database tables containing the same or similar data. This has been the root of many well documented data maintenance and quality issues that helped establish data normalization as widel... (more)