Building Reusable Services for your SOA

Vijay Narayanan

Agenda

• Brief introduction to SOA

• Business Rationale for Reusable Services

• Building Reusable Services

• Recent Trends Shaping Services Strategy

About Me• Technical lead for data services and business processes

• Working in financial services for 7+ years

• Software Reuse Evangelist

• Blogger: http://softwarereuse.wordpress.com/

What is SOA?

• SOA stands for Service Oriented Architecture (Yes, yet another TLA!)• Services are software capabilities using new and legacy assets• Goals – increase business/IT alignment, reduce integration costs, increase revenue

by building new products/services• When web services are used to realize SOA they bring increased interoperability via

“open” standards such as HTTP, XML• Pursuing SOA must be a conscious decision - requires retooling, change in developer

mindset, refactoring of legacy processes, governance, operating model for internal teams to use/engage with etc.

Different

folks will give you

different

answers!

Why Pursue SOA?• Aligned to business goals – not simply a technology approach• Transparency into business processes and technology assets • Release new products and services into the marketplace• Reduce integration costs with new projects and initiatives• Based on open standards (for the most part!) and tools provided by several

technology vendors• Leverage legacy systems and their capabilities• Integration along the length and breadth of a business capability – including

partners, suppliers, and internal players.

Reuse is a key reason why enterprises

pursue SOA!

Reusable Services Generate New Revenue• Create new products and services

faster using existing services as-is or reusing them as part of orchestrations (quicker time to market)

• Charge internal and external clients either via a chargeback model or a subscription-based pricing model

• Generate growth by hosting services on behalf of other groups/teams

• Provide opportunity for cross-sell/up-sell across customer touchpoints. With reusable services, this will result in a consistent client experience

Reusable Services Help Reduce Costs

• Reduce development, maintenance, and testing costs as you integrate new applications and business processes

• Reduce cost of ownership by migrating clients off legacy platforms/processes

• Reduce number of redundant service capabilities spread across teams

• Over time, will result in architecture convergence across business processes and applications that leverage a common set of reusable services

• Migrate service capabilities to cheaper service providers and not impact every application.

Some Foundational Concepts• A service capability provides tangible value to the enterprise• Building a service inventory for a specific domain involves much

less risk compared to an enterprise wide inventory• Identify and organize service capabilities based on business domain

(continuously seek subject matter expertise!)• Don’t mix domain specific service capabilities with domain agnostic

ones i.e. they should be separate services• Plan to support multiple versions – full blown service versions or

service capabilities. Every consumer won’t use the version you want at the same time!

• Most ideas when for succeeding with reusable code applies to service capabilities as well

Building Reusable Services• Decouple channel-specific from channel-agnostic logic

• Provide standard interfaces for services

• Offer standardized publications

• Apply cross cutting concerns horizontally

• Ensure services avoid needless coupling

Decouple Channel-specific from Channel-agnostic logic

• Avoid service parameters bound to a specific transport protocol. Examples of transport specific parameters - HTTP request headers, JMS Headers

• Offer service capability across multiple transports (e.g. HTTP and JMS)

• Offer service capability across multiple message exchange patterns (E.g.: Synchronous request/reply via HTTP and JMS, Asynchronous request/reply via JMS)

• Encapsulate channel-specific business rules and behavior – Note: Different channels might need different levels of robustness/SLA!

Provide Standard Interfaces for Service Access

• “Standard” interface also referred to as Service Mediation

• Decouples service providers and service consumers

• Hook cross cutting concerns (e.g. authentication/logging)

• Wrap legacy capabilities – Translate legacy syntax and semantics– Alignment of legacy interfaces with

strategic enterprise contracts • Offer value added capabilities for

performance tuning (e.g. caching, dynamic resource allocation), service level agreement (SLA) adherence)

Offer Standardized Publications

• Avoid one-off or point to point integrations– If there is a consumer-specific message required subscribe to standard message and then transform to specific format

• Publish standard event messages from both coarse-grained and fine-grained services.

– Entity services publish creates/updates to critical data– Business Processes or task services publish milestones and business exceptions.

• Publications can be offered in conjunction with a subscription model (e.g. publish only a subset of events based on business rules or policies)

Apply Cross Cutting Concerns Horizontally• Cross cutting concerns apply to several

capabilities (e.g. authentication, encryption/decryption, logging, metrics, error handling)

• Several ways to integrate service capabilities with these

– Configuration (XML/properties files or database driven)

– Template Method Pattern (recipes to process requests with hooks to cross cutting concerns)

– Using a container with support for aspect orientation

• Decouple business logic from these horizontal functions. No different than aspect oriented programming where aspects are applied before and after method.

Ensure Services Avoid Needless Coupling• Service capabilities can easily inherit

unwanted coupling!• Avoid or at least minimize:

– Vendor specific coupling (platform specific headers/parameters/service contracts, transports)

– Legacy coupling (legacy data, semantics, error codes)

– Transport and Channel specific coupling (covered earlier)

– Consumer specific coupling (contract specific to consumer system or usage)

… a few tips for the road• Recognize that building reusable services is an

iterative process! You have to continuously align project after project…

• All this talk about service decoupling, mediation, standard publications are really about the fundamentals of good design

– Loose Coupling– Encapsulation

• Use Before Reuse– Don’t build a service capability unless there is a

consumer– Iteratively build capabilities based on business

priorities– Plan to refactor capabilities at least once before

making it ‘fit’ for reuse

Where Are Services Headed?• Cloud Computing – “rightsource” service capabilities, reduce fixed

costs, and utility-like billing/subscription

• Software As a Service (SaaS) model

• Tighter alignment with the Business Process Management (BPM) and messaging strategies

• Event Driven Architecture

• REST-based service design in addition to Web Services

• Enterprise Service Bus (ESB) deployments