Adobe | 63000203 | Datasheet | Adobe Integrated solutions LiveCycle Mosaic 9.0, EN

Adobe Integrated solutions LiveCycle Mosaic 9.0, EN
Adobe LiveCycle ES2 Technical Guide
Adobe’ LiveCycle” Mosaic ES2 (9.5) Implementations
Creating intuitive, contextual workspaces for better decision-making
Adobe LiveCycle Mosaic ES2 provides a framework to create composite rich Internet applications (RIAs).
Composite RIAs are web-centric applications combining multiple Ul components and are assembled and
displayed on the client during runtime, leveraging contextual information. LiveCycle Mosaic includes server
components, browser and desktop clients, a Flex/ActionScript SDK and a JavaScript SDK.
LiveCycle Mosaic ES2 is targeted at enterprise RIAs and specifically suited to build user-centric applications,
including workspaces for support and sales. Mosaic allows IT departments to distribute the development of
various components of a composite application (e.g. customer records, issue reports, enrollment application)
and then combine those components dynamically into a rich composite application. The Mosaic framework is
highly customizable and allows IT to deliver applications that can be personalized and mashed-up by end-
users as well as applications that are completely pre-configured by IT.
Tiles are a core concept of Mosaic applications. Tiles are application user interfaces developed in Flex or
HTML, enhanced with the Mosaic client SDK and registered in the Mosaic catalog. As opposed to traditional
enterprise portals, Mosaic fully leverages modern RIA technologies (Flex and Ajax), resulting in a lightweight
server (based on Java and Spring) and a rich client SDK available in ActionScript and JavaScript. Tiles can
connect to any backend server, as well as hosted applications, in the same way that applications run in a
standalone browser. Just by adding simple script to the client code and without any changes to the server code,
tiles can leverage the Mosaic framework to communicate with other tiles in a view, persist contextual data and
trigger actions (e.g. launching of another tile). This client-centric concept makes it very easy to convert existing
web application Uls into reusable Mosaic tiles.
To minimize total cost of ownership (TCO), Mosaic integrates with existing enterprise software infrastructure.
Most importantly it allows integration with the existing security infrastructure by integrating with existing
authentication and authorization services. Mosaic assets can be stored in the out-of-the box repository or
integrated via WebDAV with external repositories. Mosaic integrates seamlessly with other LiveCycle ES2
modules via the LiveCycle Foundation.
Architecture and Deployment
The Mosaic server is implemented in Java using the Spring framework, and runs on top of Tomcat as well as
Java EE application servers. For a local developer deployment, there is a fully functional Mosaic standalone
server that includes Tomcat. It can be unzipped onto a development computer (desktop, laptop or server) and
be immediately ready to use. Alternatively it can also be deployed onto an existing Tomcat instance. For
production environments it is recommend to deploy Mosaic on top of the LiveCycle Foundation. LiveCycle ES2
is supported on IBM WebSphere, Oracle WebLogic and JBOSS application servers. The LiveCycle Foundation
provides advanced user management capabilities, integration with LDAP, authentication and SSO
infrastructure, as well as a robust repository. Detailed system requirements for server, development
infrastructure and client can be found within the LiveCycle Mosaic Documentation.
Desktop Client Browser Client
Runtime Perspective
Design Perspective* Runtime Perspective
Catalog Management Perspective*
AIR Flash Player
Mosaic Server
Catal Composite RIA Vi Е Authentication /
ES Service N Authorization
WebDAV / Spring Security
LiveCycle ES2 Foundation
Tomcat Repository User Management
Java EE App Server
Developer Deployment Production Deployment
* Preview
The Mosaic server provides the following core services to run composite RIAs:
The catalog service manages the composite RIA assets, specifically all the available tiles. The catalog contains
both metadata about the tiles (e.g. name, description, min/max size) as well as the SWF file. In the case of
HTML tiles it includes the URL to the actual web application. Other assets managed by the catalog service are
panels and template views. This allows a decomposition and reuse of Mosaic applications and parts of it. This
is, for example, supported through APIs that allow to load default views and templates from the catalog
(instead of creating everything programmatically).
Composite RIA service
This is the core runtime service of Mosaic. The composite RIA service gets the requests from the runtime and
delivers the application XML. The composite RIA XML description is registered with this service.
View management
The view management service handles the persistence of views on the server. Once a user requests to save a
view, it is stored in the repository. This service also retrieves stored views from the repository and serves it to
the client runtime on request.
Authentication and authorization
These service components handle Mosaic security. Based on the Spring security framework, they manage the
user authentication. An XACML based service handles authorization policies.
Users can access Mosaic applications both via a web browser and as a dedicated desktop client. The clients
communicate with the server using REST over HTTP or HTTP/S (configurable on the server). The browser client
requires the Flash Player 10.1 plug-in. Mosaic applications run within the Flash Player on the client. The
desktop client is based on Adobe AIR 2. It can be deployed on Windows, MacOS and Linux. See “System
requirements” in the Getting Started Guide for details on the supported platforms, browsers, Flash Player and
AIR runtime.
Developing Mosaic Applications Overview
Before creating Mosaic composite RIAs, it is important to understand the different framework objects and how
they relate to each other.
View Organizer
I Mosaic : Runtime
Favorite Views
Aled Ace. 546-0 V
Sunshine Motor Co.
PM. MT |
Oper Cat
Customer Overview
id Issue Ds clientid | bugid
1234 problem v| Solaris | 58 23312 =
1278 date form: Windows | 12 23313
1279 fails to los| Windows | 62 23290
1295 missing fi| AX 38 23310
1308 permissic| Solaris | 12 23304 Г
1311 problem c| Mac 58 23306
1312 | accounts) Windows | 38 23288
1318 | failedto ca) Mac 72 23303 -
Bug Tudo x
Bugs: | 23208 |
Title: (Nullam eget at nulla nec eget ipsum. |
Date Opened: [2009-03-20 |
Priority: |3 |
Sed at odioaugue, ut blandit diam.
Chant Edo
Allied Accounting
1548 Broadway
New York, NY
Este Statistics
Allied Accounting
Open Issues
, m al
Mur fpr May Jun Jul ug
Ш Past issues
Issue History
A Mosaic server can host one or multiple Mosaic applications. A Mosaic application is described in XML (for
more info on the Mosaic application XML, see section "application schema” in the Adobe LiveCycle Mosaic 9.5
XML Schema Reference. The Mosaic application XML is deployed on the Mosaic server and used during
runtime to dynamically assemble and present the application to the end-user. The two core elements of a
Mosaic application are the shell and one or multiple views. The shell includes components that are always
available when a user is working with the application. The shell could include a menu tile, company logo,
search tile or similar common functionality. Shell positioning and layout is dynamic and can be defined in the
application XML. Within the shell the user can access one or multiple views.
A view packages one or multiple tiles that are required to perform a specific task (e.g. a customer overview
view would include tiles showing information of a specific customers from different backend systems and the
web). Furthermore each instance of a view is associated with a context (for example, the customer name and
ID). The context is a Mosaic framework-managed memory object that is accessible to all tiles in a view (in case
of the global context it is accessible to all tiles in the application). The end-user can customize the view (e.g. by
adding or deleting tiles) or change the context and then save the modified view for later usage. A view can
have multiple panels to help organize the layout of the tiles. A panel is typically represented with a tab in a
Mosaic view (customizable). A panel arranges multiple tiles together in a predefined layout (see the section
"Using application layouts” in Developing Applications for Adobe LiveCycle Mosaic for more information on
Mosaic layout types). Panels (with different layout managers) can be nested to achieve more complex layouts.
Mosaic Server
Can host 1:n
Creates for Global Context
each session
Application I
(e.g. Financial Advisor Desktop)
^^ Consists of #
View View
. Persists data in Context Management
Shell + View 1:1
| Are part of _-
Shell Tiles mn =m ПОТ |]
(e.g. Menu) Saved Views
Saved by
user (stored per user)
| Catalog
Consists of
Panel 1: Views
Defines I
layout of
m:n .
Layout Contains Panels &Tiles
ee - [|
Developing Tiles
Since tiles are the fundamental building blocks of a Mosaic application, the first step in a Mosaic project is to
develop the tiles and register them in the catalog. Mosaic comes with a number of sample tiles with source
code to accelerate custom tile development. Mosaic recognizes three types of tiles: Flex application tiles, Flex
module tiles and HTML tiles.
Flex Tiles (Sub-applications or modules)
Flex tiles can be developed in Adobe Flash Builder (formerly known as Flex Builder). Existing Flex applications
can be easily converted into tiles in three steps:
- Add the Mosaic TileSDK.swc into the Flex library folder (there is one for Flex 3 and one for Flex 4),
- Add the namespace xmins:mc="com.adobe.mosaic.core.*" to the root MXML element, and
- Change the root element: mx:Application to mc:Tile or mx:Module to mc:ModuleTile.
At this point, the tile can be enhanced with specific Mosaic runtime capabilities (see Tile APIs) and uploaded
into the catalog.
Application Tiles vs. Module Tiles
Application tiles provide the most flexibility. They are compiled as SWF and can run both within Mosaic and as
standalone applications. Application tiles also can be compiled with different versions of the Flex SDK (3.3 and
higher), providing the largest degree of independence between different application development teams. The
flexibility comes with the price of a larger memory footprint since each tile requires the Flex framework to be
loaded into memory.
Module tiles need to be compiled with the same version of the SDK the Mosaic framework is compiled with (in
Mosaic 9.5 that is Flex SDK 4.1).
Adobe's general recommendation is to use application tiles whenever possible.
HTML Tiles
An HTML-based application can be registered in the Mosaic catalog without any modifications.
In the browser client, an HTML tile will be loaded as an iFrame within the overall Mosaic application. In this
case, the HTML is rendered by the browser and will support any features (e.g. plug-ins, including Flash Player
and Adobe Reader) that the browser supports. The Mosaic framework handles all the underlying complexities
with running HTML in a Flash container, including layering (z-order determination) and communication
between tiles. This requires the HTML application to be able to run in an iFrame and to be compatible with the
browser used to run the Mosaic application.
In the desktop client, the AIR web browser engine, based on WebKit, renders the HTML tile. Therefore the
HTML-based application needs to be compatible with WebKit (also used in Safari and Google Chrome). AIR
does not support browser plug-ins (except the embedded Flash Player and Adobe Reader).
To provide tighter integration between an HTML tile and the overall Mosaic application, a range of tile APIs are
available in JavaScript (see Tile APIs). In order to leverage these APIs, a link to the mosaicBridge.js library
needs to be embedded into the HTML. All APIs are client-side API's and dont require modification of the
business logic on the server.
An HTML tile can also participate in the overall context of the Mosaic application without code changes. If the
HTML-based application supports passing of parameters via the URL, those can be passed dynamically with
data from the Mosaic context during runtime (e.g. the symbol of stock to be displayed in Google finance).
Tile APIs
Many of the tile APIs are available in both ActionScript and JavaScript and the scope of API functionality will be
extended with each release of LiveCycle Mosaic. LiveCycle Mosaic ES2 includes the following API functionality:
Inter-tile communication
- The context is a runtime object that is accessible to tiles to set or get context attributes. There are two context
instances: A view context that is available to all tiles in a specific view instance and a global context that is
available to all tiles in an application. When a user saves a view, the view context is saved with it, so it can not
only be used to pass data between tiles but also to re-instantiate tiles when saved views are being loaded by
the user. The API allows tiles to set attributes in the view context or global context, register or remove
context attribute watchers (monitoring if an attribute in the context changes), and get attributes from the
- Another means of inter-tile communication is sending messages between tiles. Messages are not persisted.
The API allows tiles to send a message and add or remove a message listener, subscribing to messages by
namespace and name.
Navigation and user interface actions
- Get the name of the currently active view and panel.
- Add a new view in the application.
- Add a new panel to a view (including setting the layout manager).
- Geta tile from the catalog and add it to the current panel.
- Remove a tile form a panel, remove panel and remove view
- Geta view/panel from the catalog, add it and display it
» Panel state change (i.e. displayed) notifications
Saving and loading custom views
- Request a save view action (activates user interface to save a view).
» Save view programmatically (without user interaction).
- Get a list of all saved views of current user.
- Load a saved view back into the application.
- Delete a saved view.
User information
- Get full name of current user.
- Get login handle of current user.
» Get SAML assertion of the current user (enables Single-Sign-On).
» Get style sheet(s) referenced by application. This allows developers to retrieve the global style sheet(s) of an
application and apply it to the style of a tile.
- Return name of catalogs used by application.
- Get catalog of a specific tile.
- Get a specific catalog.
Other APIs
- Navigate and manipulate the application XML programmatically.
- Get label of tile.
- Get list of all views in an application.
- Get list of panels in a view.
- Get list of all tiles in panel.
- Get parent view of panel, parent panel of tile or parent view of tile.
Best practices for inter-tile communication and using persisting context
Passing information between tiles can be accomplished in multiple ways, including using the view context, the
global context and messaging. In a lot of cases, the best option is to use the view context. When publishing
data to the view context, all other tiles in the view can pick up the information. Even when the user adds a tile
to the view later, that tile can pick up the existing context and adjust itself to show relevant information to the
user. The view context is constrained to sharing of data between tiles in the same view. Since users could have
multiple views open with the same tiles but different contexts (e.g. support views showing support information
for different customers). Using a dedicated context per view is the desired behavior in many cases. Sometimes,
however, it is necessary to pass data to all tiles in all views. An example of this is sharing user-specific
configuration data. A user configuration tile running in the shell might allow a user to set application-wide
properties. The global context can be used to pass these properties to all tiles. In general, tiles in the shell can
only use the global context, since they are not associated with a specific view.
In certain cases it is not required to have data that is exchanged between tiles to be persisted in memory or on
disk. The view context is stored in memory and persisted alongside with the tile and layout information when
a user saves a view on the server. The global context is only stored in memory throughout a user session. The
third option to share data between tiles is to use the messaging APIs. This option is specifically recommended
for use cases that require a transient exchange of data between tiles. Using the messaging APIs, tiles can send
information to any other tiles running in the application (not restricted to a view) that are listening to a specific
namespace and subject name.
Leveraging the view context can add significant usability and productivity boosts to Mosaic application. To
fully leverage the context, a couple of guidelines need to be considered when developing tiles:
It is necessary to always check the current context on initialization of a new tile. When a new tile is being added
to a view the context might be already set with information that could be useful to the new tile. It has to be
ensured, that a tile consumes the content properly and takes action in the tile Ul (e.g. if the context includes a
customer ID and the newly loaded tile provides a list of customers, the customer currently set in the context
should be activated and highlighted in the list). Another case to consider is that users might be able to save the
view with context (assuming that that is enabled in the composite RIA). In that case a tile needs to reload the
context when the user opens the view. It is also mandatory that a tile is listening for changes in the context that
it can react to these changes (e.g. retrieve and display detailed information about the current customer in
Proper documentation of the inter-tile communication is recommended, including the names of the attributes,
the used APIs, and when the API is triggered. This information needs to be coordinated between all the teams
that develop Mosaic tiles. Currently, this cannot be automatically discovered in Mosaic. It is planned to
introduce a feature to handle the automatic inspection of inter-tile communication features of a tile in a future
Mosaic release.
Some use cases require loading initial configuration information into a tile. In Mosaic this information can be
stored within the Mosaic catalog in the /Resources directory. The information (e.g. an XML file) is then
available to all tiles via a URL. Since the catalog can be easily moved from development to test a test server
and finally to a production server, this ensures that the configuration information is always available in the
same relative path.
Communication between tiles and backend
Mosaic does not facilitate the communication between the tiles and backend application logic. Tiles can
leverage the same methods to communicate with backends that are used today for Flex or HTML applications.
For Flex tiles it is recommend leveraging LiveCycle Data Services to establish a robust and highly performing
connection between the tile and the server application logic. Tiles can also leverage BlazeDS, direct Web
Services or REST communication.
Services for initialization and backend communication
A service is ActionScript code that is loaded before the tiles of a Mosaic application are loaded and run (by
definition services do not have a Ul). Services can be used to implement an initialization hook used to setup
tiles or the Mosaic application, or to configure backend connections (e.g. LiveCycle Data Services channels or
web services). A tile can depend on services where services can be singletons (shared between multiple tiles)
or instantiated for each tile (referring to the service). When designing a Mosaic application keep in mind that
services cannot depend on services (i.e. nested services are not supported).
Additional information on Tile API's
» The LiveCycle Mosaic ES2 ActionScript Language Reference
- The LiveCycle Mosaic ES JavaScript Language Reference
Managing Assets in the Mosaic Catalog
All tiles are managed on the Mosaic server in the catalog. The catalog keeps track of all available tiles and their
metadata. Tiles can be uploaded and managed in the catalog using an XML description and running the
Java-based build tool Apache Ant. As part of the metadata, the user can configure the initial, maximum and
minimum width and height of the tile when loaded into a view. Additional metadata includes the tile name,
label, category, tags, description and icon, improving manageability and searchability of the catalog.
Besides tiles, the catalog service also manages services, template views, panels, style sheets and more.
A preview version of a visual catalog management tool is available in the Mosaic desktop client. A full version
of the visual catalog manager, as well as a catalog browser tile for end-users, will be available in a future
version of Mosaic.
Designing Composite RIAs
Mosaic applications are defined in XML and dynamically assembled during runtime on the client. The
application XML can be created in any text or XML editor, or even programmatically by another application.
The Mosaic desktop client includes an early preview version of a Mosaic application design tool that allows
editing and saving the application XML in the desktop client. A visual design tool is planned in the future.
The first section in the application XML references one or multiple catalogs used by the application. In this
section the application developer specifies the URIs and names of the catalogs that store the tiles used in the
application. Tiles in an application could be retrieved from multiple catalogs.
Next the shell of the application needs to be defined. The shell is the outer frame of the application that is
consistent, regardless of the specific view the user is working with. The shell typically includes a menu and the
view organizer, but it is completely configurable for custom applications. The shell supports different layout
managers, and can be configured in different ways (e.g. just top bar, side bar, bottom bar, L-shape, etc.). As a
next step, the tiles that should show up in the shell need to be configured and positioned. Generally it is most
efficient to start with a shell from one of the application samples provided and then customize it.
An Adobe-provided out-of-the-box component for the shell is the view organizer. It can be activated in the
shell by adding <view:Organizer height="x" width="y"/> to the application XML. The view organizer allows
users to access and load their saved custom views. The APIs used by the view organizer are also part of the
runtime SDK allowing custom implementation of tiles that can manage custom views.
The other major aspect of Mosaic application design is to configure the default application views.
Fundamentally, a view is the container for one or multiple tiles. Tiles can be located on one or multiple panels,
each panel can have a different layout manager, and panels can be nested. There are two types of layout
managers: static layout managers (users cannot modify tile position) and dynamic layout managers (users can
re-arrange tiles). Available static layout managers include absolute layout, column layout, row layout, flow
layout, horizontal layout, vertical layout and tile layout (similar to the Flex 4 tile layout). The dynamic column
layout and the dynamic row layout are dynamic layout managers that allow re-arranging tiles. Nested panels
with different layout managers can be used to achieve complex layouts. Additionally, the panel XML can define
the name of the panel, if tiles in the panel have chrome or are displayed without chrome and if the user can
delete them or not.
Deploying Composite RIAs
Mosaic applications are deployed to the Mosaic server using Apache Ant. A sample Ant script to deploy Mosaic
catalogs and applications is provided with Mosaic. Once the catalog XML description, SWF files for tiles and
application XML are loaded in the proper folders, Ant will deploy them on the server. This procedure works
exactly the same regardless if the development server is running on Tomcat or the production server is running
on the LiveCycle Foundation in a Java EE server. Once the application is deployed, it is accessible in the
desktop client and browser client.
This standard deployment model is easy to automate via scripting, and can be used to move Mosaic
application and catalog deployments from development to test and then to production servers.
Browser Client
Mosaic applications can be directly accessed via an application specific URL (like http://server:8080/mosaic/#/
applications/<application_name>) in the browser. If not already authenticated, the user will be required to log
in. The Mosaic application itself runs within the Flash Player.
Desktop Client
The Mosaic desktop client runs on Adobe AIR. Users can install the runtime client on their desktop and - based
on their permissions - access different perspectives:
Runtime Perspective
The runtime perspective allows users to run Mosaic composite applications straight from their desktop. A
separate launch window displays a list of all applications available to the specific user.
Design Perspective
The design perspective is available as a preview in Mosaic ES2. It allows developers to create and modify
Mosaic applications. The preview version enables developers to change the composite application XML within
the client and re-deploy it to the server. A visual design tool is planned for future versions.
Catalog Management Perspective
The catalog management perspective is the administration tool for all Mosaic catalogs. It allows users to
visually browse the catalog. In Mosaic ES2 it is provided as a preview version.
End-user functionality
Mosaic provides a range of out-of-the box end-user functionality that can be enabled in custom Mosaic
applications. The IT department can configure (or completely disable) all of the functionality.
If enabled by the Mosaic application (turned on out-of-the-box view management or custom built thought
APIs), users can add new views and new panels to an existing application. Tiles can be added to existing panels
or to new panels. Furthermore, users can rearrange or delete tiles from panels. A user can save the customized
view with a new name. The saved view immediately shows up in the view organizer, a shell component that
allows users to browse saved views. Saved views can later be opened again in the applications or can be
deleted if no longer needed. Views and Panels can be renamed and for deleting them a confirmation is
required to avoid accidentally losing the work results of the view or panel.
Authentication, authorization and single-sign-on
Authentication is the process of confirming the identity of the user. Out-of-the-box Mosaic supports
authentication based on username and password using HTTP Basic Authentication and Web Form Login. Users
can be managed directly in the LiveCycle user management system, which also allows synchronization with
external user management systems (LDAP and databases). Since the Mosaic authentication is based on the
Spring Security framework, administrators can customize the mosaic-context.xml file and use any Spring
Security mechanism. The Spring Security framework provides integration with NTLM/Active Directory, LDAP
Directories, major SSO vendors, OpenID, as well as simpler arrangements such as JDBC database with
username and passwords and built-in Application Server mechanisms.
Authorization is the function of specifying access rights to individual resources (like Mosaic applications, tiles
or other asset). For example, a view can contain tiles with different authorization rules. Depending on the user
accessing the view different tiles are shown which allows to provide different perspectives just by
authorizations. Authorization utilizes the established identity to make decisions about what the user is allowed
to access and what types of access are permitted. Users and roles, upon which authentication and
authorizations may be based, are configured for the standalone Tomcat server in <war>/META-INF/spring/
mosaic-context.xml. These users and role definitions are not needed when running Mosaic on LiveCycle as the
users and roles defined for LiveCycle are used. Beyond standard role-based auth entication, Mosaic also
provides a policy decision engine based on XACML. XACML allows the configuration of complex policy rules
including roles, user attributes, date ranges, and time of the day. The default system policy is defined in <war>/
WEB-INF/classes/config/mosaic/xacml/mosaic_default_asset_policy.xml. This default system policy allows
users to view, designers to write and view, owners to change ownership and remove policies, and policy
administrators to manage policies. This default system policy, which applies to all unprotected assets, may be
modified or custom policies may be deployed to the Mosaic server and applied to specific assets, completely
overriding the system policy.
The Mosaic client also respects server session timeouts. The server administrator can set session timeouts to
any time range or inactivity period. The client handles this by performing a status ping every minute. If the ping
results in a redirection to the login page, the client will require the user to re-authenticate before continuing.
The objective of single-sign-on (SSO) is to make users more productive and eliminate separate logins to
different applications. Mosaic supports SSO, leveraging existing enterprise SSO solutions as well as SSO with
other LiveCycle services. Mosaic offers tile developers the ability to utilize the current user's Mosaic user
context to log in to other enterprise systems. This is achieved by providing an API in the Tile SDK that returns a
Base64-encoded SAML assertion available from the configured authentication provider.
The enterprise world is full of proprietary solutions for solving the single sign-on problem, and it follows that
there are many different ways Mosaic can be configured to work into those various SSO solutions. Using the
Spring Security framework as the basis for securing Mosaic opens many options.
The Spring Security framework provides the ability to integrate with Kerberos/SPNEGO. This configuration
requires that the client runs only on browsers that support and are configured for Kerberos/SPNEGO (i.e.
Internet Explorer, Firefox, Safari).
The Spring Security framework also supports the use of HTTP-based SSO solutions, such as CA SiteMinder.
This configuration is known as the "PreAuthentication” filter (i.e. the user was authenticated by some other
web entity prior to reaching the servlet). This filter can be configured to check for the standard HTTP headers
and/or cookies provided for this type of SSO, such as SM_USER and SM_SERVERSESSIONID in the case of
Finally, the Spring Security framework provides JAAS (Java Authentication and Authorization Service)
integration. JAAS is a long-time standard in the Java world that is well supported across application servers.
This integration is very powerful because many systems have a JAAS interface. The Oracle Application Server
SSO provides out-of-the-box JAAS interfaces for integrating web applications to Oracle’s SSO solution. Many
enterprises may find that there is an existing JAAS interface that they have already written for integrating into a
legacy authentication system. This configuration is known as the "JaasAuthenticationProvider”.
A catalog stores tiles, view templates, panels, style sheets and other components of a Mosaic application.
A context is a data store that allows sharing of data between multiple tiles. It can include both simple and
complex objects. Tiles can both get data from and store data in the context. There are two different types of
context. The view context is the context to share data between tiles in one view (this context should be used
by default for most cases). A global context allows sharing of data between all tiles in all views of a Mosaic
application (to be used for global preferences and similar use cases).
A layout controls the arrangement of tiles in a panel. The required layouts are configured when designing
Mosaic applications. Dynamic layouts (currently dynamic column layout and dynamic row layout) allow users
to change the arrangement of tiles in a panel.
Mosaic application
A shell that can hold one or multiple views defines a Mosaic application. A Mosaic application can be accessed
via a specific URL in the browser or via the Mosaic desktop client. Use cases for Mosaic applications include:
Financial Advisor Desktop, Support Desktop, Sales Workplace, and Case Worker Desktop.
Mosaic browser client
Users can access Mosaic applications using a web browser with Adobe Flash Player installed.
Mosaic desktop client
The Mosaic desktop client is an Adobe AIR application that allows users to access Mosaic applications (i.e. the
runtime perspective). It also includes the design perspective and catalog manager perspective (only available
as a preview).
Mosaic server
The Mosaic server includes the catalog that stores application components, handles persistence of users’
custom views and handles identity/entitlement management. The server is implemented in Java using the
Spring framework. The server can run on Apache Tomcat (for development environments) and on the Adobe
LiveCycle ES2 Foundation (J2EE-based app servers), which is recommend for production environments.
A panel can consist of one or multiple tiles and panels can be nested. Panels visually group together tiles in a
view. Panels can group tiles by task or some other category and configure a unique layout for each panel. It can
be allowed that users add and remove panels from a view.
A shell and one or multiple views running within the shell define the user interface of a Mosaic application. The
shell layout is configurable for each Mosaic application. A shell typically contains key functions that need to be
available to end users throughout using a specific Mosaic application including a shell menu, view organizer
and other custom tiles.
Shell menu
The shell menu is a specific tile located in the shell of a Mosaic application. It organizes and lists Ul
components (e.g. pre-configured views or tiles) that are available to a user. For example, the user can add a
new tile to an active panel by selecting it from the shell menu. Adobe provides a sample Flex shell menu that
can be used as a starting point to create custom shell menus.
For more information and
additional product details:
Adobe Systems Incorporated
345 Park Avenue
San Jose, CA 95110-2704
Tiles are the building blocks of Mosaic applications. Typically a tile encapsulates a rich internet application or
the user interface for a backend application. A tile can be implemented as a Flex application, a Flex module or
HTML application. Using the tile SDK, developers can leverage Mosaic framework capabilities (like the shared
context) in their tiles. Tiles can be used both in views (grouped in panels) and in the shell.
" Sep. 2, 2009 | Welome, Andy Tanaka [Logout]
EN Finance
dor kei application
Tem a Fundamentals:
Campbeil 604-877-5522 has 42 F 3
Harris Monk 776-561-6574 Medical History Com É N
john Jacobs 774-656-8787 pican 3 Rizk Cope Lace
> а Month by premium will be y
Ripley d03-555-5987 Chent Information:
Mame Jahn Jacobs
Morgan 604-877-8767 Modifications:
Addr ess 2974 Carmden La, San Jose, CA 95175 -
Chiu 789-855-1237
Phone 774-656-8787
ZI KO | sa
E overdue Details:
B today Vils pt &
next day че нд Я 150 ibs
ii 20
About client coverage: Ll accepted as is’
Connect 19 P | Mamie av 234587AT897L0L accepted &s modified
Rye ‘Woodard CORRE ' i pr
y declined
Type Whole Life
46 applications to review Dis 3100.000
x tb pie cs EET ENT
id Death $500,000
curity & Legal | Report Email Fraud | Sitemap
Amy references to Finance Co
ned to refer to any sctual erpanizatien
Tile SDK
The tile SDK comprises JavaScript and ActionScript libraries that developers can use to create Mosaic tiles and
access the Mosaic runtime APIs. The tile SDK also includes the API documentation. There are separate versions
of the Flex Tile SDK for Flex 3 and for Flex 4.
A Mosaic view contains one or more panels in which tiles are laid out to suit the user's needs. Mosaic
applications contain one or more views. Users can save views on the Mosaic server and retrieve them using the
view organizer, which can be enabled or disabled for each Mosaic application.
View organizer
The view organizer is an optional Adobe-delivered Ul component in the shell. It is used to access views that
were previously saved by the user and load them back into the Mosaic application. Users can only see the
views in the view organizer that they saved (they cannot see views of other users).
We welcome your comments. Please send any feedback on this technical guide to
Adobe, the Adobe logo, Flex, LiveCycle, PostScript, and Reader are either registered trademarks or trademarks of Adobe Systems Incorporated in the
United States and/or other countries. All other trademarks are the property of their respective owners.
© 2010 Adobe Systems Incorporated. All rights reserved. Printed in the USA. Jan/13/10
Adobe LiveCycle Mosaic ES2 Datasheet
Product summary
Adobe LiveCycle Enterprise Suite
2 (ES2) is a software suite that
extends the value of existing
back-end systems by engaging
users with collaborative rich
Internet applications (RIAs)
and guided forms, streamlining
internal processes, managing
correspondence, and strengthening
information and document security.
Sample use cases
Case management
Financial advisor desktop
Sales workplace
Self-service applications
Adobe’ LiveCycle’ Mosaic ES2
Create intuitive, contextual workspaces for better decision making
Increase productivity and improve the quality of critical business decisions by providing
knowledge workers with real-time, contextual information from multiple sources in a
single, personalized view. Assemble composite rich Internet applications (RIAs) that
deliver superior flexibility, ease of use, and performance.
Improve user productivity
LiveCycle Mosaic ES2 lets organizations deliver intuitive, highly productive user-centric applications that
provide complete context to business users in their daily work. Developers can extend existing enterprise
applications by exposing their business logic and user interfaces into application “tiles.” Tiles are
context-aware Ul application components that can be assembled to create unified views that best suit
the user's work habits and specific needs. Users no longer need to sign into multiple applications or drill
down through each of them separately, saving time and effort.
Less training is required for new employees, because LiveCycle Mosaic provides an intuitive experience,
eliminating the need to learn the different features and navigation systems of each underlying source
system. The new Ul gives users only what they need from the back-end systems. Because LiveCycle
Mosaic maintains a persistent state, any changes made by the users, such as customizing the layout,
creating new views, or drilling down into information, are retained, so users don’t need to repeat the
same steps every time they return to the application.
Make better informed decisions
Mosaic tiles can be easily designed to be context-aware, so when the user makes a selection or updates
an entry in a tile, other tiles sharing the same context are automatically refreshed. For example, a
procurement manager can use a procurement application that contains tiles for current inventory levels,
product specifications, vendor information, and standard documents such as contracts and forms. The
inventory tile displays a dashboard alerting the manager that a part is running low. When the manager
clicks on the part, the other tiles in the view are immediately refreshed to show additional data about the
part, such as detailed specifications from the PLM system, current or pending product changes, and lists
of appropriate or preferred suppliers. By having all this information in one view, the manager can easily
select the correct suppliers and kick off the Request for Quote process to source it.
Mosaic also supports role-based access, so others who need this information, such as the supplier
manager, shop floor supervisor, management team, and even external vendors, can access and interact
with the same tiles in views customized for them.
Accelerate application development
Mosaic uses a composition approach to enable developers to build applications faster. Instead of building
a large monolithic application, developers can easily create application component tiles that expose
business logic from existing Flex and HTML applications, extending the return on existing investments.
Developers can work more effectively as a team by creating and testing different tiles in parallel and later
assembling them into an application. Tiles, default panels and views can also be stored in the Mosaic
Catalog for sharing with others or for reuse in future projects.
Using tiles also simplifies ongoing maintenance because, unlike with current monolithic applications,
developers can update and roll out one application component at a time instead of having to redeploy
and retest the whole application.
Mosaic includes out-of-the-box skins, shells, and layout managers to help developers quickly
create a variety of intuitive interfaces. They can also use their own skins and shells to brand the
applications with their own look and feel.
Simplify integration with core business systems
Extend your current investments by integrating application tiles with your existing business logic
and infrastructure using LiveCycle Data Services ES2. The open adapter architecture enables
connection with Spring, JMS, Hibernate, EJB, and other data persistence mechanisms. Backed by a
powerful data management API and connectors, LiveCycle Data Services simplifies client-server
data communication challenges from multiple sources, including collaborative content shared
across application tiles in real time.
Adobe LiveCycle Mosaic ES? features
Componentize applications
Mosaic makes it easy for developers to create reusable application tiles by updating existing Flex
and HTML code or by creating brand new tiles.
Design custom shells
Design application shells, including menu and shortcut bars, in a variety of layouts. You can also
create multiple shells for different use cases—for example, one for employee self-service and
another for a trading desktop.
Make tiles communicate
Design tiles to communicate with each other through either shared context variables or a publish
and subscribe messaging model by just writing a few lines of code that invoke the Mosaic runtime
APIs, which are available in both Adobe ActionScript’ and JavaScript.
Share and reuse application elements
Developers store tiles, views, panels, style sheets, graphics, and context in the Mosaic Catalog so
others can reuse them in their own projects, speeding application development.
Permissions are supported on application and on tile level
Mosaic comes with user management capabilities allowing administrators to maintain a database
of all users and groups, which can be synchronized with one or more third-party user directories.
These capabilities provide authentication and authorization and can also integrate with existing
Single Sign On (SSO) providers to ensure Mosaic applications participate in the company’s SSO
Empower end users
Business users access Mosaic using a browser-based client or a desktop client based on Adobe AIR:
They can add, delete, and rearrange tiles to customize their views and create and save new ones
that retain a persistent state.
Improve responsiveness
Because communication between tiles is done on the client, Mosaic applications can serve up data
faster and reduce the load on back-end servers.
Simplify integration with enterprise applications and processes
Using LiveCycle Data Services ES2, developers can easily connect Mosaic tiles with existing
enterprise systems. And with the full suite of LiveCycle ES2 modules, Mosaic applications can be
designed to enable users to participate in, drive, or manage end-to-end business processes.
System requirements
Adobe LiveCycle ES2 supports market-
leading operating systems, web application
servers, and databases. For product-specific
platform support and system requirements,
For more information
Product details: www.adobe.
Adobe Systems Incorporated
345 Park Avenue
San Jose, CA 95110-2704
docket application
Sep. 2, 2009 | Welcome, Andy Tanaka [Logout]
Harris Monk
John Jacobs
403-556-5987 |
Medical History
Client Information:
I overdue
I today
next day
46 applications to review
Pending Applications — © Connect to Agent =
Connect to
Rye Woodard
“Must be online to use it
Name John Jacobs
Address 2974 Garden Ln.. 5an Jose, CA 35125
Phone 774-656-B787
Email ijacobsé
Height &
Weight 150 lbs
EMI 20
About client coverage:
Proposal Number
Whole Life
Select a Client = a Application Details - 0
| Work Phone
Risk Assessment
Monthly premium will be: $124.56
(_) accepted as 'is'
(_) accepted as modified
(J) declined
Additional documents...
About Us | Careers | Security & Legal | Report Email Fraud | Sitemap
Diversity & Accessibility | Important Notice on Trading in Fast Markets | Online Access Agreement
Copyright 2009 Finance Corporation All Rights Reserved,
Any references to Finance Corporation and its related logo is for Adobe demonstration purposes only and is not intended to refer to any actual organization.
With this Mosaic application, an insurance underwriter can see the entire risk profile
for a potential customer to decide whether to approve the request for coverage.
Adobe, the Adobe logo, ActionScript, Adobe AIR, AIR, Flex, and LiveCycle are either registered trademarks or trademarks of Adobe Systems Incorporated in
the United States and/or other countries. All other trademarks are the property of their respective owners.
© 2010 Adobe Systems Incorporated. All rights reserved. Printed in the USA.
91021603 6/10
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF