CSE586 Project 3

CSE586 Project 3
Persistence

Introduction:

In the final project we will enhance the Servants that are ultimately responsible for fetching and distributing news so that thet are more useful. In the previous project, it was not required that the Servant be very elaborate. Old news was not neccessarily sent to NewsCallbacks that registered after that news was detected; and some news may have been sent several times. In this part of the project we will use an Enterprise Java Bean (EJB) to create a Servant that will keep track of what news has been detected so that old news can be sent to new clients and so that news is not repeated.

An Overview:

A diagram of the system is shown below. This shows where EJBs fit into the archetecture we have built over the duration of this course.

All that needs to be done is to create a Servant implementation that communicates with an EJB server. The rest of the system will remain unchanged. When this project is complete you should be able to run your NewsService and NewsCallback implementations with the last project together with a Servant implementation from this project and begin to immediately see the benefits of your new Servant implementation without having to change any of the other code.

EJBs:

There are two types of EJBs, stateful-beans and stateless-beans. Since you will need to persist some information, stateful-beans, also called session beans, will be used. To learn more about Enterprise Java Beans work through Suns tutorial. A copy of the J2EE software will be placed in the /projects/bina directory for you to run on a workstation (not a fileserver like yeager or hadar). You may also download a copy for your own computer if you wish. You are responsible for creating a descriptor, writing and packaging the bean for use with the J2EE EJB server. The design and implementation of this bean are completely at your discretion, so long as the Servant you implement can work with it as described below.

Servant implementation:

This implementation will be slightly different from the last one; you must implement the following behavior:

Your servant implementation should interface with an EJB to persist (save) whatever information it needs.
Your servant should sleep, (Thread.sleep) waking up periodically check a news site and report the news to its registered NewsCallbacks - but it should NOT repeat news; each piece of news should be reported to each registered NewsCallback only once. You will use the EJBs persistence to keep track of old news.
When new NewsCallbacks register you should send them all the news that has been persisted up to that point, after that the callback is treated normally and will only recieve news as new items appear.
Because news updates are not all that frequent and because we are not permitting news to be repeated your servant should fetch news from several sites (at least three), selecting only one (however you'd like to) to check each time it wakes up. This will ensure that a Servant can't get all the news at once - at most it can get 1/3rd of the news any time. This allows the Servant to be tested and debugged to see that Newscallbacks are getting older news reported when they first register and get the newer news as it is discovered.

Grading Guideline:

Your code will be tested in the following configurations. In each configuration, several instances of the NewsCallback will be started, and several Servants will be started and how the news is distributed will be observed. The NewsService will be used in both round robin and in random selection modes.

Your Servants, Your NewsService, Your NewsCallback

Your Servants, Our NewsService, Your NewsCallback

Your Servants, Your NewsService, Our NewsCallback