The eXo Platform branch in Tunis is growing fast with new eXo collaborators. In the last two weeks, we organized an internal training for our new comers with Patrice, PM of eXo CS and KS and Nicolas PM of eXo ECM. They had the opportunity to discuss with their tunisian collegues and to discover the new eXo MEA office based in Tunisia.
eXo Platform MEA is still looking for talented people, we are hiring computer science engineers and also business development/sales managers. Don’t hesitate to contact us.
Deploying portlets by the UI… Humm, my first reaction was:
“Yeah this is cool! But what is the real enterprise use case for this?”. It is probably a very nice feature for demonstration during a pre-sale meeting, but do you think the sysadmin wake up one day and decide to
deploy a portlet in production?
Personally, i don’t think so.
Since we are talking about “Enterprise Portal“, the deployment of new portlet should be integrated to the deployment model used by sysadmin. This could be done by the administration console of the application
server, administration scripts, … Portals should not reinvent the wheel here, and simply leverage the standards (JSR88 for example) and best practices already in place. Why? take a simple example: what about the deployment of a new portlet in a cluster environment? App server do manage that. When testing and developing you can easily use the hot deployment that most of the application server support. (no need to go to the portal to deploy a new version of the portlet.)
We have some features for the upcoming release of portal 2.6 to make more easy to develop, mashup and publish application directly on the server by the portal UI. We will provide an interface to write gadgets and webservices directly from the portal thanks to WS 2.0, groovy and gadgets.
Portlets are made for developing complete and rich business applications, this is what we do for our Collaboration Suite, ECM, and others.
Gadgets + WS will be for creating more lightweight application for a dashboard, creating quickly and easily small applications. (that could leverage services provided by business applications. For such tools, where do create composite application with gadgets you want to be able to have a very simple lifecycle management this is why at eXo you can easily write services and gadgets directly from your Portal.
JCR based WSRP persistence service allows avoid using old JDBC based one, so almost all eXo services uses eXo JCR as back storage building full eXo components stack (from storage to UI)
WSRP administration interface allowing remote management of the WSRP service configuration
Improved Administration portlet allowing simply administer remote portlets including such advanced features as: choosing producer version, “temporary” producer creation, detailed information about registered producers and portlets and other
Besides of specification implementation current eXo JCR includes a lot of content management oriented extensions and frameworks on top of JCR, including:
JCR tooling and ability extension such as backup/restore, replication services
JCR Session event – driven framework allowing dispatches and fires an event upon each transient session level changes and many services built on top of it such as Audit, Security, Metadat extensions and others
JCR network protocol specific frameworks such as RMI, WebDAV, CIFS(SMB), FTP servers over JCR
JCR application framework helping building reliable, good designing JCR backed-end applications
Benchmark framework for simplify programming use cases for performance, stress testing in multi-thread, heavy loaded regimes
J2EE JCR connectors
Other platform scoped content oriented services (Groovy, Organization, Registry services and others)
The main features offered by JCR 1.11 including:
First release of Asynchronous Replication service, which allows collect changes made by several disconnected nodes of JCR cluster and schedule its connection and synchronization. In the other words it allows independent “off-line” modification of several Java content repositories and synchronize theirs state (make them store identical data) once a day/week etc or just calling synchronization manually when needed. Unlike Synchronous Replication (which is also supported in eXo JCR) it does not require peermanent opened connection between nodes.
eXo JCR 1.11 implements such a cool feature offered by JCR 2.0 (with our proprietary extension) as JCR Node Types and Namespaces altering. Indeed, before even small storage structure changing, for example moving to new version of JCR based application causes big head ache, a lot of time and developers involvement, thats why such a features have to be appreciated by administrators and application developers.
Starting from version 1.11 eXo JCR dependent REST resources, including WebDAV service, which is build on REST dependend on WS 2.0 which mean that all of them conform JAX-RS JSR-311 specification
Besides those big features eXo JCR 1.11 includes improvements of Amazon’s Simple DB based data container (offered in JCR 1.10), improvements of External Values storage (transaction fail-over), JCR based Organization service performance improvements, Ingres database support and others
In eXo DMS (Document Management System), users manage content through an application called ”JCR File Explorer”. This one allows to create, retrieve, update or delete content. Until now, it forced users to initially select a drive. A drive can be considered as a logical unit of storage (for example: live documents, user private documents, workgroup documents) :
Choosing a drive in JCR File Explorer
This selection step was not really convenient and we thought there was matter to improve productivity.
So JCR File Explorer will optionnally allow bypassing this drive selection and immediately let the users access the drive matching the context of their work.
in the “spaces” use case, the JCR File Explorer will directly access the drive containing content shared by the community he’s connected to (this use case is compatible with the eXo Spaces module),
in the “jailed” use case, the administrator will reference a unique drive or document from the application preferences. This can be considered as a Unix “chroot”,
in the “parameterized” use case, the application fetches some location information from the portal page URL. Then it will directly access that specified location in the storage (can be a folder or a document). This use case is handy to allow linking the JCR File Explorer from external applications. A typical example is a Google gadget listing the last 5 modified documents. When clicking, the user is redirected to eXo Portal and directly accesses the document in its context.
Of couse, in all cases, security checks are performed to ensure the current user is granted to access the target location.
Developments should be ready when eXo DMS 2.3 is released (middle of march).