eXo is coming to Italy! We’ll be presenting at the Red Hat Symposium Open Source Day in Rome, 14-June 2011. I will be traveling from our office in Tunis, and look forward to meeting people from the Italian open source community. I hope you’ll stop by the booth to say hello!
Is this for me? Who should join this event, besides those wanting to enjoy some great Italian food?
Developers looking for the next big thing in the Open Source world
CTO’s and heads of IT who want to know about the latest tools for improving efficiency and reactivity
Entrepreneurs and business leaders who are building modern companies, where teams collaborate, coordinate and communicate with the best of Web 2.0 technologies
Systems integrators looking for the “killer portal” – a fully-integrated, cloud- and mobile-ready portal with built-in CMS, social and collaboration features – which will suit you customers’ needs and will make the difference compared to the competition
“Not-so-technical guys” looking for a simple user-friendly platform to help you organise your work routine and your team interactions
If any of the above sounds familiar, then you should definitely stop by our booth (or attend our session) to learn about eXo Platform 3!
Ok I’m sold – now when and where is this amazing event?
Yesterday Red Hat introduced their new Platform-as-a-Service (PaaS) offering, called OpenShift, which will be offered in Express, Flex and Power modes. As Benjamin described in his blog about OpenShift, our partnership with Red Hat is expanding is expanding in support of this. Developers can use eXo Cloud IDE to quickly build applications that can be deployed to the OpenShift PaaS; this native integration is made possible due to both solutions supporting Git.
eXo Cloud IDE can plug into the OpenShift platform as a cartridge. But that isn’t the only way eXo technology runs with Red Hat cloud offerings. We’ve also been working on bringing our flagship enterprise product, eXo Platform 3, to take full advantage of deploying to a PaaS.
The first step is to port eXo Platform 3 for JBoss EPP Site Publisher to OpenShift Flex, so our mutual customers can quickly onramp to the new OpenShift offering. (As you already know, Site Publisher is powered by eXo and brings WCM capabilities to the JBoss portal; eXo Platform 3 for EPP Site Publisher allows Red Hat customers to extend their portal-based solutions with user experience features like social, collaboration and content management.)
As they have for the last two years, our friends at Red Hat have been completely supportive, assisting our own engineering teams with getting eXo Platform deployed on OpenShift even before it was announced publicly. I’m now happy to report that eXo Platform 3 for EPP Site Publisher can be deployed in the cloud as a Flex-managed cartridge.
It’s still a work in progress, but the core features like logs and performance monitoring are already there, as you can see in the following screenshots:
Red Hat and eXo teams are currently working together so eXo Platform can leverage the full scaling capabilities of Flex. And since customizing eXo Platform in your personalized portal server involves deploying so-called extensions as EAR archives, this capability will be possible directly through the Flex UI.
We’re really excited to be one of the first to deploy to the OpenShift PaaS, and know our customers will be eager to try it too. We’ll keep our community updated on new developments, but in the meantime, if you’d like to see a demo, drop us a line at info (at) exoplatform.com.
Almost two years ago we announced our partnership with Red Hat, with the goal of building the best open source portal framework ever: GateIn. Today we announced that we’re extending this partnership by offering an easy way to develop apps for OpenShift, Red Hat’s new Platform-as-a-Service offering. Before I dive into the details of how eXo Cloud IDE will work with OpenShift, I’ll quickly recap what we’ve done with Red Hat to date.
To put it simply, GateIn is the foundation for both eXo and Red Hat enterprise offerings. For Red Hat, this product is JBoss Enterprise Portal Platform 5 (EPP). We also use it as the core runtime for our own user experience platform, eXo Platform 3. Here’s a simple visual of this:
Our partnership reached another important milestone at the end of 2010, when Red Hat announced Site Publisher, an extension for EPP that is powered by eXo’s WCM technology. With EPP-SP, Red Hat customers can create and manage websites on top of the EPP portal.
Site Publisher is ideal for building sites that need to mix content and transactional applications that integrate well with customer’s IT environment. In many cases these are customer-facing portals, which are typically strategic projects for our common customers.
The natural next step was introducing eXo Platform 3.0 for EPP-SP. This adds a large set of user experience features like document management, workflow, communication and collaboration tools, to enterprise social networks. It also includes the same IDE as our now-famous eXo Cloud IDE. This is the full stack:
We recommend this complete stack to customers already using Red Hat technology, since everything has been tested and certified together, from the JBoss EAP application server to the RHEL Operating System!
I’m excited to share that today we are again expanding our collaboration with Red Hat, going beyond portals to the Cloud.
Red Hat’s OpenShift PaaS announcement sends a strong message that the company is serious about becoming a leader in the PaaS market. They have the vision and already a great partner ecosystem. I’m really excited that eXo can be one of the first to integrate with this new public Cloud offering.
Earlier this year, we announced our own cloud strategy. Part of this will be offering several free online services for PaaS developers. eXo Cloud IDE, which is already available, is an online development environment (IDE) that developers can use to create applications in the cloud (collaborating with up to 5 other developers in their dedicated domain), then deploy to the PaaS of their choice.
Today, we announce the native integration of eXo Cloud IDE and Red Hat OpenShift. A developer in eXo Cloud IDE can create a Ruby application and easily deploy it to OpenShift.
The integration is made possible by Git, which is now supported by both the eXo Cloud IDE and OpenShift. A simple push of the application source code from the IDE will trigger the automatic (re)deployment of the application in the PaaS. This push action can be used both during the development phase as a “test as you code” tool (where you need a quick visual result on your changes) and to do production deployment.
Working with the cloud team at Red Hat has been a really rewarding experience, just as it has been collaborating with the JBoss team around GateIn. The people are open, talented and hard-working, and seem to genuinely care about their partners. I look forward to collaborating around OpenShift, and to seeing what other great things our partnership will bring in the future.
The core Java Content Repository functionality that we leverage in both GateIn and eXo Platform 3 is eXo JCR (developed in JBoss.org, the JBoss open source forge). We have made many improvements and introduced new features in our upcoming version of eXo JCR (eXo JCR 1.14.0-CR1). The following post provides a technical deep-dive into some of these changes.
New Features
JBoss Infinispan
The most significant of the new features found in eXo JCR 1.14 is the ability to rely on Infinispan as the underlying cache; this provides a more scalable clustering solution. For now, we only used and tested Infinispan (also known as ISPN) as an alternative to JBoss Cache (also known as JBC, which you can still use if you prefer). In other words, Infinispan is only used as a simple replicated cache, which is still interesting in terms of memory footprint and concurrency.
According to our first internal tests, ISPN seems to consume less memory than JBC; more importantly, ISPN clearly reduces the contention compared to JBC. With JBC, you can face contention issues especially when you use any eviction algorithm other than expiration, since any read access to a JBC Node will add an eviction event to the LinkedBlockingQueue instance of the whole region. In ISPN, they had the brilliant idea to implement their own version of ConcurrentHashMap, which they call BoundedConcurrentHashMap, to manage the eviction within each segment. This means that we now have one LinkedBlockingQueue instance per segment, so you can reduce the contention generated by the eviction algorithm by simply increasing the concurrency level.
Another significant improvement ISPN offers is the remove method. In our internal tests we realized that in some use cases, it could be over 800 times faster to remove a cache entry in ISPN compared to JBC. This is mainly due to the notion of Node trees in JBC that is not found in ISPN. Actually, when you remove a node in JBC, it needs to remove all its descendants – which consumes a lot of time and CPU when you have a lot of children nodes.
Next we will try to improve our ISPN integration, to fully benefit on the distributed cache capabilities offered by ISPN. In real-life scenarios, it is difficult to ask a customer to deploy their application on hundreds of instances of a given application server, since the required licenses and support would be cost-prohibitive (not to mention a nightmare for the administrator). On the other hand, it sounds more acceptable if the customer only needs to deploy their application on 3-8 app server instances; these would be used as frontal servers, while hundreds of ISPN cache instances could be deployed in standalone mode to act as the cache server. This would allow ISPN to be used as a cache server, although in our context this is not possible out of the box (due to a lack of JTA support when ISPN is used as cache server – more details here).
Java Security
As you may know, our new eXo Cloud IDE is a free developer service for Java Platform as a Service (PaaS). This ability to easily create and deploy REST components on the fly is very interesting in terms of productivity. However, it needs to be over-protected to ensure that no malicious users affect the integrity of your environment. So we made the entire eXo JCR stack rely on Java Security, meaning that when the SecurityManager is installed, access to sensitive methods is impossible unless the full call stack has enough rights.
Apache Tika
eXo JCR already has a plugin-based framework that enables the extraction of both the meta-data and the full text content of the most common document types, such as Text, XML, HTML, PDF, MS Office and Open Office documents. But we wanted to support many more types of documents, so we decided to implement a plugin for Tika. This is actually an open door to many new document types, including images, audio and video.
Other Interesting New Features…
If you dedicate a listener for a specific event broadcast by the ListenerService, you can elect to receive the event asynchronously by adding the annotation @Asynchronous (from the package org.exoplatform.services.listener) to the class declaration level of your listener.
eXo JCR can be deployed on Jetty.
H2 DB is now supported.
Improvements
JCR Re-Indexing
With full text search engines such as Lucene, it is helpful to rebuild them regularly to preserve consistency, get rid of potentially corrupted indexes, and ensure optimal performance. We decided to speed up the re-indexing mechanism by making it multi-threaded, and by relying more on features specific to RDBMS, such as SQL paging. The results are quite interesting: according to the total amount of core and the db type used, the indexing of millions of JCR nodes could be 4 to 6 times faster.
Lucene Indexing in Clustered Environments
In the previous version of eXo JCR, we stored the Lucene indexes in a shared file system, so it was possible to add a node to the cluster dynamically (meaning the new node could access the Lucene indexes directly, so they could be started and made available quickly). The problem with this approach was that the performances in read and write accesses were affected, and that using a shared file system could have side effects. In addition, only the main cluster node (a.k.a. coordinator in JGroups terminology) could see the latest changes. This is because, for performance reasons, they are only persisted after a certain amount of time, while the rest of the cluster could only see the persisted changes.
To improve this, we took a new approach. Each node can see all changes in near-real time, and has its own version of Lucene indexes. This improves performance and means we no longer rely on a shared file system. This change is possible because we were able to improve the index recovery. Now, when a new node is launched that doesn’t have its own version of Lucene Indexes, you can either decide to rebuild them from a configuration (if the DB is not too big, knowing the re-indexing has been improved too) or get it from the coordinator. The latter method allows you to get a new node up and running in a reasonable amount of time, and fully benefit from having the Lucene indexes locally.
The next step will be to implement a non-blocking index recovery in order to have the new cluster node ready to use even faster.
Backup/Restore
The backup/restore feature has been completely reviewed to better fulfill the requirement of an enterprise; it is now faster, more reliable and much easier to use.
Other Interesting Improvements
An application with a lot of workspaces requires a lot of JBC instances (3 per workspace: JCR Cache, JCR Indexing and JCR Lock). To reduce the total amount of JBC instances, you can configure your JCR to make your cache instances shareable – meaning you only need 3 JBC instances, and they can be used by all your workspaces. With this configuration, your JCR will create a dedicated JBC region per workspace instead of launching a new JBC instance.
The way missing values are cached is optimized for applications that require frequent testing of the existence of specific nodes or properties. If the searched-for node or property does not exist, the information indicating that the data is missing in the DB is stored in the cache, instead of accessing the database at each call. Because future re-tests will find this information in the cache instead of having to query the DB, your application will be faster and more scalable.
All cluster nodes can now be launched in parallel, even when the JCR has never been initialized. This was a limitation in the previous version, since the JCR had to be initialized first.
Download
You can download eXo JCR 1.14.0-CR1 from here and get the documentation from jboss.org here.
You can test it with jetty or tomcat; for both be sure to read the file exo-readme.txt to know how to test it with the default configuration, JBoss Cache or Infinispan. In a nutshell, you simply need to launch it from eXo batches with a new parameter: jbc for JBoss Cache and ispn for Infinispan.
For those of you who are attending the JBoss User & Developers Conference (JUDCon) in Berlin next week, be sure to check out Julien Viet’s session. Julien, who serves as the project manager (from the eXo side) for GateIn, will be giving a talk on Day 2 of the conference, 8 October, at 14:30 in the Workflow and BPM track. He’ll be introducing Chromattic, an open source project that provides GateIn with a JCR persistence layer for rapid development of content-based apps. Here’s the complete abstract:
The GateIn Portal comes with a built in Java Content Repository server for managing pages, layouts and portlets. The Chromattic open source project was initiated to develop the GateIn object model persistence in a JCR server. Beyond natively powering the heart of GateIn, Chromattic can be used to rapidly develop rich and complex JCR based applications.
Chromattic is an object mapper framework that uses JCR as persistence layer. It provides a natural support for various JCR features, thanks to the usage of Java Annotations. Annotations declare which and how classes are mapped to nodes, turning any repository node into a Java object. It provides important features to JCR development such as type safety and object orientation which are lacking when the JCR native interfaces are used. Moderns IDE most used features like code completion and refactoring are de facto available when developing Chromattic applications.
The key concepts of Chromattic will be presented, through the development of a simple Chromattic application in real-time. This sample application will be made available to the attendees so they can use the sample code as a starting point. This advanced technical session will show:
How to integrate Chromattic with a modern IDE using a Maven-based build
How to deploy a Chromattic application in GateIn
How to connect to and manage a repository server
In addition, several advanced features of Chromattic will be highlighted, to demonstrate the power of the framework.