Service Oriented Architecture with O.K.I. Tom Coppeto (tom@mit.edu) OnTapSolutions Stuart Sim Sun Microsystems 5 December 2005

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

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

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

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

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

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

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

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

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

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

Software Design (3) (adapters) Application Service Implementation

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

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

Degrees of Interoperability Interface Types Logic

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

Planetary Alignment Server Application API

Planetary Alignment (2) Server OSID API Application

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

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

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

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 www.okiproject.org