Why Service Oriented Architecture is HARD

1
Why Service Oriented Architecture is HARD
Lessons Learned From the Notification Project

• June 6, 2006
• Tom Dimock

2
Agenda

• What is SOA?
• What is the Notification Project
• Why is it hard?
• A few thoughts on pluggability and service types
• What are OSIDs, 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

10
So Why is it Hard?

• The technology isnt that hard, its the
  interface design thats 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 wont 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
• Lets get Cornell involved!

21
Questions