When you configure your implementation, note that e-Biz Impact components have a hierarchical relationship.
Figure 1-1: Component hierarchy
Clusters A cluster is the highest-level logical component of the e-Biz Impact architecture and coordinates the activity of controllers. Each cluster can contain one or multiple controllers. Clusters reside within a domain, which provides a logical grouping under which clusters can be run. Domain types might include Development, Testing, or Production. The default domain is Impact.
A cluster represents a container for a single, distinct e-Biz Impact environment. Each e-Biz Impact instance (installation) can have multiple clusters, which can be local or remote. Multiple clusters allow for development, testing, production, or load-balancing schemes.
When you save a cluster node in the Configurator (right-click a cluster in the tree view and select Save), the resulting XML file (<cluster_name>.xml) contains all configuration information for a specific cluster and references the individual configuration files for each controller and its associated applications.
To configure a cluster, see Chapter 2, “Configuring Clusters.”
Controllers Controllers manage e-Biz Impact applications. You can create multiple controllers for each cluster. For example, you can create a controller that includes an SFM and AIMs to interact with billing and inventory systems and another controller to interact with ordering and fulfillment systems.
To configure controllers, see Chapter 3, “Configuring Controllers.”
Applications Applications are controller components. You can have all SFMs and AIMs under one controller, or have each AIM and SFM have its own controller to distribute the load. e-Biz Impact applications include:
SFM – Store and Forward Manager applications that define the routing of information from application to application. SFMs handle message qualification, safe storage, translation, and distribution, in conjunction with the production objects that you build in TRAN-IDE.
Router – routers are used instead of SFMs in WebSphere MQ messaging implementations. Routers are similar to SFMs, but do not provide safe storage.
ODL – ODL applications, such as acquisition or delivery AIMs, built using MSG-IDE. ODL applications are responsible for gathering data from an endpoint application and delivering it to another endpoint application via the SFM.
Multisrv – Multisrv applications work with ODLs to support multiple simultaneous connections on a single socket.
MQAcq – configurable WebSphere MQ acquisition AIMs.
MQDel – configurable WebSphere MQ delivery AIMs.
Java – Java applications, such as Java-based AIMs.
Dfcsrv – applications that bridge distributed function calls to remote clusters; that is, applications that run on a different cluster.
Each application has its own configuration file that uses a naming convention of <cluster_name>.<application_name>.cfg.
An ODL AIMs have a project file that uses the naming convention <project_name>.prj. For example, the project file for an acquisition AIM might be acq.prj. One project file can also be associated with multiple AIMs.
To configure applications, see Chapter 4, “Configuring Applications.”
| Copyright © 2005. Sybase Inc. All rights reserved. |
|
|
