|
| |
| Sun Java System Message Queue 3 2005Q1 Technical Overview | |
Chapter 4
Message ServerThe Message Queue message server, introduced in Message Server, consists of a single broker or a set of brokers working in concert (a broker cluster) to perform message routing and delivery.
This chapter discusses the internal structure of the broker, describes its various components, and outlines the steps required to configure and manage it in development and production environments. It consists of the following sections:
Understanding the functional parts of the broker can help you configure desired broker behavior, scale operations, and optimize performance. This chapter might therefore be of more interest to administrators than to application developers.
Broker ArchitectureTo perform message delivery, a broker sets up communication channels with clients, performs authentication and authorization, routes messages appropriately, guarantees reliable delivery, and provides data for monitoring system performance.
To perform this complex set of functions, a broker uses a number of different internal components, each with a specific role in the delivery process. These broker components are illustrated in Figure 4-1 and described briefly in Table 4-1. The Message Router component performs the key message routing and delivery service, and the others provide important support services on which the Message Router depends.
Figure 4-1 Broker Components
When you configure the broker, you are actually configuring these services to optimize the broker’s performance, depending on load conditions, application complexity, and so forth.
Broker ComponentsThe following sections describe each of the broker components shown in Figure 4-1, their functions, and their behavior. See the Message Queue Administration Guide for their respective properties and configuration procedures.
Connection Services
A Message Queue broker supports communication with both application clients and administration clients. Each connection service is specified by its service type and protocol type.
service type Specifies whether the service provides JMS message delivery (NORMAL) or Message Queue administration services (ADMIN) that support administration tools.
protocol type Specifies the underlying transport protocol layer that supports the service.
The connection services currently available from a Message Queue broker are shown in Table 4-2.
You can configure a broker to run any or all of these connection services. Each connection service supports specific authentication and authorization (access control) features (see Security Manager). Each connection service is multi-threaded, supporting multiple connections.
Each connection service is available at a particular port, specified by the broker’s host name and a port number. The port can be dynamically allocated or you can specify the port at which a connection service is available. The general scheme is shown in Figure 4-2.
Figure 4-2 Connection Services Support
Port Mapper
Connection services are assigned a port by a common Port Mapper. The Port Mapper itself resides at a standard port number, 7676. When the Message Queue client runtime sets up a connection with the broker, it first contacts the Port Mapper, requesting the port number of the connection service it desires.
You can override the Port Mapper by assigning a static port number for the jms, ssljms, admin and ssladmin connection services when configuring these connection services. However, static ports are generally used only in special situations, such as in making connections through a firewall (see HTTP/HTTPS Support), and are not generally recommended.
Thread Pool Manager
Each connection service is multi-threaded, supporting multiple connections. The threads needed for these connections are maintained in a thread pool managed by a Thread Pool Manager component. You can configure the Thread Pool Manager to set a minimum number and maximum number of threads maintained in the thread pool. As threads are needed by connections, they are added to the thread pool. When the minimum number is exceeded, the system will shut down threads as they become free until the minimum threshold is reached, thereby saving on memory resources. The threads in a thread pool can either be dedicated to a single connection or assigned to multiple connections, as needed.
HTTP/HTTPS Support
HTTP/HTTPS support allows Message Queue clients to interact with the broker using the HTTP protocol instead of through direct TCP connections. If the client needs to be separated from the broker by a firewall, you can use HTTP/HTTPS service because it allows communication through firewalls.
Figure 4-3 shows the main components involved in providing HTTP/HTTPS support.
Figure 4-3 HTTP/HTTPS Support Architecture
- On the Message Queue client side, an HTTP or HTTPS transport driver encapsulates the JMS message into an HTTP request and makes sure that these requests are sent to the Web server in the correct sequence.
- The client can optionally use an HTTP proxy server to interact with the Web server, if necessary.
- An HTTP or HTTPS tunnel servlet (both bundled with Message Queue) is loaded in the Web server and used to pull JMS messages out of client HTTP requests before forwarding them to the broker. The HTTP/HTTPS tunnel servlet also sends broker responses back to the client. A single HTTP/HTTPS tunnel servlet can be used to access multiple brokers.
- On the broker side, a broker connection to the tunnel servlet is established at broker startup time. As messages are sent from the HTTP or HTTPS tunnel servlet, the httpjms or httpsjms connection service, respectively, unwraps the message and submits it to the broker’s Message Router component.
The architectures for HTTP and HTTPS shown in Figure 4-3 are very similar. The main difference is that, in the case of HTTPS (httpsjms connection service), the tunnel servlet has a secure connection to both the client and broker.
Message Queue’s HTTPS tunnel servlet passes a self-signed certificate to any broker requesting a connection. The certificate is used by the broker to set up an encrypted connection to the HTTPS tunnel servlet. Once this connection is established, a secure connection between a Message Queue client and the tunnel servlet can be negotiated.
The httpjms and httpsjms services are configured using properties described in the Message Queue Administration Guide.
Message Router
Once connections have been established between clients and a broker using the supported connection services, the routing and delivery of messages can proceed.
Message Queue messaging is premised on a two-phase delivery of messages: first, from a producing client to a physical destination on the broker, and second, from the destination on the broker to one or more consuming clients. The Message Router manages the process of placing arriving messages in the appropriate destination and then routing and delivering the message to the appropriate consumer(s).
This section discusses the different kinds of destinations and the management of memory resources for those destinations, individually and collectively. A discussion of the mechanisms of routing and delivering messages can be found in Chapter 3, "Reliable Message Delivery."
Physical Destinations
Physical destinations represent locations in a broker’s physical memory where incoming messages are stored before being routed to consuming clients.
Destinations fall into a number of categories, depending on how they are created and for what purpose: admin-created, auto-created, temporary, and the dead message queue.
Admin-Created Destinations.
Admin-created destinations are created by an administrator using Message Queue administration tools. These correspond either to a logical destination that is created programmatically or to a destination administered object that is looked up by the client.
Because a Message Queue message server is a central hub in a messaging system, its performance and reliability are important to the success of enterprise applications. Since destinations can consume significant resources (depending on the number and size of messages they handle, and on the number and durability of the message consumers that register), they need to be managed closely to guarantee message server performance and reliability. It is therefore standard practice for an administrator to create destinations on behalf of an application, monitor the destinations, and reconfigure their resource requirements when necessary.
Auto-Created Destinations
Auto-created destinations are automatically created by the broker as they are needed, without requiring the intervention of an administrator. In particular, an auto-created destination is created whenever a message consumer or message producer attempts to access a nonexistent destination. They are used when destinations need to be created dynamically: typically during a development and test cycle. You can configure a broker to enable or disable the auto-create capability.
When destinations are created automatically, clashes between different client applications (using the same destination name) or degraded system performance (due to the resources required to support a destination) can result. For this reason, an auto-created destination is automatically destroyed by the broker when it is no longer being used: that is, when it no longer has message consumer clients and no longer contains any messages. If a broker is restarted, it will recreate auto-created destinations only if they contain persistent messages.
Temporary Destinations
Temporary destinations are explicitly created and destroyed (using the JMS API) by clients that need a destination at which to receive replies to messages sent to other clients. These destinations are maintained by the broker only for the duration of the connection for which they are created. A temporary destination cannot be destroyed by an administrator, and it cannot be destroyed by a client application as long as it is in use: that is, if it has active message consumers. Temporary destinations, unlike admin-created or auto-created destinations (that have persistent messages), are not stored persistently and are never re-created when a broker is restarted; however, they are visible to Message Queue administration tools.
The Dead Message Queue.
The dead message queue is a specialized destination created automatically at broker startup that is used to store dead messages for diagnostic purposes. A dead message is one that is removed from the system for a reason other than normal processing or explicit administrative action. A message might be considered dead because it has expired, because it has been removed from a destination due to memory limit overruns, or because of failed delivery attempts.
There are two ways to have messages placed in the dead message queue:
When a message is placed in the dead message queue, additional property information is written into it, providing you with information about the cause of death.
Memory Resource Management
A message server is limited in resources: memory, CPU cycles, and so forth. As a result, depending on the use patterns of the messaging applications the broker supports, it is possible for a message server to become overwhelmed to the point where it becomes unresponsive or unstable. In particular, this can be a problem if production of messages for a destination is much faster than consumption.
The Message Router has mechanisms for managing memory resources and preventing the broker from running out of memory. It uses three levels of memory protection to keep the system operating as resources become scarce: destination message limits, system-wide limits, and system memory thresholds.
Destination Message Limits
Since messages can remain in a destination for an extended period of time, memory resources can become an issue. You do not want to allocate too much memory to a destination (there is only so much system memory), nor do you want to allocate too little (messages could be rejected).
To allow for flexibility based on the load demands of each destination, you can set properties that manage memory resources and message flow for each destination. For example, you can specify the maximum number of producers allowed for a destination, the maximum number (or size) of messages allowed in a destination, and the maximum size of any single message.
You can also specify which of four responses are taken by the Message Router when any such limits are reached. The four limit behaviors are:
System-Wide Message Limits
System-wide message limits constitute a second line of protection. You can specify system-wide limits that apply collectively to all destinations on a broker: the total number of messages and the memory consumed by all messages. If any of the system-wide message limits are reached, the Message Router rejects new messages.
System Memory Thresholds
System memory thresholds are a third line of protection. You can specify thresholds of available system memory at which the broker takes increasingly serious action to prevent memory overload. The action taken depends on the state of memory resources: green (plenty of memory is available), yellow (broker memory is running low), orange (broker is low on memory), red (broker is out of memory). As the broker’s memory state progresses from green through yellow and orange to red, the broker takes increasingly serious actions of the following types:
- Throwing out in-memory copies of persistent messages in the data store.
- Throttling back producers of non-persistent messages, eventually stopping the flow of messages into the broker. Persistent message flow is automatically limited by the requirement that each message be acknowledged by the broker.
Both of these measures degrade performance.
If system memory thresholds are reached, then you have not adequately set destination-by-destination message limits and system-wide message limits. In some situations, it is not possible for the thresholds to catch potential memory overloads in time. Hence you should not rely on this feature, but should instead configure destinations individually and collectively to optimize memory resources.
With careful monitoring and tuning, destination-based limits and behavior can be used to balance the inflow and outflow of messages so that system overload cannot occur. While these mechanisms consume overhead and can limit message throughput, they nevertheless maintain operational integrity.
Persistence Manager
For a broker to recover in case of failure, it needs to re-create the state of its message delivery operations. This requires it to save all persistent messages, as well as essential routing and delivery information, to a data store. To recover, the broker must also be able to do the following:
The Persistence Manager manages the storage and retrieval of all this state information.
When a broker restarts, it uses the data managed by the Persistence Manager to re-create destinations and durable subscriptions, recover persistent messages, roll back open transactions, and re-create its routing table for undelivered messages. It can then resume message delivery.
Message Queue supports both built-in and plugged-in persistence modules (see Figure 4-4). Built-in persistence is a file-based data store. Plugged-in persistence uses a Java Database Connectivity (JDBC™) interface and requires a JDBC-compliant data store. The built-in persistence is generally faster than plugged-in persistence; however, some users prefer the redundancy and administrative control provided by a JDBC-compliant database system.
Figure 4-4 Persistence Manager Support
Built-in persistence The default Message Queue persistent storage solution is a file-based data store that uses individual files to store persistent data. To alleviate fragmentation as messages are added and removed, you can compact the file-based data store. To maximize reliability, you can specify that persistence operations synchronize the in-memory state with the physical storage device. This helps eliminate data loss due to system crashes, but slows performance. Because the data store can contain messages of a sensitive or proprietary nature, you should secure the data store files against unauthorized access.
Plugged-in persistence You can set up a broker to access any data store accessible through a JDBC driver. This involves setting a number of JDBC-related broker configuration properties and using Message Queue’s Database Manager utility to create a data store with the proper schema. The procedures and related configuration properties are detailed in the Message Queue Administration Guide.
Security Manager
Message Queue provides authentication and authorization (access control) features, and also supports encryption capabilities:
- Authentication ensures that only verified users can establish a connection to a message server.
- Authorization specifies which users have the right to access resources like connection services or destinations to perform specific operations supported by the message service.
- Encryption protects messages from being tampered with during delivery over a connection.
The authentication and authorization features depend upon a user repository (see Figure 4-5): a file, directory, or database that contains information about the users of the messaging system—their names, passwords, and group memberships. The names and passwords are used to authenticate a user when a connection to a broker is requested. The user names and group memberships are used, in conjunction with an access control file, to authorize operations such as producing or consuming messages for destinations.
You can populate a Message Queue-provided user repository or plug a preexisting LDAP user repository into the broker. The flat-file user repository is easy to use, but is also vulnerable to security attack, and should therefore be used only for evaluation and development purposes. The LDAP user repository is secure and therefore best suited for production purposes.
The following subsections describe authentication, authorization, and encryption. For more detailed information, see the Message Queue Administration Guide.
Authentication
Message Queue security supports password-based authentication. When a client requests a connection to a broker, the client must supply a user name and password. The Security Manager compares the name and password submitted by the client to those stored in the user repository. On transmitting the password from client to broker, the passwords are encoded using either base-64 encoding or message digest (MD5). For more secure transmission, see Encryption. You can configure the type of encoding used by each connection service separately or set the encoding on a broker-wide basis.
Authorization
Once the user of a client application has been authenticated, the user can be authorized to perform various Message Queue-related activities. The Security Manager supports both user-based and group-based access control: depending on a user’s name or the groups to which the user is assigned in the user repository, that user has permission to perform certain Message Queue operations. You specify access controls in an access control properties file (see Figure 4-5).
Figure 4-5 Security Manager Support
When a user attempts to perform an operation, the Security Manager checks the user’s name and group membership (in the user repository) against those given access to that operation (in the access control properties file). The access control properties file specifies permissions for the following operations:
You can define groups and associate users with those groups in a user repository (though groups are not fully supported in the flat-file user repository). Then, by editing the access control properties file, you can specify what destinations are accessible to a user or group for production, consumption, or browsing. You can make individual destinations or all destinations accessible only to specific users or groups.
In addition, if the broker is configured to allow auto-creation of destinations (see Auto-Created Destinations), you can control for whom the broker can auto-create destinations by editing the access control properties file.
Encryption
To encrypt messages sent between clients and broker, you need to use a connection service based on the Secure Socket Layer (SSL) standard. SSL provides security at a connection level by establishing an encrypted connection between an SSL-enabled broker and an SSL-enabled client.
Monitoring Service
The broker includes a number of components for monitoring and diagnosing its operations. Among these are the following:
- Components that generate data (a metrics generator and broker code that logs events)
- A Logger component that writes out information to a number of output channels
- A message producer that sends JMS messages containing metric information to topic destinations for consumption by JMS monitoring clients.
The general scheme is illustrated in Figure 4-6.
Metrics Generator
The metrics generator shown in Figure 4-6 provides information about broker activity, such as message flow in and out of the broker, the number of messages in broker memory and the memory they consume, the number of connections open, and the number of threads being used.
You can turn the generation of metric data on and off, and specify how frequently metrics reports are generated.
Figure 4-6 Monitoring Service Support
Logger
The Message Queue Logger shown in Figure 4-6 takes information generated by broker code and the metrics generator and writes that information to a number of output channels: to standard output (the console), to a log file, and, on Solaris™ platforms, to the syslog daemon process.
You can specify the type of information gathered by the Logger as well as the type written to each of the output channels. In the case of a log file, you can also specify the point at which the log file is closed and output is rolled over to a new file. Once the log file reaches a specified size or age, it is saved and a new log file created.
For details about how to configure the Logger and how to use it to obtain performance information, see the Message Queue Administration Guide.
Metrics Message Producer (Enterprise Edition)
The metrics Message Producer component shown in Figure 4-6 receives information from the Metrics Generator component at regular intervals and writes the information into messages, which it then sends to one of a number of metric topic destinations, depending on the type of metric information contained in the message.
Message Queue clients subscribed to these metric topic destinations can consume the messages in the destinations and process the metric information contained in the messages. This allows developers to create custom monitoring tools to support messaging applications. For details of the metric quantities reported in each type of metrics message, see the Message Queue Developer’s Guide for Java Clients, which explains how to develop a Message Queue client for consuming metrics messages. For information about how to configure the production of metrics messages, see the Message Queue Administration Guide.
Development and Production EnvironmentsThe messaging infrastructure provided by the Message Queue service is needed to develop and test messaging applications, as well as to deploy and manage those applications in a production environment.
This section introduces the different approaches to using Message Queue in development and production environments. It covers the following topics:
Although the administrator has charge of setting up and managing production environments and tasks, it is important for the developer to understand such environments in order to provide administrators with the information needed to set up and configure some parts of this environment and to determine whether clients are behaving as expected.
Development Environments and Tasks
In a development environment, the work focuses on programming Message Queue client applications. The Message Queue service is needed principally for testing.
Out-of-the-Box Configuration
The Message Queue product is designed to be used out of the box. You can start up a broker with default values and you will be provided with a default data store, user repository, and access control properties file.
The default user repository is created with default entries that allow the Message Queue broker to be used immediately after installation without any intervention by an administrator. In other words, no initial user/password setup is required for the broker to be used. The default user name (guest) and password (guest) can be used to authenticate a client user.
A number of sample applications are also provided to guide you in developing new applications.
Development Practices
In a development environment, the emphasis is on flexibility, and you typically adopt the following practices:
- You want minimal administration, consisting mostly of starting up a broker for developers to use in testing.
- You use default implementations of the data store (built-in file-based persistence), user repository (file-based user repository), and access control properties file. These default implementations are usually adequate for developmental testing.
- You use a simple file-system object store (by creating a directory for that purpose) in which to store administered objects, or you instantiate administered objects in client code and don’t use an object store at all.
- If you are performing multiple-broker testing, you probably would not use a Master Broker (see Cluster Synchronization).
- You generally use auto-created destinations rather than explicitly create destinations.
Production Environments and Tasks
In a production environment, applications must be deployed, managed, and tuned to maximize performance. In such situations the management and tuning of the messaging infrastructure is an important, if not crucial, requirement.
In addition, the deployment must support enterprise requirements, both in scale and availability. This requires customized configuration and setup of the message service, tuning performance and scaling the system to meet increasing loads, and performing day-to-day monitoring and management of both the message service and application-specific resources. The administration tasks therefore depend on the complexity of your messaging system and the complexity of the applications it must support. The following sections group administrative tasks into setup operations and maintenance operations. For the procedures required to perform these tasks, see the Message Queue Administration Guide.
Setup Operations
A production environment requires setting up secure access, configuring connection factory and destination objects, setting up clusters, configuring persistent stores, and managing memory.
To Set Up a Production Environment
Typically you have to perform at least some, if not all, of the following setup operations:
Maintenance Operations
In a production environment, Message Queue message server resources need to be monitored and controlled. Application performance, reliability, and security are at a premium, and you have to perform a number of ongoing tasks, described below, using Message Queue administration tools:
To Maintain a Production Environment
