190 likes | 278 Views
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
E N D
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 • not a discussion of SOA standards: web service’s or ESB or workflow/BPEL
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
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
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
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
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
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
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
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
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
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
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
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
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
Questions & Comments • Your experiences with SOA designs and implementations • Other useful patterns