open knowledge initiative scott thorne ([email protected]) jeff kahn ([email protected])

Open Knowledge Initiative

Scott Thorne ([email protected])

Jeff Kahn ([email protected])

Topics

Architectural Overview Assumptions Goals Design Benefits

Applying O.K.I.™

Assumptions

Things Change New Services & Functions Method of Accessing Services More Central Software Services

Authorization, Calendaring, etc.

Evolving Systems Definition

More Assumptions

All Enterprises won’t have the same Technologies

All Enterprise Systems won’t use the same Technology

The need for sharing will grow Differing “connectedness” Not Web only

Goals

Better Integration Allow data to be exchanged Allow software to be integrated

Predictable Evolution Allow for changing functionality Minimize the negative impacts

Expanding Market Possibilities

Possible Integration Goals

Allow enterprise systems to exchange & synchronize information

Allow different organizations to exchange & synchronize information

Allow systems to use enterprise services Allow for modular software which plugs

into a known framework Single system responsible for information

Data and Functional Specification

Data standards serve two goals Data exchange inter/intra enterprise

Both Data & Function needed for all Goals Data duplication and propagation

data specifications can’t address all issues Both Needed for Interoperability

And more!

Systems Exchanging Data

System A System B

1 2

Systems Integrated Functionally

System A System B

2

OSIDs

Definitions

ExampleOSID

OSIDs

Definitions Implementations

Service

OSID

Implementation

Infrastructure

public class Factory implements org.okip.service.APIName.api.Factory { private static final blah blah bhal

private static final yada yada yada } …

Example

Service-Based Architecture

public class Factory implements org.okip.service.Example.api.Factory { private static final blah blah bhal

private static final yada yada yada } …

ExampleOSID

…org.okip.service.shared.api.Thing things = myFactory.getSomething();

if (null != thingss) { for (int i = 0; things.length != i; i++) { out.println(things[i]); System.err.println(types[i]); } } …

Application

Implementation

Infrastructure

Service

The OSID Approach

OSID are Interfaces only, not Implementations

Code Reuse Could Achieve Real-time Integration Clean Separation or Boundaries Minimizes Impacts of Changes

A single application with a module of functionality

Group

An application using an OSID internally, but with no real benefit

Group

The module is outside the application, but still local

Group

A client-side OSID and a remote service

Group

Remote Machine

Data Store

Integration of two applications with a single service

Group

App 1 App 2

Introduction of a common tool for Group management

Group

App 1 App 2GroupMgmtTool

Group maintenance can be removed from applications

Group

App 1 App 2GroupMgmtTool

Common Service Level OSIDs

Allows Integration with Enterprise Services Adapts to Multiple Standards Allows Several Sites to Share Services Independence from Changing Technology

The OSIDs“Common Services”

Agent Authentication Authorization Id Scheduling User Messaging Workflow Dictionary Filing Hierarchy Logging SQL

“Educational Services”

Course Management Digital Repository Assessment Grading

Kerb5

One Application Using Multiple Implementations of One API

X509

AuthN

App

Two Back End Systems –Single Access Method

CourseMgmt

EnrollmentApp.

SIS System HR System

Group Integration

Group Function Group Function

Group Service

System A System B

Implementation Supporting Multiple Protocols

OSID X OSID X

SRMI SOAP

Infrastructure ServiceSupporting both SRMI

And SOAP

Same Application Using Different Implementations

Service 1 Service 2

Application A

Service 1 Service 2

Application A

Independent or Tightly Coupled Implementations

AuthN AuthZ AuthN AuthZ

Application A Application A

“LMS”

Varying Granularity of Service Exposure

Assess

Application Y

AuthN AuthZ

C.M. Etc.

AuthZ

Assess

Application Z

C.M. Etc.

Overall Benefits

Stable and Well-Known Integration Points Common Factoring of Domain Code Reuse Reduced Risk Matched Expectations Shorter Development Cycle / Lower Cost

Benefits of OSIDs for Enterprise IT

Provides enterprise integration strategy Define responsibilities between application developers

and enterprise infrastructure Centralize a function or service

Enforce uniform business logic

Predictable technology migration Costs, resources, process

Structures vendor delivrables (RFP) Integrate two applications with overlapping functions

Benefits of OSIDs for the Developer and Development Manager

Allows tracking of progress Does the application call the xyz OSID? Who is working on the xyz implementation? Is the xyz OSID implementation done?

