Overview

Universal Command Agent for SOA is based on a Light Weight Container Architecture (LWCA).

This architecture, combined with the Federated architecture of the current Universal Automation Center line, provide your enterprise with a loosely coupled, scalable, and secure solution to your enterprise workload management tasks.

Supported Protocols

Universal Command Agent for SOA supports synchronous and asynchronous communication for workload execution via the following four protocols: HTTP, SOAP, JMS, and MQ.

Synchronous communication requires that the calling party wait for a response from the target application before beginning the next task.

Asynchronous communication allows the calling party to move on the next task without waiting for a response (if there is one) from the target application. If there are responses to asynchronous requests, more effort is required to correlate the request to the reply, as they are two separate events. Most middleware and integration software operate in this manner.

HTTP

HTTP (HyperText Transfer Protocol) is the underlying protocol used by the World Wide Web. It is a synchronous (blocking) protocol, which means that the requestor waits for the response before executing another task.

HTTP uses the Request / Reply message pattern.

HTTP is one of the ways that you can execute remote workload such as CGI, servlet, or web service-based applications.

SOAP

SOAP (Simple Object Access Protocol) is a synchronous protocol for exchanging XML-based messages over computer networks, normally using HTTP / HTTPS. However, you can send SOAP messages over JMS, as well.

SOAP forms the foundation layer of the Web services stack, providing a basic messaging framework upon which abstract layers can be built.

There are several different types of messaging patterns in SOAP, but by far the most common is the Remote Procedure Call (RPC) pattern. In RPC, one network node (the client) sends a request message to another node (the server). The server immediately sends a response message to the client; that is, request / reply. SOAP is used predominantly to provide an interface to web service-based workload or legacy workload with a web service interface.

JMS

JMS (Java Message Service) defines the standard for reliable Enterprise Messaging and provides a reliable, flexible service for the asynchronous exchange of critical business data and events throughout an enterprise.

JMS uses both point-to-point (queue-based) and publish / subscribe (topic-based) messaging patterns. It is used extensively in middleware implementations and large J2EE application deployments.

MQ

IBM WebSphere MQ (Message Queue) is a family of network communication software products launched by IBM in March, 1992.

It was previously known as MQSeries, a trademark that IBM rebranded in 2002 to join the suite of WebSphere products. WebSphere MQ, which users often refer to simply as "MQ," is IBM's Message Oriented Middleware offering. It allows independent and potentially non-concurrent applications on a distributed system to communicate with each other. MQ is available on a large number of platforms, both IBM and non-IBM

MQ uses both point-to-point (queue-based) and publish / subscribe (topic-based) messaging patterns. It is used extensively in IBM-based and legacy middleware implementations in mid-size and enterprise environments.

Supported Messages Exchange Patterns

A message exchange pattern (MEP) describes the pattern of messages required by a communications protocol to establish or use a communication channel.

There are two major types of message exchange patterns:

• One-way: Publish or Listen (asynchronous)
• Request / Reply pattern (synchronous)

Universal Command Agent for SOA supports the Publish MEP and the Request / Reply MEP, as described in the following sections.

Publish MEP

The Publish MEP represents an asynchronous outbound workload execution event. This means that you can request execution of a workload using the JMS protocol to a target JMS provider.

Since JMS is queue-based, this outbound operation puts a message on the queue of the JMS provider. A process within the target application environment, such as a WebSphere container or middleware application, will read the message from the queue and execute the appropriate workload.

Technically, you can initiate a publish operation using the SOAP protocol, but it is still just a request / reply where the reply is treated as an acknowledgement similar to that of the TCP protocol.

The following figure illustrates a logical view of the Publish MEP.

Request / Reply MEP

The Request / Reply MEP represents an outbound request to a target workload followed by an inbound reply from a target workload. This is a synchronous operation, as the calling party blocks, or waits, for the reply to come back before releasing its resources and moving on to the next task.

This is one of the most common message exchange patterns used. Every time you use a web browser to go to a website, you are initiating a request / reply operation where you request a page and the server replies with the page (or an error if it cannot find the page).

You can execute workload via the Request / Reply MEP using the HTTP, SOAP, JMS, or MQ protocols.

The following figure illustrates a logical view of the Request / Reply MEP.