Metadata for an Enterprise SOA
In my previous post I asserted that today the best way to think about SOA is to think of it as an Enterprise Architecture. Specifically, if an organization wishes to maximize reuse and make sure that all their services are well behaved and operational, then information will need to be stored and maintained such that all services are well known and capable of being managed. Since we want to manage the entire lifecycle of services in a SOA this information must be captured and maintained for services under development as well as services that are deployed. For a collection of services to be well known and manageable, information must be maintained which describes in a consistent way the functionality of each service, the service owner, interested parties, dependencies, configuration, the services categorization according to a business taxonomy and finally a description of proper behavior.
In this post I will investigate this information. Figure #1 below shows the data types which make up a metadata DB for an Enterprise SOA. At the present time we are not concerned with the design time processes and the run time processes that will use this data to manage the various phases of a services lifecycle. These processes will be covered in a later post. Also the astute reader will recognize this information as information usually contained within a UDDI Registry/Repository (also known as a SOA System of Record). This topic is also beyond the scope of this post and will also be investigated in later posts. For now I want to focus on the metadata needed for a collection of services to be well known and manageable. Discussing lifecycle processes and standards for data storage often confuses and overshadows the importance of the SOA metadata itself.
Figure #1 – Data types for SOA visibility
Service Information
Service information should contain everything that is needed to understand a service’s purpose. For a developer or architect a technical specification may be referenced that describes in technical terms the information and business logic contained within a service. However, non technical roles within the software development lifecycle should also be able to use this data type to understand a service’s capabilities. For example, a business analyst should be able to read a service description while composing a business process (or workflow) in order to determine whether the service can be used as an activity within the business process.
Provider Information
A Provider is a service owner. This could be any entity within an organization that develops or acquires services that will eventually be deployed to the datacenter. Geographic territories, companies, departments and application development teams are examples of entities that may be described with this data type. A consumer of a service who wishes to speak with a human being would use this data type to find contact information for such a responsible party.
Subscriptions
Subscriptions are a list of interested parties that need to be notified if anything changes with respect to a specific service. It is a best practice for all dependent parties to be subscribers to change notifications. If a business service is scheduled for change then all parties that depend on that business service should be notified. It is important to note that subscribers should be concerned with more than changes to a service’s contract. Changes to service level agreements and other run time policies are also important to track and may require attention by dependent parties.
Dependencies
Consider the business process of Figure #2 which is exposed as a service and is composed of several other services each of which may have been developed by separate development teams within the organization. This scenario is the goal of service orientation. Clearly, being able to reuse the assets of other teams implies that those assets did not have to be redeveloped. By discovering as many existing assets as possible the team that developed this 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.
Figure #2 – Business Process with Service Dependencies (click for larger image)
Unfortunately, this level of reuse can make a business process fragile. If just one of the teams that built one of the dependent services deploys a breaking change then the entire business process could fail. Scheduled down time and service failure will also cause the entire business process to fail. Therefore, support personnel need to understand dependencies so that support issues can be prioritized and downtime for maintenance can be schedules appropriately.
It is important to note that there may be hidden dependencies. Consider the scenario shown in Figure #3. Here service A consumes service B which in turn consumes services C and D. The ramifications of these dependencies must be understood by the providers of service A and to IT administrators responsible for supporting service A. As organizations become more accustomed to building composite services then dependency mappings could become much more nested than what is depicted in Figure #3.
Figure #3 – Hidden Dependencies
Configuration
Potentially there are two types of configuration that could be stored for each service in a SOA: Client Configuration and Server Configuration.
Client Configuration is all the information that a consumer of a service needs to consume the service. If a service is a web service than this information is packaged as a WSDL file. Web Service Description Language (WSDL) is an industry standard format for describing a web service’s contract, bindings, and address. Centrally storing client configuration information allows development tools to discover and reference services at design time. At run time consumers of a service can use centrally stored client configuration for location transparency. For example, service consumers can look up (and cache) an address if they receive a fault due to a service changing locations.
Server configuration can also be centrally stored. This information would be in a format that is specific to the service’s implementation and would contain information that a service host would use to instantiate a service and listen for request messages on a network address.
Business Taxonomy
A Business Taxonomy is a custom categorization scheme for classifying services. This is an important tool for facilitating reuse as it can greatly narrow search results during discovery. A Business Taxonomy can be a simple single level structure or it can be more complex with many dimensions of classification. Figure #4 below is an example of a categorization scheme that could be used as a business taxonomy.
Figure #4 – Example of a Business Taxonomy
Policies
A SOA policy is a declarative electronic rule that describes correct behavior. Design time policy describes correct behavior for developing business services within the software development lifecycle. Run time policy describes correct behavior post deployment or at run time. An example of design time policy would be a policy which states that WS-Security (a web service standard) must be used to ensure private communications. Whereas an example of run time security would be a policy which states that a service must produce a response within a certain time frame. In these examples the design time policy describes the correct configuration for a service because most application development tools can setup WS-Security for a service via configuration. The run time policy describes performance metrics that must be met each time the service is invoked.
Policy Association
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. Oftentimes policies are associated with a specific level in an organization’s business taxonomy. Associating a policy with different levels of a business taxonomy gives a policy scope and makes policy easy to reuse and maintain. Figure #5 is an example of a design time security policy and a run time security policy being associated with the Human Resources business function category. As a result all services that are categorized as Human Resource services will need to conform to these policies. This means that policies do not have to be individually linked to every service being managed. If a new service is entered into our “SOA Metabase” and is categorized as a Human Resource service then the development team building the service will have to configure the service for privacy if it is to pass the checks that result from these policies. Also the same service will have to produce a response for every request within 0.5 seconds if it is to be in conformance with the run time policy.
Figure #5 – Example of a Policy Association
Conclusion
Any large system composed of many components will need a central database or directory where each component can be sufficiently described for processes that are responsible for keeping the system as a whole healthy. In an Enterprise SOA this can be done with the data types described in this post. This post was only concerned with the data need for tracking and managing a collection of services. Future posts will describe design time processes and the run time processes that use this data for keeping an Enterprise SOA operational.