1. Service Oriented Architecture with O.K.I.
Tom Coppeto
OnTapSolutions
Stuart Sim
Sun Microsystems
5 December 2005

2. Service Oriented Architectures
An architecture is a framework that defines an organization of system components
SOA is an architecture organizing systems around services
Each service is defined using a service interface
Service implementation hidden from the interface consumer

3. It’s About Integration
Making applications work with IT infrastructures
Making system components work with each other
The interfaces define the integration points among disparate services, not the technologies or other service implementation details

4. It’s About Software Some SOAs place the interface boundary on the wire
We believe the interface boundary is better placed in the software
consumer
consumer
provider
provider

5. O.K.I. Open Service Interface Definitions (OSIDs)
O.K.I. is an SOA built on service definitions
OSIDs define software interfaces
The interface is a contract between a service consumer and a service provider
OSIDs do not specify how a service works
Different providers of the same OSID may do entirely different things

6. OSID Specifications www.okiproject.org Id Agent Authentication
Authorization
Grading
Logging
Filing
Repository
Scheduling
Assessment
Course Management
User Messaging
Workflow

7. OSID Providers
O.K.I. does not specify what a provider implementation can do other than to implement the interface
An Authorization provider that makes use of LDAP should work just as well as an Authorization provider that simply said yes
One may be a bit more useful than the other, however
Sometimes it’s useful to have a provider do nothing

8. Old School Programming
Core application
Data to be parsed
read response
Log
config
status
command
Send command
status
Authentication credential
APIs
Authentication configuration
Authentication credential
Connection handle
Server identity
Send
credential
Get auth
credential
Make server
connection

9. Interface Programming
Core
application
log
Service
Interface
Service
log
Service
Implementation
authN

10. Software Design (the way not to look at OSIDs) Repository Application
AUTH
LOGGING
REPOSITORY

11. Software Design (2) (better) Repository Application Repository
Authentication
Agent
LOGGING
Logging

12. Software Design (3) (adapters) Application Service Implementation

13. Software Design (4) Client/server systems begin with standalone impls
Application
IMPL
Client
Server
IMPL
IMPL

14. What an Implementation Looks Like
APPLICATION
INTERFACE
INTERFACE
CONTRACT
CONFIGURATION
PROPERTIES
TRANSACTION
MANAGEMENT
UTILITIES
CLIENT
PROTOCOLS
WIRE PROTOCOLS
REMOTE SERVER
OTHER
IMPLEMENTATIONS

15. Degrees of Interoperability
Interface
Types
Logic

16. Interfaces & Protocols
Developers use code
Protocol APIs tend to be fragile, and they get everywhere
Not all services involve servers
Stubbing: top down design
Unit testing
Effective project management
Adapters
Protocols are ever-changing implementation “details”
Interfaces change as well, but slower and version skew is much easier to cover with an adapter
An OSID impl can built by a third party to cover an existing service without the cooperation of the service provider

17. Planetary Alignment
Server
Application
API

18. Planetary Alignment (2)
Server
OSID
API
Application

19. Pound Wise, Penny Foolish
As software engineers, we get too caught up in reusing small amounts of code
Instead of worrying about reusing a particular java class, we should worry about not replicating entire services

20. Architectural Case Study
Atheltics
Alumni
SloanSpace
Atheltics
Alumni
Sloan
Student Services
Libraries
SIS
Data
Warehouse
DSpace
Project Athena
IST
Parking
Moira
Techtime
Parking

21. Resulting System Architecture
Moira
SIS
Alumni
Athletics
Agent
Group
Authentication
Authorization
Messaging
Scheduling
Course Mgmt
Repository
SloanSpace
DSpace
Techtime
Parking

22. Taking The Red Pill
Top-down organization of processes, services and utilities
Bottom-up adoption through OSID support
Technology specifics don’t matter to application code
Consumers should not tell providers how to do their job, just that it needs to be done
Services relying on data feeds need to be refactored