Patch Bay defines a simple life cycle for message sources, sinks, and filters. When Patch Bay is started, it resolves each of the Nucleus names. If the referenced components are not yet created, they are created at this time according to the standard Nucleus name resolution procedure (including a call to doStartService if the component extends GenericService). For information about Nucleus name resolution procedure, see the Basic Nucleus Operation section of the Nucleus: Organizing JavaBean Components chapter.

At this point, message sinks should be prepared to receive messages, which can start arriving at any time, possibly from multiple simultaneous threads.

Message sources follow a slightly more complicated protocol. After a message source is resolved in Nucleus, Patch Bay calls MessageSource.setMessageSourceContext() on the component. This provides the component with a context object that it can use to create and send messages. However, the component should not begin to send messages yet.

At this point, Patch Bay initializes the various JMS providers and makes sure that the messaging infrastructure is up and running. It then walks through each of the message sources and calls MessageSource.startMessageSource() on each one. After this call, the message sources can start sending messages. Depending on the message source, this method is where a message source registers itself with the scheduler, or start a server to listen for incoming messages, or just set a flag that gates the sending of messages.

Message filters are combinations of message sources and message sinks. They implement both interfaces, and must follow the protocols for both. This means that a message filter must be able to receive messages as soon as it has been initialized, but should not initiate the sending of messages before setMessageSourceContext() and startMessageSource() are called.

There is one situation where message filters behave differently. A typical operation for a message filter is to receive a message, then to send another message in response. In this case, it is acceptable for the message to send a message in response to a received message, even if startMessageSource() has not yet been called (although setMessageSourceContext() must be called first in all cases). It is still not acceptable for a message filter to initiate a message before startMessageSource() has been called, but it is fine for the message filter to send a message in response to a received message.