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.]

Resources:
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.

Deconstructing Experience Services: the Java content repository

The Experience Services platform is built on top of a Java content repository (JCR). Day Software developed the JCR, CRX, that is in use by Adobe.

The term Java content repository can be used interchangebly for the Content Respository API for Java or for a software implementation of that API. The JCR is at heart an object database, with a hierarchical description of data. The API has standard methods to interact with an object database. It describes methods for importing and exporting data. It describes methods for searching the object database. Defined in the API, also, is data versioning.

Object databases (ODB) are interesting beasts. Most any type of data that is stored within a computer’s file system can be store in one. A Web site, with its whole directory and file structure, could be replicated in one. In addition, code can be stored and called inside an ODB. An ODB can be much more than the computer’s file system. Metadata can be defined for objects and the type of metadata stored can contain anything that the ODB can store.

My first introduction to an object database was with Userland Frontier back in the ’90s. The ODB contained scripts that ran a language called UserTalk. Website management capabilities were added to it and that is what I used it for. I learned the power of the practice of separating content from the code of the implementation. The information for the Website could be stored in the ODB not as HTML pages, but as content. The HTML was defined in separate templates, and the content and HTML code stayed distinct from one another until it came time to deploy. Then the pages would be created and placed online using FTP. A Web server was added to the ODB and Frontier became a content management system. Frontier had a lot of potential, but the company that developed it eventually stopped maintaining it.

The JCR at the core of Experience Services actualizes the potential that Frontier had, plus some. By itself, an object database does not do much. It is the parts that are hung from it that give it power.

First step with the Experience Services trial: how to deploy

UPDATE: 2 April 2012. I have more details about how to deploy Experiences Services (and CQ and CRX). I created a new post based on seeing the things that can go wrong when deploying the CRX Quikstart.

See: Installing CRX, CQ or Experience Services for Desktop Development

The trial download for the ADEP Experience Services is a single jar file. Deploying the Experience Service server is easy. Place the jar into the directory you want your server files to be. Make sure you have Java 1.6 installed. Java 1.7 will not work. Double click on the jar and it will start the server. The first time Experience Services runs it deploys its files into the same directory that contains the jar. After it has started up the administrative page opens in the Web browser. The default user name is ‘admin’ and the default password is ‘admin’.

What’s next? Quite a bit is crammed in that single file. You can do a lot. Some of the pieces inside Experience Services are familiar, such as Data Services (formerly LiveCycle Data Services). Other pieces may not be as familiar.

Problem with iframes on Motorola Xoom

I have seen a problem with the way the Android system handles iframes on my particular tablet, the Motorola Xoom. In the most recent versions of Android, the system browser does not pass click events to iframes that overlay plugin media. You can reproduce this by creating a Web page that has a Flash movie covering the entire page and an iframe in a layer above the Flash movie. Touch events, including taps, will not be sent to the iframe at all.

Someone was kind enough to test different versions of the system on the Xoom for me. This behavior was not in the Xoom with Android 3.0.1. It showed up in the Motorola Xoom running Android 3.1 or higher. The version of the Flash player had no effect.