realizing great customer experiences with adobe® livecycle® es3

© 2010 Adobe Systems Incorporated. All Rights Reserved.

Realizing Great Customer Experiences

with Adobe® LiveCycle® “ES Next” ES3 Craig Randall | Principal Scientist, Adobe

@craigsmusings

http://twitter.com/craigsmusings

http://twitter.com/craigsmusings


Great customer experience

Adobe’s CEM platform

LiveCycle focus


Technical more than visual


LiveCycle – Platform for Customer Experience Management

EXISTING APPLICATIONS & SYSTEMS

Legacy

Systems

Enterprise

Information

Systems

Databases Directories Message

Queues

ECM

Repository LIVECYCLE SERVICES

&

3rd Party Services

DEVELOPMENT & DELIVERY

RICH CLIENT BROWSER RICH DOCUMENT

RIA SERVICES DOCUMENT SERVICES BUSINESS PROCESS

MANAGEMENT

4


Adobe® LiveCycle® Enterprise Suite 2

eMail Remoting SOAP Task Manager Watched Folder REST EJB

ENDPOINTS

RIA Services BPM Document Services

Output

PDF Generator

Process

Management

BAM

Data Services

Mosaic

Collaboration

Service

Production Print

Forms

Rights

Management

Digital Signatures

Assembler

Content Services

Common & Foundation Services

SERVICES

\

Content

Manager SharePoint FileNet Documentum

ECM CONNECTORS

Legacy

Systems

Enterprise

Information

Systems

ECM

Repositories

Directories

Message

Queues Databases

EXISTING

APPLICATIONS

& SYSTEMS

Reader

Extensions

5


Fully Integrated Design-Development Workflow

6


Announcing LiveCycle ES2.5

Platform release focused on solutions and their acceleration

Extending the goodness of ES2

Same component and application models

Introduction of LiveCycle Mobile

Updated SharePoint connectors

Enhancements to LiveCycle Collaboration Service and Mosaic

7


LiveCycle Mobile

Dramatically enhance mobile worker productivity

by introducing

Data capture

Critical document access

Process initiation/completion in the field

Extend leadership position in bringing

worker productivity to mobile devices.

Major Capabilities

Data capture via Guides-based Form; authoring of mobile-optimized Guides

Simultaneously connect to multiple LiveCycle Instances

Content browser/viewer

Server-side provisioning of services

8


Merge LiveCycle Process Management with the

SharePoint user interface

SharePoint 2010

Replace the SharePoint process engine with

LiveCycle Process Management

Embrace and extend SharePoint capabilities

with LiveCycle

Add support for SharePoint 2010

LiveCycle ECM Connector for Microsoft® SharePoint®

Major Capabilities

Find LiveCycle Form or Guide within SharePoint, click to render & pre-populate

See and act on LiveCycle tasks from within SharePoint

Initiate a LiveCycle process from SharePoint 2010

9


LiveCycle Rich Internet Application (RIA) Services

LiveCycle Collaboration Service

Build real-time, multi-user

collaboration into existing or new

rich Internet applications

LiveCycle Mosaic

Assemble intuitive, personalized

and highly productive applications

through a composite RIA

framework

LiveCycle Data Services

Improve the performance and

simplify the development and

integration of your RIA

application with backend

systems

10


LiveCycle Mosaic

Composite RIA Framework for rapidly assembling intuitive, personalized and

activity-centric RIA applications that aggregate existing enterprise applications

11


LiveCycle Mosaic – 9.5 Release Feature Highlights

Application layout

UI customization through Flex 4 skinning

Nested panels

Enhanced tile layout

Application composition

Fine-grained permissions to applications and catalog content

Panels and view templates stored in catalog

Default panels and views; configurable layout for default panels

User Experience

Renaming views and panels

Deleting tiles confirmation

API enhancements

Injectable services to implement application or tile initialization hooks

Panels and view templates; dynamic loading and activation

Remove tiles from panels and views from applications

Display state change (including notifications) for tiles, panels and views

Figure 1: Default Aqua theme

12


LiveCycle Mosaic – Developing Composite RIAs

Composition approach to application

development

Client side communication between

application components

Comprehensive ActionScript and JavaScript

