1

Why Service Oriented Architecture is HARD

June 6, 2006Tom Dimock

Lessons Learned From the Notification Project

2

Agenda

• What is SOA?• What is the Notification Project• Why is it hard?• A few thoughts on pluggability and service

types• What are OSID’s, and why are they

important?

3

What is SOA?

Service Oriented Architecture expresses a perspective of software architecture that defines the use of services to support the requirements of software users. (Wikipedia)

4

No, really, what is SOA?

• A shift in focus away from “applications” towards business processes

• An architecture in which processes are constructed either in whole or in part by assembling reusable services

5

What is it not?

• SOA is not SOAP, or .net, or DCOM• SOA can be implemented with any of these

technologies, but is fundamentally technology independent

6

Managing Complexity

• Full-blown “applications” have become unmanageably complex

• Difficult to build, harder still to maintain• Can SOA help?

7

What is the Notification Project

• A common channel for notifying users• Notification of tasks assigned by workflow

systems• Spam resistance a must• Give users one “in box” which can be used by

many applications• Handle notification of other events of interest

8

Notification Project

• Consists of the Notification Client, which will be implemented as a uPortal channel

• And the Notification Server, which will manage the notifications

• Intended from the start to be an open source project

• Initial concepts and architecture contributed by Cornell

9

Notification and SOA

• Notification project is very service oriented

• Interfaces first• Use external

services wherever possible

Notification Administration

Client

Notification Administration

Service

Notification Client

Notification Service

Notification Submission

Client Notification Submission

Service Other Notification Submission Applications

Groups Service

Preferences Service

Tickler Service

E-mail

Fax Jabber

Etc.

Notification Types

Active Notifications

Expanded Notifications

Filtered Notifications

Preferences

Filters / Rules

Notification

Engine

Archived Notifications

Authorization Service

Authorization OSID

Agent OSID

Usermessaging OSID

Authentication Service

Authentication OSID

Logging Service

Logging OSID

Directory Service

Agent OSID

10

So Why is it Hard?• The technology isn’t that hard, it’s the

interface design that’s hard• Designing an interface suitable for your

current project is relatively easy• Designing an interface for a reusable service

is hard:– It must be future-proof

– It must handle differing authorizations

– It must avoid institutional specifics

11

How Do We Deal With This?

• Learn from existing examples• Involve more people - open source• Accept that you won’t get it right on the first

try– But having to upgrade a number of processes that

all do something the same way is better than if they all do it different ways

– So track usage!

12

Static Pluggability

• Frameworks such as Spring give static pluggability

• Configuration files specify the components to use and the “wiring”

• Allows decoupling of a distributed development effort

• Relies on dependency injection

13

Dynamic Pluggability

• Manager class acts as factory, returning iterator over supported instances

• Allows multiple service implementations to be active simultaneously

• Allows seamless transition to new versions of services

14

Kinds of Services

• Utility• Institutional• Application specific

15

Utility Services

• Utility services provide functionality that is application independent– Authentication– Authorization– Workflow– Notification

• Utility services should be dynamically pluggable

16

Institutional Services

• Institutional services expose data and functions to facilitate inter-application business processes– Demographic data– Account number lookup

• May be dynamically or statically pluggable• Consider stability of the service provider

17

Application Specific Services

• Services which are used only within a very specific application domain

• Are you sure?• Probably statically pluggable

18

Service Interface Standards

• Service interface standards unleash the power of dynamic pluggability

• Leverage code sharing amongst institutions• Emerging area of interest

19

OKI

• Open Knowledge Initiative– www.okiproject.org

– The Open Knowledge Initiative (O.K.I) develops and promotes specifications that describe how the components of a software environment communicate with each other and with other enterprise systems. O.K.I. specifications enable sustainable interoperability and integration by defining standards for Service Oriented Architecture (SOA).

20

OSIDs

• Open Service Interface Definitions– Technology agnostic

• Main work product of OKI• Version 2 available now, Version 3 is under

development• Great examples to learn from• Let’s get Cornell involved!

21

Questions