Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

Web Development

Scaling SOA with Distributed Computing

Robert is the CTO and cofounder of Digipede Technologies, and is an accomplished software architect and entrepreneur with over 15 years experience developing award-winning applications. You can read his blog at http://et.cairene.net and he can be contacted at [email protected]

Daniel is the Director of Products at Digipede Technologies, and has been developing enterprise software on Microsoft platforms since 1990. He blogs about distributed computing at http://westcoastgrid.blogspot.com and can be contacted at [email protected]

Enterprise architects are looking to service-oriented architectures (SOA) to solve a litany of real-world problems—brittle systems with tight interdependencies and language lock-in, data stuck in single-purpose silos, and applications that can't scale to meet growing demand, to name a few. The attraction of SOA is that it builds on the concepts of reusable software components, while emphasizing the service abstraction. This means that ideally, services in an SOA are interoperable, language agnostic, reusable, independent, stateless, autonomous, and publish a clear contract. To enable interoperability, services should be composable, loosely coupled, and standards compliant. These should be your design goals when designing SOAs.

SOA concepts stand in contrast to tightly coupled object-centric architectures such as Distributed-COM or CORBA. To create service components using these technologies, you build a component, define a distributed interface, and distribute the definition of that interface to all clients of that component. Clients of the service would also need to use that same technology. In contrast, SOA resolves many of the limitations inherent in earlier technologies by building on top of standards-based services.

Wise choices for implementation of an SOA can accomplish some of the design goals essentially for free. For example, by relying on standards-based web services as your basic building block, you get an interoperable, language-independent architecture. However, other design goals—scalability, for instance—are not so easy to come by.

SOA and Scalability

To create a scalable SOA requires an analysis of scalability requirements and issues at design time. In working with enterprise clients across different industries, we've found that these include:

  • Properly estimating usage patterns.
  • Managing user authentication/authorization.
  • Managing session state (where applicable).
  • Scaling customer or internal-facing web sites.
  • Scaling data resources.
  • Scaling CPU load.

While some of these issues might apply to the entire SOA, others apply only to specific services inside the greater architecture. Still, the result is the same: You can't build a scalable SOA on top of services that don't scale.

Of course, focusing on scalability needs to be traded off against other goals—budget constraints, transactions per second of a key system, user security, and the like. Unfortunately, we've found that in the planning stages, scalability tends to fare poorly against these other goals. Moreover, it becomes a greater problem during rollout.

By evaluating the requirements and capabilities of services, you better understand scalability hot spots. For example, if your services are stateless, autonomous, short running, and non-CPU intensive, then simple web server scalability options will suffice. However, for services with even moderate CPU intensity (like reformatting a PDF), then these options will come up short.

Time and again, customers have found that, as their services become more available to their enterprises, their usage patterns change dramatically. From the perspective of the SOA, a service implies simultaneous users and disparate usage (perhaps with peak usage and variable work sizes). But does your service know this? Or what if your service requires high availability to your greater enterprise yet also consumes significant CPU time?

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.