RNA

Your real-time online news

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!

 

SourceForge Logo

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).