Posts tagged "osgi"

Restart/Refresh the ADEP OSGi container [Apache Felix]

One of the main components of the Adobe Digital Enterprise Platform is the Apache Felix OSGi Container over which the various services and sub-components of the platform are deployed.

The container obviously brings along the great capabilities of OSGi as a dynamic component model, where components (and services) can be remotely installed, started, stopped, updated and uninstalled without requiring a reboot. However, one of the other very cool aspect of the container is the ability to Stop and/or Restart  the entire OSGi framework remotely, to help resolve/refresh the installed bundles, their bundle contexts and dependencies, etc.

To do so, you just need to go to the Felix Web Console @ the URL – http://server:port/system/console. Go to the System Information tab, where you will something like this:

 

 

 

 

 

Note the Restart and Stop options indicated in green.

The System Information tab is also useful to gather other system related information such as the JVM details, memory consumption (with the ability to perform a forced Garbage Collection), etc.

Customizing ADEP Solutions – simplified!

Here are some critical aspects that contribute greatly towards the ease of customization of Adobe’s Customer Experience Management (CEM) Solutions.

No EAR deployments and Application server overheads!

The fact that the CEM solutions sit over the OSGi framework (the Apache Felix OSGi container), has completely changed the way they are built and deployed. As compared to the conventional application server model, where one would typically deploy an EAR file, restart the server and wait for an awful long time for the complete server startup, the OSGi model and the new platform brings in the capability to deploy artifacts (bundles and packages) at runtime, without having to bounce the entire server (which anyway is much, much faster). If at all, there may be cases where you would have to restart the OSGi bundles, but that’s a piece of cake given that you have a sophisticated console to do this from, within a few seconds.

Simplified UI changes – Great separation of concerns!

The UI components of all CEM solutions are based on what is known as the Experience Oriented (XOA) architecture. These UI components are popularly known as UX Components, which by definition is a combination of MXML and ActionScript classes that is bundled into SWC files that separate concerns and encapsulate each concern behind an interface. Interfaces make the implementation of concerns (i.e. presentation, domain, etc.) replaceable and extensible. The Presentation layer of each component, further has the separation of a HostComponent and the Skin, such that one can change the UI look-and-feel (for example, re-ordering of UI elements) by simply modifying the Skin of that component, without having to worry about the overall presentation logic (which lies in the HostComponent). Similarly, the component’s Styles are externalized into CSS files, such that one can change the themes, colors, fonts, etc. by simply changing these CSS files. This allows changes to the solutions while still retaining supportability. Apart from these, other enhanced customizations may involve changes to the HostComponents or the Domain layer, as per the desired use case.

Apart from these, the overall development model around customizations on the UI layer, takes-away the overhead of making changes in various different projects. One can now just add the necessary customized artifacts (MXML, Actionscript, CSS, etc.) to the Solution Template projects itself and override the default implementations via CSS definitions and/or standard inheritance. To learn more, refer to this sample scenario from the Correspondence Management solution.

CRX as the Content repository – Ease of debugging!

The solution assets are now stored in CRX, which provides an Apache Jackrabbit based content repository. The nice and intuitive Content Explorer allows an easy way to navigate across the repository to search for your assets (that are clearly visible as nodes, by their names). Users can select an asset or one of its child nodes to see/investigate the properties associated with the asset. One can also download asset content by selecting an asset and clicking on the data property of that asset (for example, for a Layout asset in CM, it is the filexdp property on the layout node). This greatly helps in debugging/troubleshooting assets within the system.

Apart from this, there is also the CRXDE Lite interface that enables you to perform standard development tasks from the browser.

Check out the links to some of these common interfaces in ADEP,  that you would need frequently during development.

OSGi Services – Possibility of isolated server-side customizations!

Since services deployed in the container are classic OSGi services, one can choose to build/deploy his/her own service as a separate OSGi bundle. Thus, allowing clear separation of custom services vs. the out-of-the-box ones.

Great overall Development Platform!

The Adobe Digital Enterprise Platform (ADEP) offers great tools to support development with ADEP Experience Services. The tools include a set of additional extensions for Flash Builder and a rich SDK (Flex, Java, Mobile) for building applications. The Experience Services SDK is an Experience Package distributed and downloadable using Adobe Package Share.

Overall, since the solutions are built on top of the Adobe Digital Enterprise Platform, they leverage these great capabilities of the platform itself, such that one can build custom applications around it that solves one or more end-to-end use cases.

Comprehensive Help Content!

The solutions publish comprehensive documentation around the usage of the solution, steps to customize areas within the solution, sample customization scenarios, etc. – all of which are a great set of resources to learn about the solution and provide helpful starting points/references for customizations. These learning resources keep evolving as more features are added to the solution, and more scenarios are identified. So, keep an eye on them!

 

Find your OSGi-ready enterprise (thirdparty) libraries

Ok, this is  going to be a short one…

While building custom OSGi bundles or components over the Adobe Digital Enterprise Platform (which contains the Apache Felix OSGi container) or any other OSGi container for that matter, you may often come across a need to access and hence introduce OSGi bundles of other enterprise thirdparty libraries within the container.

A common way to achieve this is to create a wrapper bundle for these libraries using the BND  tool. However, thanks to SpringSource, we already have the OSGi-ready versions of hundreds of open source enterprise libraries that are commonly used/needed, hosted for public use.  So, you can easily search for the library you are looking for here, before creating one on your own (in case the one you are looking for does not exist – which should be quite rare).

 

 

Common ADEP URLs

As part of your journey into the Adobe Digital Enterprise Platform (Experience Server), there are certain parts/applications of the platform that you may need access to quite frequently.

Here is a list of some of those with a short description of what they can be used for (assuming that your Experience Server is running on localhost and port 4502 – if you have a different server URL, the links should change accordingly):

 

Bookmark the above links and enjoy development over ADEP!

Building OSGi bundles for ADEP

When building custom enterprise applications and solutions over the Adobe Digital Enterprise Platform, there is often a need to build custom OSGi bundles that deploy/expose services to be used within the application (typically by the UI layer). Such bundles are deployed in the platform’s OSGi container (Apache Felix).

Here’s a sample Java project, that can be used as a reference or a template to help you build your own OSGi bundle within minutes.

The project essentially consists of the following:

  • Sample Service (com.adobe.adep.sample.ADEPSampleService), and its implementation, that is exposed by this bundle.

 

  • osgi-context.xml – configuration file (snippet below) that defines the service bean, and uses Spring (Blueprint) to expose it as an OSGi service, available over Flex and HTTP remoting.

 

  • BND tool/library and the supporting configuration file (snippet below) – to help generate an OSGi bundle.

  • ANT based scripts – to build the final deployable bundle.

 

To build the above project and generate your OSGi bundle, simply import the project in Eclipse and run the associated build.xml file. Or, use ANT over command line to do the same. The final deployable bundle archive (JAR) is generated in the dist directory of your project root directory.

This can now be deployed over the ADEP OSGi container, the URL of which would typically be http://server:port/system/console/bundles. Your deployed bundle would be listed on the console as shown below, once deployed successfully:

 

Of course, this is just a sample that illustrates how easy it is to build your OSGi bundles for ADEP. You could extend this to define more complex, real life services within the bundle and get yourself going in minutes…