This is a work product created from an Enterprise Architecture view and thought processes around the process of establishing an Enterprise Service Taxonomy for Enterprise wide SOA adoption.
Purpose of this work product is to help SOA professional to define service taxonomy at the enterprise level during the SOA adoption activities.
Definition of Service Taxonomy
- Define the categories of services inside an enterprise domain.
- Define the relationships among categories of services.
- Define the principles underlying the classification of different service types into the different categories.
- Address the categorization of services with both the software architecture and the business-related aspects relevant to the construction and management of composite applications using services.
- Is based on the concept of classification of things, as well as the principles underlying such a classification.
- Can be hierarchical, meaning it is a tree structure of classifications for a given set of service objects.
- Use an ontology concept – a data model that represents a set of concepts within a domain and the relationships among those concepts.
Benefits of Service Taxonomy
- For the software architecture of composite business applications, a common ontology and taxonomy enables the identification of the common characteristics of services used in the composite application. Such common characteristics affect the architecture and design of SOA-based solutions, from the individual service level up to the entire composite application.
- The categorization in taxonomies supports composability by clarifying the roles of different components, thus promoting the understanding of component interrelationships.
- Categorization also assists with the discoverability of services (for example, searching for existing services by using a service repository), which can further promote reuse.
- A proper common ontology and taxonomy can be used in making business-related decisions about service composition, such as deciding how to obtain a capability (build versus buy versus lease) or how to manage services (central management versus per application) and making other decisions.
Service Categories and Types
Categorization of services can be done using either a horizontal ontology approach or a vertical ontology approach. A horizontal approach classifies services according to the type of tasks they support, while a vertical approach uses business-specific concepts and relationships for classification. The following sections explain these approaches.
Horizontal Approach
The horizontal approach is typically the first one used when employing a "bottom-up" approach for service identification. In this approach, services usually are divided into two major groups:
- Infrastructure services – Services that provide common facilities that are not considered part of an application; these range from low-level services offered by the operating system such as the memory management and I/O handling to the high-level runtime-environment-specific facilities such as the Java Runtime Environment (JRE) Runtime Library or the Microsoft .NET Framework.
- Application services – services that provide building blocks for business applications. Application services can use infrastructure services as well as other application services to provide functionality.
Infrastructure Service Categories :Infrastructure services can be further divided into:
- Communication Services, which provide message-transfer facilities such as message-routing and publish-subscribe.
- Utility Services, which provide capabilities unrelated to message transfer such as service-discovery and identity federation.
Application Service Categories:Application Services can be further divided into the following, in increasing order of complexity:
- Entity Services, which expose and allow the manipulation of business entities.
- Activity Services, each of which implements a single functional building block of the application (sometimes referred to as a component or module); they are also referred to as task-centric services. An Activity Service is singular in context – it represents an atomic service task. A Java example would be a stateless session bean exposed as a web service.
- Capability Services, each of which also implements a functional building block of an application and is task-centric, but is plural in context in that it is a composite of multiple tasks. A Java example would be a stateful session bean exposed as a web service. A single capability service may use multiple activity services.
- Process Services, which compose and orchestrate entity, capability and Activity Services to implement business processes.
Horizontal Approach Example Scenario
The following diagram illustrates how a business process is composed of other services in different horizontal categories.
- This Process Service orchestrates three Activity Services and two Capability Services. (It is typical for Process Services to tie together multiple services to implement a complex business process.)
- One of the Activity Services (Activity 2) is using a Capability Service (Capability 3), possibly because Activity 2 may be implementing a multi-step activity over that Capability Service or exposing a different service interface than that of the underlying Capability Service.
- Capability Services 2 and 3 use Entity Services 2 and 3, respectively.
- Entity Services 2 and 3 access the same underlying data store. Possible reasons might include:
- To expose different entities from the same underlying store, or
- To expose the same entity in different ways to fulfill different requirements that Capability Services 2 and 3 have regarding the data model.
- To expose different entities from the same underlying store, or
- Capability 1 resides outside of the organizational boundary (as indicated by the Internet cloud), and acts as an external resource that is woven into the business process.
Using Horizontal Service Categories
Use the following table to determine the category that your services will use, based on your service's characteristics.
| Service Category | Characteristic | Explanation |
| Communication Services | Main purpose | Message transportation |
| Interface | Not processing application messages; may have management and monitoring interfaces | |
| State management | No management of application state | |
| Transactions | Not applicable (they are not processing application messages) | |
| Error handling | No application-related error handling | |
| Security | User/Application/Both | |
| Management/Governance | Centralized | |
| How built | Centrally built or purchased | |
| Utility Services | Main purpose | Generic (non-application-specific) infrastructural functionality |
| Interface | Service interface for exposing the service's functionality; may also have management and monitoring interfaces | |
| State management | No management of application state; may have their own state | |
| Transactions | Typically, not supported | |
| Error handling | No/limited application-related error handling | |
| Security | User/Application/Both | |
| Management/Governance | Centralized | |
| How built | Typically purchased | |
| Entity Service | Main purpose | Expose and manage business entities |
| Interface | Entity-level CRUD and domain specific operations | |
| State management | Managing application state is the primary purpose of the service | |
| Transactions | Atomic and/or Reservation Pattern | |
| Error handling | Limited error compensation (affects SLE and SLA) | |
| Security | User/Application/Both | |
| Management/Governance | Centralized | |
| How built | In-house/Purchased/Leased | |
| Activity Services | Main purpose | Implement a specific application-level business capability |
| Interface | Service interface for exposing main functionality | |
| State management | Typically, holds no application-specific state (unless when wrapping and exposing an existing system) | |
| Transactions | May support atomic transactions and/or implement the Reservation Pattern over an existing system | |
| Error handling | Limited error compensation (affects SLE and SLA) | |
| Security | Application-level | |
| Management/Governance | Per application | |
| How built | In-house | |
| Capability Services | Main purpose | Implement a generic value-add business capability |
| Interface | Service interface for exposing main functionality | |
| State management | Typically, holds no application-specific state | |
| Transactions | No state implies there is no need for transactions; may implement atomic and/or Reservation Pattern over an Entity service | |
| Error handling | Limited error compensation (affects SLE and SLA) | |
| Security | Application-level | |
| Management/Governance | Centralized or per application | |
| How built | In-house/Purchased/Leased | |
| Process Services | Main purpose | Implement a business process by orchestrating other services |
| Interface | Service interface targeted at human or machine consumer-facing applications | |
| State management | Manages process state | |
| Transactions | No support for atomic transactions; may use atomic transactions with the services it uses; may implement a Reservation Pattern | |
| Error handling | Implemented as part of the business logic | |
| Security | User | |
| Management/Governance | Per application or (more likely) centralized | |
| How built | In-house |
Vertical Approach
Use the vertical approach in addition to the horizontal approach where business-specific semantics apply, typically for application services.
Benefits of Vertical classification
- Creates a richer, semantic and hierarchical understanding of the services available, specifically in terms of their relationship to the business.
- Improves the ability of business-focused users to find and understand services.
- Establishes a common language that makes the technical and business problem domains more understandable.
- Promotes interoperability.
- Helps analysts think in terms of services when capturing business requirements.
- Promotes enterprise-wide understanding of the business' functional architecture.
- Shows progression (or lack of progression) of service catalog population, helping organizations plan and prioritize service creation.
- Assists in understanding when a service is overstepping its bounds.
- Simplifies identification and management of service ownership.
Creating a Vertical Taxonomy via Top-Down Analysis
Vertical taxonomy development requires comprehensive business analysis to form a model of the functional domain model and business processes that constitute the enterprise. In a rushed development practice, this activity may not seem relevant to business stakeholders. In such a case, an incremental approach may be used to create vertical service categories. Vertical industry models, such as those developed by the Open Travel Alliance, can help accelerate this process.
Use the following steps to create a vertical taxonomy:
- Identify the key business processes of an organization using enterprise business models.
- Analyze these processes and divide them into intra-organizational vs. inter-organizational processes.
- Further divide each category from the above group into following groups:
- Core – processes that are directly related to the objectives of the company.
- Support – processes that are indirectly related to the objectives of the company, and which support the core processes.
- Core – processes that are directly related to the objectives of the company.
Note: It is also possible to use a well defined industry specification such as ETOM for defining the vertical taxonomy for all major and minor business domains. In such cases, it is required to perform a gap analysis between current business model and the recommendation from the industry specification.
Assigning Business Services in a Vertical Taxonomy
Business analysis involves connecting business actions and events from core and sub-business processes so that each business use case can be implemented as a business service. As each service is identified, assign its location in the taxonomy to the core or sub-business process to which the beginning action or event belongs.
Relationship of Horizontal and Vertical Taxonomy
Each node inside a business service representation (such as a workflow) can be used to build the relationship between the vertical and horizontal service taxonomies. The vertical taxonomy will be used while decomposing the service into nodes. For each node, however, the horizontal taxonomy will be used to locate and assign the individual service to be executed by the node to fulfill the business action or event.
Service Taxonomy-Based Naming
Services can be named based on the service taxonomy, the service name should be based on two parts:
- Verb or noun from services taxonomy such as
- Communication (Verb)
- Utility (Verb)
- Entity (Noun)
- Activity (task/function (Verb-Noun – do something)
- Capability (task/function (Verb-Noun – do some things)
- Process (group of capabilities and/or tasks that orchestrate together – Verb-Noun)
- Communication (Verb)
- Service context scope, which can be negative or positive.
The following sections describe the specifics for the Infrastructure and Application service categories.
Infrastructure Service Naming
Utility and communication services are wide in scope and are usually cross cutting functions applied across the applications. Examples of well known utility services are event logging, exception handling and notification. These reusable services need to be named taking into consideration:
- Specific processing context
- The need to be agnostic in terms of any particular solution environment
For example, a utility service might be named Notify because it can be used to notify of a number of things such as a celebration, an error or an event. Since the service can be used in multiple contexts, a context specific part does not need to be added to the service name.
Application Service Naming
An entity-centric context is established in a business context that represents a specific business entity, such as an invoice or a purchase order. The naming of an entity-centric service should be predetermined by the entity name (a noun). For example, a service may simply be named Invoice or Customer.
For an activity, capability or process service, use a combination of verb and noun in the service name. For example, a task-centric atomic service may be called "GetProfile" or "ProfileRetrieval". A task-centric composite service that uses services such as GetProfile may be called "HandleOrder". An even higher level process-centric service that uses the HandleOrder service may be called "ProcessOrder".
Service Operation Naming
To eliminate naming redundancy operations inside a service should be named based on the service context. Because a good service name will already establish a meaning and context, operation names should be streamlined to avoid the use of redundant wording.
For example, an operation that retrieves invoice history data for a service named Invoice does not need to be labeled "GetInvoiceHistory" because the invoice context is already established by the service name; GetHistory is sufficient.
Conclusion: An Agile approach to define service taxonomy in common sense language promote the SOA adoption across the enterprise irrespective of the maturity level of different business and technical organizations.
No comments:
Post a Comment