Introducing Publish-Subscribe Model in Oracle10g

In an enterprise, Database is the most noteworthy resource of information. Oracle has created a publish-subscribe solution for delivery of enterprise information and messaging to enhance this role. Applications that communicate through a publish and subscribe model require the sending application (publisher) to circulate messages without specifying recipients openly and receiving applications to only receive messages that the subscriber has registered for.

This decoupling between senders and recipients is accompanied by an intervening unit, a queue which serves as a level of indirection. A subscriber subscribes to a queue by means of expressing interest in messages of that queue. At runtime publishers place various messages to the queues. The delivery mechanism of the queue delivers the appropriate message to the subscribers.

To support database enabled publish-subscribe model Oracle has the Database Events, Advanced Queuing and Client Notification features.

Database Events enable the publication of messages in an event driven mode. Oracle Advanced Queuing supports a queue based method along with capabilities to permit publish and subscribe based on queries. Client Notification supports asynchronous deliverance of messages to subscribers who denote interest.

The underlying entities related to publish-subscribe are queue, non persistent queue, persistent queue, agent, client, rule on a queue, subscriber, database event publication framework etc. The process involves registration, publishing a message, rules engine, subscription services, posting and receiving of a message. The entities are described in detail below.

A queue is an entity in a database infrastructure that can hold messages, notifications and events. It can be of type non-persistent or persistent.

Agents are the publishers and subscribers who express interest in the queue through the process of subscription.

The client is a temporary physical entity. The attributes of a client is the physical process where the client programs run, the name of the node and the application logic of the client. The client can take action on the behalf of multiple agents or several clients can perform on behalf of a single agent.

A rule on a queue is the conditional expression using a set of operators that is defined earlier on the attributes of the message format or header. Each queue has a linked message content format that may be a well defined structure or unstructured leading to subject on content based subscriptions.

The subscribers are the agents who stipulate subscriptions on a queue by means of a rule. The database represents a major source for the publishing information. It allows the actual deliverance of information to end users in an event determined manner.

The Registration is the process of related delivery information by a given client, acting on an agent’s behalf. During registration a client associates a host and port, signifying where the delivery should happen and a callback, signifying how it should be done. The Publishers publish messages to queues by the suitable queuing interfaces.

When a message is posted to a given queue, the rules engine locates the set of candidate rules from all rules defined in that queue that go with the published message. The set of subscribers that match the candidate rules can thus be evaluated. Following this the set of agents corresponding to the subscription can be notified. The concept of notification is called Posting.

A subscriber may receive a message through three types of mechanisms. A client process that is performing on the subscriber’s behalf specifies callback via the registration mechanism. When a message matches the subscriber’s subscription the posting mechanism asynchronously invokes the callback and the full message content is passed to the callback function. This is applicable to non persistent queues only.

The posting mechanism can also invoke callback without the full message content but instead just as a notification passed to the callback function. Subsequently, the client retrieves the message content in a pull approach that is applicable to persistent queues only. A client process acting on subscriber’s behalf retrieves message from a queue in a periodic or appropriate manner.

Thus using the Publish Subscribe model feature, it is possible for businesses and organizations to integrate information with their own data by seamless interoperations. Advanced queuing tools provides the potential to have database queues serve as messaging stores for queue based publish-subscribe systems.

| About Sequences and their attributes in Oracle10g | Accessing Remote data with Database Links in Oracle10g | A Guide to Iterative Processing with Loops in PL/SQL | A note on Dynamic SQL and its implementation in PL/SQL Application | Autonomous Transactions in Oracle – How to create and use if efficiently | Backup and Recovery – Best Practices in Oracle10g | Compiling Procedures, Functions and Packages during Application Development in Oracle10g | Introducing Publish-Subscribe Model in Oracle10g | Exploring Debugging Procedures in Oracle10g | External Procedures and their uses in Oracle10g | Guidelines for Locking Data in Oracle10g | How to customize an oracle10g Database using Database triggers | Specifying Constraints while creating table in Oracle10g to enhance Data Integrity |