API – HTML and Flex integration

Central catalog for housing all reusable

application components

Out-of-the box skins, shells and layout

managers

Pluggable component model

Integrates with existing SSO, directory and

entitlement management solutions

13


LiveCycle Mosaic – UI Components

View organizer

Shell

View

Panel

Tile

14


LiveCycle Mosaic – Architecture

Developer Deployment

Tomcat

Mosaic Server

WebDAV / Spring Security

Catalog Composite RIA

Service

View

Management

Authentication /

Authorization

AIR Flash Player

Desktop Client

Runtime Perspective

Design Perspective*

Catalog Management Perspective*

Browser Client

Runtime Perspective

REST (HTTP + HTTP/S)

Java EE App Server

Production Deployment

Repository User Management

LiveCycle ES2 Foundation

* Preview

15


Engage more effectively through a web presence

enhanced with real-time collaboration tools.

Integrate text chat, whiteboard functionality, webcam

video, and audio into any rich Internet application

(RIA),

Multi-user collaboration in real time

LiveCycle Collaboration Service

Major Capabilities

Peer-to-peer (P2P) streaming of data, audio and video

HTTP server-to-server APIs

Private audio/video streaming Server-side provisioning of services

Large Rooms – via on-demand loading of user presence

Audio/video application multicast

Record and Playback Screen sharing

JavaScript APIs – integration with a customer’s existing websites

16


LiveCycle Collaboration Service – SDK makeup

High-level

Components

Foundation

Classes

Pods

RTC UI Components

Shared Managers Shared Model

Session

(Connection, Authentication, Reconnect/Failover, RMI Routing)

Audio Pub / Sub Webcam Pub / Sub File Pub / Sub Shared Cursors

Users AV Streams

Files Room

Pub / Sub Messaging + Permissions

Shared Collection Baton

Shared Property UserQueue

Roster WhiteBoard Chat FileShare Note WebCam

17


Announcing LiveCycle ES2.5 (continued)

Platform release focused on solutions and their acceleration

. . .

LiveCycle ES2.5 Solution Accelerators

Correspondence Management streamlines customer correspondence from

creation to archival

Interactive Statements transforms the static monthly statement into a

dynamic, two-way channel for customer engagement

Managed Review & Approval makes structured reviews efficient, collaborative

and auditable

18


ES Modules

ES3 Platform Stack for CEM Solutions

Spring-based DSC-based

• Content integration

• LCDS

• Enterprise collaboration

• Mosaic catalog

• . . .

• Process management

• Forms

• PDFg

• Reader extensions

• . . .

ES Foundation

Spring beans OSGi bundles

• Bootstrap

• Edge caching

• Spring DM framework

• . . .

• Lightning container

• ES core services

• FIRE (LCDS)

• . . .

• User management . . . • Logging . . . POJO + DI

ES Solution Accelerators (Correspondence Mgmt, Interactive Stmts, MRA, Field Force Automation, …)

Building blocks

• Selection and capture

• Field enablement framework

• On-demand assembly

• . . .

• Data dictionary

• Review, comment, approval

• AIR2PDF

• . . .

19


Aspect-Oriented Programming (AOP)

Plain Old Java Object (POJO)

21


LiveCycle

Foundation Spring

Dependency Injection (DI)

Aspect-Oriented Programming (AOP)

Plain Old Java Object (POJO)

22


LiveCycle RIA Goals

Technology platform to power enterprise RIAs

Enable Customer Experience Management solutions

Infrastructure for XOA

Enterprise and Web scale support

Multiple client technologies: Flex/Flash, HTML/JavaScript, Devices

Modularized RIA technology (client, server, tooling)

Increases productivity of enterprise developers, SIs and ISV partners

Easy adoption for individual developers

Deployed and customized on premise or hosted

On-premise with seamless enterprise IT infrastructure integration

Managed on-demand services

Pay-per-use subscription (platform-as-a-service)

24


• Custom web apps

• RIA services

• Mosaic server

• Data Services

• Collaboration Service

• Content (CRX)

• Common libraries

• Caching

• Logging

• User management

integration (LiveCycle ES)

• Spring-based

• OSGi-ready

