Developing Enterprise Web Applications with Cocoon and Spring
Ugo Cei, cocoon user since 1.7, committer since last year
What makes an application 'enterprise'?
- have to manage data (create update etc) by many users at the same time
What are the issues: think about concurrency, locking, cache, avoiding overwrites.
This presentation is not about a new version of Cocoon. Everything you will see can be done with cocoon 2.1.5 (current version)
Strengths of Cocoon * Promotes separation of concerns * SAX based pipelining * Powerful caching * Continuation based flow control * Powerful forms framework
CForms and Continuations are the most important aspect of Cocoon for making it the best WebApp development framework.
The Spring framework Enterprise application is typically multi-tiered. You have to deal with business logic and things like persistence. Cocoon is not inclusive, doesn't force you to choose one thing or the other. For instance for heavy applications you can use EJB, but it is falling out of fashion, because it is heavyweight and difficult to test. So the last developments are more lightweight containers like Spring, based on Inversion of Control and Dependency Injection
Aim of the new lightweight frameworks is to simplify development, by reducing what you have to write just to cope with the development framework.
Ugo will show how you can leverage the strength of the spring framework with Cocoon.
Spring features: * Setter and Constructor based Inversion of Control (Dependency Injection) * Decouple how a component is instantiated from the user of the component. * Nice layer of abstraction for JDBC. * Hibernate, OJB, JDO work within Spring. * Transaction management, difficult to do, so that it is scalable. Spring helps you with this.
* Aspect oriented programming, abstract away cross-cutting concerns in your application (own framework, can use AspectJ and AspectWerkz * MVC Framework * Lots more... (EJB, JMS, Mail etc.)
Spring provides you with a whole stack of enterprise services
Spring aims: * simplicity * modularity - include only the parts you use * extensibility - add your own stuff * non invasive framework. Components do not have dependancy on the framework itself. No implementing of interfaces or lookup service to locate other components. So the code remains portable to other frameworks. This is not possible with EJB or Avalon * Testibility - you can test your components separately from the framework. For instance, Unit testing for EJB is impossible. * Promotes best practices * In practice: a simpler way of developing J2EE applications without EJB * Does not add stuff that is commonly available (Logging, Pooling or Object Relational Mapping etc.). But spring makes it easier to use those libraries.
Architectural Components * Database layer: e.g. JDBC * Persistence layer: e.g. Hibernate, JDO,... * Data access objects: decouple business logic from specific Persistence * Service layer: simple access point to your functionality * Controller: well implemented by Cocoon's flowscript * View layer: Cocoon's template languages
Patterns of Enterprise Architecture is a book by Martin Fowler, Gang Of Four type book for Enterprise Applications Ugo will show how you can implement these in Cocoon
Decides which domain logic to run and with which view to display the response Cocoon flowscript ideal for this job.
Two step view
Multi channel presentation layer. Split act of getting data, present it as xml format and then transform to a specific view.
First step: Cocoon generator turns domain model into XML Second step: transformers.
Cache in front or inside Cocoon to avoid to repeat database queries on data that haven't been changed.
Single entry point to many business logic domains. Using spring, it's recommended to implement a service layer to centralize resource and transaction management.
Data Access Objects
Decouple business logic from persistence mechanism
Define abstract interface, then Spring will be used to define which implementor of that interface is called at runtime.
== Declarative Transaction Management Example of service layer in spring * Define the service (xml configuration file) * wrap an AOP proxy around it * AOP will automatically execute the calls in the context of a transaction * Service layer is a convenient place for transaction boundaries
Complex web, hierarchy of connected objects. Hard to represent in EJB. So it's better to implement in POJO's, in combination with a O/R mapper. This can be a valid alternative to EJB
Never use raw JDBC directly
* it's verbose (try/catch/finally...) * it's difficult * Not fully portable ** Proprietary codes in exceptions ** Blob handling ** Stored procedures... ** Proprietary SQL
Object Relational mapping
Any persistence layer should give you lazy loading. The object knows how to load the dependent loading on demand. Hibernate does this via proxies. Problem: lazy loading overlaps with transactions/database sessions Solution: Open Session in View Filter. Close connection after view has been rendered. A few simple lines to add to web.xml. Once again: without writing code
==Serialized Large Objects == Very easy with cocoon forms and persistence layer
Hibernate detects conflicts by automatic versioning
Ugo shows some hibernate configuration example. Again: no hardcoded details, just xml configuration
accessing Spring application context
* ContextLoaderListener configured in web.xml. Attaches spring container to current Cocoon servlet. * read spring application context from flowscript * There is no step 3
Why use cocoon/spring instead of more traditional solutions? Because you have flowscript and forms, and no one else has that.
Why spring with cocoon instead of avalon? Spring is geared towards developing enterprise applications.
Spring petstore cocoon block: http://new.cocoondev.org/main/g1/43 Online since yesterday.