SOA Architecture, Governance, and Industry Standards in the Enterprise

Paul Lipton

Subscribe to Paul Lipton: eMailAlertsEmail Alerts
Get Paul Lipton: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: MultiTouch Developer Journal, SOA & WOA Magazine

Multi-Touch: Article

In a Service-Oriented Architecture, Who Will Do the Cooking?

Understanding management trends in the new age of service-oriented architectures

The acclaimed essayist and novelist Nora Ephron once said, "What my mother believed about cooking is that if you worked hard and prospered, someone else would do it for you." Nothing could better capture the spirit of service-oriented architectures (SOAs) than this statement from a person who clearly does not consider cooking a core competency. Translated to human terms, an SOA can help make sure that the right person is doing the cooking at the right time.

The idea of a service-oriented architecture is simple, and much older than any Web services standard. Instead of services being statically bound to each other in some sort of "hard-coded" relationship (which is often the case for many real-world Web service deployments today), in an SOA, service consumers can discover the service providers that they need and use them as required. Typically, information about these other services is stored in a database or directory, often referred to as a registry by the Web services savvy. To reiterate an often-used analogy, this is similar to how consumers can discover needed services in the phone book.

For business, this architecture can serve as a foundation for distributed systems that are far more flexible and responsive to the organization. This is especially important today. Factors such as globalization, higher customer expectations, and increased regulatory pressure have put pressure on IT to be more responsive to the needs of the business, and SOAs are widely held as the key architectural element to making this possible. In short, SOAs are about encapsulating valuable functionality as services made available inside and outside the enterprise, and leveraging those available services to build a better, more flexible, and more useful enterprise IT environment.

A New Paradigm
Certainly many essential services will be hosted within the enterprise, but others will just as surely be hosted by specialists who will provide their own expertise to other businesses. A number of useful commercial Web services in areas such as sales force automation and customer relationship management will undoubtedly appear. Significant business services are likely to be offered by suppliers, government regulators, customers, and partners as well.

An example of one such service that is already taking hold is the use of outsourced geographic services exposed as Web services. This is an increasingly popular option for some businesses. Rather than try to master the arcane geographic arts, these businesses are beginning to focus on their own core competencies and are content to leave other tasks to experts. In the area of geographic services, Microsoft's MapPoint Web service, which handles millions of service requests a day, would be a good example.

Customers today are increasingly mobile. Wireless devices, many GPS-enabled, are starting to flood the market. Most of the vendors of the underlying operating systems in these devices are already committed to including Web services stacks in future releases. This would make the devices even more useful in a world where enterprise SOAs will extend to touch the customers directly.

Given these trends, imagine a company like Starbucks being able to direct its customers to its many locations before they are lured into the storefronts of new and old competitors that have "smelled the money in the coffee." Using an outside specialist service to provide dynamically generated, location-dependent walking or driving directions would be very useful indeed to a company whose view on providing directions is centered on the art of brewing, not driving.

In fact, the trend in IT is not dissimilar from trends in the consumer market. In the latter half of the 20th century, many consumers in industrial societies were unlikely to grow their own food. But recently, consumers have left even more of the "personal business process" of putting food on the table to others. Today there are an increasing number of food delivery options, as well as food markets that offer ready-made food that can be reheated at home. This allows busy consumers to focus on what they feel are their own personal priorities - their "personal core competencies" - such as raising children, pursuing careers, or painting pictures, rather than taking valuable personal time to cook. Clearly Nora Ephron knew more about IT trends than she was letting on when she made her prescient comment about cooking!

If Web Services Are the Trees, then SOAs Are the Forest
In the past, IT organizations focused primarily on the idea of using Web services to enable cheaper, more effective point-to-point integration. Now the idea has taken hold that Web services play only a part (albeit a very important one) in the larger, more strategic stage production called an SOA. How do Web services management/security products need to evolve in order to meet the needs of a service-oriented world? In other words, if Web services are the trees and SOAs are the forest, how do we manage the forest and how do we manage the other types of trees that live in the forest?