LiveCycle RIA Anatomy – Client Stack

25

Gravity

Flash Player

SWF/Module Loading

Dependency Injection Messaging

RIA Core Services

Logging Authentication

Configuration

Context

Persistence

more …

LiveCycle

RIA

Server RIA Component Libraries

Content Collab Mosaic

Data

Serv

ices

LiveCycle ES3 Solution Application

(e.g. Field Force Automation)

Security Guides more…


• Custom web apps

• RIA services

• Mosaic server

• Data Services

• Collaboration Service

• Content (CRX)

• Common libraries

• Caching

• Logging

• User management

integration (LiveCycle ES)

• Spring-based

• OSGi-ready

LiveCycle RIA Anatomy – Client Runtime Foundation

26

Gravity

Flash Player

SWF/Module Loading

Dependency Injection Messaging

RIA Core Services

Logging Authentication

Configuration

Context

Persistence

more …

LiveCycle

RIA

Server RIA Component Libraries

Content Collab Mosaic

Data

Serv

ices

LiveCycle ES3 Solution Application

(e.g. Field Force Automation)

Security Guides more…

Collab Mosaic


What Is Gravity?

A binary plugin framework for the Flash runtime

A framework for binary code reuse across space and time

Space…

An application and plugins can use other plugins from all kinds of sources

A plugin can be used by arbitrary applications and other plugins

Time…

Applications can be upgraded without upgrading all the plugins

Plugins can be upgraded without upgrading the application or other plugins

27


Key Features of Gravity

“Configuration, not recompilation”

Functionality is requested by the desired capability, not by

implementation

Different plugins can have conflicting versions of the same classes

Including conflicting versions of the Flex SDK

This feature is not yet available for single-SWF platforms

Classes can be shared between a subset of plugins

Code can be transparently demand loaded

The SWF isn’t loaded until the code is actually required

The caller doesn’t need to know anything about demand loading

Makes loose-coupling easy

Swap plugins via configuration to swap implementations

28


Quick Facts about Gravity

Closely based on OSGi, a popular Java module system

Optional Dependency Injection based on the Spring “IoC” container, also

popular in the Java world (might recognize the OSGi/Spring IoC combo

as “Blueprint services” from OSGi)

Works on any ActionScript 3 platform

AIR

Flash Player

Works well in Flex applications but does not require the Flex SDK

Makes it easy to create applications with parts built on different Flex SDKs

29


Why Do We Need Gravity?

Enable the Flash platform for distributed development of large

applications

Large applications are frequently just small applications that “grew up”

Enable the Flash partner ecosystem

30


Distributing Code – a Comparison

Libraries Modules Marshall

Plan

Gravity

Strongly typed ✓ ✓ ✓

Isolation of implementation ✓1 ✓ ✓

No recompilation ✓2 ✓ ✓

Incremental ✓ ✓ ✓

Discoverable ✓

Lightweight ✓ ✓ ✓

Flex SDK multi-version ✓ ✓

Flex not required ✓ ✓

31

1 Partial: the main application is isolated from modules, and modules are isolated from each other, but

modules are not isolated from the main application.

2 Partial: since modules are tied to a specific Flex SDK version, the main application and all modules must

be recompiled if any piece needs to move to a new Flex SDK.


How Does Gravity Fit into the Flash Platform?

32

Flex SDK

Text Layout

Framework Gravity

Flash Runtime


Gravity and Frameworks

Gravity is not an application framework or micro-architecture

This is explicit policy: as much as possible, Gravity does not dictate how your

write your application

In general Gravity should work well with frameworks such as Parsley and

Cairngorm

Typically framework use is per-plugin and Gravity is used for cross-plugin

integration

This means that different plugins in an application might use different

frameworks; this should not be an issue

Frameworks are just starting to provide functionality in this area of

modularity

Adobe is considering how to potentially open source Gravity

Adobe acknowledges the wider community of project with some overlap

33


Gravity and Enterprise Rich Internet Applications

Gravity is the core client technology for LiveCycle RIA

Already present, but not a public API, in Mosaic 9.5

LiveCycle ES3 RIA also includes client and server components for

security, content management, and other capabilities

Some previously existing LiveCycle RIA client pieces such as LiveCycle

