Administration and Configuration Guide

Configuring the HTTP Publish-Subscribe Server

This section contains information on the following subjects:

Overview of HTTP Publish-Subscribe Servers

An HTTP Publish-Subscribe Server (for simplicity, also called pub-sub server in this document) is a mechanism whereby Web clients subscribe to channels and then publish messages to these channels using asynchronous messages over HTTP.

The simple request/response nature of a standard Web application requires that all communication be initiated by the client; this means that the server can only push updated data to its clients if it receives an explicit request. This mechanism is adequate for traditional applications in which data from the server is required only when a client requests it, but inadequate for dynamic real-time applications in which the server must send data even if a client has not explicitly requested it. The client can use the traditional HTTP pull approach to check and retrieve the latest data at regular intervals, but this approach is lacking in scalability and leads to high network traffic because of redundant checks. The HTTP Publish-Subscribe Server solves this problem by allowing clients to subscribe to a channel (similar to a topic in JMS) and receive messages as they become available.

The pub-sub server is based on the Bayeux protocol proposed by the cometd project. The Bayeux protocol defines a contract between the client and the server for communicating with asynchronous messages over HTTP. It allows clients to register and subscribe to channels, which are named destinations or sources of events. Registered clients, or the pub-sub server itself, then publishes messages to these channels which in turn any subscribed clients receive.

The pub-sub server can communicate with any client that can understand the Bayeux protocol. The pub-sub server is responsible for identifying clients, negotiating trust, exchanging Bayeux messages, and, most importantly, pushing event messages to subscribed clients.

The following figure describes the basic architecture of the pub-sub server included in Oracle CEP.

How the HTTP Pub-Sub Server Works

There is a one-to-one relationship between a servlet and a pub-sub server; in other words, each servlet has access to one unique pub-sub server. Each pub-sub server has its own list of channels. The servlet uses a context object to get a handle to its associated pub-sub server.

In Oracle CEP, pub-sub server instances are configured in the config.xml file of the server instance. System administrator uses the config.xml to configure the name of the pub-sub server, specify the transport and other parameters. You then use Visualizer to add new channels and configure security for the channels.

Oracle CEP application developers can optionally use the built-in HTTP pub-sub adapters to publish and subscribe to channels within their applications. If, however, developers need the pub-sub server to perform additional steps, such as monitoring, collecting, or interpreting incoming messages from clients, then they must use the server-side pub-sub server APIs to program this functionality.

For Web 2.0 Ajax clients (e.g. Dojo) or RIA (e.g. Adobe Flex) to communicate with the pub-sub server, the clients need a library that supports the Bayeux protocol. The Dojo JavaScript library provides four different transports, of which two are supported by the HTTP pub-sub server: long-polling and callback-polling.

HTTP Pub-Sub Server Support in Oracle CEP

Every Oracle CEP server includes a default HTTP pub-sub server. This server is used internally by Visualizer and by the Record and Playback example. You can either use the default pub-sub server for your own Web 2.0 application or create a new one.

The default pub-sub server has the following properties:

For details about configuring the default pub-sub server, or creating a new one, see Configuring an Existing HTTP Publish-Subscribe Server.

Oracle CEP also includes two built-in adapters that easily harness HTTP pub-sub server functionality in your applications. By adding these adapters to your application you can both publish messages or subscribe to a server to receive messages, using either the local HTTP pub-sub server or a remote one. For details, see Using and Creating HTTP Publish-Subscribe Adapters.

Configuring an Existing HTTP Publish-Subscribe Server

The following procedure describes how to configure an existing HTTP pub-sub server. See Creating a New HTTP Publish-Subscribe Server for a full example from the config.xml of a configured HTTP pub-sub server.

Creating a New HTTP Publish-Subscribe Server

The following procedure describes how to create a new HTTP pub-sub server. See Creating a New HTTP Publish-Subscribe Server for a full example from the config.xml of a configured HTTP pub-sub server.

Example of Configuring the HTTP Publish-Subscribe Server

The following snippet of the config.xml file shows the configuration of the default HTTP pub-sub server present in every Oracle CEP server:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:config xmlns:ns2="http://www.bea.com/ns/wlevs/config/server">

    <domain>
        <name>myDomain</name>
    </domain>

    ....

    <http-pubsub>
      <name>pubsub</name>
      <path>/pubsub</path>
      <pub-sub-bean>
        <server-config>
          <supported-transport>
            <types>
              <element>long-polling</element>
            </types>
          </supported-transport>
          <publish-without-connect-allowed>true</publish-without-connect-allowed>
        </server-config>
        <channels>
          <element>
            <channel-pattern>/evsmonitor</channel-pattern>
          </element>
          <element>
            <channel-pattern>/evsalert</channel-pattern>
           </element>
           <element>
            <channel-pattern>/evsdomainchange</channel-pattern>
          </element>
        </channels>
      </pub-sub-bean>
  </http-pubsub>
...

</ns2:config>