Extending Service Boundaries to Infrastructure Resources

The article appeared in the MSDN Architecture Journal, Issue #21, Sep 2009.

To download a copy of this edition of the MSDN Architecture Journal, click here.

Extending Service Boundaries to Infrastructure Resources

by Nayan B. Ruparelia and Salim Sheikh

With data centers considering infrastructure resources as service-on- demand resources and amalgamating them with application services, we redefine an SOA service as comprising the server-side application and the infrastructure that hosts it.

The business benefits of this type of architecture are twofold—a reduced infrastructure footprint and a lower cost of service delivery— and are enunciated as follows:

  • Commoditization of services enables true SOA-service rationalization that takes place at the service level, instead of separately at the software and hardware boundaries. This reduces the data-center (or infrastructure) footprint for the business and, thus, provides a more environmentally friendly SOA service at lowered costs.
  • Encapsulation of an SOA service across the hardware-software stack provides a complete measure of return on investment (ROI)—from application to infrastructure. This gives a more transparent, accurate, and rationalized view of the cost of a service and its time-to-market (TTM) cost. These factors drive down the cost of an SOA service, because it allows the business to measure reusability of the SOA service across all tiers of IT and, thereby, create a framework for more efficient use of services.

Problem Statement

Generally, an SOA service comprises applications that serve client (or consumer) applications. The management of infrastructure resources that the service consumes—specifically, in relation to capacity and performance—is left to the engineer to plan and model manually. This means that service demands might not always be met within the required time constraints, if the capacity management is reactive instead of proactive; thus, there is a danger that the infrastructure will act as a bottleneck.

Conversely, infrastructure resources can remain idle should the service demand be below that which is provisioned by capacity planning. This represents a waste of money on unused infrastructure. Furthermore, capacity planning and modeling, when performed properly, can itself be a very costly and time-consuming exercise and would need to be performed regularly in order to track changing SOA-service workloads over time. Therefore, a more efficient and cost-effective solution is needed for designing and implementing SOA services.

In this context, we refer to infrastructure resources as the hardware platform and its related services that are required for hosting the SOA applications, not the ESB.

Proposed Solution

We propose an SOA service that makes up the entire hardware- software stack. We term such an SOA service a “composite service element” that would be provided in a virtualized environment, in order to better provision the resources of the service and measure its resource usage.

The host platform (comprising hardware computing resources such as CPU, RAM, and local storage) as well as the operating system would be provisioned as a virtual machine (VM). The VM, as much as the software that it hosts, can be considered a service; we denote this VM as an SOA service element. Furthermore, the entire hardware-software stack can be virtualized to include the storage (such as SAN and NAS devices), the LAN, and the interfaces to both of these. This means that all of the layers in the architecture that comprise the logic, data- access, and data-storage layers can be virtualized and provisioned as part of a single SOA service.

To address performance, scalability, and availability requirements, the VM can be configured in a cluster to provide both integrity and workload sharing. The number of VMs that are used in the cluster would be defined by orchestration software that would instantiate VMs as needed. Indeed, the resources of the physical computer that hosts the VM would also be provisioned to suit demand.

In addition, virtualization of the storage and the LAN means that these components can be provisioned individually to meet the workload demand. Demand forecasting can be performed by instruments that measure the resource requirements and predict their usage over certain timeframes by using various load-prediction models.1 This demand forecast can then be used to drive workflow- automation software (such as the HP Blade Matrix System) that would provision the virtualized resources to meet the predicted demand.

Service-Element Pattern

A pattern is a solution to a common problem that is documented in a consistent format and used as part of a larger collection.2 We propose the service element as a pattern that is defined by a VM; thus, the SOA-service design pattern comprises the producer application and its virtual host.


In this article, we redefine an SOA service as being composed of the entire hardware-software stack; we refer to this type of service as a composite service element. Furthermore, virtualization is used so that we might be able to provision our SOA service in an efficient and complete manner and with the smallest cost overhead possible. Also, our approach predicts the workload demand and integrates it with workflow-orchestration technologies, so as to automate the provisioning of resources that are used by the composite service element. Apart from a reduction in cost, a benefit of this approach is that it reduces resource consumption in an environmentally friendly manner.


For additional information, please refer to the blog of the lead author.


  1. Andreolini, Mauro, and Sara Casolari. “Load-Prediction Models in Web-Based Systems.” ACM International Conference Proceeding Series. Vol. 180, October 2006.
  2. Erl, Thomas. SOA Design Patterns. Upper Saddle River, NJ: Prentice Hall, 2009. Page 86.

Nayan B. Ruparelia (nayan@acm.org) is an IT Architect at EDS, part of Hewlett Packard’s TSG group.

Salim Sheikh (salim.sheikh@gmail.com) is an Independent Consultant and Enterprise Architect, certified in a number of frameworks including TOGAF, Zachman, COBIT and ITIL. He is also a Certified Process Professional and LEAN/Six Sigma practitioner.

One thought on “Extending Service Boundaries to Infrastructure Resources

  1. Hey, I found your blog while searching on Google your post looks very interesting for me. I will add a backlink and bookmark your site. Keep up the good work!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s