by Prasad Jayakumar, Technology Lead at Enterprise Solutions, Infosys Technologies Ltd SERVICE TECHNOLOGY MAGAZINE Issue L May 2011 Introduction There is nothing either good or bad, but thinking makes it so - William Shakespeare World-renowned SOA expert Thomas Erl had stated the following on Service Reusability, A service capability can be reused in two different ways. It can be repeatedly invoked by the same service consumer program automating the same business task or it can be invoked by different service consumers automating different business tasks. Based on this thought, services are generally classified into Shared Services and Internal Services. 1. Shared Services (Multiple-Purpose Programs) are true enterprise resources with agnostic functional contexts. They cater to larger groups of service consumers. An example is services which are defined at Enterprise level or Inter-portfolio level. 2. Internal Services (Single-Purpose Programs) have specific functional context. They serve with limited scope to a known service consumer. An example is services that are limited to Intra-application or Interapplications within a portfolio. SOA governance board should identify the category to which a service or service candidate belongs. There are many instances where a service candidate is identified by a business unit for a specific requirement. This service is termed as an internal service, but the scope could be broader. Once a service is properly tagged, the governance board should evaluate shared services as well as internal services. If the board doesn t do so, the pitfall of the existing service will not be known until a problem occurs. This then leads to a delay while they amend the existing service (non-backward compatible changes) or totally create a new service altogether. Both of these results completely defeat the purpose of the SOA service. An SOA governance board has to create a set of rules (Smart Assist) to evaluate a service. I have created a Smart Assist model to evaluate a service based on SOA Principles of Service and SOA Patterns by Thomas Erl. The yes/no responses to these rules will be translated to a percentage that will be compared against the 8 Principles of Service. This approach will help an SOA governance board to quantify the deviation a service makes from the defined standard of the enterprise. It allows everyone to know where a service stands and what needs to be improved. However, please note that the accuracy of the content and evaluation mechanism used in the Smart Assist approach is subjective. One can analyze and draft such guidelines and evaluation mechanism in order to better suit the enterprise and SOA project Copyright Arcitura Education Inc. 1 www.servicetechmag.com
Figure 1 Please note that the above graph is just indicative Standardized Service Contract # Guidelines Rationale Phase Importance 1 Service contracts are standardized through naming conventions and application of design standards Service contracts may express similar capabilities in different ways, leading to inconsistency and risking misinterpretation Is a service contract (comprised of technical interface details and one or more service description documents) provided with the service? Is the Contract First approach or refractor as per Meet-in-the-Middle approach applied towards creation of the service contract? Copyright Arcitura Education Inc. 2 www.servicetechmag.com
(Compatible Change) Is a service contract extensible by design so that some changes are backwards compatible, thereby avoiding negative consumer impacts? (Canonical Expression) Are naming conventions applied to the service contract as part of a formal analysis and design processes? Are policy assertions expressed in a standardized structural manner so as to be consistent? (Canonical Schema) Service uses standardized data models within an inventory boundary for common information sets. Are policy assertions expressed in a standardized structural manner so as to be consistent? 2 (Canonical Schema) Service uses standardized data models within an inventory boundary for common information sets. Services with disparate models for similar data impose transformation requirements that increase development effort, design complexity, and runtime performance overhead Yes/No Smart Assist Query Comments (if any) Is a service inventory defined at an enterprise level and/or a meaningful segment of an enterprise level? Are business subject matter experts (SME) involved in creating the data models? Copyright Arcitura Education Inc. 3 www.servicetechmag.com
(Entity Data Abstraction) Are Entity-centric schemas defined and standardized separately in support of service layers? 3 (Canonical Versioning) Service contract versioning rules and the expression of version information are standardized within a service inventory boundary. Service contracts within the same service inventory that are versioned differently will cause numerous interoperability and governance problems Medium Are service versioning rules defined within a service inventory boundary? i.e., a) When should a major or minor release happen? b) What should the version numbering scheme be? 4 (Schema Centralization) Select schemas that exist as physically separate parts of the service contract and are shared across multiple contracts. Different service contracts often need to express capabilities that process similar business documents or data sets, resulting in redundant schema content that is difficult to govern Medium (Version Identification) Are version numbers incorporated into namespace values (or other means) and as annotations in the service contract? (Termination Notification) A service contract extended with ignorable policy assertions or supplemented with humanreadable annotations when a service or a service contract version is scheduled for retirement? Copyright Arcitura Education Inc. 4 www.servicetechmag.com
Is the process defined for governance of shared schemas as multiple services form dependencies on the same schema definitions? 5 Policy Centralization: Global or domain-specific policies can be isolated and applied to multiple services. Policies that apply to multiple services can introduce redundancy and inconsistency within service logic and contracts. Low (Policy Enforcement) Is inventory architecture equipped with policy processing and enforcement features? Are policy definition documents modularized allowing for the creation of a base policy definition containing broad, generalized assertions and creating a specialized one separately on need basis? (Canonical Policy Vocabulary*) Are the vocabularies used by service contract policy assertions standardized across all services within an inventory boundary? Copyright Arcitura Education Inc. 5 www.servicetechmag.com
Service Reusability # Guidelines Rationale Phase Importance 1 Service is defined by an agnostic functional context. Logic encapsulated by the service is associated with a context that is sufficiently agnostic to any one usage scenario so as to be considered reusable Agnostic Context) Is the service logic that is not specific to one purpose isolated into separate services with distinct agnostic contexts? (Agnostic Capabilities) Is agnostic service logic partitioned into a set of well-defined capabilities that address common concerns not specific to any one problem? Are business subject matter experts (SME) involved in creating the data models? 2 (Service Normalization) The service inventory needs to be designed with an emphasis on service boundary alignment. When delivering services as part of a service inventory, there is a constant risk that services will be created with overlapping functional boundaries, making it difficult to enable wide-spread reuse. Is service inventory defined at an enterprise level and/or at meaningful segment of an enterprise level? Copyright Arcitura Education Inc. 6 www.servicetechmag.com
(Service Layers) Is inventory structured into two or more logical service layers, each of which is responsible for abstracting logic based on a common functional type? (Service Inventory Blueprints) Is a conceptual blueprint (based on common business and data models) of all the planned services established for a given inventory? Did the service candidate emerge out of service inventory blueprint or at the least could it be mapped to one of the service layer? 3 (Logic Centralization) Access to reusable functionality is limited to official agnostic services. To avoid redundant functionality being delivered in other services, resulting in problems associated with inventory denormalization and service ownership and governance Are agnostic services usage enforced via enterprise design standards? For example, if a new capability is needed which clearly falls within the boundary of an existing service, the corresponding functionality needs to be added to that service instead of creating a new service. (Contract Denormalization) Do service contracts include a measured extent of denormalization, allowing multiple capabilities to redundantly express core functions in different ways for different types of consumer programs? Copyright Arcitura Education Inc. 7 www.servicetechmag.com
4 Services are designed to facilitate concurrent access by multiple consumer programs Once a service inventory is relatively mature, reusable services will find themselves in an increasingly large number of compositions Medium Is a scalable runtime hosting environment capable of highto-extreme concurrent service usage available? Is service designed to facilitate simultaneous access by multiple consumer programs? 5 (Rules Centralization) The storage and management of business rules are positioned within a dedicated architectural extension from where they can be centrally accessed and maintained. The same business rules may apply across different business services, leading to redundancy and governance challenges Low Are business rules separated from core service logic and centrally located? Is the business rules management system or engine employed? Are business rules accessed via system agents or a dedicated service? Copyright Arcitura Education Inc. 8 www.servicetechmag.com
Service Autonomy # Guidelines Rationale Phase Importance 1 Services are deployed in an environment over which they exercise a great deal (and preferably an exclusive level) of control Gives the freedom and control to make its own decisions without the need for external approval or involvement. The more independent a system is from unpredictable outside influences, the more reliable it will be Runtime / Implementation Is the service hosted in a middleware product(s) or at least on an application server specifically dedicated for services? Is a distributable deployment environment available, so as to allow the service to be moved, isolated, or composed as required? 2 Service instances are hosted by an environment that accommodates high concurrency for scalability purposes. To guarantee acceptable runtime execution performance and to ensure a greater level of behavioral predictability Runtime / Implementation Is scalable runtime hosting environment capable of highto-extreme concurrent service usage available? 3 (-time Autonomy) Control over how a service is designed and developed The greater the amount of design-time autonomy, the greater the amount of attainable runtime autonomy Medium Copyright Arcitura Education Inc. 9 www.servicetechmag.com
Are underlying services components dedicated to the service and can be isolated? Are physical data models (database artifacts) dedicated to the service? Does the service encapsulate legacy logic? Service Statelessness # Guidelines Rationale Phase Importance 1 State management delegation and deferral extensions to be designed into the component logic Helps maximize scalability Is shared architectural extension designed/ available for reliable and flexible state deferral? (State Repository) Is state data temporarily written to and then later retrieved from a dedicated state repository? 2 (Services have no shared state with other services through common data is stored (separation of the data stores is conceptual). To support the design of agnostic service logic and improve the potential for service reuse. Is the service designed to not retain state information for any specific parent business process? Is the service contract less constrained so as to allow for the receipt and transmission of a wider range of state data (if any) at runtime? Copyright Arcitura Education Inc. 10 www.servicetechmag.com
Service Discoverability # Guidelines Rationale Phase Importance 1 State management delegation and deferral extensions to be designed into the component logic Helps maximize scalability Has functional meta information been expressed as part of the service contract for discoverability purposes? Has the quality of service meta information been clearly expressed as part of the service contract or a formal SLA? Have business subject matter experts contributed to the definition of business centric discoverability meta information? Has all discoverability meta documentation been subjected to standards and conventions to ensure consistency? 2 Service contracts should be enriched further with additional metadata information to describe the purpose and capabilities in human readable format To enable a wide range of project team members to effectively carry out the discovery process and not to limit it to those with technical expertise. And for a service consumer to make an informed decision. Has functional meta information been documented in plain English? Has quality of service information been documented in nontechnical English? Copyright Arcitura Education Inc. 11 www.servicetechmag.com
Have business subject matter experts contributed to the definition of business centric discoverability meta information? 3 Service profile document or service record is made available in Service Repository/Registry. To facilitate central discovery mechanism Medium Are Service Registry/Repository available at enterprise level and/ or at meaningful segment of an enterprise level? Has a service profile document or the corresponding service registry record been created? Does the service profile/registry record contain all relevant functional meta information? Does the service profile/registry record contain all relevant quality of service meta information? Service Loose Coupling # Guidelines Rationale Phase Importance 1 (Logic-to-Contract Coupling) Approach building a service by designing its physical contract prior to its underlying solution logic. Maximizes the freedom with which the service can be evolved over time Has functional meta information been expressed as part of the service contract for discoverability purposes? Copyright Arcitura Education Inc. 12 www.servicetechmag.com
Is the "Contract First" approach or refractor as per "Meet-in-the- Middle" approach applied for creation of the service contract? Is the "Contract First" approach or refractor as per "Meet-in-the- Middle" approach applied for creation of the service contract? Is the usage of physical data model details into the service contract avoided? i.e. Placing auto-generated schema from database tables, views or similar objects into service contract Is a canonical data model that is independent from the type systems (used in the called applications) part of the service contract? 2 (Consumer-to-Contract Coupling) Service contract is accessed as the sole or primary endpoint into service logic and resources To achieve the greatest amount of independence between the consumer and the service. Gives Service owner the ability to swap service implementation technologies without affecting the service's existing consumer base Is a service contract decoupled from proprietary technology and use XML and Web services standards? (Contract Centralization) Is access to service logic limited to the service contract, forcing consumers to avoid implementation coupling? Copyright Arcitura Education Inc. 13 www.servicetechmag.com
Service Abstraction # Guidelines Rationale Phase Importance 1 Services consistently abstract specific information about technology and logic away from the outside world (the world outside of the service boundary). This gives the service owners the maximum amount of freedom in evolving the service over time Has functional meta information been expressed as part of the service contract for discoverability purposes? Is technology information such as programming language, system resources used by the service hidden? Are low-level design details such as algorithms, exception handling and logging routines and other logic associated with the service protected by access control measures? Is source code of the service protected by access control measures? Have efforts been made to moderate usage of policy assertions so as to not reveal too many details about service's underlying logic, behavior and preferences? 2 Service contracts are carefully designed to express just the right amount of functionality and select quality of service (QoS) details To prevent unnecessary access to additional service details Has a formal audit undergone on a service contract to trim unnecessary metadata and constraints? Copyright Arcitura Education Inc. 14 www.servicetechmag.com
Has a formal audit undergone on a service contract to trim unnecessary metadata and constraints? For all of the meta information the service capability abstracts, does it provide a clear expression of important quality of service characteristics? Is quality of service characteristics documented and maintained as part of SLAs (and access control measures taken as required)? Conclusion The guidelines for Service Composability are described in detail for a similar pattern in the book SOA Principles of Service book by Thomas Erl. Please refer the book for more information. Note that shared service evaluation effort is not about finding the absolute truth; it is about measuring and publishing the relative truth. It is to help understand the efficiency of your service, so that no problematic surprises would arise. The success of your SOA system should not be determined by luck. About the Author: Prasad Jayakumar Prasad Jayakumar is a Technology Lead at Enterprise Solutions, Infosys Technologies Ltd. He provides solutions and services to global companies based on Oracle SOA 10g/11g and Oracle AIA. Prasad specializes in BPEL, ESB/Mediator, B2B and Oracle Service Bus. Having achieved a Master s Degree in Computer Applications, he has over 8 years of experience in software development and is a Oracle 9i Certified Professional. Read Prasad s blogs about SOA at: www.infosysblogs.com, or reach out to him at: prasad_jayakumar@infosys.com www.servicetechmag.com/contributors/prasadjayakumar Copyright Arcitura Education Inc. 15 www.servicetechmag.com