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

id COT Enterprise App

COTS App

API

SQLClient

Services

Access App

Query

GenerateEvents

ReceiveEvents

Extended UI

Query ReceiveEvents

GenerateEvents

COTS DatabaseSQL Server

«delegate» «delegate» «delegate»

«delegate»

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

id Cross-Functional Workflow

Support Application

API

Operation Application

GenerateEvent

ReceiveEvent

Inventory Application

GenerateEvent

ReceiveEvent

Support Services

Call API

GenerateEvent

ReceiveEvent

Process Manager

ReceiveEvent

GenerateEvent

Control

Support Application Database

Inventory Application Database

Operation Application Database

Cross Functional UI

Initiate

«delegate»

«delegate»

«delegate» «delegate»

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

id Large Grain Components

Order Processing Service

EventsManage

Order Validation Service

EventsManage

Inventory Tracking Service

Manage Requests

Order Processing Database

Process Manager

Events

Control

Order Entry UI

Requests

Initiate

Order Validation Database

Inventory Database

Management Service

Manage Monitor

Query

Management Application

Query «delegate»

«delegate»

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