Provides a context for project metrics How’s the performance of the xyz implementation? How many OSIDs / implementations are done?

Benefits of OSIDs for the Vendor

Create a product that can adapt to many customers’ environments

Separate application issues from enterprise infrastructure

Create an integration point Create means for integration with other vendor’s

products

Applying O.K.I.™

Topics Covered

Organizing for Applications and Implementations

Legacy Migration Testing Debugging Performance and

Scalability

Configuration Software Development

Training Release Management -

When OSIDs Change Build vs Reuse Technical Issues Support Resources

User-FacingApplication

Back-End SystemsIntegration

Single

Team

User-FacingApplication

Back-End SystemsIntegration

Applications

Team

Implementations

Team

OSID

Legacy Migration

Course Management System(Single Purpose Communication)

CourseCatalog

AuthorizationAuthentication

SQL

Authenticate

Authorize

CourseManagement End User

Application

Communication Through OSIDs

CourseCatalog


SQL

Authenticate

Authorize


Application

CourseMgmt

Stand-Alone OSID Implementations

CourseCatalog


SQL

Authenticate

Authorize


Application

CourseMgmtCourse

Management

System Migration

CourseCatalog


SQL

Authenticate

Authorize


Application

New CourseManagement

CourseMgmt

Series (A) Infrastructure

CourseCatalog


SQL (A)

Authentication (A)

Authorization (A)


Application

CourseMgmt (A)

Series (A) and (B)

CourseCatalog


SQL (B)

Authentication (B)

Authorization (A)


Application

CourseMgmt (A)

Testing

Reuse tests since OSIDs are stable Complete test plan before development is complete

no interface feature creep

Tests with sample values can help developers Reuse tests within and across institutions Good tests lower risks in reusing implementation

Debugging

Problem determination can be a significant challenge in complex systems

New code is a source of bugs Reuse of validate components reduces

supply of bugs OSIDs compartmentalized functionality and

limit scope in search for bugs

Performance and Scalability

Architecture envisions relatively few implementations and relatively many applications

Reuse spreads investment in well performing, scalable implementations across more deployments

All dependant applications benefit from enhancements

Configuration

Selection of implementation to use Implementation configuration Sharable context Adapters

User-Facing Application

XxxManager.properties YyyManager.properties

Xxx OSIDImplementation

Yyy OSIDImplementation

OwnerContext

Configuration Mechanisms


OSID “A” Implementation Adapter

Back-End Services

OSID “B” ImplementationOSID “A” Implementation

Configuration Using Adapters

Software Development Training

Keeping current is a continuing challenge Stable abstractions and factoring across technology cycles OSID implementations deal with back-end systems;

generally the longest shelf-life Consistent approach across OSIDs results in higher reuse of

skills

Release ManagementWhen OSIDs Change

Version 1.0

Version 1.1

OSID “A”

New Versions are Supersets


Assessment OSID v1.0(Implementation “A”)

Repository OSID v1.0(Implementation “A”)

Back-End Services

Typical Layered Solution



Repository OSID v1.0(Implementation “B”)

Back-End Services

Substituting Implementations of the Same OSID Version




Back-End Services

Impact of an Implementation of a Newer OSID Version on a Low Layer




Back-End Services

Impact of an Implementation of a Newer OSID Version at a High Layer



AdapterRepository OSID v1.0(Implementation “A”)

Back-End Services

Combination of a New OSID Version Implementations and an Adapter

Build vs Reuse

Inventory of reusable applications and implementations

Institutional context Team’s skills and priorities Architectural design issues

Development Team and Context

Requisite expertise Best use of limited resources Will reuse foster adoption Is reuse mandated Is reuse faster Can new implementation be tested and

supported

Design Questions

Which OSIDs and other interfaces Which methods Which Types What Ids Which language Local implementation? Layering

Technical Topics

Object Lifecycle OsidManager, Persistence, Managing Objects, Static and Dynamic

Binding Integrating Objects and Approaches

Ids, Types, Properties, Owner Context, Out-of-Band Agreements Iterators Exceptions Solution Organization and Configuration Transactions Serialization

Support Resources

http://web.mit.edu/oki https://sourceforge.net/projects/okiproject

OSIDs Documentation Implementations Discussion

[email protected]

http://web.mit.edu/oki

https://sourceforge.net/projects/okiproject

https://sourceforge.net/projects/okiproject

mailto:[email protected]

Questions

open knowledge initiative scott thorne ([email protected]) jeff kahn ([email protected])

Documents