RNA
We are there to provide you with news from around the globe fast and reliable. You can visit our website, look at our teletext pages and receive e-mails on breaking news!
Introduction
Student 1 |
Student 2 |
Ying Zhang |
Guus Bosman |
1104330 |
1042114 |
jennie@cs.vu.nl |
gbosman@cs.vu.nl |
VU |
VU |
INF |
INF |
SE |
SE |
1998 |
1997 |
Yes |
Yes |
Design
bus structure
The backoffice systems are connected using a bus structure, implemented in Corba & XML. This bus connects all the applications. There quite diverse application programs connected to the bus, some are not made in-house but are provided by external parties. Therefore a Corba bus has been chosen (Corba is supported in many languages, so writing wrapper software is possible). We will have to choose a "message interface" to support the different messages appearing on the bus.
We don’t know yet how exactly we will implement the bus (push or pull; how to implement workflow somewhere).
reusability
An important part of this practical assignment will be to implement reusability. Many parts of the software "do the same" only with different user interfaces. There are for example two client programs that will put news into our system. The functionality required for this, for example user authentication, spell checking etc. should be implemented only once for both clients.
The re-use of software to provide a visual layout (for both the web- and teletext server) is another area where reusability shows.
design patterns
We expect that especially in the client software design patterns will be very useful. Many of the thing we will do "have been done before". Things like implementing sessions for stateless protocols, queues of messages etc will most likely have suitable patterns. We will investigate which patterns to use where.
Technology
We will use Java, Corba and a J2EE webserver (for the teletext-server and the website).
A first drawing of our software bus:
Type of client |
Description |
Amount of clients |
|
1 |
Local editors |
Journalist in office, inserting stories, checking and approving external newsfeed |
More than 1 computer; will need a central "chief editor" application as well for final approvements. |
2 |
Text server |
Our newsfeed will be placed on teletext pages of tv-stations. These pages are produced in-house. |
One text server only. |
3 |
Webserver |
Our newsfeed will also be placed on our own website, this will be a important "view" on our newsfeed, we expect many visitors. |
One webserver only. |
4 |
Webserver logged in journalist |
Journalist not in office, perhaps in another country. Provides a mean of adding stories to our newsfeed through a web-browser. Access will have to be secure of course. |
More than one editor can be online, but most likely not more than 20 at the time |
5 |
Debugging console |
At the console an overview is given of the amount of messages and types of messages given. |
One debugging only. |
6 |
Newsfeed receiver |
Here headlines from other agencies as ANP, AP, Reuter etc will be received and translated into our internal formats (and put on the bus). |
More than 1 receiver can exist. Per technique used to receive messages. |
7 |
Customer news feed exporter |
Special customer will be able to receive XML files on regular intervals with the latest news. This might be: stock markets, financial instituations, etc. |
Only one exporter will exist, this can spread the messages to multiple external parties though. |
8 |
Breaking news email/sms server |
Customers can subscribe themselves on different services, including breaking-news or special topics (for a nominal fee) |
One e-mail, one sms server. |
The difference between 4 (editor in office) and 7 (external editor, editor on the spot) is that the first editor will have a broad overview of all the incoming messages. The latter will not have all the message visible (this is more about inserting stories, not creating the whole newspaper/newsfeed).