1 / 17

Introduction to Sakai and Sakai Services

Introduction to Sakai and Sakai Services. Aaron Zeckoski azeckoski@gmail.com. From slides by Antanig Basman & Ian Boston. Enterprise Production-ready Abstraction boundaries between tools, services, framework, and presentation Seamless integration across tools when appropriate

patsyf
Download Presentation

Introduction to Sakai and Sakai Services

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. Introduction to Sakai and Sakai Services Aaron Zeckoski azeckoski@gmail.com From slides by Antanig Basman & Ian Boston

  2. Enterprise Production-ready Abstraction boundaries between tools, services, framework, and presentation Seamless integration across tools when appropriate Component-based expandability with ClassLoader isolation Data interoperability and ability to expand Sakai without using Java Flexibility - Ease of local customization Sakai Technical Goals

  3. Sakai is aimed at Enterprise Deployments. Sakai supports organizations with > 100,000 users in a single installation Sakai consists of technologies chosen to be common in Java Enterprise Environments. The Sakai Enterprise Technologies Java 1.5 Apache - SSL, mod_jk(optional) JSP, JSF, Velocity, RSF Tomcat 5.5.x Spring Hibernate, JDBC Presentation App Delivery Database MySql Oracle Others?

  4. Sakai Structure 1: Physical Deployment IP Sprayer w/ Sticky Session Hot Spare Load Balancer: Hardware or Software UM = NetScaler IU = Software App servers with identical software loads. UM = 8X Dell PowerEdge 2650, dual 2.4-3.2 GHz CPU, 4 GB RAM Database Server UM = SunFire V480, Quad 900 MHz CPU, 20GB RAM, 4 StorEdge 3310 SCSI RAID Arrays w/ 12 73Gb disks (Oracle) File Server (optional) IU = NetApp App Server Hot Spare File Server (opt) Database Server Hot Spare

  5. Tools Responsible for presentation (GUI) Should not do any type of persistence User facing Services / Components Must provide documented API Cannot do any presentation (not aware of HTML at all) Must access other services through service APIs Developer facing Framework Provides registration for tools and service Provides common capabilities and services Knows nothing of domain objects Developer/Service facing Framework, Tools and Services

  6. Presentation Tech Sakai Application Structure Web Browser WS Client Presentation Abstraction New Portal Portal Other Tools New Tool Axis Web Svcs Framework WS Endpoint Service Interface (i.e. API) Application Other Services New Service Common Services Kernel DB DB

  7. Sakai has many core services to support the tool writer and higher level services Here are the common ones used by most application developers UserDirectoryService – handles user information lookups SessionManager – handles user sessions SecurityService – does authorization checks SiteService – allows integration with Sakai sites ToolManager – allows finding out the location of a user and information about tools FunctionManager – registers permissions for tools Basic Sakai Services URL: http://confluence.sakaiproject.org/confluence/display/BOOT/Sakai+Framework+Tips

  8. In addition to core services, Sakai also supports the use of providers for integration UserDirectoryProvider – map local user information into Sakai (e.g. in LDAP, IMS Enterprise, Kerberos) GroupProvider – map enrollments in groups into Sakai CourseManagementProvider - map courses and sections and related information into Sakai Sakai also has specialized integration points Entity Broker / Provider – allows your app to participate in the Sakai environment and not just be a user of the services Create and detect events Control entity URLs Attach properties Import/Export Etc… Standardized Sakai Services

  9. The Sakai “container” is a lightly(ish) modified J2EE (Servlet) container Tomcat, WebSphere, WebLogic, etc. are all in use A Sakai tool is a user-facing element, and is basically a kind of Servlet A Sakai component is the implementation of some Sakai API, and is a (collection of) Spring Beans How do tools and components relate to and talk to each other? Need to step back and review some J2EE basics. What is in Sakai, where is it all?

  10. ClassLoaders are the key means for code insulation and dynamism in Java Most other environments don’t have anything like them ClassLoader rules are poorly understood, even by Sun Unfortunately a working understanding is key to successful Sakai development ClassLoaders

  11. Java ClassLoaders are (meant to) form a tree This is the standard layout for a Servlet container Note that Webapp ClassLoaders are slightly “odd” in that unlike all others, they will look *locally* to resolve non-System classes first, rather than looking in parent first This can be the cause of various “hilarious” errors/difficulties in Sakai ClassLoaders in Tomcat (J2EE)

  12. Sakai adds to the J2EE standard ClassLoader layout “Component” environments are just like Servlets (webapps) in many ways Use URLClassLoader Parent is Shared Unlike them in some others Only components.xml (Spring file), no web.xml Respond only to function calls, not to Servlet dispatches! Do not reload (currently – actually they really should) ClassLoaders in Sakai APIs up here Components in here Tools in here Component1 Component2

  13. A Sakai tool is “nearly” like a normal Servlet, only with some oddities URL environment is “screwed up” which prevents using normal view technologies straightforwardly RSF, JSF and Velocity have “first class support” Extra packaging required, with special material in web.xml, as well as a tool registration file (tools/toolname.xml) All of this is taken care of by the App Builder Plugin The tool’s Spring context (applicationContext.xml) is automagically “glued” onto the bottom of the global shared Spring context, so Sakai services can be directly referenced in Spring Spring JARs must NOT be included in the application, since they are already in shared Writing Sakai Tools

  14. A Sakai component is divided into three parts An API module contains Java interface definitions and constants often contains model and sometimes utils might also contain HBM mapping files forms a JAR which is sent to the shared area An Implementation (IMPL) module contains implementations for the API interfaces among other things a Spring-formatted components.xml file which publishes the implementation beans to the shared Spring context. forms a WAR which is sent to the components area A test module Contains programmatic tests (unit/integration tests) Writing Sakai Components/Services

  15. Sakai takes advantage of Spring to create service beans and load resources Spring is primarily used for IoC (dependency injection) Transaction control (for DB access) Testing (Transactional testing) Resource loading (properties etc.) Basic Spring understanding is critical for working with Sakai framework services Spring framework in Sakai URL: http://www.springframework.org/

  16. Sakai is currently using Spring 1.2.8 Upgrade to 2.0.6 is in progress Sakai ComponentManager is built on the Spring framework This will not change anytime soon Spring must be deployed in shared Work is in progress to move this out of shared More spring framework

  17. Questions?

More Related