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@example.com.
Enterprise architects are looking to service-oriented architectures (SOA) to solve a litany of real-world problemsbrittle 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 goalsscalability, for instanceare 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 goalsbudget 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?