eBus supports optional net.sf.eBus.client.ECondition to be associated with notification subscriptions and reply advertisements. Conditions restrict message delivery to those messages which satisfy the condition. For subscribers, this check is done just prior to actual message delivery. This means that potentially more messages are posted to the subscriber than are actually delivered.

For repliers, this check is done prior to posting the request message. This is necessary because eBus must determine if any repliers accept a request in order to return the correct request state to the requestor.


Dispatcher asynchronously delivers messages to eBus clients. A Dispatcher consists of a client run queue and one or more threads. An application may configure multiple Dispatchers, each handling different client classes.


eBus creates one EClient instance for each application client, regardless of the number of interfaces the client implements or open feeds. The client maintains a weak reference to the application client, the undelivered message queue, and the client's open feeds. EClient connects the application client with the Dispatcher.

Feed Scope

An application defines a feed's scope when opening the feed. This scope defines the feed's visibility. That feed may be visible only within the local JVM, within both local and remote JVMs, and in remote JVMs only. For example, if a subscription feed has local-only scope, then it will receive notifications from local publisher feeds only. Notifications from remote publishers will not be forwarded to the local-only subscriber. The following table shows the interface between feed scopes:

Feed Scope
Local Only Local & Remote Remote Only
Local Only Match Match No match
Local & Remote Match Match Match
Remote Only No match Match No match

(Notice that a remote feed may only support a local & remote feed and not other remote only feeds.)

Feed scope gives the application developer control over how "far" a will go. If a notification message is intended to stay within a JVM, both the publish and subscribe feeds may be set to a local only scope. If a notification is meant for remote access only, the the publish feed is set to remote only scope. These examples also apply to request/reply feeds.

Message Key

eBus message feeds are uniquely identified by a "type+topic" message key. The "type" refers to a concrete message class. The "topic" is the unique message subject. Using "type+topic" allows a message subject to be used for multiple message classes.

Example: there is a message class named CatalogUpdate and a message subject "FishingGear". Combinining the two results in the message key CatalogUpdate:"FishingGear". The message class may be combined with another subject to form another key CatalogUpdate:"CampingGear". Likewise, the subject may be combined with another message to form the key SalesSpecial:"FishingGear".

If you are familiar with subject-based addressing for message routing, then you know that these systems require subjects to be formatted according to a particular scheme. eBus has no subject-formatting requirements. You are free to format your message subjects any way you like.


An eBus message derived from net.sf.eBus.messages.ENotificationMessage. A notification message is posted by net.sf.eBus.client.EPublisher instance and forwarded to all net.sf.eBus.client.ESubscriber instances currently subscribed to that notification message key.