Posts tagged "Experience Services"

A quick way to find an out-of-control thread within CRX

It happens. A process is out of control, consuming system resources on your server and bringing performance to its knees. And many times it is very hard to tell what is behaving badly. For CRX on the Experience Services platform there is a rudimentary profiler that comes in handy when trying to troubleshoot this sort of problem.

The URL for the profiler is at http://[your crx host]:[your crx port]/crx/diagnostic/prof.jsp. This profiler is started, then stopped. It shows the number of times threads ran while the profiler was collecting, sorted in the order of frequency. That’s not a lot of information, but for a quick test to see what is wreaking havoc the built-in profiler works. For more complete profiling use a third party profiling tool such as YourKit.

Optimize the CRX repository

The CRX repository stores its data in tar files. Data is not overwritten or deleted as it is changed. The changed data is added to the tar files and older data continues to exist in the tar files, unused. Doing this makes the repository much more efficient. But this means that even small changes, if there are enough of them, will cause the amount of data residing in the jar files to become quite large.

How can the amount of space taken up by the repository’s tar files be quickly reduced?

CRX has functionality that works like memory garbage collection except for tar files. The tar files can be optimized with this functionality and reduced in size. When this happens the unused data stored in the tar files will be removed and the amount of data stored in the tar files can become much less.  By default, this optimization occurs in the early morning hours. If the size of the repository tar files becomes too large the optimization can be run manually any time it is needed.

Running the CRX respository tar file optimization

After logging into the Experience Services console with an administrator account select the link, Repository Management, on the right. This will take you to the management screen for the CRX repository. Select the link, Tar Persistence Manager Optimization.

On this screen is a field, Delay after optimizing one transaction. Changing this to be a higher number will cause the optimization to take longer while using less of the processor on the server.

To optimize the tar files of the repository, press the button, Start Optimization. While this is running you will see two buttons, Refresh and Stop Optimization. To get updates of the progress of the optimization you will need to press the Refresh button. When completed, a message is displayed: Optimization successfully finished.

For more information see:
Documentation for CRX Persistence Managers

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

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.