This section contains information on the following subjects:
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.
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.
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:
http://
host
:
port
/pubsub
, where host
and port
refer to the computer on which Oracle CEP is running and the port number to which it listens, respectively.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.
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.
config.xml
file.
This file is located in the DOMAIN_DIR
/
servername
/config
directory, where DOMAIN_DIR
refers to the domain directory and servername
refers to the name of the server, such as /oracle_cep/user_projects/myDomain/defaultserver/config
.
<http-pubsub>
element that corresponds to the HTTP pub-sub server you want to configure. For example, the default pub-sub server is as follows:<http-pubsub>
<name>pubsub</name>
<path>/pubsub</path>
<pub-sub-bean>
<server-config>
...
</http-pubsub>
<server-config>
child element of the <pub-sub-bean>
element (which in turn is a child element of <http-pubsub>
) with pub-sub server configuration as required. For the full list of possible elements, see the
XSD Schema. The following are the most common configuration options:<supported-transport>
element to specify the transport; currently the two supported transports are long-polling and callback-polling. The format of this element is as follows:<server-config>
<supported-transport>
...
<types>
<element>long-polling</element>
</types>
</supported-transport>
</server-config>
<publish-without-connect-allowed>
element to specify whether clients can publish messages without having explicitly connected to the pub-sub server; valid values are true
or false
:<server-config>
...
<publish-without-connect-allowed>true</publish-without-connect-allowed>
</server-config>
<work-manager>
element to specify the name of the work manager that delivers messages to clients. The value of this element corresponds to the value of the <name>
child element of the <work-manager>
you want to assign. See work-manager Configuration Object for details.<server-config>
...
<work-manager>myWorkManager</work-manager>
</server-config>
<client-timeout-secs>
element to specify the number of seconds after which the pub-sub server disconnects a client if the client does has not sent back a connect/reconnect message. <server-config>
...
<client-timeout-secs>600</client-timeout-secs>
</server-config>
config.xml
file and restart Oracle CEP.
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.
config.xml
file.
This file is located in the DOMAIN_DIR
/
servername
/config
directory, where DOMAIN_DIR
refers to the domain directory and servername
refers to the name of the server, such as /oracle_cep/user_projects/myDomain/defaultserver/config
.
<http-pubsub>
child element of the root <config>
element of config.xml
, with <name>
, <path>
and <pub-sub-bean>
child elements, as shown in bold:<?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>myPubSubServer</name>
<path>/myPath</path>
<pub-sub-bean>
...
</pub-sub-bean>
</http-pubsub>
...
</ns2:config>
Set the <name>
element to the internal name of the HTTP pub-sub server. Set the <path>
element to the string that you want to appear in the URL for connecting to the HTTP pub-sub server. The next step describes the <pub-sub-bean>
element.
<http-pubsub>
<name>myPubSubServer</name>
<path>/myPath</path><pub-sub-bean>
</http-pubsub>
<server-config>
...
</server-config>
<channels>
...
</channels>
</pub-sub-bean>
<server-config>
child element of the <pub-sub-bean>
element with pub-sub server configuration as required. For the full list of possible elements, see the
XSD Schema. The following are the most common configuration options:<supported-transport>
element to specify the transport; currently the two supported transports are long-polling and callback-polling. The format of this element is as follows:<server-config>
<supported-transport>
...
<types>
<element>long-polling</element>
</types>
</supported-transport>
</server-config>
<publish-without-connect-allowed>
element to specify whether clients can publish messages without having explicitly connected to the pub-sub server; valid values are true
or false
:<server-config>
...
<publish-without-connect-allowed>true</publish-without-connect-allowed>
</server-config>
<work-manager>
element to specify the name of the work manager that delivers messages to clients. The value of this element corresponds to the value of the <name>
child element of the <work-manager>
you want to assign. See work-manager Configuration Object for details.<server-config>
...
<work-manager>myWorkManager</work-manager>
</server-config>
<client-timeout-secs>
element to specify the number of seconds after which the pub-sub server disconnects a client if the client does has not sent back a connect/reconnect message. <server-config>
...
<client-timeout-secs>600</client-timeout-secs>
</server-config>
<channels>
child element with at least one channel pattern. Channel patterns always begin with a forward slash. These channels are what clients subscribe to either publish or receives messages. Add a channel pattern as shown:<channels>
<element>
<channel-pattern>/mychannel</channel-pattern>
</element>
</channels>
config.xml
file and restart Oracle CEP.
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>