The major components of SmartSockets are:
Within a SmartSockets application, interprocess communication occurs using messages. A message is a packet of information sent from one process to one or more other processes providing instructions or data for the receiving process. Messages can carry many different kinds of information, including:
All of these different kinds of messages are classified by message types. For example, numeric variable data is typically sent in a NUMERIC_DATA type of message, and an operator warning is typically sent in a WARNING type of message. A SmartSockets application can use both the standard message types provided with SmartSockets as well as user-defined message types.
A message is composed of the header and the data. The header contains properties that specify control information about the message. Examples of SmartSockets message properties are the message sender, destination, type, priority, and delivery mode. The data contains the information you wish to send and is usually the largest part of the message. The message type property defines the structure of the data part of the message.
Typically, when building a SmartSockets application, these steps are required when constructing a message:
The same message can be used many times, changing only the data part of the message or a property such as the destination. There are many different types of fields that can be appended to a message’s data. These field types include three sizes of integers, character strings, three sizes of real numbers, and arrays of the scalar field types, such as an array of four-byte integers. Fields can also be associated with a name, allowing them to be accessed by that name. Messages themselves can even be used as fields within other container messages; this allows operations such as large transactions to be represented with a single message.
Once a message is constructed, it can be sent to another process through a connection or published to a subject to be delivered to multiple processes.
As described earlier, each message has a type property that defines the structure of the data property of the message. A message type can be thought of as a template (or class) for a specific kind of message, and each message can be considered an instance of a message type. For example, NUMERIC_DATA is a message type with a predefined layout requiring a series of name-value pairs, with each string name followed immediately by a numeric value. To send numeric data to a process, the sending process constructs a message that uses the NUMERIC_DATA message type. A message type is created once and is then available for use as the type for any number of messages.
SmartSockets provides a large number of standard predefined message types that you can use, and that are also used internally by SmartSockets. When a standard message type does not satisfy a specific need, you can create your own user-defined message types. Both standard and user-defined message types are handled in the same manner. Once the message type is created, messages can be constructed, sent, received, and processed through a variety of methods.
All messages are transmitted between processes through connections. A connection is an endpoint of a direct communication link used to send and receive messages between two processes. The two processes, called peer processes, share the link.
While connections allow two processes to send messages to each other, RTserver and RTclient allow many processes to communicate with each other. RTserver routes messages between RTclients. A key feature of SmartSockets is the ability to distribute RTservers and RTclients anywhere over a network. Different processes can be run on different computers, taking advantage of all the computing power a network has to offer. Processes can be dynamically started and stopped while the system is running.
The functionality of RTserver and RTclient is layered on top of connections and messages, but adds greater functionality and ease of use. Some of these features are listed below.
Before you use RTserver and the RTclient API, you should have an understanding of the concepts involved. The RTserver and RTclient architectures and the major concepts that you need to understand are:
A SmartSockets project is a group of RTclients working together with one or more RTservers to perform some set of tasks as part of a specific system. Within a project, processes can communicate with other processes on the same machine or over the network. RTclient processes in different projects cannot send messages to each other.
Typically, an RTclient belongs to only one project. An RTserver does not belong to any project, but can provide message routing services for one or more projects. You can think of a project as a firewall that prevents messages from being dispatched outside the specified process group. It is possible for an RTclient to connect to more than one project in the same RTserver or to multiple projects across RTservers. See the TIBCO SmartSockets User’s Guide for more information.
For example, in Figure 1 the RTclients are running on the same network and are each monitoring two factories, so the projects named FAC1 and FAC2 are used to ensure that messages are not sent between the two separate projects. The option Project is used to specify the project to which an RTclient belongs. The default value for Project is rtworks. Always set this option to prevent becoming part of the default project, which can cause unwanted messages to be received.
Just as projects restrict the boundaries of where messages are sent, subjects also further partition the flow of messages within a project. A subject is the fundamental concept used in taking advantage of SmartSockets publish-subscribe communication services. A subject is a logical message address that provides a virtual connection between RTclients.
When an RTclient has subscribed to a subject, it gets any messages sent to RTserver whose destination property is set to that subject. For example, in a stock trading application, you might partition messages by stock market sectors, such as computer stocks, automobile stocks, financial stocks. These areas would be declared as subjects such as /stocks/computer, /stocks/auto, /stocks/financial. All messages pertaining to computer stocks are constructed with the /stocks/computer subject as their destination property. Any RTclient interested in receiving messages published to /stocks/computers subscribes to the /stocks/computer subject. This is also known as the publish-subscribe communications model in that the RTclients publish messages to a specific subject, and the RTclients subscribe to subjects in which they are interested.
If you are not using SmartSockets publish-subscribe services, when two processes create connections to each other, they need protocol-specific network addresses to begin communicating (for example, TCP/IP needs a node name and port number). If a process wants to send a message to many other processes, it first needs to know the protocol-specific network addresses of the other processes and then creates connections to all of those processes. This kind of architecture does not scale well as configuration is complicated and tedious. The RTserver/RTclient architecture’s use of subjects for message addresses allows RTclient to simply send the message with a subject as the destination property, and RTserver takes care of routing the message to all RTclients that are receiving that subject.
Connections by themselves do not scale well to many processes. RTserver fills this void and expands the capabilities of connection-based message passing. RTserver is a powerful message router that uses connections to make large-scale distributed IPC easier.
In addition to routing messages between RTclients, multiple RTservers can route messages to each other. Multiple RTservers can distribute the load of message routing. If a project is partitioned so that most of the messages being sent are routed between processes on the same node, then the placement of an extra RTserver on the local node can reduce the consumption of network bandwidth (processes on the same node can use the non-network local IPC protocol).
An RTclient is a process that is connected to RTserver as a client. Usually, each RTclient has exactly one connection to exactly one RTserver. This is a single, global RTserver connection. An RTclient can send messages, receive messages, and create callbacks using this connection, just as it does any other connection. The message routing capabilities of RTserver are transparent to RTclient, and subjects provide a virtual connection between RTclients.
An RTclient can have complete control over when it creates a connection to RTserver, or it can automatically create the connection when it is first needed. An RTclient can partially destroy its connection to RTserver and temporarily continue running as if it were still connected, or an RTclient can fully destroy its connection to RTserver and continue as if it had never been connected at all.
An RTclient can have multiple RTserver connections. Usually, the single, global RTserver connection is sufficient, but when threads such as Java applets or servlets need individual connections, you can create new RTserver connections independent of the global RTserver connection. For more information, see Multiple RTserver Connections.
RTmon is a powerful tool you can use to monitor and manage your distributed project. You can access the RTmon through the RTmon Graphical Development Interface (GDI) or through a built-in command-oriented interface called the RTmon Command Interface (CI).
The RTmon GDI is a graphical point-and-click interface that is intuitive and easy to use. The RTmon provides an assortment of tools for viewing your project, including graphical trees, browsers, graphical charts, and watch windows. The RTmon CI is a command-line-based interface, allowing you to monitor and manage your project using a command prompt.
The RTmon Main window presents an animated graphical tree of your project, with nodes in the tree representing RTclients, the subjects to which they are subscribing, and the RTservers running in the project. As changes occur, the tree is updated in real time. The Watch Server Connections window graphically displays the RTservers in your project and their connection topology. You can use this window to monitor the load on your RTservers and their connections using a variety of different metrics. RTmon even allows you to look at individual messages and their contents as they are passed from process to process.
One of the principal features of RTmon is that it is non-intrusive. You can monitor, debug, and log information in your project without changing the running processes. RTmon also provides real-time system usage information on processes, such as CPU and memory resources. This is useful for stopping a process that is using excessive system resources.
The content and functionality of the RTmon GDI are identical between the Windows and Motif platforms.
|
TIBCO SmartSockets™ Java Library User’s Guide and Tutorial Software Release 6.8, July 2006 Copyright © TIBCO Software Inc. All rights reserved www.tibco.com |
