TIBCO ActiveMatrix applications assume different forms in different phases of the application life cycle.
In the design phase a TIBCO ActiveMatrix application consists of one or more composites. Each application has a root composite. A composite contains components, services, references, and properties. The components, services, and references depend on custom features and resources. Services, references, and properties promoted to the root composite comprise the public interface of the application.
The output of the design phase is a distributed application archive (DAA). A DAA contains features and an application template, which consists of the root composite and a set of related configuration files: nested composites, resource templates, WSDL files, and substitution variable files.
In the administration phase, you create an application by instantiating an application template. The product installer adds product application templates to Administrator. When you upload a DAA file to Administrator, Administrator extracts the application template and (optionally) the features and resource templates.
You can configure the application by setting properties, logging configurations, and substitution variables.
You can add bindings to services, promote services and references to the environment, and wire services and references to services and references in other applications or environments. You also specify a distribution of the application to the runtime infrastructure. You can explicitly distribute application fragments—components and bindings—to one or more nodes or you can specify that an application should be distributed to the same nodes as another application. When you deploy the application, Administrator applies the distribution and the configuration. Features are automatically distributed with components, but resource instances required by the application must be manually installed into nodes before deployment. Life cycle operations on the application are translated into life cycle operations on the application fragments. You can also start and stop application fragments.
The following figure illustrates the application artifacts across the application life cycle.
26 | Applications
Figure 7: Application Life Cycle
Applications | 27
Chapter
3
Platform
The TIBCO ActiveMatrix platform has four functional areas—design, runtime, administration, and governance—that address all phases of the distributed application life cycle.
Topics
• Design
• Runtime
• Administration
• Governance
Design
TIBCO ActiveMatrix design activities are performed in TIBCO Business Studio, an extension of the Eclipse SDK Workbench. In TIBCO Business Studio, analysts, architects, and developers, design, implement, configure, test, and package TIBCO ActiveMatrix applications. Beyond the standard Eclipse Workbench features, TIBCO Business Studio provides:
• Wizards and editors for creating projects and applications.
• Resource template editors for resources such as LDAP and JDBC connections, security providers, and so on.
• Editors for specifying intents and creating policies for governed objects.
• A distribution editor for specifying constraints on how application components are distributed across nodes.
• Rapid application deployment features that support deploying and testing applications on a local deployment environment.
• Tool for generating scripts to deploy applications to a remote deployment environment.
• Support for debugging applications running in a remote deployment environment.
For information on TIBCO Business Studio, see Composite Development.
30 | Platform
Runtime
TIBCO ActiveMatrix employs a three-level runtime environment consisting of hosts, nodes, and application fragments. A host runs TIBCO ActiveMatrix platform services, manages the life cycle of nodes, and maintains software features and resources shared between nodes. Nodes run application fragments.
The following figure illustrates a possible configuration of hosts, nodes, and application fragments. The host manages node A and node B. Application 1- Fragment A runs on node A. Application 2's fragments are distributed over nodes A and B.
Figure 8: TIBCO ActiveMatrix Runtime
Hosts
A host is the runtime object that serves as the point of contact between nodes and Administrator. Hosts perform operations such as software distribution, node life cycling, and application deployment. It is not necessary for a host to be running to perform administrative operations. Administrator queues operations and processes them when the host and the nodes it manages are available.
A host has a software repository that contains the application templates, features, and resource adapters available to the nodes managed by the host.
Hosts are typed. In the current release, the only supported type is TIBCO Host. TIBCO Host is the TIBCO native host implementation.
A host is bound to a single Administrator server at a time. Hosts can contain nodes from multiple environments within one Administrator server.
It is recommended that a host should manage nodes belonging to only one environment.
Nodes
A node is the runtime environment for applications. Nodes exist in an environment and are managed by hosts. When managed by a host, a node runs in its own OS process and JVM. You can configure a host with multiple nodes. Nodes act as sandboxes for applications.
The reasons to use multiple nodes include:
• Increase throughput.
Platform | 31
• Run different versions of software and limit the set of affected application fragments when updating software versions.
• Allow applications to use different resource instance configurations of the same name.
• Enable fault tolerance.
• Implement various security policies by limiting access to certain nodes and resources.
The reasons to share a node include:
• Share resource instances between applications such as thread pools and database connection pools.
• Communication between components in a node avoids serialization overheads.
• Reduced overall memory utilization.
Application fragments are components or bindings of an application that are distributed and deployed to nodes. A fragment can be distributed to many nodes, and a single node can run many fragments. To increase throughput for a component or binding you can deploy multiple copies of the fragment to multiple nodes.
A node has a set of product and features shared by resource instances and application fragments running on the node. You can upgrade or downgrade the features to match the feature versions to those available in the software repository.
The following figure depicts a configuration of environments, hosts, and nodes that illustrates the flexibility achieved with a multinode setup. The two environments are assigned to groups of users that have responsibility for a specific phase of the application life cycle: Development and Production. Isolation between the groups is achieved by creating two nodes on each host and assigning them to different environments. Nodes A and B are located on Host 1 and nodes C and D are located on Host 2. Nodes A and C are managed by the Development environment and nodes B and D are managed by the Production environment. In addition, access to a JDBC resource is restricted to the nodes in the Production environment.
Figure 9: Multiple Node Scenario
Features
A feature is a software package that contains plug-ins, which in turn contain component implementations and libraries. A feature is identified by an ID, a multi-part version, and its dependencies on other features.
There are two types of features: system and shared library. System features are part of a TIBCO ActiveMatrix product or contain the drivers that are installed using TIBCO Configuration Tool. Shared library features contain component implementations and libraries. When you create a distributed application archive containing a composite, you can package the composite's required features in the application archive or you can package the features as a standalone distributed application archive.
When you upload a distributed application archive containing a composite in Administrator you can optionally
32 | Platform
an application, Administrator automatically distributes the features (and any features that it depends on) to the host that manages the nodes on which the application is distributed and installs the features on those nodes. You can also manually install features on the other nodes managed by that host.
Resource Templates and Instances
Resource templates are defined at the enterprise level. You create resource templates in two ways:
• Manually via actions in the command-line and web interfaces
• Automatically when you import them during the procedure to create an application In either case you must have the enterprise permission Create Resource Template.
A resource instance is a runtime object that represents a resource, such as an HTTP, JDBC, or LDAP connection.
A resource instance instantiates the configuration defined in a resource template and makes it available to services running on a node.
Applications, components, bindings, logging appenders, and resource templates can have properties whose value is the name of a resource instance. For example, an HTTP client resource template's SSL property configuration includes a property whose value is the name of SSL Client Provider resource instance. Figure 10: TIBCO Business Studio Resource Instance on page 33 and Figure 11: Administrator Resource Instance on page 33 show how to set a resource instance property in TIBCO Business Studio and Administrator respectively.
Figure 10: TIBCO Business Studio Resource Instance
Figure 11: Administrator Resource Instance
The following figure illustrates a possible configuration of hosts, nodes, features, resource instances, and application fragments. In the figure the host has three product features: PF1, PF2, and PF3, one custom feature CF1, and one resource template A. Custom feature CF1 is dependent on product feature PF2. On Node A all the available features are installed. Node B has one installed product feature and one installed resource instance. Application 1- Fragment A on node A is dependent on two product features: PF1 and PF3. Application 2- Fragment A is dependent on custom feature CF1 and product feature PF1. Application 2- Fragment B is dependent on resource instance A. Application3 - Fragment A is dependent on the product feature PF3.
Platform | 33
Figure 12: Runtime Configuration
34 | Platform
Administration
TIBCO ActiveMatrix administration is supported by TIBCO ActiveMatrix Administrator and TIBCO Business Studio. In TIBCO ActiveMatrix Administrator, administrators configure environments and messaging buses, register hosts and associate them with environments, provision nodes with features and resources, and deploy, configure, and manage applications. In TIBCO Business Studio developers deploy and debug applications.
The following figure illustrates the relationship between TIBCO ActiveMatrix Administrator and the objects it manages. This section provides an overview of Administrator, environments, and Messaging Bus. Runtime on page 31 discusses hosts, nodes, applications, features, and resources. Governance on page 39 discusses TIBCO ActiveMatrix Runtime UDDI Server.
Figure 13: TIBCO ActiveMatrix Administration
TIBCO ActiveMatrix Administrator
TIBCO ActiveMatrix Administrator consists of the following components:
• Administrator server
• Administrator server clients – Administrator web interface
– Administrator command-line interface
Platform | 35
– TIBCO Business Studio
In the following figure the Administrator web interface is opened to the welcome screen.
Figure 14: TIBCO ActiveMatrixAdministrator
The communication channel between Administrator server and its clients can be secured with SSL.
Administrator server hosts TIBCO Credential Server, which provides credentials to secure communication between TIBCO ActiveMatrix Administrator server, hosts, and nodes using SSL.
The node on which the Administrator server runs product applications that provide various platform services:
Function Service
Aggregates log data from nodes and saves to persistent store.
Log
Stores and retrieves large payloads for log entries.
Payload
Aggregates performance data from nodes and saves to persistent store.
Monitoring
Servers
Administrator servers interact with other servers:
• Database - maintains Administrator server configuration, performance, log, and payload data
• Authentication realm - maintains user data
• Notification - propagates status messages between Administrator server, hosts, and nodes
• Messaging Bus - propagates messages between applications
• UDDI server - (optional) maintains published service data
The communication channels between Administrator servers and other servers can be secured with SSL. For information on SSL support, see the installation manual for your product.
36 | Platform
Enterprise
In the TIBCO ActiveMatrix platform the term enterprise has meaning in two different contexts: runtime and administrative.
In the runtime, enterprise refers to the collection of runtime objects that share the Enterprise Message Service server that functions as the notification server. The enterprise is identified by a name specified when you create an Administrator server.
In Administrator, enterprise refers to the top-level administration object. An enterprise contains environments, hosts, and objects shared between all the environments in an enterprise.
Environments
An environment is a logical grouping of applications and nodes. An Administrator server can have multiple environments. For example, you can define environments distinguished by product life cycle function such as development and production, by geographical area, or by business unit.
Environments provide a way to isolate one group of applications and nodes from another. This is useful for security, optimizing network traffic (each environment has its own Enterprise Message Service server for service bus communication) and visual organization in the Administrator UI.
Environments contain the following types of objects:
• Applications The services and references defined by an application can be promoted to the application's environment. Services and references promoted to the environment level can be wired to each other. The following figure illustrates a service and reference exposed by a component, promoted to the composite level, promoted again to the environment level, and wired between the promoted reference and service.
Figure 15: Cross Environment Wires
• Nodes Nodes are runtime sandboxes that run application logic. Node names must be unique within an environment and within a host.
• Messaging Bus configuration
Platform | 37
Administrator Environment
The environment containing the node on which the Administrator server runs, SystemNode, is named SystemEnvironment.
Messaging Bus
An environment's Messaging Bus is the communications backbone that mediates message exchange between service consumers and providers. When a consumer makes a service request, it is the responsibility of Messaging Bus to locate providers that offer the service and deliver the message to a provider.
Messaging Bus enables service virtualization. With service virtualization, a reference does not need to know about the binding details of the service with which it is communicating. It only needs to know the name of the service. Service virtualization allows applications within an environment to communicate without requiring the applications' promoted services and references to have bindings.
For information on TIBCO ActiveMatrix Administrator, see Administration.
38 | Platform
Governance
Governance involves the application and assurance of organizational mandates and guidelines. In the SOA realm, operational governance assures service execution, ensuring that services are behaving according to the specified mandates and guidelines. It can include service monitoring, resource optimization, fault tolerance and access control. Several features in the design, runtime, and administration components of the TIBCO ActiveMatrix platform support operational governance. At design-time, TIBCO Business Studio allows application developers to specify intents and policy sets. At administration time, TIBCO ActiveMatrix Administrator supports metrics collection and monitoring and credentials that support identity management.
Policy Management
Policy management involves specifying a capability of or constraint on a governed object—composite, component, service, or reference—to affect runtime behavior such as security, reliability, transactions, threading, and quality of service. Such constraints and capabilities are managed separately from the core business logic of your application. To enable policy management, an application designer specifies intents and policy sets.
An intent describes abstract constraints on the behavior of a component, or on interactions between components.
Intents let application designers specify requirements in a high-level, abstract form, independent of the configuration details of the runtime and bindings. Intents guide administrators as they configure bindings, policies, and runtime details.
A policy is a configuration that specifies the details that TIBCO ActiveMatrix needs to enforce a constraint declared in an intent. A policy can also be specified without an intent.
A policy set contains one or more policies. Adding a policy set to a governed object applies its policies at the object.
TIBCO ActiveMatrix support for intents, policy sets, and policies conforms to the SCA Policy specification.
Policies specified at design time are packaged into the deployment archive and enforced via a governance agent embedded in the TIBCO ActiveMatrix runtime.
Monitoring
The monitoring service and dashboards in TIBCO ActiveMatrix Administrator provide summary and detailed views into the operational health and performance of your TIBCO ActiveMatrix infrastructure, applications, and services.
The monitoring service is a TIBCO ActiveMatrix application that aggregates performance data from runtime objects.
Dashboards display runtime object performance statistics. They allow you to monitor the overall health and performance of infrastructure objects, applications, and resources.
Identity Management
Identity management is supported by security resource instances that you define in TIBCO ActiveMatrix Administrator and install in runtime nodes. The resource instances are invoked when policies are enforced by the governance agent.
Service Registry
TIBCO ActiveMatrix Runtime UDDI Server is a lightweight Universal Description, Discovery, and Integration (UDDI) registry and metadata repository that provides a standards-based system of record for discovering and publishing reusable business and IT services based on business classification and usage models.
Platform | 39
TIBCO ActiveMatrix Runtime UDDI Server can be used by other TIBCO ActiveMatrix components. When developing applications in TIBCO Business Studio you can search TIBCO ActiveMatrix Registry for services.
You can configure a UDDI server in Administrator so that when you deploy an application in Administrator, the service is automatically registered in TIBCO ActiveMatrix Runtime UDDI Server.
Figure 16: TIBCO ActiveMatrixRuntime UDDI Server Service Console
40 | Platform
Glossary
abstract component
A component whose implementation type is unspecified but whose interfaces and connections to services, other components, and references are defined. Abstract components can be used by system architects to specify the relationship of a component to other composite elements while deferring the choice of implementation type.
application
An instance of an application template.
application fragment
A component or binding running on a node.
application template
A root composite and a set of related configuration files including nested composites, WSDL files, substitution variable files, and resource templates.
binding
A transport configuration that specifies how messages are transported from service consumers to providers.
A service can have multiple bindings. A reference can have one binding.
bundle
An OSGi mechanism for grouping Java classes into a modular, sharable unit. In TIBCO Business Studio, a plug-in implements a bundle.
component
A configured implementation that provides a business function as a service and consumes other services.
composite
An assembly of components, services, references, and properties and the wires that encapsulate the connections between these elements.
distributed application archive (DAA)
A package for applications, libraries, and adapter archives. A DAA contains zero or more application templates, custom features, and an optional distribution.
distribution
Specifies a mapping of one or more application fragments to one or more logical nodes.
endpoint
A runtime object that manages each direction of the messages associated with the operation supported by a binding.
enterprise archive (EAR)
A TIBCO ActiveMatrix Adapters deployment package. An EAR file is created in TIBCO Designer and is assembled from one or more adapter archives. The EAR file is uploaded to Administrator when creating an application. During uploading and parsing an EAR file adapter configurations are identified, global variables are collected and an application template containing a TIBCO ActiveMatrix Implementation Type for Adapters component is created.
environment
A logical grouping of applications and nodes.
feature
A software package that specifies the plug-ins (bundles) it includes and the features on which it depends.
There are two types of features:
• System, which are defined by the TIBCO ActiveMatrix product.
• Shared library, which contain component implementations and libraries.
governed object
An element at which TIBCO ActiveMatrix can enforce policies. The following elements can be governed objects:
• Composite
• Component
• Component service or reference
• Promoted service or reference
• Binding host
Runtime entity that manages nodes and installed TIBCO ActiveMatrix software.
identity provider
A resource that encapsulates a user identity. The identity may be implemented using usernames and passwords or other credentials.
intent
Describes abstract constraints on the behavior of a component, or on interactions between components. Intents let application designers specify requirements in a high-level, abstract form, independent of the configuration
Describes abstract constraints on the behavior of a component, or on interactions between components. Intents let application designers specify requirements in a high-level, abstract form, independent of the configuration