One of the great things about Web services standards is that they have been designed to support the idea of an SOA. In particular, the UDDI standard defines a registry for services, the WSDL standard defines a mechanism for service description that can be stored in the registry, and the SOAP standard defines the basic message format for information exchanged between services. However, despite the fact that Web services provide good mechanisms for building an SOA, in practical terms it is likely that not every service in many real-world enterprise SOAs will be a modern SOAP-based Web service.

While enterprises today often look forward to large, enterprise-scale SOAs or even multi-enterprise-scale SOAs, clearly less extensive SOAs have been successfully built and deployed using many other technologies, including CORBA, Java RMI/IIOP, and DCOM. Although Web services are already more widely accepted and supported by most commercial applications and software vendors, it is not likely that all existing services based on these older technologies will be converted to Web services, at least for some time to come.

There are many reasons for this decision to defer or avoid conversion to modern SOAP-based Web services. The cost of conversion to Web services may be considered too high relative to the benefit accrued, or it is impossible that it will be higher performance or other unique characteristics of the older technology (likely based on more efficient proprietary binary protocols) that will drive the decision to build or extend a heterogeneous enterprise SOA. A heterogeneous enterprise SOA would preserve some of the diversity of different standards and technologies already present within the enterprise while still embracing new Web services standards and technologies whenever possible and practical.

Practicality and cost are, indeed, the cornerstones of this approach. While the long-term goal might still be a technologically purer SOA based entirely on Web services, the short-term practical goal would be tolerance of diverse underlying protocols and technologies as part of the larger SOA. After all, even WSDL and UDDI support far more than just SOAP-based Web services.

If Web Services Are the Trees, What Are the Roots?
Web service management products can help ensure that Web services are visible and controllable. My recent articles (see Resources) have discussed many aspects of Web services management, such as the need for such products to be deeply integrated with enterprise management solutions in order to provide true root-cause analysis, and to provide the visibility and correlation necessary to understand and correct the real cause of any service disruption.

The principle is simple. Web services encapsulate business logic that does the real work as part of the traditional IT infrastructure - the heavy lifting, if you will. It is this underlying business logic that accesses databases, executes complex logic and business rules, and so on. Such business logic can function only when existing hardware (such as routers and disk drives) and software (such as operating systems and a wide range of diverse servers) function properly.

Web services exist at a logical level above the other logical layers of the IT infrastructure. Logical constructs like SOAP messages, identity, service description, and so on are logically independent, but are also highly dependent physically on lower layers such as TCP/IP. So, at least for Web services deployed within the enterprise, the Web services management products must do two things. They must function at this higher, logical level of Web services and must also be deeply integrated with the enterprise management solution responsible for the rest of the IT infrastructure. This is necessary in order to understand and correlate events and concerns at all logical and physical levels. Ideally, the two levels of management - Web services and the rest of the IT infrastructure - while independent, would function as one from the point of view of the IT operations staff. In practical terms, it would be wise to recognize the justifiable reluctance of IT operations staff to have multiple management consoles - rather, they would work through the same familiar enterprise management console using common terms and nomenclature.

Managing the SOA Forest - Active Management and Scale
While Web services can be deployed as a point-to-point integration solution, enterprise SOAs are, by definition, dynamic and flexible. Such an environment requires an active management approach. To understand what active management is, it is best to begin by understanding what it is not. Active management is not about transformation, routing, load balancing, or other functions often provided since the early days of Web services by various software-based brokers and proxies.

Why are these functions not considered active management? In the cases of transformation and load balancing, there certainly is activity. Aren't these functions important in an SOA? Certainly, they are still important and need to be performed, but active management refers to the ability of a management system to optimize the state of whatever is being managed based on policies and rules defined in the management system.

