LAL Architecture

Overview

Live Application Library (LAL) is a software development kit (SDK) for building an enterprise server platform that supports Live applications based on HP Exstream Interactive documents. Building a successful customer communication solution requires a number of key pieces, which are connected using LAL.

Components of the LAL Architecture

The following diagram shows the different components of LAL. Each
component is defined in the table that follows.

Term	Description
Business Process Management (BPM)	The BPM component orchestrates the business processes that are automated by LAL. It includes a process design environment and orchestration engine that makes it possible to integrate systems,content, and business rules into streamlined, end-to-end processes.
Fulfillment	● Automates the generation of template-driven, final-form documents in a variety of formats ● Manages the process to deliver the final form document into multiple channels including production environments, archival, or electronic delivery (email, etc.) ● Provides an administrative UI for configuration of delivery pipelines
Content Services	The Content Services component includes a set of library services that can be leveraged with other components, to allow documents to be created in a way that lets users share and collaborate within established business processes.
Data Services	The Data Services component is a framework that simplifies development of Live applications. It includes functionality for messaging, remoting, data management, and the creation of RIA interfaces. It enables centralized management of complex data. For example, using the Data Services component, you can maintain a single instance of data across the application.
Security	The Security component makes it possible to manage user accounts and authentication, access to different live document objects, and the encryption of DLF documents. The component is built on enterpise standards such as NTLM/Kerberos, CA Siteminder, HTTPS/SSL, LDAP and Active directory.
Container	The Container is where the LAL platform executes. LAL runs on most J2EE application servers (Tomcat, JBoss, WebSphere AS). The LAL platform is implemented in 3 WARS: the OSGI (Apache Felix) Web application that contains services packaged in bundles, the CRX reposioty, and the CQ or Activiti BPM engine.
API	LAL provides application programing interfaces to access the core services of the platform. APIs are provided using standard REST, SOAP and in some cases JMS/MQ endpoints. Interfaces are grouped by the services they offer.
Metadata	DLF documents include application-specific metadata. The metadata is easier to manage if it is embedded within the output document (ie. PDF XMP, Word, etc. Metadata is used by applications and the LAL framework to index, categorize and manage documents in a workflow. Usually metadata is also kept in an external database, allowing fast access for searching. Some metadata is intrinsic to the document (i.e date, document name, author), some is specific to the LAL framework (i.e. document class ID, author ID) and some is application-specific..
Dynamic Templates	The Dynamic Templates component lets you leverage LAL/Exstream capabilities for ondemand, Web-based applications. The Dynamic Templates component supports ondemand rendering of forms based on DLF or PUB files.

Flexibility of the LAL Architecture

LAL operates natively with LiveEditor. LiveEditor requires only the normal customization needed to work with any Web service that supports DLF documents. LAL is not limited to these clients. Custom clients can be developed to work with the LAL API set for exceptional functionality not provided by these clients, or if a client conforming to an established set of applications is required. LAL can be extended with custom modules that communicate by exchanging requests and responses with external services. This feature makes it possible for deployments to incorporate existing services required for an overall solution.

LAL Services

LAL services are divided into three groups: Workflow Services, Content Services and Fulfillment Services. You will use the library to build applications and integrate with external Business Process Management (BPM) engines. The API and LAL connectors allow you to build applications without working directly with specific implementations of repositories, workflows or fulfillment environments. The following diagram shows the LAL framework and some possible interface and service connections.



While LAL provides connectors to repositories, BPMs, and fulfillment and delivery systems, specific SKUs, such as Live Repository (Day CRX), Live Workflow, and Command Center, are provided as part of the CCS platform.

Jackrabbit or Live Repository (SKU) can be used as JCR repositories (Jackrabbit is the default).

Some implementations, such as a SharePoint-based portal, might require only Fulfillment Services, since there is no need to provide content management or workflow capabilities. In an implementation in which not all capabilities are needed, HP Professional services can assist you with installing only the needed modules.

Services for workflow, content or fulfillment need to abstract the underlaying implementations of the Workflow Engine, or Content Repositories (grey boxes). As part of the platform, LAL provides specific, out-of-the-box implementations for each. These implementations are discussed in the detailed sections (blue boxes). LAL Fulfillment Services provides composition engine integration with the Exstream production engine (EWS,production, real-time) and Command Center for high-volume complex production job life cycles.

Fulfillment Service

Within LAL, the term “fulfillment” is used to describe the automation of activities involved in the creation and disposition of documents. This includes the generation of Interactive documents, composition of final-form output, and programmatic execution of post-processing steps like multi-channel delivery.

The core component of fulfillment processing is the pipeline. A pipeline is a logical entity that can be described as an ordered sequence of activities. Each activity or step in the pipeline is represented by a channel.

A pipeline works by passing a message between the various channels on the pipeline. The message is received and processed by a class in each channel. The channel's message processor extracts the payload and metadata from the message, and then uses this information to perform a predefined set of operations. This message-oriented implementation promotes a loosely-coupled programming model where development of each channel can happen independently with little-to-no dependency on other channels.

Each channel is registered as an OSGi bundle which makes it a discoverable component (by other channels, for example). In addition, each channel can have multiple channel configurations defined in the repository. The specific channel configuration parameters are set when the pipeline definition is created.

The channel configuration is cached on first invocation and is then reused for subsequent calls.

Fulfillment Bundles

Fulfillment includes the following bundles:
● Message Creator
● LAL Route Manager
● LAL Remote Engine Channel
● LAL Command Center Channel
● LAL Staging Channel
● LAL SMTP Channel
● LAL Template Channel
● LAL Channel Creator
● LAL HTTP OutBound Channel

Bundle	Properties
Message Creator	The Message Creator bundle is responsible for generating the LALMessage structure. The LALMessage data structure carries information about the payload, the next channel to be invoked, and the message correlation ID. This class provides the execution Context for the LAL channels. The LALMessage has two main components: ● Body—An internal Data Structure of the LALMessage class. This class provides the necessary metadata and references to the data to be operated upon by the channels. The following is a list of the main components of this class: ◦ Payloadpath—Lists the path to the driver file in the JCR Repository ◦ AppRequest—Carries the Dialog Application Request parameters ◦ ChannelRequest—Contains a list of the channel configuration ID and key value pairs ◦ ChannelConfigs—Contains a list of channelConfigids stored against the channelIds ◦ Extra—Provides an extra Map for adding extra key value pairs to the Body, so that extra metadata can be carried ◦ CurrentChannel—Stores information for the RouteManager to determine the next channel to be executed for the pipeline. ● Headers—Contain metadata about the message ● ExecutionContext—Stores the success or failure of the channel if the channels are running in synchronous mode
LAL Route Manager	This bundle is responsible for controlling the flow of the message across the channels defined in the pipeline. The pipeline definition is loaded from the repository based on the pipeline ID passed by the client. The Route Manager controls the flow and determines which channel(s) need to be invoked as part of the pipeline.
LAL Remote Engine Channel	This bundle invokes the HP Extream Engine using the Engine as a Web Service (EWS) product over a SOAP protocol. The configuration will refer to the HTTP host, port and URL of the server running the EWS Servlet.
LAL Command Center Channel	This bundle invokes the HP Extream Engine using the Command Center product over a REST protocol. The configuration will refer to the HTTP host, port and URL of the server running Command Center.
LAL Staging Channel	This bundle provides the ability to store files on the LAL server's local file system. The channel extracts the payload file from the pipeline and stores it in the local file system using the location found in the Staging channel configuration (baseDirectory attribute). If the file already exists, the file name will have a timestamp (Mask is YYYYMMDDHHMMSSsss for example: 20110223102543301) appended to it prior to storing. If no file name is specified, the file name will be the based on the payload path (for example: 1/628c228e-9620-416a-bf46-d0c86d3ae6d61298564282601), replacing the / with a hyphen.
LAL SMTP Channel	This bundle abstracts the email functionality. The configurations are stored in the CRX repository. The channel extracts the payload path from the message and uses it to access the output generated by the engine. It will send the output as an email attachment, based on the configuration(s).
LAL Template Channel	This bundle is a template bundle the Channel Creator bundle uses internally to generate custom bundles or channels. The end user never interfaces with the template bundle as its for internal usage. The template channel is a JAR file which is stored at a specified location in the repository. The creation and persistence of the JAR is set by the build process. Custom bundles created in the Fulfillment UI use this JAR file.
LAL Channel Creator	LAL Channel Creator This bundle uses the template channel JAR file to create an OSGi bundle and register a Spring Integration based channel into the OSGi registry. The channel name is same as the service name. The UI creates a bundle by the same name as the channel ID and associates it with the channel. At this point the channel is ready for pipeline consumption. The custom channels allow the user to write plugins and plug them as part of the OSGi bundle without having to explicitly handle OSGi issues. Also, 3rd party libraries used can be plugged in and will be loaded by the bundle classloader.
LAL HTTP OutBound Channel	This bundle can be used for callbacks as well as HTTP error logging. Since the communication across pipeline channels is primarily asynchronous, any error occurring in a channel running in asynchronous mode is pushed to this channel. The specific Error channel used is determined by the settings in the pipeline configuration process. The Current release supports only HTTP bound error channels.