Track Service Reuse Metrics

December 24, 2011

Service driven systematic reuse takes conscious design decisions, governance, and disciplined execution – project after project. In order to sustain long running efforts such as service orientation, it is critical to track, report, and get buy-in from senior management in the organization. So what metrics are useful? Here are a few:

  • Total number of service operations reused in a time period
  • Total effort saved due to systematic reuse in a time period
  • Number of new service consumers in a time period
  • Number of new consumer integrations in a time period (this includes integrations from both new and existing consumer
  • Service integrations across transports/interface points (for instance, the service operation could be accessed SOAP over HTTP, or as SOAP over JMS, or REST, etc.)

What metrics do your teams track?

Rationale for Compensating Service Transactions

March 5, 2011

Compensating Service Transaction pattern helps consistently handle composition runtime exceptions while eliminating the need for locking resources.

Service compositions could generate various runtime exceptions as part of fulfilling service functionality. For example, imagine a service composition that invokes a decision service to validate request data, proceeds to update a customer entity via an entity service, and then sends a message on a queue for an external process to consume. Consider the three steps as part of a single unit of work – a service transaction that execute in sequence.

If runtime exceptions associated with the composition are unhandled there is an increased likelihood of compromising data and business integrity. Similarly, if all the steps are executed as an atomic transaction each service invocation will tie up backend resources (e.g. using various kinds of locks) hurting performance and scalability.

The compensating service transaction pattern introduces additional compensation steps in order to handle runtime exceptions without locking system resources. These additional steps can be included as part of the composition logic or made available as separate undo service capabilities. Continuing the earlier example, a call to undo the customer update (essentially resetting the data back to the earlier state) can be made to place the underlying data in a valid state.

The Compensating Service Transaction pattern provides several benefits:

  • Eliminates the need for executing distributed service invocations within a transactional context.
  • Provides a mechanism for services/resources that don’t support atomic transactions to participate in service compositions.
  • Reduces load on underlying systems and databases by only invoking compensation routines when failure occurs. Instead of locking resources in case failures happen, the idea is to handle runtime exceptions when they actually occur.
  • Allows reuse of compensation steps across service compositions. E.g. two business services that update a data entity can reuse the undo Update capability.

Compensating transactions tend to be more open-ended when compared to atomic transactions and their actual effectiveness varies. The extent to which the service composition can apply this pattern is directly dependent on the undo capabilities provided by various service capabilities being invoked. Consequently, this pattern cannot be leveraged if compensating transactions don’t exist. Likewise, it is necessary to ensure that the compensating steps themselves execute successfully. Error alerts/notifications may need to be sent in case compensations fail and manual interventions are needed.

Strategies for Varying Service Behavior

October 2, 2010

Services are meant to be building blocks for business processes and could provide functionality that is potentially relevant to multiple applications. In order to fully realize these benefits, it is critical that variations in service behavior are supported.

What are some of the aspects that vary in a service capability? From a functional perspective, a service could support different behavior depending on the characteristics of the invoking client, the nature of data that is worked on, or both. Additionally, a service capability could also provide optional filters and preferences that allow for varying behavior (e.g. a service could break down data into multiple chunks, and returning only those that the client is interested in). Understand your domain to identify service capabilities that could support client preferences.

From a non-functional perspective, response time, number of concurrent requests, volume of requests within a time window, and total number of requests across clients etc. are aspects that could be managed. In addition to response time, data format (supporting plain text, JSON, in addition to XML) could be varied as well to ease integration.

How Service Orientation Principles Guide Reuse

November 6, 2009

In an earlier post, I elaborated on agile principles that facilitate reuse. As a follow up, I want to emphasize how principles of service orientation do the same from a complimentary perspective.

Principle How is this supported? Why is this supported?
Loose Coupling Service logic is built independent of specific product, technology, channel, and transport. Legacy services are wrapped to avoid direct coupling between providers and consumers. Both techniques are performed iteratively using refactoring. Decouple horizontal concerns such as logging, error handling, metrics, security from core logic. Lower the coupling, higher the opportunity for service reuse. Promotes agility by making less assumptions about upstream and downstream dependencies. Gives flexibility to service provider for performing continuous refactorings. Reuse horizontal capabilities for non-service components in the codebase.
Abstraction Code reviews and refactoring used to simplify and consolidate service contracts that aren’t well abstracted. Applies to both legacy and new services in the domain inventory. Abstract common service needs using multiple iterations and user stories. Abstraction clarifies domain intent and reduces needless coupling between providers and consumers. It eliminates point to point coupling between legacy services and consumers facilitating graceful migration.
Composability Refactor both new code and legacy modules within iterations. Identify opportunities for compositions when brainstorming implementation options for user stories. Use design patterns such as template method to design orchestrations. Composability is key for high levels of service reuse for implementing task services.
Standardized contract Code and design reviews will be used to ensure reuse of data types, error codes, schema definitions, and that the contracts don’t expose implementation/technology specific details. If contract changes late in an iteration, add needed refactorings to iteration backlog and fix in a future iteration. A service is not “done,done” unless the contract is reviewed. Helps align contracts with logical data models for enterprise data entities. Delivers consistent behavior when a service is reused across physical transports. Helps create loose coupling among legacy interfaces and consumers.
Autonomy By decoupling legacy modules from being tightly bound increasing autonomy. Host services in a standard runtime environment. Autonomous services are easier to reuse both as standalone entities as well as in service compositions.
Statelessness Reuse strategy used to identify stateless services. Code reviews will identify and remove state that inhibits reuse. Stateless services offer higher degree of reuse and are simpler to scale to accommodate increased traffic.
Reusability Building reusable services that can be mapped to user stories. Using legacy services to implement user stories and code reviews to remove duplication across the service inventory. Iteration planning allocates time for wrapping legacy services, unit testing, and working on refactoring backlog. Release planning is performed to ensure services are built within the context of an overall reuse strategy and a real consumer. Use product line techniques such as to allow service variations to accommodate varying consumer functional and quality of service characteristics. Minimize service development without a real consumer. Facilitates iterative and incremental manner for building reusable services. As user stories become better understood and code reviews have been done future iterations are continuously used to refactor the service.

Do these resonate with how you approach SOA and service orientation while building reusable service capabilities?

Like this post? Subscribe to RSS feed or get blog updates via email.

tweet this add to post to facebook

Software Reuse Quick Tip #19

October 12, 2009

Tip #19 – Design loosely Coupled Service Contracts

Loosely coupled service capabilities help achieve agility in business processes and technology solutions. Why? Because, they make fewer assumptions about the implementation technologies and consumption characteristics.  Designing contracts or interfaces is a critical activity when building service capabilities. The interface needs to avoid specifying technology specific, implementation environment specific constructs. This includes operation system variables, vendor-specific variables, database layout/structure etc. The idea is to not tie yourself too closely with a particular implementation. Ask yourself – what is the impact to the service capability if the underlying database is moved to a different vendor? what if we skip the database completely and load data from a file cache? You shouldn’t have to move mountains to accommodate such changes if the interface is not tied to a single implementation. This concept must sound familiar 🙂 Indeed it is the same idea that has been espoused with object oriented design. Separate interface from implementation. A service capability may utilize a legacy provider, packaged application, an externally hosted solution (a cloud maybe). It is essential that the service capability is carefully designed when integrating with these dependencies. If there are attributes internal to a legacy system ensure that they are not specified on the service contract.

Like this post? Subscribe to RSS feed or get blog updates via email.

tweet this add to post to facebook

Service Documentation Template

October 9, 2009

Here is a template for documenting services and service capabilities as part of building up a service/domain inventory (it is available from the resources page also). This was inspired by the items from the book Principles of Service Design. I modified this slightly to include a few additional fields. Feel free to modify this template to suit your needs.

A collection of these documents can be managed via a Wiki or document management system as a starting point. As your SOA efforts mature you would want to consider replacing much of the technical details here with a governance tool. These tools can synch up schema, WSDL changes, WS-Policy specifications etc and have the ability to generate service dashboards and documentation. You might most likely still need a document to capture policies specific to your organization or SLA characteristics not captured via governance tools etc.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to Digg it : post to facebook: Stumble It! : :

%d bloggers like this: