Disruptive Library Technology Jester » spring framework

Open Repositories 2011 Report: DSpace on Spring and DuraSpace

Peter Murray — Wed, 08 Jun 2011 13:50:36 +0000

This week I am attending the Open Repositories conference in Austin, Texas, and yesterday was the second preconference day (and the first day I was in Austin). Coming in as I did I only had time to attend two preconference sessions: one on the integration — or maybe “invasion” of the Spring Framework — into DSpace and one on the introduction of the DuraCloud service and code.

DSpace and the Spring Framework

The Spring-Framework-in-DSpace was presented by Mark Diggory of @MIRE. He spoke from a DuraSpace wiki page set up as a tutorial on the topic. In the first part of his presentation he introduced the inversion-of-control pattern, explaining why it is useful and showing how it works with simple code examples. He then showed how a Spring-based ServiceManager can be integrated into the DSpace main code and then how new services can be plugged into that manager.

I came into the session more familiar with the Spring Framework than with the DSpace code, so I found the session to be a good introduction to some of the DSpace concepts even though I wasn’t the target audience. (I imagine the target audience was someone familiar with the DSpace code wanting to learn about the Spring Framework.) Thanks, Mark, for putting up the web tutorial and walking through it during the preconference session.

DuraCloud Introduction

The second preconference I went to was on the introduction of DuraCloud services from DuraSpace. I can honestly say that I didn’t get what DuraCloud was supposed to be before, but seeing the about-to-be-released web interface I can say I think I finally get it. DuraCloud is going to be both open source software and a service from DuraSpace that can back up a repository with storage, media access services, and compute/transformation services.

The session showed the web-based administration interface and the supporting tools for integrating a DSpace repository and a Fedora repository into DuraCloud. Attendees were also given access to a command-line Java application that could be used to upload content into a DuraCloud instance, although sadly it wasn’t demonstrated during the preconference session. (Perhaps I’ll try it out on the sly later with the DuraCloud credentials they gave us at the session…) In addition to the functinality being built into DSpace and Fedora there will be REST-based code libraries for Java, PHP and Python — meaning that any developer could write code to make use of DuraCloud with any repository platform. The whole DuraCloud application is going to be released into open source under the Apache 2.0 license as part of the efforts to create a community using the code and encourage others to write new services for DuraCloud. This is something I’m going to keep watching; I’ve already signed up for a preview account for when the beta is released later this month.

Thanks also to DuraSpace for sponsoring the evening reception after the preconfernce session at the University of Texas Club.

Picking a Java Web Application Framework

Peter Murray — Wed, 25 Oct 2006 15:16:21 +0000

We’re beginning a new phase of our digital library development at OhioLINK and an oversimplification of one of the consequences of this new phase is that we will be developing more software from scratch rather than adapting stuff that we find out there on the net. (Another consequence of this new phase is our interest in applying the Service-Oriented Architecture paradigm to library applications.) In previous phases, we were somewhat at the mercy of whatever development framework was used in the application we were adopting. As we start this new development where we control more of our own destiny, we wanted to take a step back and look at the available frameworks to support our development efforts. The options we identified at the start were plain Java servlets, Apache Struts, Spring Framework, and EJB3 with JBoss SEAM.

Our analysis is admittedly by proxy rather than through direct experience. If we had more time, we would start our new phase in each one of these (with the associated learning curve for some of them) and pick the one that worked out the best. We have neither the luxury of time nor of excess developer talent, so we looked at what others were saying, created some sample applications, and discussed our gut reactions to each option. In the end, we decided to start with EJB3/SEAM.

Summary of Options

Over the years, the Java community has developed frameworks to support the creation of applications in the Java programming language. These frameworks consist of a combination of code libraries, programming rules, and best practices that have evolved based on the research and experience of the developer community. Just as almost no one designs, codes, debugs, and documents their own low-level file I/O libraries any more, these frameworks provide a level of abstraction over the raw programming language that enables developers to create better code faster.

Within the web application arena, arguably the earliest successful framework was Apache Struts. It was one of the first frameworks to promote a Model-View-Controller (MVC) architecture: the Model represents the business or database code, the View represents the page design code, and the Controller represents the navigational code. By creating these three layers, Struts promoted a practice of design and development away from commingling database code, page design code, and control flow code in the same JavaServer Pages files. In practice it was found that unless these three concerns are separated, larger applications become difficult to maintain.

The latest revolution in design architectures is Dependency Injection (DI). Sometimes also referred to as Inversion of Control (or IoC), it is a programming design pattern and architectural model in which the responsibility for object creation and object linking is removed from the code of the objects themselves. As the term “Dependency Injection” may imply, it is the framework that instantiates the component objects and binds them to each other through the use of setters and/or constructors rather than the components linking themselves together. In this pattern, the objects themselves become loosely coupled, allowing for a more dynamic and testable integration of the component objects. The creation and binding of objects is defined in an XML configuration file (Spring Framework) or via Java Annotations (EJB3).

Two primary frameworks have emerged for the Dependency Injection paradigm: Spring Framework and EJB3. The Spring Framework is the grandparent of subsequent IoC efforts (including EJB3). A de facto standard, it is widely used in the Java programming community with a large number of tools and documentation. EJB3 is a formal specification adopted by participants in the Java Community Process for standardizing Java-related developments. Coupled with the JBoss SEAM framework, the EJB3/SEAM combination is roughly on par with raw technical capabilities of the Spring Framework. SEAM removes some of the complexity of raw EJB3 by providing and preconfiguring popular choices for views (JSF) and models (Hibernate) as well as integrated AJAX-based Remoting and jPBM. Both promote the same MVC architecture as Struts.

The distinguishing characteristics are that Spring acts as an open integration tool at the expense of a complicated XML-based configuration process whereas EJB3/SEAM is simpler in its configuration and more restrictive in what other tools can be easily brought into the framework. In other words, Spring has a wide array of choices for the various framework components and for the most part the developer must manage the integration; EJB3/SEAM lessens the complexity of the framework by limiting the choices available for the various components to only the most popular options. Note that there is overlap between Spring and EJB3; the Pitchfork project allows for JSR-250 (Common Annotations) dependency injection and EJB 3.0 style interception as an add-on to the Spring framework. One should also note that a full EJB3 implementation is a kind of superset to SEAM, and if the needs of our applications go beyond that of SEAM it is possible to reduce our dependency on the SEAM framework by beginning to integrate other choices (and managing that integration ourselves).

OhioLINK staff would have a learning curve associated with both Spring and EJB3/SEAM (and Apache Struts as well, although it has been discounted as an option as a mostly dead-end architecture at this point). On the question of whether the learning curve is greater than the effort of doing things the “plain Java” way, one can point to the large number of developers who have made the leap to these frameworks and are arguably more productive for doing so. Since we are beginning the development of a new code base, it seems to be the ideal time to start up that learning curve with the creation and deployment of a new service. The learning curve might be easier for Spring than for EJB3/SEAM due to the wide variety of materials already produced for Spring, although the corporate backers of EJB3/SEAM seem to be filling this gap at a steady pace. The learning curve for EJB3/SEAM may be shallower, though, because SEAM simplifies the configuration of the framework itself.

At our development team meeting yesterday, we decided that OhioLINK will adopt a Dependency Injection (DI) paradigm over use of Apache Struts and plain Java servlets because of the anticipated large productivity gains after the learning curve. Of the two DI/IoP frameworks widely available now, we decided to adopt EJB3 coupled with JBoss SEAM. The standards-driven nature of EJB3 reduces the risk of adopting a technology that may not be supported in the medium-term. It is expected that JBoss SEAM will flatten the learning curve to make EJB3 more readily understood in the short term while providing a migration path to a broader EJB3 implementation (beyond the capabilities of SEAM) if needed in the future. The Spring Framework, to its credit, also makes it possible to envelop EJB3 objects as part of a Spring-based application, which could smooth the transition to that framework should it become necessary. We also understand that there is some risk of “vendor lock-in” by relying on JBoss SEAM — in our limited experience, applications seemed to deploy better under JBoss Application Server as opposed to a stock Apache Tomcat 5.5 installation. On the other hand (if the “standards” nature of EJB3 is to be trusted), it should be possible to move our code to other application servers, leaving SEAM behind, with minimal changes. We may also be able to further flatten the learning curve by buying a support contract with JBoss in the short- to medium-term.

Details about the Candidates

Enterprise Java Beans 3 (EJB3)

The EJB 3.0 framework is a standard framework defined by the Java Community Process (JCP) and supported by all major J2EE vendors. [The architecture of the Spring framework is based upon the Dependency Injection (DI) design pattern.] Open source and commercial implementations of EJB 3.0 specifications are already available from JBoss and Oracle. EJB 3.0 makes heavy use of Java annotations.

Based on standards work (the Java Community Process)
“Configuration by default” using Java Annotations backed by more complicated XML configuration files, if needed
A more compact, rigidly-defined framework stack; easier configuration, but fewer choices
Brand new (recently ratified); fewer tools, books, tutorials available

JBoss SEAM