Think of a system that controls the temperature, oxygen content, and lighting in a large outdoor aquarium. Even in this simple example, the policies that define a healthy environment for fish and plants in the water are clearly defined. The "agents" are the temperature and oxygen sensors in the water as well as the various switches and valves that are regulated by the management system. This is an active management system - actively manipulating the infrastructure of the aquarium based on metrics and policies. More advanced versions of such a system might include predictive analysis features to anticipate fish breeding patterns, and so on. Treating this system as an SOA and extending it to weather services might allow further optimization and responsiveness by leveraging the real-time forecasts provided by these services, but the basic principle of active management of the environment based on observed metrics remains the same.

Going back to functions like transformation, load balancing, and routing, these functions are already being subsumed by a new generation of XML hardware appliances designed and optimized for those purposes. This trend is similar to what happened with TCP/IP. Initially, it might have seemed reasonable to route and perform other functions in simple software brokers, often written quickly to leverage what was then an exciting new protocol. But these days nobody would dream of performing these functions without a box made by Cisco or another hardware vendor.

By the same token, nobody today would mistake the functionality of those boxes for a comprehensive enterprise management solution. Leading enterprise vendors can continue to rest easy knowing that the capabilities they provide in their own solutions were not made irrelevant by the deployment of hardware-based TCP/IP routing, load balancing, and so forth in these boxes! In fact, quite the opposite is true since these new devices became yet another point of potential failure that needs to be visible and controllable, just like the rest of the managed IT infrastructure.

Similarly, while simple routing and transformation tasks can probably be done at reasonable speed on the various platforms used to develop and deploy services such as integration servers, application servers and enterprise service buses, a new generation of hardware XML appliances from companies like DataPower, Forum Systems, Reactivity, and Sarvega are already performing these same functions at near wire-speed for XML-based services. The move to hardware-based solutions for transformation, routing, and load balancing as well as other simple functions is likely to be universal and quick. For many applications, especially large-scale ones, XML parsing and transformation is a computationally expensive process best accomplished with hardware-based acceleration.

The challenge, of course, is to make sure that these devices, which function at the service level, are themselves fully integrated into the SOA management solution. That is, of course, the best role for these devices - as fully managed gateways just like the TCP/IP devices, often deployed in the enterprise's DMZ, between inner and outer traditional firewalls. Such devices would work as full agents (sometimes called observers) of the SOA-level management/security solution. They would work with the SOA management/security system to obtain and then act upon identity information and policy - reporting faults and errors, metrics, and more to the management system. The management system would present one common management and security console for such instrumented XML gateways, as well as for agents deployed on the service platforms themselves (see Figure 1).

Managing the SOA Forest - The Challenge of Heterogeneity
What about heterogeneous SOAs, as discussed above? Their diversity will undoubtedly increase as heterogeneous enterprise SOAs continue to grow. The growth rate will only accelerate as these SOAs begin to extend beyond the world of back-end systems to include mobile consumer devices. It will be some time before they all have full Web services stacks of their own. Many platform vendors will take an incremental approach - initially coping with platform limitations with various compromises and offering their own unique, idiosyncratic implementations.

If SOAs will often be heterogeneous - a practicality dictated by the need to support multiple protocols and types of services - how can we manage this diverse distributed environment? Web services management products in this new world must become unified SOA management and security solutions that can readily be adapted for many different types of services, not just Web services. This will require a new approach to how management agents are created.

The sheer diversity of some SOAs will mandate that it become easier for customers and their consultants to develop their own agents for these specialized platforms and technologies. Some sort of easy-to-use agent development kit will almost certainly be a necessity so that new agents can be created quickly and easily. Management vendors, in order to be serious partners for their customers building heterogeneous SOAs, must also offer comprehensive end-to-end management capability from wireless to Web services and beyond, encompassing the entire SOA and its underlying IT infrastructure.

For example, Computer Associates has released the next generation of CA WSDM, a standards-based SOA management and security solution with suitable improvements for the world of heterogeneous SOAs, including a new mechanism to build new types of WSDM agents. But CA also integrated WSDM with it's Unicenter brand, which offers comprehensive IT infrastructure management, wireless management, and so on. To do otherwise would be to leave blind spots and unmanaged areas in the SOA that would be bound to increase risk, perhaps severely. Other leading management vendors are already following suit - many beginning to integrate third-party security and wireless solutions that will likely result in more solutions in the new area of SOA management.

