Observer-Pattern with EJB

[Ali Reza Hosseini]

Hi,
How can I implement an Observer/Observable Pattern with EJB technology.

I intend to have a server component
which holds the system's state for alle the clients who subscribe
for this state (One state for all client). The server component has to notify all clients if the system state changes.

Which technology is prefered to do this?

A SFSB does not seem to be the right one because it can
only hold one client's state.

A SLSB is not the right choise because it does not provide any state at all ..

The only one remaining is an entity bean but that means having the state
saved in a RDBMS ..

What if I don't want to save the system's state in a RDBMS?

Is there any other way for implementing a server component
which can be refered by many clients and provide them the same state?

thanks for your advise ..

Alireza

[Reid M. Pinchback]

Message driven bean. Subscribers become topic listeners, and the MDB destination is the topic.

[Ali Reza Hosseini]

ok, this was my first consideration, but somewhere i read that a client can only get those messages which arrived in the topic after it has subscribed
the topic. The client has no access to those messages which
was published before it has subscribed the topic.

imagine the following situation:
A client starts and want to get the current state of the system.
The topic will propagate a new state only if there is a change on
system's state. How will the client get the information about the
current state, if there is no message published after it has subscribed
the topic?

[Stan James]

Looks like you'll need a couple mechanisms: getCurrentState and subscribeToStateChanges. I'm not sure how to handle changes that occur while get current is running. Maybe

subscribe to changes
get current state
apply changes

Check out Gregor Hohpe's Enteprise Integration Patterns for messaging and events. Maybe start with Publish Subscribe and the related patterns at the bottom of the page. You may find something like what you have to do.

[Reid M. Pinchback]

Originally posted by Ali Reza Hosseini:
ok, this was my first consideration, but somewhere i read that a client can only get those messages which arrived in the topic after it has subscribed the topic. The client has no access to those messages which
was published before it has subscribed the topic.

This is not specifically an MDB issue, this is true of any observer pattern implementation. You don't know the history of every event delivered since the beginning of time unless you have some persistence mechanism maintaining that state. If you have to bootstrap clients with correct current state then that is what you need to do, but it really has nothing to do with the observer pattern.

[Jaikiran Pai]

but somewhere i read that a client can only get those messages which arrived in the topic after it has subscribed
the topic. The client has no access to those messages which
was published before it has subscribed the topic.

You can have "durable subscriptions to topics", in which the client will get messages even if they were published before the client subscribed to the topic. This is an extract from one of the JMS related articles:

Publishers and subscribers have a timing dependency. A client that subscribes to a topic can consume only messages published after the client has created a subscription, and the subscriber must continue to be active in order for it to consume messages.
The JMS API relaxes this timing dependency to some extent by allowing
clients to create durable subscriptions. Durable subscriptions can receive messages sent while the subscribers are not active. Durable subscriptions provide the flexibility and reliability of queues but still allow clients to send messages to many recipients

Have a look at the JMS specs for more details