Creative Commons Attribution- ShareAlike 2.5 License Sakai Programmer's Café Sakai Oxford Tetra ELF Workshop Sakai Development Practices, Best, and otherwise Antranig Basman

2 Sakai Tool/Component Architecture It would be useful at this stage to review some of the reasons/thinking that have made the Sakai Architecture the way it is today. “Modular” framework where artefacts can be both consumers and producers of “services” Innovative/cheap use of Spring as an “Enterprise” Service Locator Spring is the key enabling technology of the 2000s New philosophy of “dependency management” allows arbitrarily scale-free designs, allows former O-O “philosophy” to be assessed in more fundamental terms (keep the good, throw out the bad)

3 Spring and its Meaning The whole purpose of the dependency management movement (starting with Lakos in 1996) was that code artefacts form a Tree of Knowledge A “depends on” B or “knows about” B if there is any visible mention of B in its definition (arguments, base classes, return types, imports – also now, *annotations*) Becomes a relation A~B, with respect to which code should be a tree Now it is a tree, have to worry about how it gets constructed. It’s own construction must continue to follow the tree rules – so must be constructed top-down! Natural result is a “Clapham Junction” effect at the top of your design Spring lets you offload this task to someone else. Code is now finally “scale-free” and correct.

4 A Spring Bean package myPackage; public class MyBean { private Dependency myDependency; public void setMyDependency(Dependency myDependency) { this.myDependency = myDependency; } In Code: In XML: The “final” form of “Inversion of Control” framework Sometimes called “non-interface-based” injection, since the target does not need to implement any particular interface (that was “Type I IOC”) This example is “Type II IoC” (setter-based). Spring also supports Type III = Constructor- based, but due to the way the Java language treates constructors (crummy, no named parameters) this is not really a good idea.

5 Spring and Circularity Need to distinguish between circularity of code knowledge and circularity of resulting object graph The first is obviously terrible The second *can* happen “legally”, so long as the code dependency is broken by an interface (e.g. one Object may have many “hats”) However, this creates the risk of construct-time circles, which *is* an error Need to distinguish between use made of a dependency during initialization, between use made of it post-construction Since Spring 1.2.2, construct-time circles have been *allowed*!!!! Cause of many subtle problems already in Sakai In Spring 2.0 (released this week) there is at least a per-Factory “flag” that forbids circular construction references Sakai is still at Spring 1.2.8, and the flag is hard to access In the meantime, don’t do this! Correct solution is based on ProxyFactoryBean and LazyInitTargetSource (ask for details, or consult sakai-dev archives!)

6 “ Enterprise ” When I say “Enterprise” I mean “cross- ClassLoader” Perhaps not the typical definition but at least it is precise This capability is typically associated only with $$$ commercial containers (EJBs, JBoss, WebLogic &co.) Note that Spring is planning integration with OSGi shortly, but amazingly OSGi is itself $$$! Sakai solution while slightly “ad hoc” is pretty straightforward and effective

7 ClassLoaders 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

8 ClassLoaders in Tomcat (J2EE) 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

9 ClassLoaders in Sakai Sakai introduces new citizens into the ClassLoader ecology “Component” environments are just like Servlets (webapps) in many ways –Use URLClassLoader –Parent is Shared Unlike them in some others –Only components.xml, no web.xml –Respond only to function calls, not to Servlet dispatches! –Do not reload (currently – actually they really should) Component1Component2

10 Recap of Aaron’s Structure Diagram URL: Webapps Components Shared Logic-impl (business logic) Tool (presentation) Dao-impl (data access) Public-api (service) Logic-api (business logic) Dao-api (data access) Model Each coloured area in the structure diagram is actually a ClassLoader (type) Components were invented so that the lifetimes of services were more controllable Keeping only interfaces in Shared aids truly independent evolution of implementations Classes from “foreign” = “sibling” Classloaders simply cannot be resolved Although component INSTANCES all come from component ClassLoaders, they are held in a SINGLE Spring context at the shared level. Tools and Components alike contain “Child Spring Contexts” which have the shared context as a parent. Component1Component2

11 Some current component “issues” Hibernate is a really BAD ClassLoader citizen and will not cooperate with instances of itself in different ClassLoaders Also will NOT allow itself or any of its definitions to be reloaded Therefore Hibernate itself, along with any POJOs from the model, must be stored in Shared. Due to the current ComponentManager implementation, Spring itself is currently in shared. –Parent/child contexts are established by a slick “direct” connection that is just a bit “too” slick Therefore apps may NOT deploy their own versions of Spring or Hibernate, whether they agree in version or not (your instances of Spring interfaces will become unrecognizable and cause startup failure) All service references are bound directly to objects, no component may be reloaded

12 Another look at the diagram – Domain Objects in the Web Tier This arrow here is a subject of constant debates, e.g. on the “Spring Architecture Forum” Some consider the presence of “Domain Objects in the Web Tier” as the work of the Devil Note that “our” diagram is somewhat distorted by being *forced* to put Model in Shared for ClassLoader reasons – in some models, it would stay in “Components”. Webapps Components Shared Logic-impl (business logic) Tool (presentation) Dao-impl (data access) Public-api (service) Logic-api (business logic) Dao-api (data access) Model This is also related to the debate of “Rich Domain Model” vs “Anaemic Domain Model” (i.e. one with only state, no behaviour) A lot is determined by the sheer *width* of your domain model. Some are wide and flat, others narrow and deep. Personally I feel a lot of the antipathy to Model in View stems from unruly Web frameworks that can’t be trusted not to randomly trash the model (More on OTP later)

13 Questions?