Posts tagged "OSGi"

How to have changes to bundles recognized and applied during development?

CQ and Sling have watches folders with the name of “install.” Among other things, these folder are watched for *.jar files for bundles being added or changed. These bundles will automatically will be loaded or reloaded in the Felix OSGi framework as needed. Note the emphasis on the phrase, as needed. Just changing a bundle within the CQ repository does not guarantee that your bundle will be reloaded. While developing bundles, it is important to know how CQ/Sling determines that a bundle needs to be loaded or reloaded in Felix after it is changed in the repository. Bundles will be loaded/reloaded after a bundle jar has been added or update when:

  1. The bundle does not already exist in the OSGi framework
  2. The bundle version is different and more recent
  3. The bundle version has “-SNAPSHOT” at the end

It is worth noting that it is good practice to use the “-SNAPSHOT” version for bundles that are in development and are not in their final version. One way the naming convention help is that it keeps from having problems telling which bundle build to use to deploy versus builds used in development. No “-SNAPSHOT” at the end, this is the final version. “-SNAPSHOT” at the end, the developer hasn’t finished it yet and it will change.

Here are some example of how this will work for a bundle called, my-bundle::

Existing: my-bundle-1.0.0
Added to repository: my-bundle-1.0.0
Result: Felix will NOT reinstall the bundle. It is assumed that this is the exact same version of the bundle of a released bundle

Existing: my-bundle-1.0.0
Added to repository: my-bundle-1.0.1
Result: Felix WILL install the bundle with the later version of the bundle added to the repository

Existing: my-bundle-1.0.0-SNAPSHOT
Added to repository: my-bundle-1.0.0-SNAPSHOP
Result: Felix WILL reinstall the bundle. Sling treats the bundle as being in development and considers each installation to be a new build.


Deconstructing Experience Services: the Composite Application Framework (Mosaic)

The Experience Services contains the Composite Application Framework (Mosaic). The framework has both a server component and a Flex component. Adding the ADEP tooling plugins will, among other things, provide Mosaic capabilities to Flash Builder.

Mosaic builds on the OSGi-inspired Gravity framework. It provides a Flex sdk and tools for creating Mosaic applications, functionality within Flash Builder to create catalogs and deploy applications to a server, and the Mosaic server to present the applications over the Internet.

Content, both Flash-based and HTML, can be brought to together into an application as individual tiles. The tiles can be existing content recompiled with Mosaic tags or it can be new content. The tiles do not all have to have been compiled with the same Flex SDK. The tiles can be developed independently of each other by separate team or at different times. And the tiles can be reused in other applications.

Deconstructing Experience Services: Client Component Framework (Gravity)

The ADEP Client Component Framework (codename Gravity) is an ActionScript library that takes the concepts of OSGi and applies them to ActionScript. It provides a module and/or plugin architecture in which individual pieces can be added and removed seamlessly. The Gravity SDK comes with the es-sdk package for Experience Services. The parts become much more independent of each other allowing easier integration of content from different teams or repurposing of existing content. It makes it easier to have a library of parts that are put together as needed for applications.

While Gravity can be used by itself, it is one of the foundations of the Client Application Framework (Mosaic).

An excellent sample application using Gravity has been posted along with supporting video tutorials at ADEP Client Component Framework blog.

Deconstructing Experience Services: Data Services

It began as Flex Data Services. Then the software became LiveCycle Data Services. Now it is just called Data Services. Data Services has been made a component of ADEP Experience Services. Besides a name change from LiveCycle, it can be deployed differently. No longer exclusively tied to J2EE servers, it is now available as an OSGi bundle. The Java EE application server version continues and continues to be supported. While basically the same, there are some slight differences. The location of configuration files is slightly different. In addition, there are some differences in the way Java classes need to be deployed to work with Data Services. Lin has some very good blog posts about this: [How to Create a Data Services application for the Experience Server that returns data and How to create class/jar files for data service project without using maven].

Once logged onto the Experience Services as an admin there is a dashboard with all sorts of interesting links. There are five you need to concern needed to get started with Data Services. The right side contains three: CRXDE Lite, Packages, and Package Share. On the left you need to know about two, Getting Started and OSGi Console.

Experience Services admin screen

Experience Services admin screen

CRXDE Lite is an application to browse the JCR object database. Where in the Java EE version of Data Services you would put configuration files within folders, the Data Services server is entirely self-contained within this database. Configuration files are within the hierarchy of the database. The Packages link lets you see which packages you have installed and deploy or undeploy packages. The Package Share link lets you install more. Package Share leads to a library of available packages that can be installed.