Managing the SOA Forest - Management as a Service
The trend toward SOAs begs the interesting idea of making SOA management available as a subscriber service. Truly, for at least some applications, this could be an appealing option. Significant information could be obtained about a service remotely without the need to install any agent at all. Since SOAs are message based, metrics about availability could certainly be obtained and analyzed statistically based on messages sent remotely by clients that are monitored by an SOA management system. These messages could be sent periodically over widely spaced intervals so as not to impact overall service performance by overloading the underlying systems.

This remote assessment could be used to obtain important information about the consistency of a service (how much it varies in its performance) over time. Consistency is a particularly important aspect of a service. Suppose that a service typically offers very high performance (say less than one second), but occasionally responds very slowly (say one minute). It might be possible that the average and mean performance measurements would still be fairly high. Nevertheless, every once in a while we might have a tremendously dissatisfied customer. Over time, that can add up to many angry customers for a service that still, on average, appears to be performing adequately.

This remote assessment of a service's availability and consistency could have some unique benefits. A neutral management authority could be used to provide outside service customers independent assurance that a service being provided is meeting availability and consistency levels. Also, such a service could be used to compare functionally equivalent services against one another - sort of like a rating service. CA has announced such a service, the Web Services Performance Index (see Resources). Other leading vendors have already publicly stated their commitment to the idea of SOAs and to the importance of services in general.

Ultimately, such management services could be used to remotely communicate with deployed agents so that deeper analysis, alert notification, and other functions requiring an agent can be administered in an outsourced fashion. Such solutions might be particularly appealing to small and medium-size companies that do not wish to administer and deploy an SOA management solution. The upcoming OASIS WSDM standard (see Resources) will provide a huge boost to this by providing common management interfaces that will simplify the task of remote service management substantially, thus accelerating the acceptance of management as a service.

Beyond the SOA Forest - Universal Manageability
As a wide range of IT resources become virtualized (encapsulated and managed by Web services), the strong possibility exists that we will be able to extend active SOA management principles in both a broader and a deeper fashion. Ultimately, SOA management will be comprehensive - covering how an entire enterprise and its partners, suppliers, regulators, and customers, do business together.

This is really the central promise of the on-demand and Grid computing standards and solutions that are coming together. It would not be possible without management. Management is the cornerstone of any such environment.

So it's not useful to ask who will do the cooking in a service-oriented architecture. Everyone who needs to do the cooking will do so. The more important issue is how we will ensure that any cooking that needs to be done will be performed in a fashion that is truly adequate to our needs. And for that you need management.


  • Lipton, Paul. Web Services Journal, March 2004 (Vol. 4, issue 3). "Snow White's FIRST Web Services (A Cautionary Fable for IT Management)."
  • Lipton, Paul. Web Services Journal, February 2004 (Vol. 4, issue 2). "Composition and Management of Web Services."
  • OASIS WSDM standard:
  • CA WSDM:
  • CA Web Services Performance Index:
  • More Stories By Paul Lipton

    Paul Lipton is VP of Industry Standards and Open Source at CA Technologies. He coordinates CA Technologies’ strategy and participation in those areas while also functioning as part of CA Labs. He is co-chair of the OASIS TOSCA Technical Committee, and also serves on the Board of Directors of the open source Eclipse Foundation, as well as both the Object Management Group and the Distributed Management Task Force in addition to other significant technical and leadership roles in many leading industry organizations such as the OASIS, W3C and INCITS.

    Lipton is also an approved US delegate to the international standards organization ISO, as a member of the subcommittee focused on international cloud standards. He is a founding member of the CA Council for Technical Excellence where he leads a team focused on emerging technologies, a Java Champion, and Microsoft MVP.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.