Export (0) Print
Expand All

Architectural Issues in Managing Web Services in Connected Systems


Max Morris and Frederick Chong
with Jim Clark and Dave Welsh

September 2005

Applies to:
   Enterprise Architecture
   Solution Architecture
   Service Oriented Architecture (SOA)
   Service Oriented Management (SOM)
   Application Integration
   Business Process
   Business Operations Modeling

Summary: The Architecture Chronicles on Dynamic Modeling: Aligning Business and IT seek to present to business, solution, and infrastructure architects a holistic and integrated approach to aligning business and IT through dynamic modeling to achieve better performance, accountability, and business results. The authors propose and develop a framework that seeks to address how to coordinate people, process, and technology issues throughout the service life cycle, presenting a simplified view into Web service goals and examining issues of Web service life cycle management, Web service health management, Web service deployment, and Web service identity and access management. (31 printed pages)


This Document
What's a Connected System?
Management Challenges with Connected Systems
Dynamic Systems Initiative
Perspectives on the Service Abstraction
Demystifying Web Service Management
Web Service Management Framework
Web Service Life Cycle Management
Web Service Health Management
Web Service Deployment Management
Web Service Identity and Access Management
Web Service Management Using Web Services

This Document

This document is part of the Architecture Chronicles on Dynamic Modeling: Aligning Business and IT. This volume seeks to present to business, solution, and infrastructure architects a holistic and integrated approach to aligning business and IT through dynamic modeling to achieve better performance, accountability, and business results. The information map to the series provides an up-to-date description and cross-index of the information available and can be found at the Microsoft Architecture Resource Center.


This document examines architectural issues in managing Web services in connected systems. The broader contexts of the Dynamic Systems Initiative and connected systems are considered. The business goals of a Web service and how it should be managed to achieve them are considered from resource and business collaboration perspectives. A Web service management framework is proposed that serves to address topics such as the Web service life cycle, Web service health management, Web service deployment management, and Web service identity and access management.


Many thanks to Nelly Delgado for her help with technical writing, Claudette Siroky for her graphics skills, and to Tina Burden McGrayne for her copy editing.

The authors would also like to thank Michel Burger, Bala Balabaskaran, and their colleagues on the Connected Services Framework for their contribution to the discussion on resource modeling.


Like most important IT initiatives, managing Web services requires the balanced coordination of people, process, and technology.

We begin this document with the broad context of discussing what distinguishes a connected system and identifying what role Web services play in connected systems. We then offer a brief introduction to the Dynamic Systems Initiative to give further context to the complex tasks in managing distributed applications such as connected systems.

Next, consider how to determine what the goals of a Web service actually are to help pin down more formally why and how a Web service should be managed. We consider several perspectives as illustrations, including the resource perspective and the business collaboration perspective.

The model-based development and management approaches suggest that a framework for Web service management addressing management states, actions, and rules can be overlaid onto existing IT service management systems.

We propose and develop such a framework that seeks to address how to coordinate people, process, and technology issues throughout the service life cycle. After taking a simplified view of one of the perspectives of a Web service's goals, we examine issues of Web service life cycle management, Web service health management, Web service deployment, and Web service identity and access management.

What's a Connected System?

In the most general sense, a distributed system is a set of related software and hardware resources working together to accomplish a common function.

There are many different types of distributed systems. Computer networks, clustered databases, massively parallel computers, and the World Wide Web are all examples of distributed systems. One particular type of distributed system is a distributed application, where the components collaborate on a set of related computational tasks in a transparent and coherent way.

A connected system is an emergent type of distributed application. This type of application is increasingly common nowadays as business owners and developers seek to connect people, processes, and information into effective value chains. Connected systems are characterized by how they combine several recurring logical capabilities in a similar and coherent way. These capabilities include rich user-computer interaction, service-oriented messaging using Web services, process and workflow choreography, identity and access control, shared data, and federation.

Each component in a connected system does its part to collaborate on the set of tasks in the distributed application. One or more components might provide rich user interfaces. Others might help coordinate workflows. One component might act as an identity service provider. There is no required functionality for a connected system and no rule about how its components must come together. Rather, a connected system is simply a distributed application that combines a common set of logical capabilities to achieve whatever functionality it is organized to deliver.

This dynamic and organic nature of a connected system is powerful. A connected system can evolve as business needs change; for example, a system may easily expand its role from serving only a small department to serving many organizations at the same time. Yet a connected system that connects just a few machines together has the same architectural hallmarks as one that is much larger in scope.

One particularly noteworthy hallmark of a connected system is that regardless of its specific role, each component is designed using a service-oriented approach and communicates with the other components using Web services.

Don Box provides an insightful perspective on why this service-oriented approach makes such a difference (Don Box, A Guide to Developing and Running Connected Systems with Indigo):

Service-oriented development focuses on systems that are built from a set of autonomous services. … This difference has a profound impact on the assumptions one makes about the development experience. A set of deployed services is a system. Individual services are built to last—the availability and stability of a given service is critical. The aggregate system of services is built to allow for change—the system must adapt to the presence of new services that appear a long time after the original services and clients have been deployed, and these must not break functionality.

Mike Burner has also commented on the service orientation aspect of connected systems and how it relates to their emergence as a particularly useful type of distributed application for enterprises. (Mike Burner, Service Orientation and Its Role in Your Connected Systems Strategy.)

Management Challenges with Connected Systems

The dynamic and organic nature of a connected system presents a conceptual challenge when envisioning how to manage such a system because it makes it difficult to pin down answers to a whole range of questions. Some simple questions that are hard to answer include how to identify what the connected system in question actually is, how it should perform, and who it should be used by. Moreover, because these are questions of management, many more-complicated questions about policy, governance, and life cycle come into play. These include who in an organization is allowed to decide what a connected system is, who in an organization is allowed to decide how a connected system should behave and perform, and who in an organization is responsible for understanding and managing the complexity of a connected system throughout its life cycle.

The insight into the difference between organic and dynamic connected systems and the more static and precise Web services that give rise to them not only has a profound impact on the development experience, but also on how to address these management questions.

The answer lies in employing separate perspectives on how to manage Web services and the connected systems that use them. All of the management questions asked about a connected system can also be asked about the Web services that give rise to it. The difference is that while these questions are hard to answer for a connected system, they are more readily addressed for a Web service, whose nature is more static and precise.

While this approach of employing separate perspectives may help by factoring the problem space, it brings up other challenges. Especially, having separate perspectives should not mean having separate and expensive management systems to handle each. What's called for is a holistic architecture that can support these separate management perspectives while harnessing one common base of people, process, and technology.

Today's IT Service Management Systems

In today's IT service management systems, the complexity of technology is not the only problem that organizations have to overcome. The quality of service management processes also affects their ability to perform. In many cases, the problems can be distilled down to visibility and control issues in the technology and process and the competency of the human users. Effective IT service management is the blending of people, process, and technology.

