Open Knowledge Initiative Scott Thorne Jeff Kahn

Slides:



Advertisements
Similar presentations
The e-Framework Bill Olivier Director Development, Systems and Technology JISC.
Advertisements

Course: e-Governance Project Lifecycle Day 1
Enterprise Architecture 2013 ITLC & ITAG Leadership Meeting Discussion Points April 9, 2013.
Key-word Driven Automation Framework Shiva Kumar Soumya Dalvi May 25, 2007.
Open Knowledge Initiative Phillip D. Long Senior Strategist for the Academic Computing Enterprise Massachusetts Institute of Technology eLearning Standards.
© Copyright 2006 Massachusetts Institute of Technology Open Knowledge Initiative ™ Open Knowledge Initiative International Symposium on Open Educational.
Roadmap to Continuous Integration Testing and Benefits Gowri Selka, Walgreens Natalie Koltun, Walgreens May 20th, 2014 ©2013 Walgreen Co. All rights reserved.
Copyright © 2008 Accenture All Rights Reserved. Accenture, its logo, and High Performance Delivered are trademarks of Accenture. Andrew Stone Common Security.
Enterprise Integration Architecture IPMA Professional Development Seminar June 29, 2006 Scott Came Director, Enterprise Architecture Program Washington.
Achieving Success With Service Oriented Architecture Derek Ireland 17th March, 2005.
© 2004 Visible Systems Corporation. All rights reserved. 1 (800) 6VISIBLE Holistic View of the Enterprise Business Development Operations.
ECHO: NASA’s E os C learing HO use Integrating Access to Data Services Michael Burnett Blueprint Technologies, 7799 Leesburg.
Federal Student Aid Technical Architecture Initiatives Sandy England
Component Patterns – Architecture and Applications with EJB copyright © 2001, MATHEMA AG Component Patterns Architecture and Applications with EJB JavaForum.
Technical Architectures
R R R CSE870: Advanced Software Engineering (Cheng): Intro to Software Engineering1 Advanced Software Engineering Dr. Cheng Overview of Software Engineering.
Thee-Framework for Education & Research The e-Framework for Education & Research an Overview TEN Competence, Jan 2007 Bill Olivier,
1©2005 OnTapSolutions5 December 2005 Service Oriented Architecture with O.K.I. Tom Coppeto OnTapSolutions Stuart Sim Sun Microsystems 5 December 2005.
Open Knowledge Initiative ITAG Luncheon 1/8/03 Scott Thorne.
Software Engineering Module 1 -Components Teaching unit 3 – Advanced development Ernesto Damiani Free University of Bozen - Bolzano Lesson 2 – Components.
IRS XML Standards & Tax Return Data Strategy For External Discussion June 30, 2010.
Understanding of Automation Framework A Storehouse of Vast Knowledge on Software Testing and Quality Assurance.
© 1998 Concept Five Technologies Enterprise Application Integration Capability Maturity Model.
Massachusetts Institute of Technology Page 1 Open Knowledge Initiative CSG - Princeton, 05/07/03.
Windows.Net Programming Series Preview. Course Schedule CourseDate Microsoft.Net Fundamentals 01/13/2014 Microsoft Windows/Web Fundamentals 01/20/2014.
a Service Oriented Architecture
“Behind the Scenes” of the Enterprise Development Reference Architecture (EDRA) Jonathan Wanagel Microsoft patterns & practices
Software Engineering Muhammad Fahad Khan
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
RUP Fundamentals - Instructor Notes
Update to UCA-EIM on California ISO Enterprise Model Management System Project Brian Jacobsen Enterprise Model Management California ISO June 2012 OpenSG.
Chapter 2 The process Process, Methods, and Tools
Rational Unified Process Fundamentals Module 4: Disciplines II.
Business Systems Development SDLC and introduction to the Microsoft Solutions Framework Team and Process Models.
RUP Design RUP Artifacts and Deliverables
Service Oriented Architecture (SOA) at NIH Bill Jones
Systems Design Approaches The Waterfall vs. Iterative Methodologies.
Open Knowledge Initiative. Data Specifications – IMS/SCORM Enterprise Application A Enterprise Application B Data.
Middleware for FIs Apeego House 4B, Tardeo Rd. Mumbai Tel: Fax:
Distribution and components. 2 What is the problem? Enterprise computing is Large scale & complex: It supports large scale and complex organisations Spanning.
© Copyright 2005 Massachusetts Institute of Technology Open Knowledge Initiative ™ Repository Integration Using the Open Knowledge Initiative (O.K.I.)
ANKITHA CHOWDARY GARAPATI
March 2004 At A Glance NASA’s GSFC GMSEC architecture provides a scalable, extensible ground and flight system approach for future missions. Benefits Simplifies.
SEAL Core Libraries and Services CLHEP Workshop 28 January 2003 P. Mato / CERN Shared Environment for Applications at LHC.
Chapter © 2012 Pearson Education, Inc. Publishing as Prentice Hall.
Open Knowledge Initiative Architectural Overview 12/15/01.
Software Maintenance Speaker: Jerry Gao Ph.D. San Jose State University URL: Sept., 2001.
Technical Support to SOA Governance E-Government Conference May 1-2, 2008 John Salasin, Ph.D. DARPA
Rational Unified Process Fundamentals Module 4: Core Workflows II - Concepts Rational Unified Process Fundamentals Module 4: Core Workflows II - Concepts.
Chapter © 2012 Pearson Education, Inc. Publishing as Prentice Hall.
Copyright © 2004, Keith D Swenson, All Rights Reserved. OASIS Asynchronous Service Access Protocol (ASAP) Tutorial Overview, OASIS ASAP TC May 4, 2004.
Cisco Consulting Services for Application-Centric Cloud Your Company Needs Fast IT Cisco Application-Centric Cloud Can Help.
©Ian Sommerville 2007COTS-based System Engineering Slide 1 COTS-based System Engineering.
By Jeremy Burdette & Daniel Gottlieb. It is an architecture It is not a technology May not fit all businesses “Service” doesn’t mean Web Service It is.
Advanced Software Engineering Dr. Cheng
Process 4 Hours.
Self-Contained Systems
EI Architecture Overview/Current Assessment/Technical Architecture
Understanding of Automation Framework
Distribution and components
EIN 6133 Enterprise Engineering
Notification Service May 19, 2006 Jon Atherton Mark Mara.
Tools of Software Development
Course: Module: Lesson # & Name Instructional Material 1 of 32 Lesson Delivery Mode: Lesson Duration: Document Name: 1. Professional Diploma in ERP Systems.
Scott Thorne & Chuck Shubert
Service Oriented Architecture with O.K.I.
Introduction to SOA Part II: SOA in the enterprise
ONAP Architecture Principle Review
Presentation transcript:

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