Visibility and Control in a Service-Oriented Architecture
A Collection of Enterprise Ideas
Keith Pijanowski, Platform Strategy Advisor
Microsoft Corporation
May 2007
Applies to
Service-Oriented Architecture
Summary: Services alone do not constitute a service-oriented architecture (SOA). Capabilities must be acquired that provide visibility and control into service development and service execution. Without these capabilities, IT offerings will become fragile as the number of services in the data center grows. This article investigates capabilities that provide visibility and control for the services that make up a SOA. (21 printed pages)
Contents
Introduction
Two Definitions of SOA
What Is a Service?
A SOA System of Record
Policy
Governance and Management
Putting It All together: A Service-Oriented Infrastructure
Conclusion
Acknowledgements
References
Introduction
"An idea is the object of understanding whenever man thinks."
–John Locke, Essay on the Human Understanding
Service-oriented architecture (SOA) is an idea that many developers, architects, and executives are thinking about today. Many times, in the development and communication of new ideas, confusion is created because definitions are not stated up front. Therefore, it is important to build a vocabulary of well-defined terms as the first step in developing and communicating new ideas.
In software development, the implementation of an idea is a capability. At a high level, all the capabilities discussed in this article provide either visibility or control of a service-oriented architecture. Figure 1 shows the relationship of these capabilities to an organization's current infrastructure and to software services deployed to the data center. The bottom line is that services alone do not produce a service-oriented architecture. Organizations that ignore infrastructure capabilities that can be used throughout the entire software-development life cycle and at run time will not reap the benefits of reusable services.
SOA = {SOI} + {Services}
Where:
SOI = {Current Infrastructure Capabilities} + {Service Control Capabilities} + {Service Visibility Capabilities}
Therefore:
SOA <> {Services}
Figure 1. The SOA equations
Two Definitions of SOA
Confusion over SOA starts with the term "SOA" itself. Definitions of the term "SOA" vary widely in publications and references today. Some definitions of SOA align the term "SOA" to more of a distributed computing technique that emphasizes connectivity and interoperability. Definition 1 is an example of this viewpoint on SOA; it resonates well with developers and solution architects. Other definitions take more of an enterprise-wide view of services and their life cycles. These definitions focus on reuse, management, governance, agility, and alignment with the business. Such definitions resonate among enterprise architects and C-level executives that are responsible for organizational changes that affect a large portfolio of applications. Definition 2 is SOA as seen by an enterprise architect or a C-level executive.
Service-oriented architecture—A software-design approach in which key functions are built as reusable components that implement industry standards for interoperable communications.
Definition 1. SOA as seen by the developer and solution architect
Service-oriented architecture—Enables loose coupling, interoperability, discoverability, management of change, and operation of business services in a well-governed environment. Business services operating in a well-run SOA can be composed into business processes that align IT with the business.
Definition 2. SOA as seen by the enterprise architect
Clearly, both definitions are important. After all, it takes a combination of efforts from developers, solution architects, and enterprise architects to build a SOA successfully. However, the basic premise of this article is that you cannot build a SOA with Web services alone. Capabilities must be acquired that provide control and visibility into service development and service execution. If a SOA effort is started without a plan in place that all teams can follow, individual development teams will move in different directions, causing friction within the organization. The following sections explore the capabilities that need to be acquired and understood at the enterprise level. As soon as it is understood, a plan can be built that transforms application silos into a service-oriented architecture running in a visible and controlled environment.
What Is a Service?
Another area of confusion when defining the details of a service-oriented architect concerns the actual definition of a "service." Definition 3 is the working definition of a "service" that will be used in this article. The idea of a software service is as old as distributed computing. It goes something like this: Deploy a component, and make it accessible to other components running on other machines via a network address. The idea of a service places no restrictions on the platform that the service is running, the tools used to build the service, or the protocol used to communicate with the service. The term "service" is a very generic term, and a good SOA can manage and govern all types of services. Web services, business processes, and business services are special types of services. Each of these terms is defined in the definitions that follow.
Service—A service is business logic (the server) that is capable of being accessed from another process (the client). Typically, the client is another process running on another machine that is using the network as its means of accessing the server.
Definition 3. Service
Web service—A service implemented to support interoperable process-to-process or machine-to-machine interaction over a network. In common usage, Web services have their interfaces defined using Web Service Definition Language (WSDL) and use SOAP-formatted messages for communicating across a network.
Definition 4. Web service
Business service—A business service is a service that has been published to a SOA Registry with metadata (usually, an organization's custom taxonomy) to facilitate easy discovery. Policy may also be associated with a service when it is published to facilitate governance. Business services operate in an environment that provides visibility and control.
Definition 5. Business service
Business process—A Business process is the common language between the business and IT that facilitates an effective, two-way dialogue. Organizations that want to improve efficiency and agility will need to effectively capture business-process requirements in a manner that allows the business process to be implemented as a business service that is composed of many other business services. The design-time management and run-time management of business processes that define the business is the goal of service orientation.
Definition 6. Business process
A SOA System of Record
Generically speaking, an effective system of record is information about some system that has integrity, truth, completeness, and traceability. A SOA system of record applies these concepts to all the information needed to make a collection of business services visible. The information in a SOA System of Record also facilitates control.
A SOA system of record must have integrity. Integrity is achieved by making sure that all the information describing a SOA has been approved by the proper authorities. (It is always a good idea to make your approvers the same people who will ultimately pass judgment on the success of your SOA.) IT Administrators, Solution Architects, Quality-Assurance personnel and Enterprise Architects are good candidate approvers. If a SOA System of Record has integrity we can say that this information specifies how management wants the SOA to operate. Examples of information that should be carefully reviewed during an approval process are: run-time security requirements, service-level agreements, and any specific contractual agreements made with important consumers.
A SOA system of record must be complete. If a system of record contains information about only small fraction of our business services, reuse is compromised at design time, because there are services that are not discoverable via the system of record. Additionally, management and governance are compromised at run time, because governance tools and management tools will not be able to lookup proper behavior for all services deployed to the datacenter. Clearly, completeness is a little tougher to achieve because this is a people problem requiring cultural change and discipline.
Information about a specific business service is said to be true when it accurately describes what is currently deployed in the data center. If the information describing a SOA is out of date (or otherwise untrue) it will cause problems when it is referenced or it will not be referenced at all. A SOA system of record will be consistently true if design-time policies (described later) dictate that the information describing business services must be properly approved before all versions of business services are deployed.
A SOA system of record must be traceable. As a consumer of a business service, the traceability of the information in a system of record allows us to find the owner of a business service. After all, as a consumer of a business service, real-world issues may require you to speak to a real human being about the proper use of a business service. As a provider of a business service traceability allows us to build newer versions of a business service effectively. Therefore, a system of record should be able to provide a list of service consumers; report on how consumers are using a business service; and determine high-volume consumers. Armed with this information, a business analyst can work with the appropriate consumers (those high-volume consumers) to gather the best requirements for the next version of the business service. Traceability can also help a solution architect understand the impact of change. If needed, breaking changes can be communicated to existing consumers as early as possible to determine if two versions of a business service need to be maintained.
Definition 7 is a summary of the description above. The software industry has come to view a SOA system of record as the information that is contained in a SOA Registry, and a SOA Repository. The rest of this section will define the SOA Registry and the SOA Repository and take a detailed look at the capabilities of each.
SOA system of record—A SOA system of record contains the information needed to provide visibility for all the services in a SOA. This same information can be used to enable design time controls and run-time controls. For a SOA system of record to be effective, the information within it must be true, complete, and traceable, and must possess integrity.
Definition 7. SOA system of record
The SOA Registry
A SOA Registry is where structured information about a SOA is stored. The best way to think about a SOA Registry is to think of it as an identity-management system for services. Using this analogy we can compare the high-level capabilities of a SOA Registry to the capabilities of a product like Microsoft Active Directory. A common use of Active Directory is to keep track of an organization's employees. Specifically, Active Directory can keep track of metadata about an employee and can define proper behavior for each employee when using corporate resources. The bottom line is that an organization would not allow anyone that has access to their network to use resources without first asking that individual for their identity. As soon as a network user's identity is known, their behavior can be governed as they use corporate resources. Similarly, a SOA Registry keeps track of service metadata which gives each service a unique identity. The information stored for each service should establish ownership for the service and should specify how the service should behave at run time.
For example, a consumer of a service should be able to easily find service metadata and contact information for the service owner, in the event that a conversation with a human being is needed to understand the details of a service. This is an example of visibility. A registry also keeps track of proper run-time behavior. Run-time behavior could be dictated by IT policy that places security and reliability requirements on messages coming into and going out of an organization's data center. This is an example of control. Proper run-time behavior could also be dictated by service-level agreements made between the service provider and the service consumer. For example, a service consumer may agree to make only a certain amount of requests per day and a service provider may promise a certain response time as long as the number of requests per day is not exceeded. The bottom line is similar to the bottom line with Active Directory; organizations do not want unknown services processing messages in their data centers.
Definition 8 is the definition of a SOA Registry, and Figure 2 is a capability map for a SOA Registry that shows registry capabilities categorized according to core capabilities, data capabilities, life-cycle capabilities and run-time capabilities. The remainder of this section describes these capabilities in more detail.
SOA Registry—A SOA Registry is an identity-management system for services. In addition to giving each service a unique identity, a registry can categorize services according to an organization's custom taxonomy. A SOA Registry also stores service configuration and tracks a services dependencies on other services. Finally, a registry stores policies and policy associates, so that the proper design-time behavior and run-time behavior for the service can be documented.
Definition 8. SOA Registry
Figure 2. Registry capabilities (Click on the picture for a larger image)
Core Capabilities
The lowest level of capabilities is Core capabilities, which are crosscutting capabilities that apply to all the data in the SOA Registry. These core features are UDDI Data Store, Web Service Access, Security, and Replication.
UDDI Data Store
Universal Description, Discovery, and Integration (UDDI) is an OASIS standard that started out as a standard to be used by organizations that wanted to build a public universal business registry. Microsoft, IBM, and SAP are examples of companies that built and hosted such a public business registry. The idea was that any provider that had a service to offer the public could publish information about themselves and their services to one of these "business registries." Any third party could then discover and use these services. All business registries synchronized with each other on a regular basis, so it really did not matter which node was used for the initial publication of provider and service information. In other words, information on all nodes was the same. This idea never took off, and, since then, these public business registries have discontinued operation. The standard itself has survived and has evolved into a standard that can be used for building internal SOA registries. The current version of UDDI is UDDI v3.0.2, which became an OASIS standard on February 3, 2005.
Most SOA Registries implement the UDDI specification. UDDI describes an information model and Web service APIs for accessing the information model. The Web service APIs will be discussed in the next section. Here, I will describe the benefits of a standardized information model.
The fact that a registry is built using a standardized information model provides two main benefits. First, if you need to move your data from one registry to another you should be able to do this with little problems. This could be a common scenario for organizations that do not want to pay for a high-end registry during their initial stages of SOA adoption. However, as soon as the number of services and the number of development teams using the SOA Registry increases, that same organization may require the added capabilities of a more expensive registry. It is important to note here that even though UDDI provides a common information model, this model is very flexible and vendors of SOA Registries have plenty of ways to provide unique capabilities and still be compliant with the standard put forth by UDDI's information model.
The second benefit of UDDI is that it is a public design put forth by a consortium of industry experts. By using this design, organizations (whether they are SOA Registry vendors or companies that want to build their own SOA Registry) can build upon the experiences of others. As stated earlier, UDDI is currently at version 3.0.2; therefore, much collaboration has gone into the creation of this standard.
The five core UDDI types are the following:
- businessEntity
- businessService
- bindingTemplate
- tModelInstanceInfo
- tModel
Table 1 provides a brief description of each of these types, and Figure 3 illustrates their relationship to each other.
Table 1. Core UDDI types
| Type name | Description |
| businessEntity | This is the top-level structure of the core UDDI types described here. It is used to describe a provider of services. Even though the name of this type implies that businesses are described here, you are free to use this type to describe any parent entity that provides services. Companies, Departments and Applications are examples of entities that may be described with this structure. |
| businessService | The businessService type is used to represent a logical grouping of services or a suite of services. As an example, if the businessEntity type was used to describe a department, the businessService type could be used to describe an individual application. Multiple businessServices may be contained with a single businessEntity, but each businessService must belong to exactly one businessEntity. The name of this type is unfortunate; at first glance, one may think that an actual business service will be specified here. This is not the case, because the businessService type is for organizational purposes. The bindingTemplate type is where an individual service is defined. |
| bindingTemplate | A bindingTemplate represents an individual service. A bindingTemplate is contained within the businessService type. Multiple bindingTemplates may be contained within a single businessService, but each bindingTemplate must be contained within exactly one businessService. It is at this point in the UDDI information model that technical information about the service is captured. This is in contrast to the parent types (businessService and businessEntity), which contain nontechnical contextual information about the service. |
| tModelInstanceInfo | The tModelInstanceInfo type is not considered a core structure in most UDDI texts; it is, however, important. Multiple tModelInstanceInfo elements may be contained within a single bindingTemplate, but each tModelInstanceInfo element must belong to exactly one bindingTemplate. Each tModelInstanceInfo element references exactly one tModel and is used to hold reference specific information about the tModel. A bindingTemplate may need to reference multiple tModels if there are multiple versions of the service deployed. Multiple tModels could also be used if message contracts are published and a service is reusing a message contract that was developed by a dependent service. |
| tModel | tModel stands for technical model. The most common use of a tModel is to store the location of a services WSDL file. However a tModel could be used to store just about any type of information due to its flexibility. The tModel is the only structure in this table that is not associated via parent containment. Consequently, a tModel can be referenced more than once from various places within the UDDI data model. This would not make sense if a tModel was used to store the location of a WSDL file; but, if the tModel was used to store the location of a message contract that was going to be used by multiple services, allowing different bindingTemplates to reference this tModel is advantageous. |
Figure 3. UDDI core entities (Click on the picture for a larger image)
Web Service Access
It should be no surprise that the UDDI specification describes all UDDI data access in terms of Web services. The UDDI specification uses the term "API set." An API set is essentially a single Web service containing related operations. The list of UDDI API sets and a brief description of each appear in Table 2. The WSDL files for these services can be found on the OASIS Web site.
Having a common API for accessing the information in a SOA Registry is important when an organization is looking to implement governance and management of a SOA in the data center. The information that these tools need to do their job should come from the SOA Registry. By having a common API for accessing registry information you can purchase the governance tools and management tools that are right for you and be assured that they will work correctly together.
Table 2. UDDI API sets
| API set | Description |
| Custody and Ownership Transfer API Set | During publication of an item of UDDI information, a relationship is established between the publisher and the item published. By default a publisher that creates a new entry in the registry owns the new entry and has the authority to change it. This API Set allows ownership to be transferred. |
| Inquiry API Set | Allows entries in the UDDI registry to be located and detailed information to be returned. This is the API set that should be used when searching the registry or when detailed information about an entry is needed. |
| Publication API Set | Operations in this API Set are used to add, update, and delete information contained in a UDDI registry. |
| Replication API Set | The UDDI specification supports the concept of UDDI Nodes. A UDDI node is essentially a registry instance. A logical UDDI Registry may be composed of multiple physical nodes which reside in different locations. The Replication API Set provides replication between nodes so that changes made to one node propagate throughout the other nodes in the logical SOA Registry. |
| Security Policy API Set | This API set is used to request an authentication token. Registry policy dictates whether the use of an authentication token is required. If required an authentication token will be needed when using the Inquiry API Set, the Publication API Set, the Custody and Ownership Transfer API Set, and the Subscription API Set. |
| Subscription API Set | Used to allow registry clients to register their interest in receiving information concerning changes made to a specific entity in the registry. |
| Value Set API Set | Whenever a keyed reference is involved in a save operation it may be checked to see that it is valid and consistent with registry policy. This API set allows third parties to register validation logic to be used when the registry validates information to be saved on behalf of the third party. An example of this would be run-time policies being stored in the registry for use at run time by run-time governance tools. |
| Value Set Caching API Set | This API set works in conjunction with the Value Set API Set. If appropriate all valid third-party values may be retrieved and cached for use during validation. |
Security
The UDDI specification provides full support for both authentication and authorization. Registry policy dictates whether authentication is required. If authentication is turned on, any registry feature that utilizes the Inquiry API Sets, the Publication API Set, the Custody and Ownership Transfer API Set, and the Subscription API Set will require authentication. Authorization is also dictated by registry policy which can be used to setup roles and associate identities to these roles. As an example, the UDDI registry that comes with Microsoft Windows Server 2003 defines the following roles: reader, publisher, coordinator, and administrator. Each of these roles can be associated with an Active Directory group. IT Administrators should discuss both authentication and authorization with their SOA Registry vendors to ensure that both authentication and authorization will work correctly in the organization's data center.
Finally, a SOA Registry can be configured to use HTTPS to ensure that all information going into and out of the SOA Registry is encrypted and, therefore, confidential.
Replication
Replication is part of the UDDI specification. (See the description of the Replication API set, in Table 2.) Originally, this capability was used to synchronize the different public business-registry instances, as stated previously. Today, this capability can be used within an organization, so that multiple instances of a registry can be synchronized. This could prove useful for organizations that have multiple data centers and want to have a registry instance in each data center, for performance reasons.
Data Capabilities
A UDDI Registry often contains more information than what is explicitly shown in the core types depicted in Figure 3 and Table 1. One of the most intriguing designs of the UDDI schema is the fact that each of the core types is very flexible, due to the way that tModels (or Technical Models) are designed. This flexibility allows organization-specific data such as business taxonomies and policies to be placed within the registry and to be associated with any of these core UDDI types. This also allows SOA Registry vendors to build data capabilities that are not explicitly shown in the UDDI schema. Examples of such capabilities are dependencies and configuration.
The sections that follow describe core data capabilities that are critical to providing visibility into a SOA. Specifically, the next five sections describe provider information, service information, dependencies, business taxonomies, configuration, and policy. Because some of these capabilities need to be built with UDDI extensibility, it should be noted they may not exist in all SOA Registries. Additionally, registry vendors may have found other capabilities to add to their product that are not described here.
Provider and Service Information
A SOA Registry contains descriptive data for both the business service being registered as well as the provider of the business service. It is important to note here that the UDDI specification places no restrictions on the definition of a provider. It is entirely up to each organization to determine what definition of provider best matches its business. A provider could be a territory in which an organization develops software, a department, a line-of-business (LOB) application, or a data center.
Documenting provider and service information is a feature of visibility.
Dependencies
A cruel truth is that a SOA can become the victim of its own success without the proper visibility into both internal and external dependencies. Consider a business process that is exposed as a Web service to external customers. Let us also say that this business process is composed of 10 business services that are developed by separate development teams within the organization. This scenario is the goal of service orientation. Clearly, being able to reuse the assets of 10 other teams means that those assets did not have to be redeveloped. By trying to discover as many existing assets as possible the team that developed the business process realized one of the main values of SOA which is agility. In other words, this particular business process was developed and deployed in a short amount of time.
Unfortunately, this level of reuse can make a business process fragile. If just one of the teams that built a reusable business service deploys a breaking change, the entire business process could fail. Scheduled down time and service failure will also cause the entire business process to fail.
All the dependencies of the business process need to be understood. Breaking changes must not be deployed before proper notifications are delivered. Downtime must be scheduled appropriately. Finally, when faults occur, the ramifications of these faults must be understood immediately, so that the proper support personnel are notified.
A good registry will track and report business service dependencies. It is important to note that there may be hidden dependencies. Consider the scenario shown in Figure 4. Here, service A consumes service B, which in turn consumes services C and D. All of these dependencies must be known to a consumer of service A and to IT administrators responsible for supporting service A. As organizations become more accustomed to building composite services, dependency mappings could become much more nested than what is depicted in Figure 4.
Tracking dependencies is an important feature of visibility.
Figure 4. Dependencies in a SOA
Business Taxonomy
A business taxonomy is a custom categorization scheme for provider information and service information. Figure 5 is an example of a custom categorization scheme that could be applied to a business service in a SOA Registry. Notice that the scheme depicted in Figure 5 allows a business service to be classified according to many different property types—that is, functionality, physical location, approval status, and deployment status. A business taxonomy can be a simple single level structure or it can be more complex with many levels of classification.
Figure 5. Sample service taxonomy (or Service Classification Scheme)
It is important to note that business taxonomies should be designed at the same time that an organization is determining how to define service providers. Some questions to consider here are: What is a provider of a service? What is a classification scheme for service providers? What is a classification scheme for services?
There is a lot of flexibility that can be achieved with business taxonomies, and the correct design is the design that best matches the business and best facilitates discovery.
Clearly, a business taxonomy helps to provide visibility into a SOA.
Policies and Policy Association
Policies are declarative rules that define correct behavior. The fact that policies are declarative means that they are reusable. In other words, the same policy could be associated with more than one service. A good registry allows policies to be associated with a specific level in an organization's business taxonomy. Associating policies with different levels of a business taxonomy gives a policy scope and makes policies very easy to reuse and maintain.
As an example of a policy, let's say that it is desired to have all Human Resource related services use encryption to ensure privacy. To meet this requirement, a policy that states that "business services must use WS-Security to ensure private communications" can be created using a standard format (typically, WS-Policy) and stored in the SOA Registry. This policy can then be associated with the Human Resources level of an organization's custom taxonomy. The result: All business services classified as Human Resource business services will need to use the encryption capabilities of WS-Security for privacy, if they are to be compliant with this policy. It is important to note that declaring policies and associating policies to services should not be confused with governance. Policies merely define correct behavior. Governance is the act of enforcing policies. More will be said about policy and governance, later in this article.
Policies and policy association facilitate control of a SOA.
Configuration
Potentially, there are two types of configuration that could be stored in a SOA Registry: client configuration and server configuration.
Client configuration is all the information that a consumer of a business service needs to consume the business service. If the business service is a Web service, this information is packaged as a WSDL file. WSDL is an industry-standard format for describing a Web service's contract, bindings, and address. Storing client configuration information in a SOA registry for a Web service allows tools such as Microsoft Visual Studio .NET to discover and reference Web services at design time. If the business service is some other type of service than the client configuration information will be in a format that is specific to the business service's implementation. As an example, if the business service is a DCOM component than this information will be an IDL (Interface Definition Language) file which is an artifact used to describe the interfaces of COM components. Having address information in a registry as part of client configuration provides location transparency. When address information is stored in a registry, service consumers can look up (and cache) an address if they receive a fault due to the service changing locations.
Theoretically, server configuration could also be stored in a SOA Registry. The configuration information would be in a format that is specific to the business service's implementation and would contain information that a business service host would use to instantiate a business service and listen for request messages on a network address. An example of this type of configuration would be Windows Communication Foundation's (WCF) XML configuration file. It is important to note here that storing server configuration in a SOA Registry is not a mainstream capability of most SOA Registries on the market today. This capability would require custom logic to be placed within a service host that would look to a SOA Registry for server configuration.
Centralizing the configuration of all services in a SOA is important capability that facilitates control.
Life-Cycle Capabilities
The life-cycle capabilities described here are Registry features that are used directly by the registry users depicted in Figure 2. More specifically, these users are human beings who play a role in the development of business services to be used within a SOA. As you will see in the upcoming discussion, a well-maintained registry provides capabilities for all the roles in an organization's software-development life cycle.
Publish
The ability to publish allows for all the provider and service information to be entered into the registry. It is important to note that publication includes an organization's custom taxonomy that will be used to categorized providers and services. Publication also includes the bootstrapping of the registry with an organization's policies which will be associated with services in order to describe correct behavior. The Publication API Set shown in Table 2 allows for this information to be entered into a registry programmatically.
The capability to publish provider and service information facilitates visibility.
Discovery/Service Inquiry
Discovery is the capability for business services and any type of data about a business service to be found. Discovery is a registry capability that everyone in the software-development life cycle will utilize. Consider the business process of Figure 6, which automates the updates that need to be made to various systems when a customer payment is received.
Figure 6. Building a business process with existing business services (Click on the picture for a larger image)
First, a business analyst who has just completed a logical design of the new business process could start searching through a SOA Registry, to map the business-process activities to business services that may meet certain requirements of the business process. During this phase of the business-process design, the analyst would be concerned with the functional descriptions that are found in the registry, as well as the service-level agreements that promise response times and specify the cost of using the business services.
An architect would then review the logical design of the business process and confirm that the suggested mappings between logical business-process activities and existing business services meet architecture requirements. During the architectural phase of development, the architect would also be concerned with ensuring that the entire business process meets requirements for security and interoperability. This includes all dependent business services.
Development would then take the architected business process and begin implementing it. Development tools like Visual Studio .NET allow access to any UDDI-compliant registry, so that business services can be discovered and referenced from any VS.NET project.
During the testing phase, QA would use the registry to find all policies (service-level agreements, security, interoperability, and so on) of the business process itself, as well as all the policies of all dependent services and use these metrics when performing integration testing. QA may also need to look up contact information for dependent business services, in the event that problems are discovered in dependent business services.
Finally, IT Administrators may want to use Discovery features when approving the business process to make sure that the proper resources are provisioned for all dependent business services. This is important, because the extra load of the new business process may cause dependent services to become overloaded.
Discovery and service inquiry are key components of SOA visibility.
Approval Process/Change Management
For years, development teams and IT Administrators have found it challenging to collaborate effectively in the software-development life cycle. IT Administrators are often frustrated by development teams implementing components that do not conform to policies set forth by the data center. Similarly, development teams have complained that they do not have the time to read hundreds of pages of IT policy and they need a governance framework that is agile when trying to meet the needs of the business. The root of both of these problems is a lack of collaboration. A SOA that encourages reuse by exposing business logic on network addresses will almost certainly exacerbate this problem. This is due to the fact that each endpoint is an additional configurable entity that needs to be governed and managed. Proper workflow and notification capabilities can make sure that all interested parties are informed early enough to affect the final outcome. Additionally, a good registry can limit the discoverability of new business services that have not been approved.
An approval process that manages change to the data center is important to controlling a service-oriented architecture.
Subscription and Notification
Subscription and Notification allows interested parties to register for business service change events. Consider the scenario in which a solution architect is going to reuse several business services that were implemented by another development team. The solution architect should have a way to subscribe to change events for the business services that his or her application depends upon. This will allow the solution architect to be notified as soon as changes to dependent business services are planned.
The maintenance of dependencies and change notification are two capabilities that should work hand in hand. If a business service is scheduled for change, all parties that depend on that business service should be notified. It is important to note that change notification does not always have to be a change in the service contract. Changes to service-level agreements and other run-time policies are important and may require attention by dependent parties.
Subscription and change notification are important aspects of visibility, because these capabilities can proactively keep interested parties up to date with respect to changes occurring within the SOA.
Design-Time Governance
Governance is the act of enforcing the correct behavior defined by policy. Governance comes in the same two flavors as policy: Run-Time Governance and Design Time Governance. Run-Time Governance, as the name implies, governs service behavior at run time or post deployment by enforcing the correct behavior described by run-time policy. Design Time Governance on the other hand governs behavior prior to deployment or during the software-development life cycle by enforcing correct behavior described by design-time policy. Only Design-Time Governance is a registry capability.
As an example of design-time governance, consider a business service in which policy dictates that the business service must use secure sockets when receiving and sending messages. If the business service is published with an address that does not use HTTPS for its transport, that business service should show up in an exception report and should not be promoted to a deployable status.
Governance will be discussed in more detail, later in this article. It is important to note Design Time Governance in this section because it is a key life-cycle capability of a registry that provides control during the development of services.
Run-Time Capabilities
The run-time capabilities depicted in Figure 2 are capabilities that are invoked in the Data Center when a business service is running. Unlike the life-cycle capabilities, which are used by humans, the users of run-time capabilities are tools installed in the data center that provide governance and management to the business services that make up the SOA. These three capabilities (Service Lookup, Policy Lookup, and Configuration Lookup) are special cases of service inquiry, and retrieve the information necessary for the governance and management of business services deployed to the data center.
The Repository
As stated earlier, the SOA Registry is only one of two components that make up a SOA system of record. The other component of a SOA system of record is the Repository. The definition of a SOA Repository varies widely within industry publications that can be found on the subject or related subjects. Many times, the terms Registry and Repository are deemed interchangeable when they are, in fact, different. The following definition clearly states the purpose of a basic SOA Repository.
Repository—The basic SOA Repository contains information that is referenced (usually, via a URL) from the SOA Registry. Based on common registry capabilities these documents are: WSDL files; other interface files; Policy files; and an organization's custom business taxonomy (usually, an XML file). The SOA Repository can also contain artifacts generated at run time, such as logged messages, archived performance data, and archived health data.
Definition 9. The SOA Repository
No system can be completely described by structured data alone. Ultimately, some form of "document" or nonstructured data will be used to describe some aspect of a software system. Before Web service standards, tools like Microsoft Office Word and Office Excel were used to describe system interfaces, development best practices, and data-center policy. Today, standards built with XML and XML Schema have done a lot to structure some of this information for Web services. For example, WSDL can be used to describe contracts, bindings and WS-Policy can be used to describe rules that must be adhered to at design time and at run time.
As you can see from the preceding definition, a Repository is somewhat of a document repository. A creative way to extend a SOA repository would be to add collaboration and reporting capabilities to the repository. Team sites could be used to facilitate collaboration while requirements, functional specifications and technical specifications are being development. Wikis and blogs could be used for collaboration that is external to the immediate team. Finally, reports and dashboards could be created to show Key Performance Indicators (KPIs) gleaned from message logs, performance data, and health data. Figure 7 shows both the basic repository capabilities that are common today, as well as potential extensions to a repository.
Figure 7. Repository capabilities
Policy
As stated previously, a SOA policy is a declarative electronic rule that defines correct behavior. Today, these policies typically exist as paper-based rules buried in specifications authored by architects, IT administrators, and business analysts. For example, it is not uncommon for an organization's central architecture team to write up best practices for the proper implementation of Web services. Such best practices typically include rules for ensuring interoperability and security. Additionally, IT Administrators often write up rules of their own that describe proper run-time behavior and deployment practices. An example here may be the use of wire-level encryption for all information transmitted to and from the data center. Finally, a business analyst may have negotiated service-level agreements with the users of a business service. These rules may involve the cost of using a service or the turnaround time of service requests. Definition 10 defines policy, and Table 3 is a typical example of policies that may be associated with any given business service.
Policy—Describes correct behavior. Design-time policy describes correct behavior for developing business services within the software-development life cycle. Run-time policy describes correct behavior post-deployment or at run time.
Definition 10. SOA policy
Table 3. Sample policies that may be associated with any business service
| Policy name | Description | Policy type | Author |
| Data Center Approval | Business service must be approved by an IT Administrator before being deployed to the data center. | Design Time | IT Administrator |
| Interoperability | Business service must be interoperable. | Design Time | Enterprise Architect |
| WS-I Basic Security Profile | Business service must be interoperable according to the WS-I Basic Security Profile. | Design Time | Solution Architect |
| Authentication | Business service must authenticate each call. | Design-Time or Run-Time | IT Administrator |
| WS-Security Authentication | Business service must use WS-Security for authentication. | Design-Time or Run-Time | Solution Architect |
| Encryption | Business service must encrypt all messages. | Design-Time or Run-Time | IT Administrator |
| WS-Security Encryption | Business service will encrypt using WS-Security encryption. | Design-Time or Run-Time | Solution Architect |
| Response Time (1s) | Business service will have a response time of 1 second per call. | Run-Time | Business Analyst |
| Cost ($0.01) | Business service will cost $0.01 per invocation. | Run-Time | Business Analyst |
It is important to note that these policies are named and are stored exactly once in the SOA Registry. This is important because it means that a policy can be reused easily by merely associating (or linking) it to business services that must operate under the constraints specified by the policy. As stated earlier, policy association can be done via the business taxonomy.
Another advantage to using declarative electronic policies is that they are stored, maintained, and enforced by your service-oriented infrastructure. This means that SOA policy does not require special attention by developers implementing business services. In other words, developers should not have to write instrumentation logic that tracks response time and keeps track of usage statics for the purposes of customer billing.
Design-Time Policies
Design Time Policies describe proper behavior that should occur during the software-development life cycle. The first three policies listed in Table 3 are design-time policies, because a business service's use of authentication, encryption, and interoperability is dictated by configuration. Because configuration files are artifacts that are created during the software-development life cycle, rules which govern their creation are design time policies.
Run-Time Policies
Run-time policies dictate proper behavior at run time (post-deployment). Typically, these policies dictate the proper format for messages and the proper behavior of business services while they are executing. The last two policies in Table 2—Response Time (1s) and Cost ($0.01)—are definitely run-time policies. These two policies require metrics which exist only at run time. Specifically, response time must be measured to determine if the Response Time (1s) policy is being violated and a usage count must be maintained for the Cost ($0.01) policy. The rules that pertain to authentication and encryption could be considered run-time policies, because it is possible to check request and response messages for authentication headers and some form of encryption. However, these policies could also be governed at design time because in most modern services these behaviors are controlled by configuration. Ultimately, it will be up to the solution architects and the IT Administrators to decide where to place enforcement points when governing a service-oriented architecture.
Governance and Management
Governance and Management make up the Control capabilities of a service-oriented infrastructure. Today, most data centers have general governance and management capabilities that were implemented without service orientation in mind. This section takes a look at governance and management as it applies to an environment running business services.
Governance
The enforcement of policy is known as governance. Policies that are specified electronically can be enforced programmatically. When policies are electronically specified and programmatically enforced, a human reviewer no longer needs to read pages of IT policy and inspect endpoint configuration and logged messages for conformance. In a service-oriented architecture, Governance comes in two flavors: Design-Time Governance and Run-Time Governance.
Governance—Governance is the act of enforcing Design-Time Policy and Run-Time Policy. Enforcing design-time policy ensures proper behavior during the software-development life cycle. Enforcing run-time policy ensures that messages are properly formed and that services execute according to service-level agreements.
Definition 11. Governance
Design-Time Governance
Design-Time Governance is the act of enforcing design time policies prior to business services being deployed. Therefore, Design-Time Policies can be checked at any time prior to deployment in the software-development life cycle. Design-Time Policies usually involve constraints that are placed on the configuration of business services and can also dictate the approvals that must be acquired before a business service can be deployed.
Run-Time Governance
Run-Time Governance is the act of enforcing Run-Time Policies after a business service has been deployed. Run-time governance involves message inspection as well as the monitoring of business services while they execute. When messages are inspected they are checked to make sure that they are formed according to the Run-Time Policies stored in the SOA system of record. A soon as the message is inspected and is delivered to the appropriate business service, the execution of the business service is monitored to ensure compliance with service-level agreements.
Run-time policy enforcement is done at Policy-Enforcement Points (PEPs). PEPs are points in the runtime environment in which messages are checked and business services are monitored. A PEP can be an intermediary that sits between the client and the service. Figure 8 shows an intermediary policy enforcement point and the processing that occurs from the time that a request message is first received to the time that a response message is sent back to the client. A PEP can also be an interceptor which is located within the service host. Figure 9 shows an interceptor policy enforcement point and the processing that occurs. Whether a PEP is an intermediary or an interceptor it performs the same job and that is to enforce all run-time policies.
Figure 8. Intermediary PEPs (Click on the picture for a larger image)
Figure 9. Interceptor PEPs (Click on the picture for a larger image)
Management
Management that is specific to service orientation is critical as soon as a business becomes dependent on the functionality and the business processes implemented within a SOA. Traditional data-center management is concerned with the health of servers. SOA management is concerned with the health of the business services themselves. Utilizing the SOA System of Record, SOA management tools can determine the servers that are hosting business services and check to make sure that those services are up and running. Additionally, SOA Management tools need to be on the lookout for fault messages. The ability to detect fault messages is important; without this ability, services that are faulting may appear to be healthy.
Putting It All together: A Service-Oriented Infrastructure
Figure 10 shows all the capabilities discussed in this article as they would appear in the data center interacting with existing application silos. This diagram is a generic view of the capabilities needed within a SOI for the development and execution of business services in a visible and controllable environment. The emphasis in this diagram is interoperability between line-of-business (LOB) applications.
If Figure 10 were redrawn to illustrate business-to-business interoperability, all the same capabilities discussed in this article would still be needed. You would still need visibility into your partner's business services, and you would still need to govern and control the use of these business services in the same manner in which you govern and manage your own business services.
Figure 10. Visibility capabilities, control capabilities, and business services in the data center (Click on the picture for a larger image)
Conclusion
Visibility and Control are critical capabilities to add to a data center that is going to host a large number of services.
Without the proper visibility into service offerings, discovery will be compromised. When discovery is compromised, reuse cannot be maximized, and redundant services will exist in the data center. Visibility also prevents a service-oriented architecture from becoming the victim of its own success. This is especially true of organizations that plan to make heavy use of Web services. Web services are easy to build and consume; consequently, mission-critical business services could easily become dependent on business services that they are not invoking directly.
SOA Control (Governance and Management) prevents data centers from becoming chaotic and unhealthy. SOA Governance makes sure that business services are built and execute according to data-center policy. In the case of Web services, message-level policies can be governed. SOA Management can detect problems with business services and can alert data-center administrators the moment problems occur.
All the capabilities discussed in this article do not need to be acquired overnight. If enterprise architects understand all the potential capabilities of a service-oriented infrastructure, they can ask the right questions of their staff and their vendors, so that they can develop an adoption plan that is right for their organization. With the proper infrastructure capabilities in place, organizations will prevent their IT offerings from becoming fragile and will reap the benefits of a service-oriented architecture.
Acknowledgements
I would like to thank the following people for finding the time to proof this article for accuracy and understandability:
Jeff Barnes, Architect Evangelist for the U.S. East Region Developer Platform Evangelism Team
Jim Williams, Architect for Microsoft Consulting Services
Zhiming Xue, Architect Evangelist for the U.S. East Region Developer Platform Evangelism Team
References
W3C WS-PolicyAttachment April 25th 2006
WS-I Basic Security Profile Version 1.0
About the author
Keith Pijanowski is a Platform Strategy Advisor for Microsoft Corporation, specializing in Enterprise Architecture. Keith helps Microsoft customers apply new technologies to business problems. Keith is also a frequent speaker at Microsoft events and community events in the New Jersey and New York areas.
Không có nhận xét nào:
Đăng nhận xét