Data Service will still have limitations when used in a Gravity application

for LiveCycle ES3

In general, Gravity is the basis for LiveCycle client development going

forward

Mosaic and Administrator are now Gravity-based, Mosaic tiles and

Administrator components are Gravity plugins

Workspace is providing Gravity plugins in addition to the legacy libraries

34


Bundles and Services

Gravity has two key concepts

Bundle – the deployment abstraction, just a SWF

Service – the runtime abstraction, just an ActionScript object

35


At Runtime, Nobody Knows You’re a Dog

At runtime, only services matter

Division of functionality between bundles is irrelevant

36


Gravity Bits – Deployment in a Dynamic Environment

The bootstrapper SWF – creates the initial ApplicationDomain hierarchy

Interface SWFs – provide interfaces and classes to be shared between

all bundles

Bundle SWFs – provide the implementation code; classes are not shared

globally

Manifests – provide information to the Gravity runtime about bundles,

interface SWFs, and the services they expose or consume

37


Bundles

Gravity Class Isolation

38

ApplicationDomain hierarchy

interfaces

Gravity core some bundle

main app other bundle

shared

bundle


Using Gravity – the Short Story

1. Configure the HTML wrapper or AIR application descriptor to point at the

Gravity bootstrapper instead of your application

2. Configure which bundles are to be loaded and the interface SWFs

required in the manifest file(s); your application will be one of the

bundles

3. Each bundle, when loaded, can register any number of services

4. When code is looking for pluggable functionality, it looks up the service

and uses the object returned – no need to know which bundle it comes

from

39


The Simplest Bundle Manifest

<manifest

xmlns="http://ns.adobe.com/gravity/manifest">

<bundle location="gravity_hello_bundle.swf"

loader="flex-application"/>

</manifest>

40


The Simplest Gravity Application

<mx:Application

xmlns:mx="http://www.adobe.com/2006/mxml">

<mx:Text text="Hello Gravity!"/>

</mx:Application>

41


Working with Gravity in ActionScript

It always starts with your bundle’s IBundleContext

The bundle context can always be accessed via BundleContext.currentContext:

var context:IBundleContext = BundleContext.currentContext;

To register a MyFooImpl object as an IFoo service:

context.registerService([IFoo], new MyFooImpl(), {someProp:

"foo"});

Registering properties can be useful to allow clients to filter when there are

multiple services of the same class

42


Retrieving a Service in ActionScript, the Hard Way

private function getFooService():void

{

var context:IBundleContext = BundleContext.currentContext;

var ref:IServiceReference=context.getServiceReference(IFoo);

if (ref == null)

throw new NoSuchServiceError();

var token:IToken = context.getService(reference);

token.addSuccessHandler(doSomethingWithFoo);

token.addFaultHandler(handleError);

}

private function doSomethingWithFoo(service:IFoo):void

{

// do something with the IFoo

}

private function handleError(error:Error):void

{

// deal with the error here

}

43


Retrieving a Service in ActionScript, the Easy Way

Create a ServiceTracker

var tracker:ServiceTracker = new ServiceTracker(context,

ISomeService);

Open the tracker to start tracking the service

var token:IToken = tracker.open();

Use the service or services:

var someService:ISomeService = ISomeService(tracker.service);

var someServices:Array = tracker.services;

Close the tracker to release any services held

tracker.close();

Note that ServiceTracker properties (service, services, size,

trackingCount) are bindable

44


Installing Additional Bundles in ActionScript

Very simple:

var token:IBatchToken =

context.installBundlesFromURL(manifestLocation);

Add handlers on the async token for completion and errors

Can also load from local XML:

var token:IBatchToken =

context.installBundlesFromXML(manifestXml);

45

Gravity Dependency Injection Configuration

<beans xmlns="http://ns.adobe.com/gravity/di">



<bean id="myBean"

class="com.adobe.internals.samples::SomeObject"/>



<reference id="yourService"

interface="com.adobe.samples::IYourService"/>



<service interface="com.adobe.samples::IMyService">

<bean class="com.adobe.internals.samples::MyService">

<property name="yourService" ref="yourService"/>

<property name="myBean" ref="myBean"/>