The Getting Started link points to an area with good documentation on how to use Experience Services and contains Data Services examples. After following that link you will see a section, Application Use Case Samples, with the example applications. The first example, called Data Integration, shows how to use Data Services within its new framework. Follow the link, Developer tutorial, that is in the right side of that example’s box.

There is one last thing that needs to be done before developing with this server. On any screen click the Adobe Digital Enterprise Platform logo in the top left of the screen – this will take you back to the main screen. Press the OSGi Console link in the left section. This is where configurations are set. To develop with Flex and integrate it with the Experience Services the default setting for RDS needs to be changed. The Configuration tab should be selected at the top. Select Adobe Data Services from the list. You will see its configurations. Make Enable RDS selected and the environment is ready to work with for development. Disable RDS in production environments for security.

Data Services gives the Flex front-end of an application access to the middle-tier services on a server. It has a very efficient data transport protocol for Flex. It allows real-time messaging protocols that give the developer the ability to push and pull data from Flex. Data Services can act as a relay and be a proxy host for other services. It provides data management that works with Flex, sending only the data need for display. Someone gave me a short summary of Data Services that is more complete:

Data Services provides remoting (RPC), messaging (publish/subscribe and push) and data management capabilities for the creation of rich Internet application (RIA’s) as well as multi-screen, mobile or occasionally-connected applications. Data Services also provides a highly productive set of model-driven development capabilities which enable developers to focus on application and business logic and includes a wide variety of back-office data connectivity options including connectivity to server-side Java code, SAP, RDBMS’s, Hibernate, JMS and other server-side systems and technologies.

There’s quite a bit of information in that description and it would be interesting to discuss all of its capabilities separately. Data Services is a great tool in a developer’s kit.

[Edited 10/20/2011: I said the Data Services “is deployed totally differently. No longer tied to J2EE servers….” I should have pointed out that it is not exclusively an OSGi bundle. It is continuing to be available for Java EE application servers, with the next version being 4.6. This version is available for public preview on Adobe Labs. I also added references to some very good links from Lin’s blog about creating Data Services applications for the Experience Server. I added a short summary of Data Services I got from someone else.]

First step with Experience Services trial: how to deploy
Data Integration – ADEP Samples

Deconstructing Experience Services: Apache Sling

Apache Sling implements a content management system that uses a Java content repository (JCR), an object database, to store its content and OSGi to add functionality and deploy content. It has server-side scripting and can use multiple languages such as Ruby, JSP and javascript.

Sling forms the basis of the Web Experience Management (WEM/CQ) within Adobe’s ADEP Experience Services. It is robust and makes Web sites easy to develop and then deploy into production. In addition, it has a system for managing digital assets stored within the JCR. ADEP Experience Services implements Sling using its CRX JCR.

In an earlier post I talked about my experience years ago with a content management built on top of a object database called Userland Frontier. Frontier allowed content to be totally separated from the code and HTML used to implement it. That experience has given me a deep appreciation for Web Experience Management.

Within WEM content is not HTML, but the text, photos and other media used as raw material for Web pages. Content is rendered to HTML when needed based on metadata of the content and the context the content is being viewed. If a person views the content from their desktop computer, the content will be rendered for the desktop computer. If another person views that same content from their smart phone, the content will be rendered for the smart phone. The context drives the way content is rendered, but context is not limited to device type. Content can be rendered for women differently than for men. Or it can be rendered differently for a person in one city than for someone in another. Sling makes this smart rendering of content possible and WEM gives the owner of the Web site the tools to use it.

Decontructing Experience Services: Apache Felix

It is amazingly hard to get application components to cooperate with one another, especially if the need to be dynamically added and removed. The OSGi specification attempts to standardize the integration of very different components to work together. And it tries to do this in such a way that the components can be brought in remotely and added to the larger application with minimal disruption.

Apache Felix is a Java implementation of this specification that is used by ADEP Experience Services. The Java content respository (JCR) that is the foundation for Experience Services can contain executable code, but how that code interacts with other executable code is not defined by the JCR itself. Felix provides the framework for how code executes and interacts other components. It provides a way for components to be started up and shut down properly.

Installing and removing functionality within Experience Services is done with packages. Packages are the basic units of functionality for Experience Services and these packages are OSGi bundles. Felix provides the way for Experience Services to bring packages in, deploy them, undeploy them, start them and stop them without having to restart the whole server.