8 November 2011
The latest release of ES3, now know as the Adobe Digital Enterprise Platform (ADEP), is packed with great new features. This article is part of a series of articles describing the new features. In the coming weeks, several engineers will share lists highlighting our top 10 ADEP favorite features—along with reasons for using them. I'm very excited to share my top 10 favorites with you. Some features are improvements to the existing toolset, while others are completely new. Be sure to check the ADEP Developer Center to learn more about the features listed in this article.
The new Author - Publish topology makes it easy to maintain web portals that need updating every second such as news channel, sports channel, and social networking sites. Here's a list of the new terms associated with this feature:
Review the diagram to see the publishing workflow with Dispatcher (see Figure 1).
The diagram in Figure 1 illustrates how an author/content-owner (top-most left corner) accesses the content via the Dispatcher. The author requests that certain content be published (activated); this can be initiated by a manual request, or by automatic triggers which have been pre-configured. After making changes to the content, they preview the content and then activate the content. At that point, the content is published to the Publish Instances. The end user accessing the content via Dispatcher can see the updated content.
ADEP's Customer Experience Solution contains a load balancing tool named the Dispatcher. The Dispatcher is installed on the web server. It is Day's CQ caching and load balancing tool.
When caching, the Dispatcher uses the web server's ability to serve static content. The Dispatcher places the cached documents in the document root of the web server. Due to this configuration, the Dispatcher only stores the HTML code of the page; it does not store the HTTP headers.
The Dispatcher has two primary methods for updating the cache content when changes are made to the website (see Figure 2).
The two methods are:
The Dispatcher performs load balancing in two ways:
Clustering two nodes has never been easier. Enter the IP/hostname of the other ADEP-Experience Services server's instance of the cluster, followed by username and password in the subsequent fields and click Join. The CRX cluster is then prepared with the repository now clustered. This type of clustering is known as Shared Nothing clustering. In this configuration, all three elements of CRX storage are held per instance and synchronized over the network. No shared storage is used. The three instances of CRX storage are:
The other variants of clustering are Shared Datastore and Shared Datastore and Journal (see Figure 3).
OSGi, also known as the Dynamic Module System for Java, defines an architecture for developing and deploying modular applications and libraries. OSGi containers allow you to break your application into individual modules (jar files with additional meta information, which are called bundles in OSGi terminology) and manage the cross-dependencies between them.
These services and contracts provide an architecture which enables individual elements to dynamically discover each other for collaboration. An OSGi framework provides dynamic loading/unloading, configuration and control of these bundles—without requiring restarts.
This architecture allows you to extend Sling with application-specific modules. Sling, and therefore CQ5, uses the Apache Felix implementation of OSGi (Open Services Gateway initiative) and is based on the OSGi Service Platform (see Figure 4).
RIA Content powerful feature that enables:
The structure of the RIA and CRX systems is shown below (see Figure 5).
As shown in Figure 5, LC Content is comprised of:
Until now, developing an application always involved writing code. With Model-Driven development, you can develop an application with minimal code using Flash Builder. The following list highlights top features available in Flash Builder after you've installed ADEP:
Using Flash Builder, you can drag and drop the fields you want to display in your application (see Figure 6).
After inserting fields, you can use the interface to configure them (see Figure 7).
When you run the application the fields display as expected without coding (see Figure 8).
The ADEP-Document Services server is integrated with the ADEP-Experience Services server to allow seamless configuration support for configuring the Document Server from within CRX. The integration process for CRX and Document Server involves a single mouse click. In order to access the Document Server, enter the Document Server URL, username, password and a few more entries and then click Configure. After integrating CRX with the Document Server, users in the Document Server can access CRX. Users from CRX can invoke different services of the Document Server, such as convertPDF, add encryption, work with forms, invoke the ReaderExtension and other services (see Figure 9).
Workflow is a very helpful feature included in ADEP. It allows you to create a custom workflow or use predefined workflow to perform a certain process. For example, a key application of CQ is Web Content Management (CQ WCM), which enables you to generate and publish pages to a website. This functionality is often subject to organizational processes, including steps such as approval and sign-off by various participants. These processes can be represented as workflows, which in turn can be defined within CQ and then applied to the appropriate content pages.
A workflow is a series of steps. When a workflow is started, a new workflow instance is associated with its payload. For example, the data that was submitted in a form advances through specific steps. Such workflows can pass through automated Process steps or manual Participant steps, and can follow rules (as well as optional splits and joins). Workflows can also trigger Container sub-workflows. Additionally, you can use this feature to invoke the service on the Document Server side. You can perform several operations from workflow and invoke different services from the Document Server, such as convertPDF, ReaderExtension, forms, and encryption—just to name a few (see Figure 10).
A Single Sign On (SSO) mechanism is a basic requirement in today's enterprise world because of the numerous user interfaces that exist within an organization. The Adobe Granite SSO Authentication Handler supports Single Sign On systems such as the CA SiteMinder or IIS NTLM. It extracts the user id from HTTP requests and ignores any password information. It is very easy to configure and provides the following features:
Configure the Single Sign On service (see Figure 11).
A new feature included in the ADEP-Document Services is designed to prevent Cross Site Request Forgery (CSRF). CSRF vulnerabilities occur when a website allows an authenticated user to perform a sensitive action but does not verify that the specified user is invoking that action. Cross-Site Request Forgery (CSRF) is among the top most-exploited security vulnerabilities, along with Cross-Site Scripting (XSS) and SQL Injection.
Till ES2 time frame, Cross Site Request Forgery (CSRF) was disabled by default and user were required to make changes manually in the config.xml file. But in ADEP-Document Services, at the time of System Bootstrap, the default host and the IP of the Document server are entered into the Allowed Referrer List and CSRF is activated. The user can also view, add or remove the list of allowed referrers for both the HTTP and HTTPS ports. Additionally, there are some recent changes to the CSRF functionality. For example, CSRF checks are not put on GET requests, as GET is always the safe method. Also there's updated, intelligent handling of Null referrers, and many other new safeguards (see Figure 12).
For more in depth information on developing content on the Adobe Digital Enterprise Platform and rapidly deploying Customer Experience Solutions, visit the ADEP Developer Center.
Also be sure to check out the other articles in this series to learn about other new favorite features in the Adobe Digital Enterprise Platform.