</bean>

</service>

</beans>

46


The Art of the Interface

In a Gravity application, all service interfaces are shared between all bundles

Careful management of the interfaces (and classes, if any) that go into the interface ApplicationDomain is critical to avoid compatibility issues

Best practice is to make all interfaces and classes fixed once released

No changes at all, period

You can deprecate an interface; after an appropriate number of releases with the interface deprecated, you can then remove that interface

Less strict approaches are possible but will result in less flexibility

There are standard mechanisms for adding new functionality, changing APIs, and deprecating existing functionality without changing the interfaces

Usually, you create a new interface, either with a new name or a new package

Service objects can implement both the old and new interfaces

47


LiveCycle ES3 RIA Tooling

Customer profile

Java enterprise developers. Spring or Java EE for server side

Mixture of HTML, AJAX, JSP, Flex for UI development

Want tooling that fits within their existing build, debug, deploy methodologies and skill-sets

Bridge the gap for Flex and Java developers

Solution

Integrate Adobe tools within the Eclipse framework

Deliver an integrated stack out of the box

Integrated client and server development, debug and deployment

Augment open source tooling (Eclipse, WTP, Spring, Maven) with value-add LiveCycle RIA tooling

Eclipse Core

FB Work-

bench Spring WTP RIA

Plugin

LiveCycle RIA Flash Builder plugin features:

Existing: Data Modeler, LiveCycle Service

Discovery

Mosaic app and tile projects (code generation)

Auto-include LiveCycle RIA SWCs

Augment FB build, deploy, debug for RIA

components

IntelliSense for RIA SWCs 48

http://images.google.ca/imgres?imgurl=http://www.flexlive.net/wp-content/uploads/2007/06/lc_appicon.thumbnail.jpg&imgrefurl=http://www.flexlive.net/?cat=11&h=128&w=128&sz=3&hl=en&start=75&tbnid=zCfa0jECRzdhwM:&tbnh=91&tbnw=91&prev=/images?q=adobe+livecycle+icon&start=72&gbv=2&ndsp=18&hl=en&sa=N

http://images.google.ca/imgres?imgurl=http://www.flexlive.net/wp-content/uploads/2007/06/lc_appicon.thumbnail.jpg&imgrefurl=http://www.flexlive.net/?cat=11&h=128&w=128&sz=3&hl=en&start=75&tbnid=zCfa0jECRzdhwM:&tbnh=91&tbnw=91&prev=/images?q=adobe+livecycle+icon&start=72&gbv=2&ndsp=18&hl=en&sa=N


Experience-oriented Architectural Approach

Customer-driven and design-led

Maximize potential reuse

Interface-based component interactions

Bundles for logic, UI, etc.

49

Presentation


LiveCycle RIA component patterns

50

RIA Component

Domain & Service

Presentation

View

PresentationModel

Events

Data Binding

{View State}

{Operations}

{Events}

DomainModel

Foo getFoo()

setFoo(Foo f)

IService operation()

ServiceImpl operation()

IPresentationModel

Infrastructure UtilityClasses

Liv

eC

ycle

ES

3 R

IA S

erv

er

Client Server

IDomainModel Foo getFoo()

setFoo(Foo f)


Custom View and Presentation Model

51


Domain &

Service

RIA Component Presentation

CustomPresentationModel

Events

Data Binding

{View State}

{Operations}

{Events}

CustomView

IPresentationModel


Custom Application Façade

52

Domain & Service Presentation

View

PresentationModel

Events

Data Binding

{View State}

{Operations}

{Events}

DomainModel

Foo getFoo()

setFoo(Foo f)

IService

operation()

ServiceImpl

operation()

IPresentationModel


IDomainModel

IPresentationModel

Foo getFoo()

setFoo(Foo f)

RIA Component

Customization Façade

ServiceDelegateImpl

AppDomainModel

eRIADomainModel

serviceDelegate

Foo getFoo()

setFoo(Foo f)

Bar getBar()

setBar()

IServiceDelegate

operation()

backendService

operation()


LiveCycle Foundation

Ensures LiveCycle is easy to deploy and maintain across multiple Customer Experience Management solutions

Includes:

Orchestration across multiple operations

Invocation services

Web services, email, Java APIs, watched folders

Flex Remoting

Connectors to common data sources (e.g., LDAP, file system, SQL databases, email, etc.)

Encryption across all solution components

Administration tools

Application Administration Console

LiveCycle Configuration Manager

User Manager

54


LiveCycle Foundation – DSC Container

LiveCycle Foundation serves as the main server-side runtime for the

Enterprise Suite

Foundation provides an environment to support the deployment,

execution, and monitoring of Document Service Components (DSC)

DSCs are well defined, self contained orchestrate-able software assets

As DSC container, Foundation provides the invocation layer, component

framework and orchestration engine

Ability to separate implementation from invocation

Ability for components to participate in transacted business processes

55


Document Service Component (DSC)

A component (DSC) consists of resources, metadata, and binary implementations of one or more services packaged together as a Java Archive (JAR) file.

Service: Contains business logic that consists of Java classes and interfaces.

Service operations are specified by creating a Java interface that contains public methods.

Each method defined within the interface becomes a service operation.

Component XML file: Exists for each component and specifies information such as the component's services, service operations, and other metadata related to the component, such as the component's identifier value.

Resources: Includes external libraries, icons, and other resources that the component requires.

Resources must be packaged within the component's JAR file.

Property Editor: Exposed in LiveCycle Workbench and enables process authors to specify input values required by the service as well as handle output values.

Default property editors allow process authors to work with basic data types, such as integers and strings.

56


DSC Development Workflow

To develop a component (DSC), perform the following steps:

1. Set up your development environment.

2. Create your application logic.

3. Define the component XML file.

4. Deploy the component into

LiveCycle.

5. Test your component.

After you deploy a component

into LiveCycle, you can use it to

create a process using LiveCycle

Workbench, or you can invoke

the component’s service(s) by using an invocation method such as the

Java API, LiveCycle Remoting, or Web services.

57


DSC Development Step – Create Your Application Logic

Define the service interface

Public methods become exposed service operations

Define the service implementation (POJO)

Must specify a public no-argument constructor

Class must be stateless

Input parameters, output parameters and exceptions must be serializable

Create a component.xml that describes the component

See next slide (example)

Optionally implement other classes to describe lifecycle of component, as well as enhanced design experience

Recommended: implement both com.adobe.idp.dsc.component.LifeCycle and com.adobe.idp.dsc.component.Bootstrap for your component

Property editors

58


Example DSC Manifest (component.xml)

<component xmlns="http://adobe.com/idp/dsc/component/document">

<component-id>org.example.customComponent</component-id>

<version>1.0.0</version>

<class-path>...dependent JAR’s go here...</class-path>

. . .

<services>

<service name="customComponent" orchestrateable="true" title="Custom Component">

<hint>...component-level help text goes here...</hint>

<auto-deploy major-version="1" minor-version="0" category-id="Custom"/>

<implementation-class>org.example.customComponent</implementation-class>

<operations>

<operation name="generate">

<hint>...operation-level help text goes here...</hint>

<input-parameter name="..." title="..." type="...">

. . .

</input-parameter>

<output-parameter name="..." title="..." type="...">

. . .

</output-parameter>

<description>...</description>

</operation>

</operations>

</service>

</services>

</component>

Please refer to component XML reference for complete manifest schema

59


LiveCycle Application Development Workflow

Understand the context in which a DSC may be leveraged

One possible workflow:

1. Plan

Define…data sources… *

2. Install

Set up…tooling environment (Workbench)…

3. Develop

Build, test and package your application

4. Deploy

Test application and move to production environment

5. Maintain

Maintain, monitor and back up application and provide end user support

60


EAR

EJB

LiveCycle ES2 / ES2.5 Architecture

61

LiveCycle Container

Asynchronous

Processing

JNDI JTA

JMX JDBC

WAR

EJB Invocation

S

O

A

P

R

E

S

T

LiveCycle is a hybrid architecture providing

its own component model while utilizing

EJB

Hybrid model:

Both models need to be accommodated while

neither model is fully served

EJB doesn’t understand the LiveCycle model

and LiveCycle doesn’t understand EJB

Led to the move away from JMS