JBoss Seam is a powerful new application framework to build next generation Web 2.0 applications by unifying and integrating popular service oriented architecture (SOA) technologies like AJAX, Java Server Faces (JSF), Enterprise Java Beans (EJB3), Java Portlets and Business Process Management (BPM) and workflow.
Seam has been designed from the ground up to eliminate complexity at the architecture and the API level. It enables developers to assemble complex web applications with simple annotated Plain Old Java Objects (POJOs), componentized UI widgets and very little XML. The simplicity of Seam 1.0 will enable easy integration with the JBoss Enterprise Service Bus (ESB) and Java Business Integration (JBI) in the future.

Based on EJB3
Integrates together some of the most widely adopted components such as JavaServer Faces and Hibernate
Can reportedly be used outside of JBoss Application Server (direct experience show some problems with this)

Spring Framework

The Spring framework is a popular but non-standard open source framework. It is primarily developed by and controlled by Interface21 Inc. The architecture of the Spring framework is based upon the Dependency Injection (DI) design pattern. Spring can work standalone or with existing application servers and makes heavy use of XML configuration files.

Explicit configuration via XML file
More flexible than EJB3/SEAM in swapping in and out various modules; yet the decisions made early on limit the ability to swap in and out later.
Several years old; widely available tools, books, tutorials
De facto standard of an open source community with benevolent control by a corporate entity.

Apache Struts

Apache Struts is a free open-source framework for creating Java web applications.

(Summary opinion) Generally seen as a deprecated framework; few new projects start with Struts.
Weak integration of new techniques such as AJAX.

Plain Java Servlet (No Framework)

Must build the entire application support layer (object data storage, presentation interfaces, helper functions, etc. from scratch).
No ready-made integration of new techniques such as AJAX.

Background Information

The text was modified to remove a link to http://seam.demo.jboss.com/ on January 13th, 2011.

The text was modified to update a link from http://interface21.com/pitchfork/pitchfork-faq.html to http://www.springsource.com/products/pitchfork/pitchfork-faq on January 19th, 2011.

Access Management and Provisioning Technology

Peter Murray — Tue, 18 Jul 2006 19:21:41 +0000

Building on the shoulders of others — isn’t that how that quote goes? There has been a stack of printouts on my desk for a while now for various access management and service provisioning technologies. Rather than keep the paper, I’m putting the list here so I know how to get back to them if/when I need to. (Of course, along the way if you’d like to comment on them or suggest others to look at, please feel free to do so in the comments.) Note, too, that by listing them here I’m not proposing, or even sure if, all of these pieces come together to a coherent structure.

Grouper — Internet2 Middleware

“Grouper is an open source toolkit for managing groups. It is designed to function as the core element of a common infrastructure for managing group information across integrated applications and repositories. Grouper combines multiple sources of group information, both automated and manual, in managing memberships and other group information in a Group Registry, a central information asset complementary to a site’s Person Registry. Grouper manages two primary types of objects: groups and namespaces. Groups are created and named within a namespace. Group management authority can be limited ”

Now at version 0.9, Grouper is part of a suite of tools from the NSF Middleware Initiative (NMI) that supports “development, testing, and dissemination of architectures, software, and practices in the areas of identity and access management.”

Signet – Internet2 Middleware

“Core middleware services such as identity management, directory, and authentication provide a foundation for secure, manageable applications throughout an institution. Even with this foundation, as systems and applications proliferate it becomes more and more difficult to manage user access consistently and cost-effectively. [The Signet] privilege management service is a relatively new component of campus middleware that addresses this problem by providing centralized management of user privileges across a range of applications. The benefits of this service include: a standard user interface for privilege administrators; consistent, simplified policy definition, via roles and integration with core campus organizational data; improved visibility, understandability, and auditability of privilege information; and standard interfaces to other infrastructure services and to application systems to support integration.”

Now at version 1.01, released 29-Mar-2006. Could this kind of provisioning service be used to generate XACML files to drive FEDORA?

OASIS eXtensible Access Control Markup Language (XACML)

“XACML is expected to address fine grained control of authorized activities, the effect of characteristics of the access requestor, the protocol over which the request is made, authorization based on classes of activities, and content introspection (i.e. authorization based on both the requestor and potentially attribute values within the target where the values of the attributes may not be known to the policy writer). XACML is also expected to suggest a policy authorization model to guide implementers of the authorization mechanism.”

Sun’s XACML Implementation (available at Sourceforge) is the access management engine embedded into the FEDORA repository.

Acegi Security System for Spring

“Acegi Security is a powerful, flexible security solution for enterprise software, with a particular emphasis on applications that use Spring. Using Acegi Security provides your applications with comprehensive authentication, authorization, instance-based access control, channel security and human user detection capabilities.”

Release 1.0.0 came out in May 2006 after nearly two years of development.