open knowledge initiative n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Open Knowledge Initiative PowerPoint Presentation
Download Presentation
Open Knowledge Initiative

Loading in 2 Seconds...

play fullscreen
1 / 64

Open Knowledge Initiative - PowerPoint PPT Presentation


  • 110 Views
  • Updated on

Open Knowledge Initiative. Scott Thorne (thorne@mit.edu) Jeff Kahn (jeffkahn@mit.edu). 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Open Knowledge Initiative


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
    Presentation Transcript
    1. Open Knowledge Initiative Scott Thorne (thorne@mit.edu) Jeff Kahn (jeffkahn@mit.edu)

    2. Topics • Architectural Overview • Assumptions • Goals • Design • Benefits • Applying O.K.I.™

    3. Assumptions • Things Change • New Services & Functions • Method of Accessing Services • More Central Software Services • Authorization, Calendaring, etc. • Evolving Systems • Definition

    4. 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

    5. 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

    6. 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

    7. 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!

    8. Systems Exchanging Data System A System B 1 2

    9. Systems Integrated Functionally System A System B 2

    10. Example OSIDs • Definitions OSID

    11. Example OSIDs • Definitions • Implementations OSID public class Factory implements org.okip.service.APIName.api.Factory { private static final blah blah bhal private static final yada yada yada } … Service Implementation Infrastructure

    12. Example Service-Based Architecture …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 OSID public class Factory implements org.okip.service.Example.api.Factory { private static final blah blah bhal private static final yada yada yada } … Service Implementation Infrastructure

    13. The OSID Approach • OSID are Interfaces only, not Implementations • Code Reuse • Could Achieve Real-time Integration • Clean Separation or Boundaries • Minimizes Impacts of Changes

    14. A single application with a module of functionality Group

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

    16. The module is outside the application, but still local Group

    17. A client-side OSID and a remote service Remote Machine Group Data Store

    18. Integration of two applications with a single service App 1 App 2 Group

    19. Introduction of a common tool for Group management App 1 Group Mgmt Tool App 2 Group

    20. Group maintenance can be removed from applications App 1 Group Mgmt Tool App 2 Group

    21. Common Service Level OSIDs • Allows Integration with Enterprise Services • Adapts to Multiple Standards • Allows Several Sites to Share Services • Independence from Changing Technology

    22. “Common Services” Agent Authentication Authorization Id Scheduling User Messaging Workflow Dictionary Filing Hierarchy Logging SQL “Educational Services” Course Management Digital Repository Assessment Grading The OSIDs

    23. AuthN One Application Using Multiple Implementations of One API App X509 Kerb5

    24. CourseMgmt Two Back End Systems –Single Access Method EnrollmentApp. HR System SIS System

    25. Group Function Group Function Group Integration System A System B Group Service

    26. OSID X OSID X Implementation Supporting Multiple Protocols SRMI SOAP Infrastructure Service Supporting both SRMI And SOAP

    27. Service 1 Service 2 Service 1 Service 2 Same Application Using Different Implementations Application A Application A

    28. AuthN AuthZ AuthN AuthZ Independent or Tightly Coupled Implementations Application A Application A

    29. Application Z Assess AuthN AuthZ C.M. Etc. AuthZ Assess C.M. Etc. Varying Granularity of Service Exposure Application Y “LMS”

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

    31. 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

    32. 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?

    33. 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

    34. Applying O.K.I.™

    35. 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 Topics Covered

    36. User-Facing Application Single Team Back-End Systems Integration

    37. User-Facing Application Applications Team OSID Back-End Systems Integration Implementations Team

    38. Legacy Migration

    39. Course Management System(Single Purpose Communication) Authenticate Course Management End User Application Authorize SQL Course Catalog Authorization Authentication

    40. Communication Through OSIDs CourseMgmt Course Management End User Application Authenticate Authorize SQL Course Catalog Authorization Authentication

    41. Stand-Alone OSID Implementations CourseMgmt Course Management Course Management End User Application Authenticate Authorize SQL Course Catalog Authorization Authentication

    42. System Migration Course Management CourseMgmt End User Application Authenticate Authorize New Course Management SQL Course Catalog Authorization Authentication

    43. Series (A) Infrastructure CourseMgmt (A) Course Management End User Application Authentication (A) Authorization (A) SQL (A) Course Catalog Authorization Authentication

    44. Series (A) and (B) CourseMgmt (A) Course Management End User Application Authentication (B) Authorization (A) SQL (B) Course Catalog Authorization Authentication

    45. 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

    46. 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

    47. 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

    48. Configuration • Selection of implementation to use • Implementation configuration • Sharable context • Adapters

    49. Configuration Mechanisms User-Facing Application Xxx OSID Implementation Yyy OSID Implementation XxxManager.properties YyyManager.properties Owner Context

    50. Configuration Using Adapters User-Facing Application OSID “A” Implementation Adapter OSID “A” Implementation OSID “B” Implementation Back-End Services