Forced the need for shared libraries which cause

bloat and duplication

EJB distributed processing rules are not effective or

efficient for LiveCycle components

Multiple software layers causes inefficiency

and unnecessary serialization

EJB

EJB

EJB

EJB

Shared Libraries

Dependent and Fractured

LiveCycle

Component


LiveCycle ES3 Architecture

62

Hybrid architecture is abandoned

EJBs are replaced with libraries or LiveCycle

components

Shared Libraries are managed by the

LiveCycle Container

Dependent services are pluggable

Distribution of services is handled strictly at

the LiveCycle component level

Modularity allows for control over what is

installed and why

Smaller install base smaller dependency

tree

LiveCycle Container

JDBC

JMX

JNDI

JTA

CORBA

WAR/Web

Provider

R

E

S

T

S

O

A

P

Shared Libraries

Remoting

Managed and Controlled

Asynchronous

Processing

LiveCycle

Component


LiveCycle ES2 / ES2.5 Clustering

63

J2EE Cluster

Node 1

EAR

EJB

JNDI

LC

Contai

ner

JTA

Asynchronous Processing

JMX JDBC

WAR

LC Component

LC Component

LC Component

SOAP

REST

EJB

EJB

EJB

EJB

Shared Libraries

Node 2

EAR

EJB

JNDI

LC

Contai

ner

JTA


JMX JDBC

WAR

LC Component

LC Component

LC Component

SOAP

REST

EJB

EJB

EJB

EJB

Shared Libraries

Node 3

EAR

EJB

JNDI

LC

Contai

ner

JTA


JMX JDBC

WAR

LC Component

LC Component

LC Component

SOAP

REST

EJB

EJB

EJB

EJB

Shared Libraries

HTTP Load Balancer

E

J

B

E

J

B

DB

Shared

File

Store


LiveCycle ES3 Clustering

64

LC Container

Asynchronous

Processing

LC Component LC

Component LC Component

JDBC

JMX

JNDI

JTA

CORBA

WAR/Web

Provider

R

E

S

T

S

O

A

P

Shared Libraries

Remoting

LC Container

Asynchronous

Processing

LC Component LC


JDBC

JMX

JNDI

JTA

CORBA

WAR/Web

Provider

R

E

S

T

S

O

A

P

Shared Libraries

Remoting

LC Container

Asynchronous

Processing

LC Component LC


JDBC

JMX

JNDI

JTA

CORBA

WAR/Web

Provider

R

E

S

T

S

O

A

P

Shared Libraries

Remoting

Shared Service

Registry

HTTP Load Balancer

DB

Shared

File

Store


LiveCycle ES3 Integration Possibilities

65

WAR

LC Container


LC Component

LC Component

LC Component

JDBC

JMX

JNDI

JTA

CORBA

REST

SOAP

Shared Libraries

Remoting

OEM

LC Container


LC Component

LC Component

LC Component

JDBC

JMX

JNDI

JTA

CORBA

WAR/Web Provider

REST

SOAP

Shared Libraries

Remoting

EAR

WAR

LC Container


LC Component

LC Component

LC Component

JDBC

JMX

JNDI

JTA

CORBA

REST

SOAP

Shared Libraries

Remoting

OSGI

Spring

DM

LC Container


LC Component LC


JDBC

JMX

JNDI

JTA

CORBA

REST

SOAP

BMC

BMC

Eclipse

LC Container


LC Component

LC Component

LC Component

JDBC

JMX

JNDI

JTA

CORBA

WAR/Web Provider

REST

SOAP

Shared Libraries

Remoting


LiveCycle ES3 in Summary

Architecture changes

Lightning

OSGi, Spring

Etc.

Server-side (services) enhancements and additions

Enterprise tier, Web tier

Client-side (runtimes) enhancements and additions

Gravity and enterprise RIA

Tooling enhancements and additions

Updatesites, major release as a convenience

Installation, deployment and administration enhancements and additions

Single pane of glass

Web orientation

67


Great Customer Experiences in Summary

Effective, efficient, engaging, easy to learn, error-free

Personalized, responsive experiences across devices and channels

Communication and collaboration in context

Harmonization of backend processes and services

68