OEM/ISV

eXo Products for OEM / ISV

Implementing low level specifications takes time and hence costs a lot of money. Maintenance and upgrades to new specification versions are other problems that come into play. All those issues force your developers to focus on low level code and commodities while they should spend more time adding value to your product. Therefore, by bundling eXo Platform products, OEM/ISV companies can focus more engineering resources on their product rather than building and maintaining a proprietary solution.

eXo Platform spent a lot of time and efforts building and testing two critical low level APIs (eXo JCR and eXo PC). Our main focus was to provide a clean Service Provider Interface (SPI) that you can easily extend to minimize the integration time and hence the overall time to market. We have made it easy to embed and re-brand eXo with your own brand label. Furthermore, we have teams fully dedicated to the maintenance and the development of new specification versions.

eXo Platform is available under an affordable and flexible license model that fits your business model. We can accommodate your licensing requirements regardless of your level of distribution helping you generate greater profit margin from your packaged application.

eXo Java Content Repository (JCR - JSR 170)

The main purpose of standardized Java Content Repository is to provide standardized, reliable intermediary layer between custom applications and data storage. The documents could be stored in a relational database or in a native XML DB but your client code would not change.

Advantages for application developers

  • Data repository and application are isolated to each other so application developer should not learn the details of particular data storage's interfaces and can concentrate on business logic of particular application built on top of JCR.
  • Repositories can be easily exchanged between different applications without changing the applications itself. This is the matter of repository configuration.
  • Data storage types/versions can be changed and moreover different types of data storage can be combined in one repository data model (of course the complexity and work of building interfaces between the repository and its data storage doesn't disappear but these changes are isolated in repository and thus manageable from the consumer point of view).

Advantages for managers

  • Using of standardized repository for content management reduces risk to be dependent of particular software vendor and proprietary API.
  • Costs for maintain and develop content repository based custom application is significantly lower than develop and support own interfaces and maintain own data repository applications (staff can be trained once, it is possible to take help from community and third party consultants).
  • hanks to flexible layered JCR API (see below) it is possible to fit legacy storage subsystem to new interfaces and decrease risks to loose data.

Extensions to the API exist as we can see in the following layer schema:

eXo Portlet Container (JSR 168/286)

The Portlet API is first and foremost an industry standard developed by the java software community (JCP). It stands for Java Specification Request 168 which enables interoperability among portlets and portals.
Before JSR 168 standard and JSR 286, applications couldn't be delivered through any portal immediately because portal vendors were using different proprietary portlet APIs. This created an unfavorable condition for corporate who wanted the flexibility to use portlet application from different vendors.

By using the JSR 168 industry standard API for creating portlets, eXo Portlet Container adhere to a standard that allows a smooth integration between applications. We are proud to have released one of the first JSR 168 certified implementation and so we did for Portlet API 2.0 (JSR 286).

Along with the Java standard, our Portlet Container also comes with an implementation of the Web Service for Remote Portlets (WSRP) specification from the OASIS consortium . That web services specification describes how portlets can be remotely accessed and how to consume them from a remote client. The current implementation is WSRP 2.0 and came along with the JSR 286 specification.