Maturity in the organization's service process and technology are keys to realizing this goal. The current industry landscape is decorated with a variety of service management process best practices and specifications.

The IT Infrastructure Library (ITIL) is a widely accepted approach to IT service management. (IT Infrastructure Library and ITIL are registered trademark of OGC, the Office of Government Commerce of the United Kingdom. For more information about ITIL, see http://www.itil.co.uk or http://www.itil-itsm-world.com for more information about ITIL.) The British Standards Institution has codified the best-practice processes promoted in ITIL in the BS15000 standard for IT service management. (British Standards Institution, http://www.bsi-global.com.) The ITIL process abstraction consists of a series of tasks that are performed by a set of functional roles. A collection of rules govern how those tasks are to be accomplished with the given input and expected output denoted as real world objects (RWO). Subsequently, the processes in ITIL's service management functions are derived from this process definition.

The Microsoft Operation Framework (MOF) is a specification that derives from ITIL and several other approaches to service management. It includes adaptations and inline references to Microsoft products and solutions as appropriate for automating a process. MOF defines a high-level cyclical process for managing change, operation, support, and optimization. Each process consists of a set of service management functions that are driven by well defined sub-processes. (For more information about the Microsoft Operations Framework, see the TechNet Web site.)

The Microsoft Solution Framework (MSF) contains two models to help guide businesses realize their market visions through delivering IT solutions. One model captures the team view while the other presents a process view. The team model describes a collection of role clusters. Each role cluster defines a group of related job functions to be performed. The process model is meant to prescribe the logical sequence of steps from capturing market visions and requirements to deploying the IT solution. The intersecting relationship between the two models highlights the tasks performed by each role to the process phases. (For more information about the Microsoft Solution Framework, see the Visual Studio 2005 Team System Developer Center.)

Model-Based Management

In today's IT management systems, much of the knowledge for configuring, diagnosing, and tuning IT systems is captured within the minds of a few technical IT personnel.

There are many drawbacks to this human-centric model:

  • The knowledge is not highly transferable. When a staff member is absent or leaves the organization, the knowledge is lost and it may take a long time to replace the expertise.
  • The approach is prone to human errors. Many of the management activities are driven through arcane command line input and scripts. A single typographical error can lead to undesired results.
  • The system can be slow to adapt to change. There can be a lack of timely intervention or the need for manual intervention and analysis. Also, slowness in patching and updating software leads to a significant number of security and virus incidents.

An alternative approach, referred to as model-based management, attempts to address these issues. Model-based management advocates using highly-structured information models to capture the intentions and desired results of management. The approach encourages proactive, up-front thinking of the instrumentation and tasks required to achieve desired management outcomes. Moreover, the approach attempts to identify mitigation strategies to employ in case deviations occur.

Model-based management is at the heart of the Dynamic Systems Initiative (DSI). DSI is an effort to develop such a holistic architecture, and it is especially geared for management. DSI is a commitment from Microsoft and its partners to help IT teams capture and use knowledge to design more manageable systems and automate ongoing operations. DSI is about building software that enables knowledge of an IT system to be created, modified, transferred, and operated on throughout the life cycle of that system. These core principles—knowledge, models, and life cycle—are the keys to addressing the complexity and manageability challenges that IT organizations face today.

We next provide a brief introduction to DSI, but we then refer the reader to other DSI information for further guidance on management questions from the connected systems perspective. In the remainder of the document, we put DSI into context as we turn our focus to management questions from the Web services perspective.

Dynamic Systems Initiative

Note   The information presented here about DSI is excerpted from the Dynamic Systems Initiative Overview White Paper, where more information is available.

During the mid-1990s, a team from Microsoft Research initiated a focused effort to examine the operational challenges that medium-sized and enterprise business customers face in their IT environments. Their goal was to understand the core drivers of the overwhelming complexity they were facing and architect a software solution that would help dramatically reduce the associated operating costs.

In these environments, it was clear that customers were running applications that had evolved to become increasingly distributed and service-oriented in nature. At the same time, low-cost, high-volume, industry-standard hardware, such as load balancers, switches, servers, and centralized storage, had become common building blocks for—and an integral part of—these applications. The definition of these distributed applications included much more than just the software.

The nature of these distributed systems had resulted in dramatically increased complexity, and that complexity spanned the entire application life cycle. Design of new systems required considerable time and cross-team coordination. Deployment of these new systems required new hardware acquisition and involved multiple iterations with development to optimize the system. The manual nature of operations was requiring some businesses to spend as much as 70 to 80 percent of their IT budget on maintaining their existing systems. (Accenture IT Spending survey.)

While these problems were felt more acutely by larger, enterprise customers, many of the small and medium-sized businesses were beginning to face similar challenges.

DSI Technology Principles

Note   This has been excerpted from http://www.microsoft.com/windowsserversystem/dsi/dsicore.mspx. For more detailed information about DSI, see http://www.microsoft.com/windowsserversystem/dsi/dsiwp.mspx.

From a core technology perspective, DSI is about building software that enables knowledge of an IT system to be created, modified, transferred, and operated on throughout the life cycle of that system.

Knowledge is essential to system management: knowledge of the deployed systems, knowledge of the environment in which they operate, knowledge of a designer's intent for those systems, and knowledge of IT policies.

Specifically, knowledge could include:

  • Developer constraints on settings of a component, including constraints on related systems that the component is hosted on or communicates with.
  • IT policy that further constrains settings or deployments.
  • Installation directives that describe how a system is to be installed.
  • Health models that describe system states and the events or behavioral symptoms that indicate state transitions.
  • Monitoring rules, ranging from polling frequency to event filtering and forwarding to diagnostic or corrective action in response to problems.
  • Schemas for instrumentation, settings, events, and actions.
  • Service-level agreements that define performance and availability.
  • Transaction flows and costs of processing steps for performance analysis.
  • Reports.

As IT organizations have become more geographically dispersed and individual roles more specialized, they tend to operate in silos, making it increasingly difficult to communicate relevant system knowledge across the IT life cycle. Consequently, organizations find it very difficult to collaborate across roles, promote continuous improvement of a system's design and operation, and conduct typical management tasks such as deployment, updating, and patching.

The silos that form across IT organizations interact with an application or system at some point during its life cycle. However, each silo possesses its own pocket of system-relevant knowledge that does not get communicated effectively to the rest of the organization.

Capturing Knowledge in Software Models

Software models can be used to capture this system-relevant knowledge and facilitate the communication and collaboration of this knowledge, which is required to improve the efficiency of the entire IT life cycle.

Live Software Models

A software model provides a level of abstraction for administrators, similar to what a blueprint provides to an architect or a prototype provides to an automotive designer. But for a dynamic and distributed software environment, a static model or blueprint is insufficient. The model must be living—it must evolve throughout the life of a system.

When a system is developed, basic rules and configurations are defined. As the system is deployed, the details of its configuration, environmental constraints, and requirements are added. As operational best practices are developed or enhanced, they can be incorporated into the model as well, providing a feedback loop between the operations staff and the model. In the end, the model becomes a live, dynamic blueprint that captures knowledge about a complete distributed system in terms of its structure, behavior, and characteristics.

Consider the experience provided when pressing the gas pedal in an automobile. The user, in this case a driver, has a high-level, abstract view, a model, that maps to a desired behavior, such as making the automobile go faster. Behind the simple operation of pressing the gas pedal, the system—in this case the automobile control system—takes care of adjusting the fuel intake timing, exhaust valve timing, gear selection, and so on, taking into account constraints such as engine speed and air pressure. Essentially, it carries out changes on the model as instructed by the driver.

What are the benefits of capturing knowledge in these dynamic models?

  • The system model captures the entire system's composition in terms of all interrelated software and hardware components.
  • The system model captures knowledge as prescriptive configurations and best practices, allowing the effects of changes to the system to be tested before the changes are implemented.
  • Tools that take advantage of the system model can capture and track the configuration state so that administrators do not need to maintain it in their heads. The software maintains the desired state so that humans do not need to.
  • Administrators do not need to operate directly on real-world systems; instead, they can model changes before committing to them. In this way, "what if" scenarios can be tried without impact to a business.
  • The system model becomes the point of coordination and consistency across administrators who have separate but interdependent responsibilities.
  • The modeling system becomes the integrated platform for design and development tools that enable the authoring of system models. It also becomes the platform for operational management and policy-driven tools used for capacity planning, deployment, configuration update, inventory control, and so on.

Capabilities Enabled by Software Models

Several key capabilities of IT organizations and IT systems become possible when software models are used to capture all relevant system knowledge.

Design for Operations

When creating mission-critical software, application architects often find themselves communicating with their counterparts who specify data center architecture. In the process of delivering a solution, an application's logical design is often found to be at odds with the actual capabilities of the deployment environment. Typically, this communication breakdown results in lost productivity as developers and operations managers reconcile an application's capabilities with a data center's realities.

With model-based development tools, Microsoft will mitigate these differences by offering a logical infrastructure designer that will enable operations managers to specify their deployment environment and architects to verify that their application will work within the specified deployment constraints. These tools use software models to capture the knowledge of a designer's intent, knowledge of an operational environment, and knowledge of IT governing policies to ensure IT systems are designed with operations and manageability in mind from the start.

System-Level Management

Models can capture the entire structure of an application, including all the underlying and interrelated software and hardware resources. Management tools can use those models to provide a system-level view of the health and performance of that application, enabling administrators to understand the impact of changes or errors in the system and to manage the application more effectively.

This system-wide view will enable management tools to perform robust health monitoring and problem solving, as well as end-to-end performance and service-level management.

Policy-Driven Operations

Models can also capture policies tied to IT and corporate governance, such as Sarbanes-Oxley compliance or basic security standards and operating system versioning. Management tools can use these models for desired-state management.

By comparing the model of the real-world state with the model of the compliance definition, management tools can make systems compliant before allowing them access to corporate resources.

Abstraction of Hardware Resources

Software models can capture an entire system's composition in terms of all interrelated software and hardware components. As a result, a system will contain a specific description of the hardware requirements of the environment into which it will be deployed.

This knowledge will enable resource management technologies to interpret these hardware requirements and to be used by management tools to ease the initial provisioning, ongoing change, or removal of hardware from an application based on changing business needs.

Perspectives on the Service Abstraction

This paper now turns its focus to management questions from the Web services perspective. In doing this, we must first establish a foundation for the fundamental abstraction of a service.

We start by discussing Don Box's four tenets of service orientation, as nicely summarized by Mike Burner (Don Box, op. cit.; Mike Burner, op. cit.):

  1. Boundaries Are Explicit. Services interact through explicit message-passing behind the boundaries. We make no assumptions on the space behind the service boundaries. Crossing service boundaries can be costly (for example, you may need to span geography, trust boundaries, or execution environments). We explicitly opt in to service invocation, by formally passing defined messages between services. The explicit boundaries allow us to formally express implementation independent interaction—we can be agnostic to choices of platform, middleware, or coding language used to implement other services.
  2. Services Are Autonomous. Services behave reasonably as independent entities. We make no assumptions on the space between the service boundaries. There is no presiding authority in a service-oriented environment. Services are independently deployed, versioned, and managed. The topology in which a service executes can and will evolve. The service should expect that peer services can and will fail, and that it can and will receive malformed or malicious messages. Services should be built not to fail, using techniques such as redundancy and failover.
  3. Services Share Schema and Contract, Not Class. Services interact solely on their expression of structures using schema and of behaviors using contract. The service's contract describes the structure of messages and ordering constraints over messages. The formality of the expression allows a computer to verify incoming messages, protecting the service's integrity. Contracts and schema must remain stable over time, so building them flexibly (for example, through use of xsd:any in schema) is important.
  4. Service Compatibility Is Based on Policy. Both service-providers and service-consumers will have policies—operational requirements—for interactions across boundaries. A simple example of provider-side policy is that a service may require that the invoker have a valid account with the service provider. From the consumer-side, an organization may require that service invocations across the Internet be encrypted, so it will only use services that offer the capability of bi-directional security-enhanced data exchanges. Services express their capabilities and requirements in terms of a machine-readable policy expression. Policy assertions are identified by a stable, globally unique name. Individual policy assertions are opaque to the system at large; services must simply be able to satisfy each other's policy requirements.

These tenets are very helpful in understanding how a Web service should be designed and function to handle technical interactions within a service-oriented environment, especially with other software components within a connected system. But we are left still to consider how a Web service should be designed for business and IT operations and how it should be managed. For example, we recognize that there is an equivalent set of business tenets, grounded in law and economics, that constrain and influence the design of well-formed Web service business functions.

One simple perspective to take on the business design is to ask what the goals of the Web service are. After the goals are identified in the form of a model, those goals can be used throughout the Web service life cycle to ensure the Web service is well-designed, implemented, tested, and deployed for operations. With enough foresight in design, the model can be enhanced with the mitigation activities that should be taken when the goals are not being met. Then, the model can be used to help set up the IT management system to measure performance of the Web service and to take action as necessary.

The challenge is then to identify what the goals are. Several different approaches can be used to meet this challenge. A Web service might describe for its consumers (such as other components within a connected system) how it has modeled its goals by expressing them coherently by way of its policies. This would enable the invoking application to know what it should do to comply with the invoked Web service's management expectations. Further elaboration on this topic is beyond the scope of the current paper. We discuss a couple of these approaches here and have explored one in detail elsewhere in this series. (For more detailed information about communicating business operations requirements to IT using business operations modeling, see the Architecture Chronicles on Dynamic Modeling: Aligning Business and IT at the Microsoft Architecture Resource Center.) Regardless of how the business goals of a Web service are determined, we believe effective Web service management begins with knowing up-front what these goals are, collecting them into a model, and using that model throughout the Web service life cycle to align IT with the business plan.

Resource Perspective

One approach to take in considering the overall goals of a Web service is one that employs the resource perspective. This approach was developed within the Service Network model by Michel Burger, Bala Balabaskaran, and their colleagues in the Microsoft Communications Sector. For more detailed information about the Service Network model, service enablement, and the Connected Services Framework, see the Microsoft Web site. This section was summarized from an unpublished work by Michel Burger, Bala Balabaskaran, et al. entitled "Service Enablement Cookbook."

The resource approach looks at a Web service from the perspective of its resources. A resource is the unit of consumption between a Web service and its consumer. The resource approach considers a comprehensive set of management models in that its scope includes provisioning and usage models alongside the traditional health model.

With the resource approach, a Web service must provision a resource for a consumer. Then, the health of the resource (inclusive of service level expectations) must be managed as operations that use the resource are performed against the Web service. Finally, the usage of the resource must be measured (or metered). The resource approach assumes that a Web service brokers one or more resources at its service boundary. The manageability requirements of a Web service that does not broker an underlying set of resources, such as a simple random number generator Web service, do not fit the scope of the resource approach.

With the resource approach, three semantic models and their operations can be used to effectively manage the operational functionality of a Web service. These are:

  • Provisioning model. This model includes provisioning states, events, and related task-based operations.
  • Health model. This model includes health states, events, performance counters and events, and related task-based operations
  • Usage model. This model includes usage events and related task-based operations.

Identifying the core set of resources associated with a Web service helps with understanding the details of the three models that need to exist at the level of the service boundary. The underlying models that exist for each resource owned by the Web service will ultimately contribute most of the components to the service models.

A Web service in the Service Network brokers resources. The identification of the resources is an essential task.

Two easy criteria can be used to identify what a resource is:

  • The resource tends to be the unit of transaction between the Web service and the Web service consumers.
  • A resource has identifiable provisioning, usage, and health models.

A few examples illustrate how resources can be identified:

  • The Web service may offer clearly identifiable resources if it is set up as a commercial service. Examples include a mailbox on an e-mail service, a calendar on a calendaring service, a video channel package on an IPTV service, bandwidth on a network service, and an active switch port on a DSL service.
  • The Web service may offer clearly identifiable resources if it represents tangible resources. A tangible resource includes physical resources such as a DSL router, a set-top device, or a mobile handset. A tangible resource could also be a book, a CD, a ring tone, or a user interface in use by a person.
  • The service may offer less clearly defined resources if it brokers a back-end process. An example is an order management application delivering a service. The active instance of the process can be treated as a resource brokered by the service. In the example of order management, an "order" is the resource. When aspects of the life cycle of an instance of an entity (for example, an order) are affected every time a service is invoked, that entity can be treated as a resource.

Figure 1 illustrates the mailbox example from a resource perspective. The resource that is consumed externally is the mailbox, and it must be provisioned to be usable, managed to stay healthy as it is being used, and billed after it is used (if it is offered commercially). Internally to the Web service, many resources are brokered to deliver this functionality.


Figure 1. Illustration of external and internal resources for a mailbox Web service

From the resource perspective, the goals of a Web service are largely defined from the Web service designer's viewpoint. This is a practical and useful approach for defining the goals of a Web service. The design effort is one of bringing many internal resources together to deliver on a higher-level offering made to a Web service consumer. The definition of the offering is certainly relevant to the design of the Web service and therefore also the resource perspective, but why the offering exists and how it is defined are outside the scope of the resource perspective.

Business Collaboration Perspective

The business collaboration perspective is a more comprehensive approach than the resource perspective. This approach seeks to understand the goals of a Web service by considering business resources, business events, and business agents (people) at the business operations level. It uses formal business operations modeling to find these requirements by focusing on the business collaboration that the Web service is intended to participate in; that is, how the Web service will be used collaboratively in a business context. The approach then translates these business operations requirements into a high-fidelity format that can directly drive, as much as possible, the Web service solution design and Web service health model. For more detailed information on communicating business operations requirements to IT using business operations modeling, see the Architecture Chronicles on Dynamic Modeling: Aligning Business and IT at the Microsoft Architecture Resource Center.

When two businesses collaborate with each other in a value chain, whether as supplier-customer or partner-partner, the dealings they have with one another generally follow procedures the two agree upon in advance. (For more detailed information on communicating business operations requirements to IT using business operations modeling, see the Architecture Chronicles on Dynamic Modeling: Aligning Business and IT at the Microsoft Architecture Resource Center.) These procedures are usually defined with enough clarity through a contract that each company can clearly know its role, can perform the activities it has committed to, and when its commitments are fulfilled, can collect whatever benefit or payment is due from the other.

It is the job of the business operations organization to put into place the infrastructure necessary to support at an operational level an organization's own side of the business collaborations it has with others. In performing its work, the business operations organization maps contractual requirements onto business capabilities as it defines, implements, and operates a collection of business processes. The business operations organization also works closely with the IT organization to support the IT organization's work in defining, developing, and operating technology solutions that realize the collection of business processes.

There are two ongoing challenges business operations organizations have as they oversee the running of the business, as illustrated in Figure 2:

  • Business relationship drift. This situation occurs as the two businesses in a business collaboration experience different levels of information about the ongoing business activities they share.
  • Business operations drift. This situation occurs as the business operations organization and the IT organization within a company experience different levels of information about requirements and ongoing operational performance of business processes and the technology solutions that support them.


Figure 2. Illustration of business relationship drift and business operations drift

Business relationship drift in a business collaboration is inevitable. It's not possible for one business to have all the same information at the same time as the other. But business relationship drift does not become a problem, and remains hidden away, when a business collaboration proceeds as expected. The different, shared activities unfold in a timely way, continuously bringing the business relationship back into alignment, and each business continues to experience the outcomes it expects.

It's when business exceptions occur—when an expected event is delayed, or an expected event occurs out of sequence—that business relationship drift manifests itself as a problem. Typically the manifestation is a cascade: one important activity completes late, or not at all, leading to other activities not starting, and so on. It's very hard for the businesses to get back on the same page, or to get back into business relationship alignment. Figuring out what has gone wrong and where, and getting things back on track (if that is even possible) can take a lot of time, energy, and expense.

With good up-front planning and experience to draw on, the difficulty in handling business exceptions isn't in knowing what to do about them. Most issues can be anticipated, and a good plan will include some way of dealing with the completely unexpected. Instead, the difficulty in handling business exceptions is mostly about getting useful information about an exception that has occurred to the right person in time, or even ahead of time, so that he or she can do something about the problem as it happens—or before it happens. When the right information arrives to the right person in time, there's a better chance that whatever intervention the person can implement can have a more significant mitigating effect.

Getting useful information about what exceptions are occurring to the right person in time is no easy task, and it is the hallmark symptom of business operations drift. Expected performance is not achieved, but the current performance level actually remains unknown. The information to achieve alignment of business operations usually exists, but it is almost always distributed in a piecemeal fashion throughout the technology solution that implements the business processes that work together to enable the business collaboration. In such situations, non-performance of a contractual commitment isn't something that is known at the business operations level until some time later, when an after-the-fact audit is performed. Such an audit, usually directed manually, uncovers that certain requirements from the contracted service level agreement were or were not met. In failure cases, penalties are often assessed. Meanwhile, in real-time, the non-performance of the commitment often leads to cascading business exceptions in the business operations.

The key to ensuring business relationship alignment between two businesses would seem to be business operations alignment between the internal business operations and IT operations organizations of each business. If there were some way for the IT organization to know in advance what business operations requirements needed to be met so that IT operations could then let business operations know as those requirements were not met, the business operations team would be better able to detect business exceptions that will likely worsen business relationship drift as they occur—or even before they do.

A modeling approach to formalizing business collaborations can facilitate the identification of conditions that will worsen business relationship drift. When these conditions are identified and transformed into a model that the IT organization can use, the IT solution can be designed, implemented, and operated in way that combats business operations drift. With tighter coupling between business operations and IT operations at both businesses in a business collaboration, following this approach, much more timely knowledge about the state of shared business activities can be known to both parties. This condition is referred to as business state alignment, and it is illustrated in Figure 3. With business state alignment achieved, business operations can run more smoothly and unnecessary expense and downtime can be avoided.


Figure 3. Illustration of business state alignment

The conceptual framework in Figure 4 links business operations modeling to IT service management and helps explain the business collaboration perspective. The conceptual framework provides a coherent way of relating business and IT management tasks. It connects business operations requirements to existing IT management processes and capabilities. The conceptual framework contains a services life cycle approach that includes the business operations-level scope.


Figure 4. Conceptual framework illustrating the business collaboration perspective

Business operations modeling can be used to help identify the goals of a Web service from the business collaboration perspective. The approach can help determine why a Web service should exist, what it should do, and how it should do it. This approach is more difficult and complex than the resource approach. This approach involves working with many people in the business operations domain to develop a correct model. Then, to be useful by the IT staff that must design, implement, and operate the Web service, the requirements must be translated into a form that can drive both the Web service solution design and the Web service health modeling processes. Nonetheless, despite the effort involved in determining them, Web service goals from the business collaboration perspective are very useful for helping guide how to manage a Web service: these goals are directly relevant to the company's operations.

Demystifying Web Service Management

"Web service management" is a term often used to describe the application of new technology solutions to traditional IT service management problems such as instrumentation and monitoring applied to Web services. The term is also used to describe how new, special-purpose infrastructure can connect Web services to business functions such as usage control, usage metering and billing, and customer care systems. The scope of the term is even cast to include the application of new tools and their run times designed to change the behavior of an operating Web service, sometimes transparently to it, and therefore "manage" it.

Clearly, Web service management crosses many boundaries, and there are new investments an organization can and should make to improve its ability to manage Web services. We especially believe that's true when considering the complexities of managing the connected systems that Web services give rise to, as we argued in the "Model-based Management" section earlier in this document.

But a new term such as Web service management with its attendant buzz and urgency can create confusion over what are the right investments for an organization, and when to make them. The term can also create confusion over the role existing IT service management solutions can already play in managing Web services. For example, it may not be clear that guidance that describes how to use existing health and performance monitoring infrastructure can almost directly apply to detecting problems in operational Web services.

Many businesses embarking on Web services may be new to the service paradigm. The paradigm shift requires not only adjustments to development methodologies (for instance, a focus on the four tenets), but also to the IT governance mentality. The task of managing Web services is not likely found in the panacea of a new technology solution; instead, it is likely to be found today in the coherent dedication to a set of coordinated activities throughout the service life cycle. Over time, we argue that a model-based management infrastructure will align with these activities, helping to automate them as the knowledge in the organization is formalized and more widely communicated and applied.

The capacity to achieve the shift to the service paradigm lies in a business's ability to see past the buzz and urgency around short-term approaches to Web service management into the business's motivations for managing Web services. When the motivation is clear, the extent to which a business can execute the service paradigm shift hinges on its ability to address the challenge today of coordinating and rationalizing the people, process, and technology issues throughout the service life cycle.

Web Service Management Framework

In the sections that follow, we describe a framework to help approach the challenge today of managing Web services using existing IT service management capabilities by coordinating and rationalizing people, process, and technology issues throughout the service life cycle.

We first consider the business collaboration perspective to help define Web service goals. We cast business operations requirements into a much-simplified service model, and then describe in a more granular fashion the logical entities to map onto management requirements in a Web service implementation.

Next, we describe the Web service management issues through the decomposed entities.

Finally, we address these requirements and issues by presenting a technology framework grounded in the service life cycle to help harness existing people, process, and technology to manage Web services.

Web Service Goals and Service Model Logical Entities

Figure 5 illustrates the logical entities of a much-simplified service model derived from the business collaboration perspective presented earlier and illustrated in Figure 4.


Figure 5. Service model logical entities

The logical entities are related in various ways:

  • The top of the figure shows entities representing the simplified service model. These entities are the business service consumer, the business service provider, and the business collaboration engaged in by both parties.
  • The business operations requirements in the business collaboration can be categorized in two purposeful ways. Service definitions describe the service that the parties agree to provide and consume within the business collaboration. Service commitments describe the manner in which the services are to be delivered and consumed within the business collaboration.
  • Service definitions contain information such as the service access points, service policies, and the message schema definition. Because a particular defined service may be offered to one or more business service consumers, this part of the business collaboration is considered to be business service consumer independent.
  • Service commitments are templates of the promised terms and conditions binding the business service provider to business service consumers for services within the business collaboration. Specific business service consumers will have run-time bindings for the templates that must be honored by the business service provider. For example, a service commitment template for a certain service from a business service provider might specify availability. For business service consumer A the run-time binding might be "available Monday through Friday, from 9 A.M. to 5 P.M." For business service consumer B, the run-time binding might be "available everyday, 24 hours a day."
  • The service definitions are realized through deployed instances of service implementations. Each of the service instances has a set of service policies that govern the type of information that must be present in the service requests and service responses. The service policies may also specify if the information is mandatory or optional. For example, the service policy can state that every service request message header must include a signed time stamp. Request messages that do not meet the policy requirements are to be rejected by the service.
  • Every deployed service instance also has a set of configuration settings. The configuration settings can enable services to be more flexible in adjusting to the deployment environment. For instance, the service uses the configuration data to help resolve the identity authority that it trusts for authenticating users.
  • Management instrumentation is used to provide visibility and control over running instances of Web services. Service instrumentation may take the following forms: debugging traces are used to help with diagnosing code execution behaviors; events are used to raise alerts that signify meeting certain management conditions; performance counters are used to generate statistics that reflect the health of the services; and probes are used to query and control internal service states by management applications.
  • The instrumented data is consumed by rules that enforce and govern Web service compliance with respect to the business operations requirements. Each rule can contain metrics or performance indicators that are checked against a set of conditions. The result of the check is then used to trigger and set off the pre-determined management actions.

We make a distinction between rules that are applied in a service operation environment and rules that are relevant to the fulfillment of the business operations. In a service environment, the rules are typically concerned with conditions and actions that technology operators and administrators deal with. An example of such rule is "if the number of SOAP packets processed in the last 60 seconds exceeds 600, auto-provision a new instance of Web service." Service level fulfillment rules are concerned with tracking data and events abstracted at the business operations level. For instance, a service-level rule may state the following: "promote the customer to the next service level if the business service consumer has used the service more than 6 times in the last month."

Perhaps not so obvious from Figure 5 is the fact that the service entities are not immune to updates and changes introduced by new business and technical decisions. For instance, when an existing business service is introduced in a new geography, the existing service definition may need to change to take into consideration a new service parameter that reflects the regional consumer protection scheme. In another example, the business service provider may decide to monitor a new business event as an indicator for adjusting inventory forecast. The Web services management environment must deal with these service life cycle management issues and provide the appropriate mechanism to help with version control, change notification, service deployment, and update in manners that are less intrusive to the business service consumers.

Finally, we must not forget that the identities of business service consumers, business service providers, and Web service operators are represented as digital identities in the online world. The processes of authentication and authorization are necessary to control access, usage, and administration of the Web service. Entitlements are used to represent the rights and privileges given to these parties.

Web Service Management Issues

It is logical to expect that Web services will be able to offer the same level of technical command and control capabilities as other IT solutions. However, this expectation is yet to materialize today without some generalization and implementation of Web services management technology.

Specifically for Web services, the management information model will have to document the different internal service states, desired views of the services (for example, the number of times a service has been accessed in the last hour), and the rules that govern how those states and views can be attained. Subsequently, various management activities can be automated and driven through the service metadata that is embodied in those management documents.

The logical entities represented in the service model shown in Figure 5 can be further analyzed to derive management-related properties, entry points, and task-oriented rules. Such information is to be expressed as management metadata that is used by IT service management tools to monitor and adjust the management environment to satisfy the operational requirements and fulfill the business operations requirements.

For example, the management metadata can describe the mapping between a Web service instance and the corresponding software components that can be instrumented, configured, and deployed. Properties and attributes for the components describe the events, probes, and performance counters the managed Web service has been defined to expose. A collection of operations rules determines how the instrumented data should be handled and how the service requests should be routed in order to satisfy service level requirements.

Web Service Management Technology Framework

In the previous sections, we described the logical entities that are derived from a simplified service model. We then examined the relationships between these entities as we discussed the mechanisms that are needed to manage Web services.

In this section, we describe the technology framework that can be overlaid onto existing people, process, and technology capabilities to support managing Web services.

The Web services management issues we have presented can be summarized in the following way:

  • Control the identities that can use, operate, and administer a Web service.
  • Gain visibility and control into the performance, usage, and health of a Web service at the business operations, application, and system levels.
  • Manage versioning and deployment of a Web service's updates and changes.

Our Web services management technology framework to support these requirements is structured around the following four core technology pillars that correspond to the categories of management issues that need addressing:

  • Web service life cycle management
  • Web service health management
  • Web service deployment management
  • Web service identity and access management

Web Service Life Cycle Management

Some common observations of the ITIL, MOF, and MSF approaches to IT service management discussed earlier include the following:

  • Each framework takes a process approach that when captured as a high level model, describes the complete life cycle phases of an IT solution.
  • The life cycle phases can be analyzed to derive functions that need to be performed at each phase. Each function can contain a set of tasks that must be executed to complete each function.
  • Functions and tasks can be assigned to role responsibilities.

In the same way, we assert we should use the same life cycle approach in managing Web services.

Commercial software packages are hard to deploy, maintain, and update in the production environment. Web services are no exceptions. This observation shouldn't be surprising when considering the linkages of the phases in a service's life cycle, as illustrated in Figure 6.


Figure 6. Service life cycle

The approach toward using the service life cycle shown in Figure 7 helps an IT team work together to manage a Web service to meet its goals.


Figure 7. Using the service life cycle

The service life cycle approach helps the team:

  • Consider the non-functional attributes that allow services to be operated, maintained, and upgraded over the course of time.
  • Identify the roles involved in the service life cycle and derive management tasks that each role performs.
  • Describe the conceptual elements and constraints of the management tasks using a collection of management models.
  • Build solutions for the management models using products and technologies. The resulting tools and applications are tailored to meet the needs of the individual roles in the organization.

The people responsible for each phase of the life cycle are often separated organizationally and sometimes also geographically. There has been little success to date with tools to help bridge communication across these phases. So today, there is often a gap in assumptions between the programmers who have implemented the software and the operators who are responsible for the day-to-day availability, reliability, and security of the software. This observation is at the core of model-based development and management, namely that the design and implementation of software services must take into consideration the deployment and operational requirements to reduce the ongoing service management cost.

Note   Visual Studio 2005 Team System (VSTS) is a new model-based development tool from Microsoft especially designed with the DSI model-based management approach in mind. For more information about VSTS, see the Microsoft Web site.

Web Service Health Management

Because there is no such thing as a perfect environment, a Web service will experience problems at some time during its execution. If a problem is not detected in a timely fashion, not diagnosed correctly, or not fixed properly, the Web service can degrade to the point where it is no longer available to its customers. This is expensive, time consuming, and ultimately creates dissatisfaction among users. It is up to the administrators to detect and fix issues with as little downtime for their users as possible.

A Web service health model defines what it means for a Web service to be healthy (operating within normal conditions) or unhealthy (failed or degraded) and the transitions in and out of such states. Good information on a Web service's health is necessary for the maintenance and diagnosis of running systems. The contents of the health model become the basis for system events and instrumentation on which monitoring and automated recovery is built.

To keep a Web service up and running, the operations team needs to watch the Web service's health metrics, detect symptoms of a problem early, correctly diagnose the cause of that problem, and fix the problem before the application performs unacceptably. This activity is referred to as health monitoring and troubleshooting.

To create a Web service health model, the modeler needs to do the following:

  • Collect the right information about the Web service at the right time—when running normally or when something fails.
  • Document all management instrumentation exposed by a Web service.
  • Document all service health states and transitions that the Web service can experience when running.
  • Identify the steps and determine the instrumentation (events, traces, performance counters, and Windows Management Instrumentation [WMI] objects/probes) necessary to detect, verify, diagnose, and recover from bad or degraded health states.
  • Document all dependencies, diagnostics steps, and possible recovery actions.
  • Identify which conditions will require intervention from an administrator.
  • Improve the model over time by incorporating feedback from customers, product support, and testing resources.

This section provides the background information for describing and understanding the health model concepts. Figure 8 provides a partial service life cycle view of when health models can be effective in specifying the manageability requirements. This high-level health model provides the fundamental health modeling framework that can be further extended and analyzed to identify the potential problems, the indicators of the problems, the diagnostics steps, and the recovery actions that need to be taken to ensure that the Web service's health and performance meets expectations.


Figure 8. Service life cycle from a health model perspective

Health states are high-level indicators of the Web service's ability to function correctly. A health state provides non-quantitative data, but it tells the administrator if the Web service is in trouble and gives an idea of the severity of the situation. It is important to remember that a health state is a judgment call about the severity and is almost always relative. For example, one customer may decide that a total network saturation level of 90 percent is a degraded state, while another customer would consider a level of 80 percent to be in a failed state.

The health and diagnosability workflow as shown in Figure 9 defines logical stages of the monitoring and problem recovery process. The stages of this process are:

  1. Detection
  2. Verification
  3. Diagnostics
  4. Resolution
  5. Re-verification


Figure 9. Health and diagnosability workflow

To be effectively monitored, a Web service needs to provide the right types and levels of instrumentation—it needs to expose its internal state, report changes in its state and behavior, and supply methods for administrative control. This provides the data essential for problem detection, verifications, diagnosis, and recovery. Additionally, the instrumentation needs to be lightweight and have no noticeable effect on an application's performance. There are three primary types of lightweight instrumentation that can be used for different aspects to support the health and diagnosability workflow:

  • Events. An application sends out an event when the service encounters a particular operational condition or a failure state.
  • Traces. Applications log trace information when a certain checkpoint in the code is passed.
  • Performance counters. Performance counters are numeric values that reflect the state of the application at a precise moment or averaged over a period of time.

More detailed information on Web service health modeling can be found in the Architecture Chronicles on Dynamic Modeling: Aligning Business and IT at the Microsoft Architecture Resource Center.

Web Service Deployment Management

After a Web service satisfies all testing requirements, it is ready for deployment. Traditionally, deployment of software services requires preparing the network infrastructure, hardware, and operating systems. The same rigor in preparation also applies to Web service deployment. An effective Web service deployment mechanism must allow the Web service images to be centrally prepared and configured and efficiently distributed throughout the network and Web service farm environment. Configuration management must deal with different types of management data, including service policies that service clients need to adhere to; software settings that affect how the Web service uses application, system, and network resources; and service catalog information that enables the running Web service instance to be discovered and operated. Technical solutions for configuration management must also deal with change propagation latencies that affect when configuration changes can take effect at the affected Web services.

A logical architecture for Web service deployment is shown in Figure 10.


Figure 10. Logical architecture for Web service deployment

The logical architecture consists of the following entities:

  • Deployment controller. The application administrator uses the deployment controller to:
    • Configure and manage deployment policy.
    • Schedule and trigger deployment actions at the Web service farm computer.
    • Monitor deployment progress and take corrective actions if necessary.
  • Deployment agent. This interacts with the deployment controller and performs software deployment actions according to the instructions and policy received from the deployment controller.
  • Deployment policy store. This provides the central location where the deployment policies are managed and stored.
  • Software distribution point. This provides the network location where the installation program and Web service software component can be downloaded at deployment time.
  • Deployment progress log. This provides the logical location where deployment agents write deployment status and the deployment controller monitors progress.

Over time, new technical and business requirements will necessitate technical re-evaluation and possible changes to existing implementations of Web services. The technical changes can be anything from the Web service access address, to message schema updates, to service interface or name modifications. When implementation changes occur, service providers are confronted with the challenges of minimizing or insulating the change impact to service consumers.

For example, if a local U.S. business offering financial service decides to expand its service offering to a different state in the country, the service will need to take into consideration the new state's consumer regulations. It may require additional input or output data be passed between the business and the consumer. When a Web service is used to enable this service, a couple of technical options may be considered to facilitate the new data exchanges. The business may choose to introduce a new Web service interface to support the new data parameters. Or it may choose to use a Web service proxy façade to support the existing interface, relying on the proxy to perform data transformation and internal service routing to support messaging requests from current and new service consumers. (With this latter option, consistent with the four tenets for service design, the service boundary conceptually shifts outward from the original Web service implementation to the new Web service proxy façade.)

The software industry has been applying software version control techniques and process to traditional software development for a long time. Some of the existing versioning techniques need to be adapted and applied in the Web services world to differentiate changes in service implementations and message schemas.

Depending on the Web services architecture, changes to the Web service interface or message schema may affect the Web service consumer and the Web service proxy. In either case, the consuming party needs to discover the new service definition in order to interact with the new Web service endpoint. The Web service architecture needs to specify whether the change notification and discovery is handled automatically or manually.

More detailed information on Web service deployment can be found in the Architecture Chronicles on Dynamic Modeling: Aligning Business and IT at the Microsoft Architecture Resource Center.

Web Service Identity and Access Management

As one of the co-authors has observed in a related work, identity and access management is the set of processes, technologies, and policies for managing digital identities and for controlling how digital identities can be used to access resources. (Frederick Chong, Identity and Access Management, Microsoft Architect Journal 3, July 2004.)

In the Web services management context, there are three primary parties whose identities we are interested in managing:

  • Web service consumers. Web service consumers are the users of the services. However, the definition of Web service users can vary depending on the consumption environment. For example, in a development and testing environment, the users are the software developers and testers; whereas in a production environment, the user population expands to include the end users of the services. Even within the end user environment, the consumers may be further classified according to the rights and privileges conferred through their service agreement with the service provider.
  • Web service providers. This group includes people and system identities associated with the organization providing the services. In many cases, users in service providers are interested in the usage and the performance patterns of the Web services to help them determine future technical and business directions. They may also need the ability to configure and update service level settings of the service instances.
  • Web service operators. This group usually refers to the administrators and operators concerned with managing the Web service execution and hosting environment. Web service operators monitor the health and performance of the Web services and ensure that the service operation rules are followed. These personnel also often deal with deploying and updating the Web service instances and will require visibility and control over the network and operating system infrastructure that are hosting the Web services.

Figure 11 shows the conceptual architecture of the Web service identity and access management framework.


Figure 11. Web service identity and access management conceptual framework

The core function of access control is provided through three underpinning security mechanisms: authentication, authorization, and auditing (commonly known as AAA). These three mechanisms depend on the directory and security services layer for security data-related operations. For example, storing and retrieving user credentials, entitlements, and profiles; and discovering security policies.

A provisioning component provides the capability to initialize, update, and synchronize the security-related data. User management applications and interfaces can then rely on the provisioning component to create, retrieve, and change the identity information without having to interact directly with the data layer.

Trust relationships and security policies are critical elements in an identity system because they determine the type of security proofs, statements, and actions that the Web services will accept from trusted parties. A trust and security policies management component is responsible for updating such security configuration information in the directory and security services, and for configuring the Web service instances to use the security settings.

The next few sections highlight a few important concepts in identity and access management and how they relate to Web services.

Authentication and Single Sign-On

Authentication is the process of validating the credential of an identity. The subject of authentication may concern members of the Web service consumers group, members of the Web service providers group, or members of the Web service operators group.

Most enterprises have more than one identity system to support existing services and applications. As a result, enterprise users are commonly faced with the challenge of managing multiple authentication credentials for login. Single sign-on mechanisms help deal with the complexity of using and managing multiple application credentials. Identity and access management system in the service-centric world often have to deal with the challenges of integrating with existing identity systems as well as delivering a single sign-on experience to the service users.

Entitlements and Authorization

Entitlements refer to the rights and privileges conferred to an identity while authorization is the process of verifying that a given identity has the permissions to access a protected resource—in this case, a Web service.

Like authentication, the process of authorization also applies to different kinds of tasks performed by the various categories of identities. For a Web service consumer, other than verifying that it has the ability to invoke a Web service, the Web service instance may also check more granular data access permissions to verify that the consumer is allowed to receive a particular data field in the Web service response. For Web service providers and Web service operators, the authorization process verifies that the identity has the rights to view and update internal business and operation-related information respectively.

In addition to traditional access control lists, role-based and rule-based authorization mechanisms are commonly used to represent and enforce authorization policies.

Security Auditing

Many industries involved in services are governed by governmental regulations. For example, in the United States, recent enactment of the Sarbanes-Oxley Act (Sarbox) and its compliance requirements put pressure on enterprises governed by the Sarbox law to re-evaluate their current systems for any process and technology gaps that could cause them to fail the Sarbox audit.

Given the present corporate focus on governance and transparency, information that answers the questions of "who did what, when?" needs to be readily available. Security audits provide the mechanism for tracking security actions and information access. In many cases, audit trails may also need to prove legal intent and non-repudiation so that the information can be used as evidence in the court of law.

When the reach of business information and actions is extended through Web services, it becomes even more critical for auditing and evidentiary capabilities to be integrated into the Web services implementation. The business operations modeling approach described earlier can be used to help identify the activities in a business collaboration that show legal intent. The transformation of this model into business operations requirements can help the IT team integrate appropriate capabilities into the Web service implementation.


Privacy is concerned with the business use and disclosure of individual data. In many cases, the privacy requirements have to do with how legitimate business entities that are using personal information agree to protect and limit the use of the data that is harvested from the Web service consumers.

Privacy and security are actually paradoxical concepts—as we become more secure through the processes of authentication, authorization, and auditing, it becomes easier to track, gather, correlate, and reveal user information. Therefore, it is very important that for every security condition and event that generates identity data, there is a set of peer conditions that limit the use of that data. Some of these conditions may need to be translated into machine-enforceable business rules. A Web service implementation can then depend on these business rules to restrict the visibility and access of the data.

Identity Life Cycle Management

Identity life cycle management refers to the process of identity provisioning, identity de-provisioning, and updating accounts, profiles, and entitlements associated with identities.

As mentioned earlier, most enterprises have existing identity systems. In many cases, Web service implementations must integrate with these current identity schemes. Web services depend on these systems to authenticate and authorize identities and to gather individual attributes such as phone numbers.

Identity provisioning is the process of creating and initializing accounts, credentials, and attributes in the identity systems. Identity de-provisioning is the process at the other end of the identity life cycle that de-activates the account. While the account is active, account information and credentials may be changed and updated.

Often, identity data in an organization may spread or be duplicated across different systems so that some level of data synchronization is required to maintain a consistent view of the identities. Identity integration and synchronization technology is used to address this class of identity management problems.

Identity Federation

To fulfill the Web service technology promise of facilitating cross-organization communication, it must be possible for organizations to verify and authorize the use of a partner organization's identities. Identity federation refers to the process and technology for managing and configuring trust relationships and to using identities across security administration domains.

In the Web service world, identity federation enables an organization to delegate specific security responsibilities to trusted third parties. For example, a service provider can configure its Web services to trust a well known identity provider to authenticate the identities of its Web service consumers, thus simplifying the identity management infrastructure it needs to employ while extending business reach through Web services. In other cases, a Web service provider may choose to further delegate the user authorization process to a trusted identity system of the business partner who is consuming the service.

Web Service Management Using Web Services

The discussion about Web service management has focused on the management of Web services. Another topic worth mentioning is the management of Web services (or other applications or systems) using Web services.

Whether it is used for managing Web services or other computing software or devices, a management infrastructure involves communication protocols to facilitate management functions such as discovery of managed Web service instances and raising management events to an eventing infrastructure. Existing examples of industry-standard management protocols include SNMP (Simple Network Management Protocol) and DMTF CIM (Distributed Management Task Force Common Information Model).

With the adoption of Web services technology for a variety of application and infrastructure services, such as federated identity management, the management protocol community is also realizing that the tenets of service orientation and Web services technology are highly supportive of desirable distributed management goals. For example, discoverability speaks of the ability for managed resources to be dynamically discovered, and federation enables management applications to gain visibility into trusted infrastructure without requiring complete control.

WS-Management is a Web services–based protocol that combines the practicality of a small number of fixed operations with the scalable, composable Web services architecture as its technical foundation. (For more information about WS-Management, see the Microsoft Web site.) WS-Management is largely a composite definition over other existing Web Services standards and specifications that describe the management operations. Because the protocol is defined as a composable standard, it can be implemented in the resource constrained environment, eliminating the need for a low-level wire protocol.


Like most important IT initiatives, managing Web services requires the balanced coordination of people, process, and technology

We grounded the discussion of Web service management in the broader contexts of connected systems and the Dynamic Systems Initiative. We provided some perspectives to consider in determining what the business goals of a Web service actually are to help pin down more formally why and how a Web service should be managed.

The model-based development and management approaches suggested that a framework for Web service management addressing management states, actions, and rules could be overlaid onto existing IT service management systems.

We proposed such a framework that addressed how to coordinate people, process, and technology issues throughout the service life cycle. After taking a simplified view of one of the perspectives of a Web service's goals, we examined issues of Web service life cycle management, Web service health management, Web service deployment, and Web service identity and access management.

© 2014 Microsoft