|
|
Revision/Update Information: This document supersedes the Installation and Configuration Guide for OpenVMS, Version 3.0
Software Version:
BEA MessageQ for OpenVMS Alpha, Version 4.0A
BEA MessageQ for OpenVMS VAX, Version 4.0A
Copyright 1998 BEA Systems, Inc. All rights reserved.
This software and documentation is subject to and made available only pursuant to the terms of the BEA Systems License Agreement and may be used or copied only in accordance with the terms of that agreement. It is against the law to copy the software except as specifically allowed in the agreement. This document may not, in whole or in part, be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine readable form without prior consent, in writing, from BEA Systems, Inc.
Use, duplication or disclosure by the U.S. Government is subject to restrictions set forth in the BEA Systems License Agreement and in subparagraph (c)(1) of the Commercial Computer Software-Restricted Rights Clause at FAR 52.227-19; subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013, subparagraph (d) of the Commercial Computer Software---Licensing clause at NASA FAR supplement 16-52.227-86; or their equivalent.
Information in this document is subject to change without notice and does not represent a commitment on the part of BEA Systems, Inc. THE SOFTWARE AND DOCUMENTATION ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND INCLUDING WITHOUT LIMITATION, AN WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. FURTHER, BEA Systems DOES NOT WARRANT, GUARANTEE, OR MAKE ANY REPRESENTATIONS REGARDING THE USE, OR THE RESULTS OF THE USE, OF THE SOFTWARE OR WRITTEN MATERIALS IN TERMS OF CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE.
BEA, BEA Builder, BEA Connect, BEA Jolt, BEA Manager, and BEA MessageQ
are trademarks of BEA Systems, Inc. BEA ObjectBroker is a registered
trademark of BEA Systems, Inc. TUXEDO is a registered trademark in the
U.S. and other countries.
All other company names may be trademarks of the respective companies with which they are associated.
In addition to your MessageQ license certificate, your MessageQ media and documentation kit contains:
| Item | Description | Format |
|---|---|---|
| Read Me First letter | Late-breaking news about this release and instructions for printing product release notes. | Hardcopy |
| Media | The distribution media appropriate for your system. | CD-ROM. |
| User Documentation | Introduction to Message Queuing | Online |
| Installation and Configuration Guide | Online | |
| Programmer's Guide | Online | |
| Client User's Guide | Online |
The MessageQ documentation kit contains the following user documentation:
Based on your role in the development and deployment of distributed applications using MessageQ , the following chart shows the recommended reading to learn and understand MessageQ quickly:
| Audience | Intro to Message Queuing | Install and Config Guide | Programmer's Guide | Client Guide |
|---|---|---|---|---|
| Technical Managers | X | |||
| System Managers | X | X | X | |
| Application Developers | X | X | X | X |
If you have a question you cannot answer using the manual or the online documentation, you can contact BEA Technical Support using any of the following methods:
When contacting BEA Technical Support, please be sure to have your e-mail address, company name, company address, machine type, and authorization codes available. It is also helpful to write down any pertinent error messages that can assist our BEA support team in diagnosing your problem faster.
The following sections provide contact information for documentation support amd for customer support.
If you have questions or comments on the documentation, you can contact the BEA Information Engineering Group by e-mail at docsupport@beasys.com or by telephone at 1.408.542.4193.
If you have any questions about this version of BEA MessageQ, or if you have problems installing and running BEA MessageQ, contact BEA Customer Support at one of the following telephone numbers, e-mail addresses, or through our BEA WebSupport at www.beasys.com.
When contacting Customer Support, be prepared to provide the following information:
The following conventions are used in this guide:
| Convention | Description |
|---|---|
| boldface type | Boldface type is used to distinguish routine call arguments and command parameters when they appear in text. New terms, also shown in boldface type, are defined in the glossary in the Introduction to Message Queuing. |
| system output | This typeface indicates system output or the exact name of a command, option, partition, pathname, directory, or file. This typeface also represents information displayed on the screen. |
| italic type | Italic type emphasizes important information, indicates variables, and indicates complete titles of books. |
| UPPERCASE | Words in uppercase indicate a command, the name of a file, the name of a file protection code, or an abbreviation for a system privilege. |
| lowercase | In format descriptions, words in lowercase indicate parameters or arguments to be specified by the user. |
| n | A lowercase italic n indicates the generic use of a number. For example, 19 nn indicates a 4-digit number in which the last 2 digits are unknown. |
| x | A lowercase italic x indicates the generic use of a letter. For example, xxx indicates any combination of three alphabetic characters. |
| Ctrl/ x | Ctrl/ x indicates that you hold down the key labeled Ctrl while you press another key or a pointing device button. |
| [ ] | In format descriptions, brackets indicate optional elements. You can choose none, one, or all of the options. (Brackets are not optional, however, in the syntax of an OpenVMS directory name or file specification.) Items in brackets in a query are the system's default answers. Press the Return key in response to a prompt to accept the default answer. |
|
.
. . |
The vertical ellipsis indicates the omission of information from an example or command format. |
| $ | Indicates the default Digital Command Language (DCL) prompt. |
| Return | Press the key labeled Return on the keyboard. |
| Enter | Type the information that follows and press the Return key. |
Part I contains the following information:
| Chapter | Describes... |
|---|---|
| Describes the operating system and hardware requirements for MessageQ installation and related procedures that you complete before installing MessageQ . | |
| Describes the step-by-step instructions for the installation and describes actions and considerations after the installation. |
This chapter discusses MessageQ basic terms and concepts as well as the planning, preparations, and systems requirements necessary for a successful installation of MessageQ software on OpenVMS systems.
The following topics are covered in this chapter:
The basic unit of MessageQ system management is the message queuing
group. A message queuing group is a collection of message queues that
are used by an application and that share access to a local
interprocess communications (IPC) facility and MessageQ Servers. A
message queuing group can support more than one application. Message
queuing groups are connected to one another using cross-group
connections over network links.
1.2.1 Supported Network Protocols
MessageQ has full heterogeneous communications capability for directing MessageQ messages across message queuing groups to any supported platforms.
MessageQ for OpenVMS software resides on top of DECnet and Transmission
Control Protocol/Internet Protocol (TCP/IP) networking software and
various intra-CPU communications mechanisms. On Digital VAX and Alpha
systems, MessageQ for OpenVMS supports communications using DECnet,
TCP/IP, LU6.2 protocol, and Ethernet.
1.2.2 Message Queues
The MessageQ message queuing bus provides the interprocess communications vehicle that enables applications to exchange information using queued messaging. The message queuing bus is a set of MessageQ message queuing groups that are configured to communicate with each other.
A message queue provides an area for an application to store and retrieve messages. A message queue is configured by the application developer and managed by MessageQ. To receive MessageQ messages, an application must be associated with at least one queue.
Message queues can be thought of as attachment points on the message queuing bus. A message queue is a physical resource with a unique ID within a group and can be permanent or temporary. A permanent queue exists whether or not a process is attached to it. A temporary queue exists only when a process is attached to the message queuing bus.
MessageQ supports three types of message queues: primary, secondary, and multireader.
The MessageQ environment consists of two kinds of processes:
All user processes in a MessageQ for OpenVMS message queuing group share several sections of global memory, run-time libraries (RTLs), and are served by the following MessageQ Server processes:
Figure 1-1 shows the servers and other process components of a message queuing group.
Figure 1-1 Components of a MessageQ Message Queuing Group
Naming is a MessageQ capability that enables applications to refer to queues by name instead of using their physical address in the MessageQ environment. Using naming separates applications from the specifics of the network environment and enables system managers to make configuration changes without requiring developers to change the applications.
MessageQ names can be defined to have a local or global scope. Local names are visible only to applications running in a particular group. Global names are available for use by any application attached to the message queuing group.
The MessageQ process that supports the global naming capability is
called the Naming Agent. The Naming Agent is responsible for creating
and managing the name space of global name definitions and for
name-to-queue address translation at runtime. In addition to its
built-in ability to support global naming, the MessageQ naming
feature can also use a Distributed Name Server (DNS) to provide global
naming capabilities. Refer to Chapter 8 for more information about
how to configure MessageQ global naming capabilities.
1.2.5 Global Memory
The MessageQ global memory provides storage for queue addresses and
allocates memory space for message queuing groups and message buffers.
Refer to Chapter 5 for more information on how to configure global
memory.
1.3 Configuring Distributed Systems Using MessageQ
The basic unit of MessageQ system management is the message queuing group. Message queuing groups consist of several message queues and share access to a common set of MessageQ Servers. Message queuing groups are connected to one another by network links.
Management of each message queuing group is a relatively independent task. Therefore, it is best to assign each MessageQ message queuing group a small set of application functions. Large or complex systems should be implemented as a network of queuing groups.
On large OpenVMS systems, the task of installing software is often assigned to a system manager who may not have detailed knowledge of each installed product. The system manager must learn the system resources required by each application, such as the size of the paging file, and amount of global memory and disk space required. OpenVMS SYSGEN parameters may have to be increased to accommodate installation of additional applications. To run MessageQ and it applications, the system manager must configure the system with the appropriate resources to support the needs of all message queuing groups.
While some MessageQ system parameters automatically adjust from default settings according to the load and available resources, the systems designer may have to make some decisions regarding MessageQ resources and then set the parameters accordingly.
Queues need to be assigned to particular application services and
various pools need to be sized. While this can be done in an iterative,
ad-hoc way during the development stage, it is better to have a
well-planned design and system model, and to make sizing decisions
based on this model.
1.3.1 Design Paradigms
There are many design paradigms for distributed systems. No matter which paradigm is used, it should produce an abstract description that describes the information used by the system, and the things that happen in the system.
The abstract description is then transformed into a network of queues,
application servers that read from the queues, and messages that flow
between the application servers and encapsulate the characteristics and
behavior. Each application server in a good design is assigned a
specific function or a limited number of related functions to perform.
1.3.1.1 Traditional Functional Model
Using a traditional design methodology such as Yourdon/DeMarco¹, the system would be described by a series of data flow diagrams which show data flowing to and from abstract processes and data stores.
When using such a methodology, once the system data flow is known, the process of breaking down the diagram into physical processes and messages can start. Often a one-to-one association between physical process and abstract process can be made; for example, a process bubble in the diagram becomes a physical process. In some cases, several actions will be assigned to one physical process.
You should also consider the storage of data in media under application control, such as shared memory, disk files, or data base packages. The details of the choice for the type of storage are driven by access time requirements: how long the data must be stored, and how the data will be used.
The decision to place data in some type of data store, necessitates the assignment of a physical process to manage writes or reads and writes to the data store. Data stores are often local to a particular computer or network node. The assignment of a server process to manage the store and a design that buffers access to the server by message queuing leads to a design with wide distributed access, fast and deterministic access times, and good scalability.
The location of physical processes on a network is sometimes well known
because a data store managed by a service must be located on a
particular node. In other cases, the decision to assign physical
processes to network nodes is driven by load balancing considerations.
1.3.1.2 Object-Oriented Methodology
One of the difficulties that arise from a traditional design approach is that specification often becomes biased toward the flow of data rather than the understanding of the important underlying processes of the system. Object-oriented² analysis and design changes the focus from the data to the process, and produces a series of models in addition to the traditional functional model.
The end result is a series of abstract "objects" and "methods". When object-oriented systems are implemented using MessageQ, each major object is assigned to an application server process and a queue. The invocation of a method on an object corresponds to sending a message to an application server associated with the object.
At this stage in the design, there is enough information to assign
physical processes to MessageQ groups and to assign network node
locations to those groups.
1.3.2 Determining Queue Sizes
In addition to the system flow, you need to determine expected arrival rates to key inputs of the system. One way to estimate this is to look at the expected or required response times to any particular action. So, if a input stream needs an response time of 0.5 seconds, you might expect that the arrival rate for that particular input might be 2 events per second. (The worst case then, as far as the system load, would be that the 2 events per second rate would be maintained over some relatively long period of time, say five minutes.)
The sum of input rates from all the events to a particular service determines a maximum input rate (and queue size) that the service must handle. If the events are correlated closely to messages, then the input messaging rates to the system can be determined.
The messaging rates for key inputs to the system, as well as the service rates for various processes, determine the queue size that the system needs to be configured to handle.
A rough way to do this is to use the following calculation³ for each queue:
Q_DET = P/(1-P) - (P * P/2 * (1-P)) assumes constant service times Q_EXP = P/(1-P) assumes random service times