Most of the projects we have been doing at LodgON over the past few years
have “something” to do with users and content. From a technical point,
these projects typically require persistent storage, scalability,
transaction support and other technologies that are offered by Java
Enterprise Application Servers. Apart from these standard technologies, there
are a number of common functions that we encountered in many projects,
and that also require the basic technologies offered by the Java EE
specification. At LodgON, we created the DaliCore code that is built
on top of the Java Enterprise specification and that adds functionality
commonly encountered in projects related to end-users and (their) data.
About DaliCore
From a functional point, DaliCore is a logical extension of the Java Enterprise
specification. The Java EE specification defines the common infrastructure
needed for a wide range of enterprise applications. It does not
contain domain-specific specifications. This is what DaliCore aims to do
in the domain of social networking and user-generated content.
In a number of projects, one should be able to create user profiles, to
add content, to assign roles and permissions, to query, tag, search and manage
all the users and data. The DaliCore contains a set of REST handlers,
Session Beans and Persistence Entities to achieve this.
Stabilize a moving target
The story of DaliCore is probably not very different from software development
in a number of companies. While doing projects, developers try to reuse and
improve existing code. The fact that the code is continuously improved by
adding new features and removing old features, or by reorganizing some of the
concepts makes it difficult to package it as a “product”.
This also happened inside LodgON. Most of the projects we were doing required
more or less the same conceptual behavior, and lots of code was reused.
However, major changes in underlying technology and minor changes in concepts
caused the “reusable codebase” to be a moving target.
This has changed now. For most of the projects we worked on during the last
months, we used code from an internal repository called DaliCore. There are
a number of reasons why we were able to make the functionality more stable:
- We use Java EE 6. The Java EE 6 specification makes it much easier to
create, implement and use domain-specific tools. DaliCore is built on
top of Java EE. The easier Java EE, the easier to use DaliCore.
With the release of Java EE 6, a major step towards simplification has
been set. - We use Glassfish. The Jersey implementation in Glassfish allows an
easy REST-based client-server model that is fully interoperable with the
model of using Session Beans. Development for Glassfish using NetBeans is
easier than before. - DaliCore provides both a REST interface and an EJB approach. This allows
our own developers and third parties to either extend DaliCore by extending
the code or by importing the Jar in a project, as well as to use it as a
standalone WAR, and call the REST interface to use the functionality from
a project in any language that supports REST. - Maturity of the concepts. LodgON has been working on community projects
for more than 5 years. We see that the concepts are now more wide-spread
and accepted.
Open Source
We are in the process of making DaliCore open-source. We didn’t do this before, since the
concepts and functionality were changing rapidly. For third-party
developers, it is not very motivating if they have to change their
approach too often. But since we now feel confident about the concepts, we
don’t expect frequent major changes. That said, we are very open to
ideas and contributions from others.
Sometimes, code is made open-source in a final attempt to get it working.
This is absolutely not the case with DaliCore. We are using it in a number
of commercial projects that are very demanding, and really, it works great. We also
do not plan to reduce our own development resources on it, at the
contrary. Also, we are very aware that our end-customers do not want a
technical product, but an end-to-end functional project. Hence, the
added value is mainly in using DaliCore in projects, and build
some customer-specific functionality around it or on top of it.
Finally, I strongly believe in Open-Source Java projects. These are
exciting and turbulent times for Java developers. We all have our own,
personal likes and dislikes, but we all use Java. Being open about what
we use, why and how we use it, can only help other developers. Some
Open-Source projects are welcomed by lots of developers, others stay
small projects. And that is how it should be. Let the community decide.
I don’t claim DaliCore is the best code for every project. We use it
internally and are happy with it, but it is up to you to decide if and
how you want to use it.
We are working on making the code and documentation easily available.
For now, check out
http://lodgon.com/lodgon/DaliCore.html or mail me at johan (at) lodgon.com.
Johan's blog 