DaliCore, user-generated content on top of Java EE
DaliCore, user-generated content on top of Java EE
Join the DZone community and get the full member experience.Join For Free
Java-based (JDBC) data connectivity to SaaS, NoSQL, and Big Data. Download Now.
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.
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.
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.
Opinions expressed by DZone contributors are their own.