ServiceTechMag.com > Issue LV: October 2011
Download Issue
Download Full Service Technology Magazine PDF




Thunder Clouds: Managing SOA-Cloud Risk

Philip Wik

Philip Wik

Clouds in nature are both the wonder and the sorrow of humanity. White puffs drift across blue skies and streaks of neon and gold at dusk are a sight of beauty and awe. But the days pass and we see the violence of tornadoes, blizzards, and hurricanes. And even fog as gentle as cat feet can send trucks off cliffs and ships into rocks. Commercial clouds provide leanness and savings, extend service-oriented principles, and represent a shift in how we practice information technology (IT). But SOA-clouds (SOA-C) can also expose us to loss. The purpose of this article is to explore why clouds are inevitable, where they can fail, and how we can mitigate risk. We'll discuss the following: Clearing the Mists: Definitions, Drivers, and SOA; Thunder Clouds: Challenges and Solutions; Cloud Contracts: Trust and Consideration; Conclusion: Blue Skies. Information technology clouds are a figure of speech. Fog with cat feet conjures an image in the same way that IT clouds conjure an image. We have a vague idea that our wattage comes from reactors, water, wind, or diesel and have no control over the grid that transmits that power. The power company cares only that we pay for that current and we care only that it's reliable and cheap. Services that were once tangible are now virtualized in the same way that electricity is a service. This metaphor speaks both to the goal of hiding the operating of services from those who consume those services as well as to the haze and hype that surround clouds. The internet delivers cloud services using virtual machines that abstract its delivery from the hardware. The deployment of enterprise computing has changed only glacially since the days of the IBM System/360 when children were watching pre-industrial and futuristic cartoons on their rabbit ear television set. Bedrock's data centers have concentrations of hardware with rising fixed costs but little elasticity in response to changing market conditions. Human resources consist of mole farms of on-site staff. Orbit City's data centers share infrastructure, storage, and development just-in-time resources through clouds as represented by...


Mapping Service-Orientation to TOGAF 9
Part IV: Applying Service-Orientation to TOGAF's Service Contracts

Filippos Santas

Filippos Santas

In this series of articles we examine the correspondence and synergies of service-orientation and The Open Group Architecture Framework. In parts I and II of this article we went through the phases related to architecture definition, service design and implementation, architecture adoption and vision, the main roles, and the implementation and governance of multiple service inventories using hierarchies of the TOGAF ADM. In the process, we also examined the synergies between the two methodologies. In the last article of this series we examine the level of abstraction that is necessary to apply service contracts in TOGAF, using service-orientation principles and patterns. One of the primary focal points of the service-orientation paradigm is the design and standardization of service contracts. In TOGAF and in SOA, the contracts are important in communicating and enforcing functionality, policy/structure requirements, and constraints between different pieces of heterogeneous software. The favorite metaphor used for describing the ability of service contracts to provide a healthy provider/consumer relationship, is the way in which business contracts establish an agreement and maintain trust in a commercial relationship between parties. The difference between service-orientation and TOGAF is how detailed this agreement is, and how the provider and consumer interact. Service-orientation recommends a high level of abstraction for the information provided in the contract. This is because one service should be used by many different kinds of consumers (Service Reusability principle). In order to accomplish the desired level of abstraction without compromising the precision or usefulness of the information in the contract, service-orientation applies principles such as the Standardized Service Contract and the Service Loose Coupling early in the analysis process. On the other hand, TOGAF considers contracts to be unique to a specific provider/consumer relationship, and they act as the container for both formal policies, as well...


Understanding Reuse and Composition: Working with the
Service Reusability and Service Composability Principles

Thomas Erl

Thomas Erl

This article is a modest collection of excerpts from three books in the Prentice Hall Service-Oriented Computing Series, combined to provide a concise overview of what lies at the very core of the service-orientation paradigm and the service-oriented architectural model: the identification and aggregation of agnostic logic into reusable and composable units. These units represent the foundational moving parts that collectively define and enable service-oriented solutions. Understanding how they are realized and then subsequently (and repeatedly) utilized is the most essential requirement to successfully benefiting from anything that SOA has to offer. The upcoming sections explore this topic area by focusing on the Service Reusability and Service Composability principles, as they are applied to the early stages of service modeling and design, and how they are further supported by key design patterns. The SOA design patterns catalog establishes a set of foundational service patterns responsible for identifying and defining the scope of functional service contexts and boundaries, as well as service capabilities. The majority of these patterns pertain and lead to the definition of agnostic logic suitable for reuse and therefore subject to the Service Reusability principle. As explained in the upcoming sections, the combined application of these patterns essentially carries out the separation of concerns in support of the service-orientation paradigm. The separation of concerns theory is based on an established software engineering principle that promotes the decomposition of a larger problem into smaller problems (called concerns) for which corresponding units of solution logic can be built. The rationale is that a larger problem (the execution of a business process, for example) can be more easily and effectively solved when separated into smaller parts. Each unit of solution logic that is built exists as a separate body of logic responsible for solving one or more of the identified...


2017 2016 2015 2014 2013 2012 2011 2010 2009 2008 2007 2006