building reusable services

Download Building Reusable Services

Post on 01-Nov-2014




2 download

Embed Size (px)


Introduction to SOA, business rationale for service orientation, and techniques for building reusable services.


  • 1. Building Reusable Services for your SOA Vijay Narayanan
  • 2. Agenda
    • Brief introduction to SOA
    • Business Rationale for Reusable Services
    • Building Reusable Services
    • Recent Trends Shaping Services Strategy
  • 3. About Me
    • Technical lead for data services and business processes
    • Working in financial services for 7+ years
    • Software Reuse Evangelist
    • Blogger: http:// /
  • 4. 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!
  • 5. 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!
  • 6. 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
  • 7. 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.
  • 8. 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!)
    • Dont 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 wont use the version you want at the same time!
    • Most ideas when for succeeding with reusable code applies to service capabilities as well
  • 9. 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
  • 10. 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!
  • 11. 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)
  • 12. 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)
  • 13. 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.
  • 14. 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)
  • 15. 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
      • Dont 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
  • 16. 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


View more >