|
|
|
|
|
|
How BEA Tuxedo ATMI Processes Messages
All communication within the BEA Tuxedo ATMI environment is accomplished by transferring messages. The BEA Tuxedo ATMI environment passes service request messages between clients and servers through operating system Inter-Process Communications (IPC) message queues. System messages and data are passed between operating system-supported, memory-based queues of clients and servers in buffers. In the BEA Tuxedo ATMI environment, messages are packaged in typed buffers, buffers that contain both message data and data identifying the types of message data being sent.
Processing a Request
A client uses an ATMI function to request a service by name. A naming facility is used to check the MIB to determine whether the specified service is currently available. The BEA Tuxedo system uses an automatic routing option to map messages that meet specific criteria (message value) to a specific server. This is called data-dependent routing. If messages use data-dependent routing, the system uses the data in the buffer for the routing algorithm. This algorithm provides a method of selecting a group of servers that can process the service request. To avoid burdening a few servers with many requests while leaving other servers that advertise the same services idle, the BEA Tuxedo system maintains a set of metrics in the MIB that help it distribute service requests evenly across all servers. This practice is called load balancing. A local service request may be prepared for a selected server and enqueued on that server's queue with a predefined priority. This practice is called service prioritization. Once the service request is on the server, the run-time system retrieves the message in priority order. The message is dispatched to the appropriate service and processed. Then the results are returned to the client queue. BEA Tuxedo system-provided software offers features that an application can automatically and routinely use during message processing. These features include: data encoding and decoding, data compression and decompression, transactional context setting, and security processing, to name a few. In addition, the BEA Tuxedo system software invokes application business logic by dispatching a service function and passing it to the appropriately preprocessed buffer. The service routine is executed and returns a reply (also a typed buffer). The run-time system prepares the reply for the client by encoding the message automatically: it packages the data in such a way that it can be transmitted between machines on which different types of byte ordering are used, allowing data to cross network and platform boundaries. The system then sends the message to the client. This process is called data encoding. The run-time system on the client retrieves the reply message, decodes it if necessary, and delivers the FML buffers (or buffers of another message buffer type) to package the application data. Type validation, encoding, routing, and load balancing are performed as required. Service requests can be performed synchronously or asynchronously. Remote requests travel through the local bridge to the remote machine, where the remote bridge simply acts as a client and the request is processed as if the client and server were on the same machine. The bridge provides standard data encoding/decoding and uses standard network transports to communicate. Bridges look like ordinary local servers to clients and servers. What Are the Benefits of Service Request Processing?
See Also
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|