building reusable services
out of 17
Post on 01-Nov-2014
Embed Size (px)
DESCRIPTIONIntroduction 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:// softwarereuse.wordpress.com /
- 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.
- 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.
- 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
- 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 >