1 / 22

Service Oriented Architecture with O.K.I.

Explore the fundamentals of Service Oriented Architectures (SOA) and O.K.I., emphasizing integration, software design, and OSID specifications. Learn about degrees of interoperability, architectural case studies, and the importance of top-down organization.

waggonere
Download Presentation

Service Oriented Architecture with O.K.I.

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Service Oriented Architecturewith O.K.I. Tom Coppeto (tom@mit.edu) OnTapSolutions Stuart Sim Sun Microsystems 5 December 2005

  2. Service Oriented Architectures • An architecture is a framework that defines an organization of system components • SOA is an architecture organizing systems around services • Each service is defined using a service interface • Service implementation hidden from the interface consumer

  3. It’s About Integration • Making applications work with IT infrastructures • Making system components work with each other • The interfaces define the integration points among disparate services, not the technologies or other service implementationdetails

  4. It’s About Software • Some SOAs place the interface boundary on the wire • We believe the interface boundary is better placed in the software consumer consumer provider provider

  5. O.K.I. Open Service Interface Definitions (OSIDs) • O.K.I. is an SOA built on service definitions • OSIDs define software interfaces • The interface is a contract between a service consumer and a service provider • OSIDs do not specify how a service works • Different providers of the same OSID may do entirely different things

  6. OSID Specifications www.okiproject.org • Id • Agent • Authentication • Authorization • Grading • Logging • Filing • Repository • Scheduling • Assessment • Course Management • User Messaging • Workflow

  7. OSID Providers • O.K.I. does not specify what a provider implementation can do other than to implement the interface • An Authorization provider that makes use of LDAP should work just as well as an Authorization provider that simply saidyes • One may be a bit more useful than the other, however • Sometimes it’s useful to have a provider do nothing

  8. Old School Programming Core application Data to be parsed read response config Log status command Send command status Authentication credential APIs Authentication credential Connectionhandle Authentication configuration Server identity Send credential Make server connection Get auth credential

  9. Interface Programming Core application log Service Interface Service log Service Implementation authN

  10. Software Design (the way not to look at OSIDs) Repository Application AUTH LOGGING REPOSITORY

  11. Software Design (2) (better) Repository Application Repository Authentication Agent LOGGING Logging

  12. Software Design (3) (adapters) Application Service Implementation Service Implementation Service Implementation

  13. Software Design (4) Client/server systems begin with standalone impls Application IMPL Client Server IMPL IMPL

  14. What an Implementation Looks Like APPLICATION INTERFACE INTERFACE CONTRACT CONFIGURATION PROPERTIES TRANSACTION MANAGEMENT UTILITIES CLIENT PROTOCOLS WIRE PROTOCOLS REMOTE SERVER OTHER IMPLEMENTATIONS

  15. Degrees of Interoperability Interface Types Logic

  16. Interfaces & Protocols • Developers use code • Protocol APIs tend to be fragile, and they get everywhere • Not all services involve servers • Stubbing: top down design • Unit testing • Effective project management • Adapters • Protocols are ever-changing implementation “details” • Interfaces change as well, but slower and version skew is much easier to cover with an adapter • An OSID impl can built by a third party to cover an existing service without the cooperation of the service provider

  17. Planetary Alignment Server Application API

  18. Planetary Alignment (2) Server OSID API Application

  19. Pound Wise, Penny Foolish • As software engineers, we get too caught up in reusing small amounts of code • Instead of worrying about reusing a particular java class, we should worry aboutnotreplicating entire services

  20. Architectural Case Study Atheltics Alumni SloanSpace Atheltics Alumni Sloan Student Services Libraries SIS Data Warehouse DSpace ProjectAthena IST Parking Moira Techtime Parking

  21. Resulting System Architecture Moira SIS Alumni Athletics Agent Group Authentication Authorization Messaging Scheduling Course Mgmt Repository SloanSpace DSpace Techtime Parking

  22. Taking The Red Pill • Top-down organization of processes, services and utilities • Bottom-up adoption through OSID support • Technology specifics don’t matter to application code • Consumers should not tell providers how to do their job, just that it needs to be done • Services relying on data feeds need to be refactored • www.okiproject.org

More Related