Posts Tagged ‘Basics of Adobe Experience Manager’


Open Systems Gateway Initiative (OSGI)

OSGi has developed a specification to build modular and extensible applications. The OSGi module system allows building applications as a set of reloadable and strongly encapsulated services. OSGi “bundles” run inside an “OSGi container”, which manages relations among bundles. Again, bundles are simply JAR files that contain extra metadata indicating what services they require and which they provide.

OSGi Framework

The OSGi Framework is made up of three layers which define how extensible applications are built and deployed.

  • Module
  • Lifecycle
  • Services.

The responsibilities of the layers are:

1. Module:

Defines how a module, or a Bundle in OSGi is defined. Basically, a bundle is just a plain old JAR file, whose manifest file has some defined entries. These entries identify the bundle with a symbolic name, a version and more. In addition there are headers which define what a bundle provides – Export-Package – and what a bundle requires to be operative – Import-Package and Require-Bundle.

2.Lifecycle:

The lifecycle layer defines the states a bundle may be in and describes the state changes. By providing a class, which implements the BundleActivator interface and which is named in the Bundle-Activator manifest header, a bundle may hook into the lifecycle process when the bundle is started and stopped.

3. Services:

For the application to be able to interact, the OSGi Core Specification defines the service layer. This describes a registry for services, which may be shared.

Sample Manifest information:

Export-Package: *
Import-Package: *
Private-Package: *
# Include-Resource: 
Bundle-Name: Workflow Purge
Bundle-Description: Allow automatic & scheduled purge of workflows
Bundle-SymbolicName: com.adobe.daycare.workflow.purge
Bundle-Version: 1.7.1
Bundle-Activator: com.adobe.daycare.workflow.purge.Activator



Apache Sling

Apache Sling is a web framework that uses a Java Content Repository, such as Apache Jackrabbit or Adobe CRX to store and manage content. Sling applications use either scripts or Java servlets to process HTTP requests in a RESTful way. The Sling application is built as a series of OSGi bundles and makes heavy use of a number of OSGi services. Being a REST framework, Sling is oriented around resources, which usually map into JCR nodes.

Traditional web applications select processing script based on the URL, and then attempt to load data to render a result.

In Apache Sling,  request URL is first resolved to a resource, then based on the resource it selects the actual servlet or script to handle the request.

The Resource is one of the central parts of Sling. Sling assumes that “Everything is a Resource”. Sling resources usually map to a JCR node.

Every script, servlet, filter, error handler, etc. is available from the ResourceResolver just like normal content providing data to be rendered upon requests, and they are accessible by a resource path.

Using Sling, the type of content to be rendered is not the first processing consideration. Instead the main consideration is whether the URL resolves to a content object for which a script can then be found to perform the rendering.

In Sling, and therefore also in AEM, processing is driven by the URL of the HTTP
request. This defines the content to be displayed by the appropriate scripts. To do this, information is extracted from the URL. When the appropriate resource (content node) is located, the resource type is extracted from the resource properties. The sling:resourceType property is a path, which locates the script to be used for rendering the content.

Advertisements