aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes Observer-Pattern with EJB Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Observer-Pattern with EJB" Watch "Observer-Pattern with EJB" New topic
Author

Observer-Pattern with EJB

Ali Reza Hosseini
Ranch Hand

Joined: Apr 28, 2005
Posts: 33
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
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
Message driven bean. Subscribers become topic listeners, and the MDB destination is the topic.


Reid - SCJP2 (April 2002)
Ali Reza Hosseini
Ranch Hand

Joined: Apr 28, 2005
Posts: 33
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
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
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
Marshal

Joined: Jul 20, 2005
Posts: 10102
    
165

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


[My Blog] [JavaRanch Journal]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Observer-Pattern with EJB