These pages provide an introduction to the structural design of AquaLogic User Interaction (formerly called the Plumtree Application Suite). This introduction is focused on the areas required for development; for a general overview of the portal architecture, see the Deployment Guide for AquaLogic Interaction (Plumtree Foundation).
The following diagram summarizes the architecture of AquaLogic User Interaction. Scroll down for more information on each component and links to additional resources.
Note: This information represents a logical architecture and does not necessarily reflect a physical architecture. For example, the portal may actually be load-balanced across several machines, or an Image Service and a Remote Server might simply be different virtual directories on the same machine. In a large implementation, separate machines are used to run specific components of the portal.
AquaLogic User Interaction (previously called Plumtree Foundation) includes the following core components:
AquaLogic Interaction is the portal framework that integrates applications and ALI components into a cohesive Web-based environment.
The User Interface (UI) handles incoming HTTP requests, builds HTML responses, and returns the appropriate portal pages to each client.
The portal hosts Integration Services that integrate functionality from remote services, and handles gateway and tag transformation for remote content.
The Parallel Portal Engine allows the portal to access each remote server in parallel, resulting in faster, more efficient processing of the portal page.
The AquaLogic Interaction Image Service hosts images and other static content used by the portal and remote services. This configuration allows large static files to be sent directly to the client browser without impacting the portal. For details on the Image Service, see Adding Custom Images. (The servers hosting the portal and Image Service must be in the same domain.)
The AquaLogic Interaction Database is used to store metadata about portal objects and content in the portal Knowledge Directory. For details on types of metadata, see Settings Model.
The AquaLogic Interaction Automation Service manages portal job scheduling and implementation. The Automation Service also accesses remote content services and identity services that store and retrieve information in the ALI database.
AquaLogic Interaction Activity Services provide support for content management and collaboration. The following servers appear in most portal configurations:
AquaLogic Interaction Collaboration supports collaboration from the Web, the desktop, applications and projects. ALI Collaboration functionality can be accessed from remote services through the IDK.
AquaLogic Interaction Publisher allows publication & management of Web content for portals and Web applications, with forms-based publishing, branding, templates, workflow, approvals, and content expiration.
AquaLogic Interaction Process is an extended version of AquaLogic BPM, used to create and manage departmental, enterprise, and inter-enterprise business processes. ALI Process is designed to integrate with AquaLogic Interaction to provide an enhanced set of administrative features and end user experiences.
AquaLogic Interaction Analytics delivers comprehensive reporting on activity and content usage within portals and composite applications, allowing you to know and meet user information needs.
AquaLogic Interaction Studio allows you to create applications through a GUI, using a portal-ready framework.
AquaLogic Interaction Search indexes and searches all the documents, information, applications, communities, discussions, Web sites and other content accessible through the portal. Using the IDK PRC search API, you can query document (card), folder, user and Community objects from remote services using a standard request-response model.
Remote Servers host portlets, content services, and identity services written using the AquaLogic Interaction Development Kit (IDK), formerly called the EDK. These servers can be in different domains, on different platforms, even running in different countries. Remote services integrate functionality from a range of back-end applications, including databases, business applications, content repositories and search engines. For details on the remote services architecture, see Portal to Remote Server Communication and the Portal Gateway.
Authentication Servers handle user authentication for the portal, and can be accessed by remote identity services through the IDK.
The pages that follow provide more detail on key components and concepts used in ALI development.
If you are implementing basic portal customizations or creating portlets, it is important to understand the following basic concepts.
Portal to Remote Server Communication and the Portal Gateway: Services on remote servers communicate with the portal via HTTP and SOAP. This page explains the basics of communication between the portal and remote servers, and introduces the portal gateway.
Related Protocols: Services on remote servers communicate with the portal via HTTP and SOAP. This page provides detailed information on these standard protocols.
Application Integration: This page summarizes the range of options available for extending portal functionality and building integrated applications.
Portal components and remote services have access to settings in the ALI database. These settings are detailed on the following pages:
Settings Model: The ALI database stores a range of settings. These settings can be used by portlets and services to provide personalized functionality and seamless access to back-end systems.
Portal Settings (Headers): The portal uses a group of custom headers to communicate system and user configuration variables. These headers include information that can be used by services.
If you are implementing advanced UI customizations or portal component replacement, the following pages provide detailed portal architecture information.
Portal UI Layers: This page describes the major portal UI projects and how they depend on each other.
MVC Architecture: This page provides an introduction to the Model-View-Control (MVC) design pattern used throughout the portal UI.
Activity Spaces: This page shows how Activity Spaces group multiple task-specific actions into a logical set and provide base functionality.
Session Management: This page introduces the Sandbox Session Manager, where UI developers can store data on the session.
PEIs: This page explains how the Programmable Event Interface (PEI) framework defines a set of user actions that fire programmatic events that allow you to execute custom code without editing the portal source code.
Request-Control Flow: These pages summarize what happens when a request is made by taking a look inside the Interpreter to see some of the common checks that are processed for each request, exploring the relationship between the Interpreter and Activity Spaces, and illustrating how control flows from one to another.
For instructions on how to get started, see the next section, ALI Development Environment. For a full list of topics, see the table of contents.
Next: Portal to Remote Server Communication and the Portal Gateway