html5-img
1 / 19

Why do I care about SOA?

Why do I care about SOA?. Perspective from a service provider Keith Ball. What is this Session?. What it is Practical uses of architecture for a medium-sized service provider Solution patterns leveraging SOA What it isn’t not selling products or services

kamana
Download Presentation

Why do I care about SOA?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Why do I care about SOA? Perspective from a service provider Keith Ball

  2. What is this Session? • What it is • Practical uses of architecture for a medium-sized service provider • Solution patterns leveraging SOA • What it isn’t • not selling products or services • not a discussion of SOA standards: web service’s or ESB or workflow/BPEL

  3. Background • many years architecture experience at software companies and service providers • Currently, architect for media operations business • medium scale business with large scale infrastructure • build out service infrastructure to support operations • sell infrastructure as part of solutions and services business – customer is operator

  4. Service Infrastructure • Developing scale through automation • Building out service infrastructure – the service platform. • Service platform has lots of moving parts • Can’t build everything, don’t want to – buy wherever can, build where must • Build for core added value: significant IP, barrier to competition, or core competency • system of systems: service platform is composite by nature • Each application does useful set of work for a focused set of business functions

  5. SOA Fits With Service Provider • A service infrastructure is composed of lots of moving parts. • How to connect them together to make a single functional platform? • standards focus appears to be on B2B • Interesting, but not driving current value • SOA’s service provider value: • Internal services and connecting internal systems • Expectation to leverage services for integration with customer infrastructure

  6. How SOA Fits • For service infrastructure – the principles of design & technology that forms the glue • functional separation – create a component that provides reusable functionality • loosely coupled systems cooperating to provide broader function • integration focused – system of systems • cross-cutting concerns implemented outside components, in glue

  7. Applicable SOA Solution Patterns • adopting commercial-off-the-shelf (COTS) enterprise applications • cross functional workflow automation • leverage value in existing systems • large grain component application architecture with orchestration • Haven’t built out any external service-based integration points • Some portals, but not with SOA

  8. COTS Enterprise Applications • Key Issue • How to put info in and take info out • COTS: buy APIs vs. use direct Data • leverage to make services • Business logic vs. internal data model • Build service interfaces • generate events to create, delete, modify of core entities • query for data – get canonical form, • receive events to create, delete, modify core entities

  9. Cross-functional Workflow Automation • Each application in service • Focused on small set of the total service’s business functions • Function-specific workflow with own UI • Own data and business logic • Service requires some cross-functional workflow • Need to move data between function-specific apps. • a composite cross-functional workflow specific UI. • Building a system of systems • For each application expose services (similar to COTS) • generate events with data • perform specific function • query for data • receive update events for internal data • Process manager to control via metadata workflow definitions • how to connect to apps • when to do so • operations to perform

  10. Large-Grain Components • divide application into major components • Each is a complete service function • Reusable as service function for other applications • Leverage existing applications as services – don’t recreate functionality • divide functionality along • scale points • variation of implementation • Each is a small application on its own and has • well defined set of one or more interfaces • likely no UI, except for configuration or monitoring • Two major glue styles • event oriented service interfaces – ala message passing • request/reply service interfaces – ala client/server • Some combination • No shared data between components, keep loosely coupled • Provide application UI as one or more separate components

  11. Orchestrate w/ Process Manager • Could put orchestration, workflow control in UI part of application • Better: add-in process manager in glue that is metadata driven • SOA technology providers have process managers as part of solution

  12. What Else Potentially in Glue • Management Console • Management service interfaces in components • Composite-style management console for all components • SOA products often support centralized management console • Cross-cutting concerns • Careful: keep it small, simple, test out ideas before dive-in • What is best for your environment? • Remove cross-cutting concerns from each component • Implement in glue layer – ala AOP • Easy example is authentication and authorization • SOA products built-in some cross-cutting concerns support

  13. Some Issues • Development and operations culture: people must think about how to build and manage applications in a different way. • Always need to build service interfaces, even if don’t use immediately for application construction • Break big apps into multiple components that do not share database – this is always point of disagreement. • Classic EAI issue: Canonical vs. internal data • Medium size business can’t afford to buy expensive 3rd party components and then spend even more to customize. • Configuration complexity, difficult for operations team to handle deployment

  14. UML & Books • Enterprise Architect v6.1, Sparx Systems • Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions by Gregor Hohpe & Bobby Woolf • Provides useful language for part of SOA • Enterprise Service Bus by David A. Chappell • Sonic guy, but book isn’t sell • good intro to ESB

  15. Summary • Medium-sized service provider able to apply SOA to service infrastructure successfully • Start small, don’t be overly ambitious • Look to apply patterns in most straight-forward cases • Work the cultural issues

  16. Questions & Comments • Your experiences with SOA designs and implementations • Other useful patterns

More Related