Open Knowledge Initiative Scott Thorne Jeff Kahn
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 ASystem B 2
OSIDs Definitions Example OSID
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 } … Example OSID … 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 1App 2
Introduction of a common tool for Group management Group App 1App 2Group Mgmt Tool
Group maintenance can be removed from applications Group App 1App 2Group Mgmt Tool
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 Enrollment App. SIS System HR System
Group Integration Group Function Group Service System ASystem B
Implementation Supporting Multiple Protocols OSID X SRMISOAP Infrastructure Service Supporting both SRMI And SOAP
Same Application Using Different Implementations Service 1Service 2 Application A Service 1Service 2 Application A
Independent or Tightly Coupled Implementations AuthNAuthZAuthNAuthZ Application A
“LMS” Varying Granularity of Service Exposure Assess Application Y AuthNAuthZ 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-Facing Application Back-End Systems Integration Single Team
User-Facing Application Back-End Systems Integration Applications Team Implementations Team OSID
Legacy Migration
Course Management System (Single Purpose Communication) Course Catalog Authorization Authentication SQL Authenticate Authorize Course Management End User Application
Communication Through OSIDs Course Catalog Authorization Authentication SQL Authenticate Authorize Course Management End User Application CourseMgmt
Stand-Alone OSID Implementations Course Catalog Authorization Authentication SQL Authenticate Authorize Course Management End User Application CourseMgmt Course Management
System Migration Course Catalog Authorization Authentication SQL Authenticate Authorize Course Management End User Application New Course Management CourseMgmt
Series (A) Infrastructure Course Catalog Authorization Authentication SQL (A) Authentication (A) Authorization (A) Course Management End User Application CourseMgmt (A)
Series (A) and (B) Course Catalog Authorization Authentication SQL (B) Authentication (B) Authorization (A) Course Management End User 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.propertiesYyyManager.properties Xxx OSID Implementation Yyy OSID Implementation Owner Context Configuration Mechanisms
User-Facing Application 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 Management When OSIDs Change
Version 1.0 Version 1.1 OSID “A” New Versions are Supersets
User-Facing Application Assessment OSID v1.0 (Implementation “A”) Repository OSID v1.0 (Implementation “A”) Back-End Services Typical Layered Solution
User-Facing Application Assessment OSID v1.0 (Implementation “A”) Repository OSID v1.0 (Implementation “B”) Back-End Services Substituting Implementations of the Same OSID Version
User-Facing Application Assessment OSID v1.0 (Implementation “A”) Repository OSID v1.1 (Implementation “A”) Back-End Services Impact of an Implementation of a Newer OSID Version on a Low Layer
User-Facing Application Repository OSID v1.0 (Implementation “A”) Assessment OSID v1.1 (Implementation “A”) Back-End Services Impact of an Implementation of a Newer OSID Version at a High Layer
User-Facing Application Assessment OSID v1.1 (Implementation “A”) Adapter Repository 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 OSIDs Documentation Implementations Discussion
Questions