open knowledge initiative. data specifications – ims/scorm enterprise application a enterprise...
TRANSCRIPT
Demo – Filing API
Provides Abstraction Boundary Between Application and one or more “file directories” known as “Cabinets.”
Application
File Synchronization Demo
Client UI Same code on Mac, Windows, Linux Rich User Experience Supports Disconnected Use
Different Byte Stores/Same application Local, Remote, AFS, IMAP – Go Crazy!
Application Portability
Possible Uses
Group Collaboration with multiple users synching to central file space
Group Collaboration using Specialized Tools Exploiting “Universal” File System
Add Authentication/Authorization for security, Logging to track activity, Workflow and Usermessaging to manage projects, etc.
More integrated authoring environments Other…
Common Service Spec Status
Authentication Authorization DBC Logging LocalID Shared Filing Hierarchy User Messaging Scheduling Workflow
0.9 – Public0.9 – Public0.9 – Public0.9 – Public0.9 – Public0.9 – Public0.9 – Public0.90.50.50.5
CS Implementation Activity
Current Activity: Authentication Authorization Filing DBC LocalID Logging Hierarchy
Required Activity: User Messaging Workflow Scheduling
OKI-In-A-Box
Educational Service Spec Activity
Class Admin Core Partner Engagment MITSIS Engagement
Content Management/Digital Repository Digital Library Community DSpace Engagement
Learning Asset Model Tool Model Assessment
OKI Application Activity
LMS’s Stellar – MIT CourseWork – Stanford University CHEF – University of Michigan Indiana University
Demo Apps Filing Demo Hierarchy Demo
Digital Library DSpace Fedora
Various Educational Tool Development
Core Institutional Partners
Cambridge University Dartmouth College MIT North Carolina State University Stanford University University of Michigan University of Pennsylvania University of Wisconsin
Specification/Standards Groups
Instructional Management Systems Global Learning Consortium
Advanced Distributed Learning Network DOD funded SCORM
See IMS/ADL/OKI Press Release
OKI Services
Course MgmtContent Mgmt Assessment
AuthN
Etc…
LocalIdFileDBCAuthZ Hierarchy UserMessagingLogging Etc…
Etc… Etc…
SharedObjects
EducationalService
APIs
CommonService
APIs
Educational Service Implementations
Common Service Implementations
Educational Software“LMS”
Institutional Infrastructure
ClientObjects
ClientApps
ClientObjects
ClientApps
ClientObjects
WebApps
Browser
Browser
ClientObjects
WebApps
Browser
Browser
ClientObjects
ClientApps
OKI ServicesOKI ClientsCampus
Infrastructure
OKI Service Model
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
The API Approach
API are Interfaces only, not Implementations Code Reuse Could Achieve Real-time Integration Clean Separation or Boundaries Minimizes Impacts of Changes
Common Service Level APIs
Allows Integration with Enterprise Services Adapts to Multiple Standards Allows Several Sites to Share Services Independence from Changing Technology
APIs
Definitions Implementations
Service
API
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 } …
ExampleAPI
…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
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!
Deployment Possibilities
One system using another systems service Framework & Component
System using enterprise service Allow for system to use service to hide:
Functions performed different places Different system responsible for data sets
Multiple OKI ServersSharing Common Infrastructure Services
SIS Data
Authentication/Authorization
Digital Repository
Messaging
Multiple OKI Servers Serving Different Content, But Sharing Some Enterprise Services
SIS Data
Authentication/Authorization
Digital Repository
SIS Data
Digital Repository
Implementation Supporting Multiple Protocols
API X API X
SRMI SOAP
Infrastructure ServiceSupporting both SRMI
And SOAP
“LMS”
Varying Granularity of Service Exposure
Assess
Application Y
AuthN AuthZ
C.M. Etc.
AuthZ
Assess
Application Z
C.M. Etc.
Anatomy of APIs
What does an API look like? Java interfaces Factory interface Object interfaces Used for
Presenting services to applications Separating services from applications
Anatomy of APIs
What does an Implementation look like? Java classes Factory class Object classes Used for
Creating objects for an application Accessing “real” services
An API can have many implementations
Anatomy of APIs
How do APIs differ from frameworks? An API presents a service A framework tells you how to code An API can run in a framework A framework might be able to run in an API APIs are enabling APIs foster compartmentalization
Anatomy of APIs
How do APIs relate to other technologies? APIs allow the use existing software APIs do not dictate the implementation APIs do not dictate the application An application doesn’t need to use all APIs An application doesn’t need to use only APIs API impls only need a thin Java shim
Anatomy of APIs
Factories A mechanism to bind Implementations to APIs Are used by apps to get API impl objects Typical impl objects have factory references Factories have owners (Agents and Context)
Anatomy of APIs
Factories - How the code changes (Before) App getting an object instance
Athing a = new Athing(args); (After) App getting an API impl object
Afactory f = FactoryManager( apiPkgName, implPkgname, owner);
Athing a = f.createAthing(args);
Anatomy of APIs
Agents and Context Factory owner is an Agent Agents
Implementation specific Application specific Out of band agreements Contain context Proxy - next Agent in context chain
Anatomy of APIs
Agents and Context Application context as owner
AppAgent appAgent = new AppAgent(context); Afactory f = FactoryManager(api, impl, appAgent); … AppAgent owner = f.getOwner().getProxy(AppAgent.class()); Context c = owner.getContext();
Implementation context as owner … Agent owner = someFactory.getOwner(); Afactory f = FactoryManager(api, impl, owner);
Anatomy of APIs
Authentication/Authorization Who are you?/What can you do? Close association Each is an API and implementation Each has session context Owner proxies can keep context
Anatomy of APIs
ROMI - remote object method invocation Client/Server with invoke method Example
public String toUpper( String s ) { if(hasClient()) { Class[] types = new Class[1]; types[0] = String.class(); Serializable[] args = new Serializable[0]; args[0] = s; String upCase = return getClient().invoke(this, “toUpper”, types, args); } return s.toUpperCase(); }
Anatomy of APIs
What does an API do for an architect? Compartmentalizes the code Hides implementation details Provides an abstraction layer Provides a way to change implementations Provides a specification mechanism Provides a way to spec app as a service Separates User Interfaces and services.
Anatomy of APIs
What does an API do for an programmer? Provides a clear specification Removes architectural detail Isolates the implementation Minimizes coupling between modules Maximizes cohesion Encourages writing for reuse
Anatomy of APIs
What does an API do for the dev manager? Allows tracking of progress
Is the API done? Is the Implementation done? Is the Implementation ROMI-ized? Who is working on the xyz implementation?
Provides a context for project metrics How’s the performance of the abc Impl? How many APIs/Implementations are done?
Anatomy of APIs
What does an API do for the CIO? Provides tracking and metrics Provides a way to cost integration Provides a way to cost development Provides a way to generate vendor requirements
“Your product must use this Authentication API” “Your product must implement the api API”
Opens a path for multiple vendor product use
Anatomy of APIs
What does an API do for the Vendor? Provides a way to create factored products Provides a way to use existing customer services Provides the customer with an upgrade path Provides a way to way to work with other
products
Dimensions of Interoperability
Data Definitions
Technology Choices
UI/Application Frameworks
Service Definitions
Conformance Conclusions
Interoperability is not easyTherefore:
Conformance will not be simple However:
We can make our lives better through intelligent choice and the company we keep.
OKI Strategic Efforts
Core Initiative CS and ES API Specs Reference Implementations Exemplar Applications OKI-in-a-Box 1.0 Communications/Marketing Sustainability Strategy
OKI Strategic Efforts (cont)
Developer CommunitiesInitial Effort → Consortia(Web/Portal, Component, Vendor)
Outreach Coordination Consolidating Spec Change Requests
Voice for Maint and Conformance Dev Support, Training, Doc, Forum Conformance? IDE?
OKI Strategic Efforts (cont)
OKI in a box V2 (Consumers)Initial Build → Consortia/Vendor Support
Product Management Packaging/Installation Distribution Documentation Support Marketing
OKI Developer’s Network
Hosted by IMS See http://web.mit.edu/oki for more info
Sustainability
Spec. Maintenance and Conformance
Development Community Web Client
MIT Infrastructure Build (one-time funding) Support Operate/Maintain
Consortium (IMS)
Consortium (?)
MIT
MIT-OKI Convergence
Libraries DSpace E-Reserves
“LMS” Stellar SloanSpace/.LRN
Educational Innovation Projects (e.g. iLabs, BCS, Teal, etc…)
Enterprise Applications MITSIS DSpace Coeus
MIT OKI Infrastructure
MIT-OKI Convergence
Libraries DSpace E-Reserves
“LMS” Stellar SloanSpace/.LRN
Educational Innovation Projects (e.g. iLabs, BCS, Teal, etc…)
Enterprise Applications MITSIS DSpace Coeus
MIT OKI InfrastructureFunding
InternalExternal
Stellar
OCW and Stellar: Fall 2002
OCWInt.
Web
OCW IP Restricted Content
OCW IP Cleared Content
Discussion Boards for OCW Internal
Other
OKI Digital Repository Services Impact on MIT Initiatives
DSpace
OCW
AFS+
Local
Stellar
OCWExt.Web
Bb
“Madagascar Institute of Technology”
= OKI “Content Management” API
Design Dimensions for Educational Applications
Technical Specs(W3C, IETFJava, I2, etc)
Interoperability Specs(IMS, ADL,
OCLC, OKI, etc.)
Learning Activity Design(?)
Philosophy
Service-based Infrastructure for Educational Software (Development and Delivery)
Driven Primarily by Higher Education Technology Requirements and Pedagogy
Open (low threshold for access/adoption) Collaborative (H.E., IMS, ADL) Enable Sharing of Instructional/Training
Applications Implementation Independent Service Definitions
Assumptions
Things Change New Services & Functions Method of Accessing Services More Central Software Services
Authorization, Calendaring, etc.
Evolving Systems Definition Boundaries
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”
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
EALP
Educational Activities and Learning Practices LMS Summit – April 2001 Needs assessment/scenarios Tool Definition Workshop – Oct 15, 16 OKIO LMS (sic) Summit II
Architecture Group
Primary team is at MIT Approximately 3FTE Provide bulk of day to day effort
Core partner designers Face to Face engagement every two months on average Critical input and contribution Competencies range from system design, instructional
application design, library systems
Deliverables
1.x Version of OKI Framework Spec. Implementations of Framework APIs Collection of Exemplar Tools/Applications
(Including “LMS” Solution) Developer Community Strategy Sustainability Strategy
APIs
Definitions Implementations
Service
API
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 } …
ExampleAPI
…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
OKI Services
Course MgmtContent Mgmt Assessment
AuthN
Etc…
LUIDFileDBCAuthZ Rules UserMessagingLogging Etc…
Etc… Etc…
SharedObjects
EducationalService
APIs
CommonService
APIs
Educational Service Implementations
Common Service Implementations
Educational Software“LMS”
Institutional Infrastructure
Example
public class Factory implements org.okip.service.authorization.api.Factory { private static final blah blah bhal
private static final yada yada yada } …
Authorization
…org.okip.service.shared.api.Type[] types = myFactory.getAuthenTypes();
if (null != types) { for (int i = 0; types.length != i; i++) { out.println(types[i]); System.err.println(types[i]); } } …
public class Factory implements org.okip.service.authentication.api.Factory { private static final blah blah bhal
private static final yada yada yada } …
Authentication
public class Factory implements org.okip.service.authorization.api.Factory { private static final blah blah bhal
private static final yada yada yada } …
Assessment
Admit One
Same Application Using Different Implementations
Service 1 Service 2
Application A
Service 1 Service 2
Application A
Implementation Supporting Multiple Protocols
API X API X
SRMI SOAP
Infrastructure ServiceSupporting both SRMI
And SOAP
Dimensions of Sustainability for OKI
Influence
Evolution
Conformance
Sustainability
Adoption
Support
Influence and Outreach
Related initiatives/projects IMS/ADL Digital Library
Interest and Adoption Licensing Arrangements (IP) OKIO
Same Application/Different API Implementations (Modularity)
API 1 API 2
Application A
API 1 API 2
Application A
Different Application/Same API Implementations (Portability)
API 1 API 2 API 1 API 2
Application BApplication A
Example
public class Factory implements org.okip.service.authorization.api.Factory { private static final blah blah bhal
private static final yada yada yada } …
Authorization
…org.okip.service.shared.api.Type[] types = myFactory.getAuthenTypes();
if (null != types) { for (int i = 0; types.length != i; i++) { out.println(types[i]); System.err.println(types[i]); } } …
public class Factory implements org.okip.service.authentication.api.Factory { private static final blah blah bhal
private static final yada yada yada } …
Authentication
public class Factory implements org.okip.service.authorization.api.Factory { private static final blah blah bhal
private static final yada yada yada } …
Assessment
QuizID = “Chem100Final”
Assessment.getQuizElements(QuizID)
Admit One
Authorization. getAuths(myPerson,QuizID)
myPerson = Authentication.getAgent()
OKI Service Framework
Specifications
Course MgmtContent Mgmt Assessment
AuthN
Etc…
GUIDFileDBMSAuthZ Rules UserMessagingLogging Etc…
Etc… Etc…
EducationalComponent
APIs
CommonService
APIs
CommonObjects
OKI Service Framework
Specifications Implementations
Course MgmtContent Mgmt Assessment
AuthN
Etc…
GUIDFileDBMSAuthZ Rules UserMessagingLogging Etc…
Etc… Etc…
EducationalComponent
APIs
CommonService
APIs
Educational Service Implementations
Common Service Implementations
CommonObjectsInstitutional Infrastructure
OKI Service Framework
Specifications Implementations
Course MgmtContent Mgmt Assessment
AuthN
Etc…
GUIDFileDBMSAuthZ Rules UserMessagingLogging Etc…
Etc… Etc…
EducationalComponent
APIs
CommonService
APIs
Educational Service Implementations
Common Service Implementations
CommonObjectsInstitutional Infrastructure
Service Framework
SISEducational
SoftwareServices
DigitalLibrary
CommonServices
Tools
Infrastructure
Service Framework
MITSISMIT
EducationalSoftwareServices
DSpace
MITCommonServices
Tools
Infrastructure
Stellar
Service Framework
SISEducational
SoftwareServices
Common Services
Tools
DigitalLibraryServices
Infrastructure
Web Service Implementations?
Imp. of X
API X
WebService
X
SOAP SOAP
Imp of X
API X
JavaC++
WS RegistryServer
UDDIUDDI
OKI BasedWSDL Spec?WSDL
App. AApp. B
WebServiceClient
Application
SOAP
API X
WebService
X
WS RegistryServer
UDDI
WSDL
Perl? C?
Web Service Applications?
Same OKI BasedWSDL Spec?
“LMS”
Varying Granularity of Service Exposure
Assess
Application Y
AuthN AuthZ
C.M. Etc.
AuthZ
Assess
Application Z
C.M. Etc.
ClientObjects
ClientApps
ClientObjects
ClientApps
ClientObjects
WebApps
Browser
Browser
ClientObjects
WebApps
Browser
Browser
ClientObjects
ClientApps
OKI ServicesOKI ClientsCampus
Infrastructure
OKI Service Model
Multiple OKI Servers Serving Different Content, But Sharing Some Enterprise Services
SIS Data
Authentication/Authorization
Digital Repository
SIS Data
Digital Repository
Multiple OKI ServersSharing Common Infrastructure Services
SIS Data
Authentication/Authorization
Digital Repository
Messaging
OKI Processes
Common Services
OKI/LMS Services
Pedagogical Tools
User Experience
Infrastructure
EALP
Architecture
Sustainability
Common Services
LMS Services
OKI Tools
User Experience
Infrastructure
OKI Service Framework
Specifications Implementations
Course MgmtContent Mgmt Assessment
AuthN
Etc…
LUIDFileDBCAuthZ Rules UserMessagingLogging Etc…
Etc… Etc…
EducationalService
APIs
CommonService
APIs
Educational Service Implementations
Common Service Implementations
SharedObjectsInstitutional Infrastructure
OKI Service Framework
Specifications Implementations
Localized Modular
Course MgmtContent Mgmt Assessment
AuthN
Etc…
LUIDFileDBCAuthZ Rules UserMessagingLogging Etc…
Etc… Etc…
EducationalComponent
APIs
CommonService
APIs
Educational Service Implementations
Common Service Implementations
SharedObjectsInstitutional Infrastructure
OKI Service Layers
Course MgmtContent Mgmt Assessment
AuthN
Etc…
GUIDFileDBMSAuthZ Rules UserMessagingLogging Etc…
Etc… Etc…
SharedObjects
EducationalComponent
APIs
CommonService
APIs
Educational Service Implementations
Common Service Implementations
Educational Software“LMS”
Institutional Infrastructure
OKI Requirements for IMS
Educational“Application”
Services
CommonServices
Class AdminContent MgmtAssessment
(Quiz and Test)
AuthN
Communication(DiscussionChat, Etc.)
LUID“GUID”
FileDBMSAuthZ RulesUser
MessagingLogging Sched.
Etc…
Work-flow
Etc… Etc…
Etc… Etc…
The Importance of an Architectural Framework
IMS Quarterly Meeting
April 29, 2002
Scott Thorne
Senior Systems Architect, MIT
MIT Systems Which Keep Track of People
Library
Parking
Accounts
Sports
Registrar Alumni
Directory
LMS
HR/Payroll
Research
Lincoln
Data Feeds of Person Information
Library
Parking
Accounts
Sports
Registrar Alumni
Directory
LMS
HR/Payroll
Research
Lincoln
Implications
Need for Integration Differing Degrees of Integration
By Function Authorization, but not Calendaring
Different SetsEx: Employees & Students
Degree of Coupling
Group Functional Specification
Add a new group Delete a group Add a member to a group Remove a member from a group List all members of a group
Different Group Integration
Systems each maintain copy Synchronization strategy
One system maintains groups, others only read Differing timeliness
Systems both maintain common groups Systems maintain different sets of groups
Read all sets Common service
Group Integration
Group Function Group Function
Group Service
System A System B
Group Function
System C
Group Integration Issues
Who should be allowed to maintain groups? How does System A know how to use the
new group system B defined? The system of record deleted the group, what
should the subsystem do?
Benefits of Architectural & Functional Specification
Perspectives; User, Vendor, Higher Education Easier and better Integration with the Enterprise More Choices
Better interoperability >> Best of functionality
How to Proceed?
Data Specification Existing
Changes, Specific Profiles
New Areas
Functional Specification Universal Definition (UML) Multiple Bindings
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!
Deployment Possibilities
One system using another systems service Framework & Component
System using enterprise service Allow for system to use service to hide:
Functions performed different places Different system responsible for data sets