Abstract to
                                  
                	      ImmoWarrior: "e-Immo"
                              ---------------------
                         Lucia Fimberger, Marion Nidetzky,
                    Robert Haral Rescher, Oskar Schobesberger,
                                 Elisabeth Strobl

  As an abstract, we want to show the system architecture. Well, first of all we
have to ask, what the system should be for - hence, what are the requirements
to the application. We have an action firm via the Internet which implies some
kind of login that distiguishes between administration and other users.
Furtheron, we need to regard that the visual components are not part of our
system, they need to be formulated as HTML or WML. The system needs to be able
to deal with a number of simultaneous logins. The action firm handles real
estates. These real estates are held in a database.
  The next question was how to realize the the user interfaces. We distinguish
between
    * Login.
    * Enquiring real estates.
    * Offering real estates.
    * Participate the auction.
    * Administrate.
We solved this by putting the point "participate the auction" to the detail
view of "enquiring real estates". The rest is clear. We have a login, and after
having logged in successfully, you will come to an action choice (what do you
want to do?). This choice will not appear if you have the right to enquire
only.
In the administration, you can edit all the users with their rights. Also the
administration of the real estates is an own mask.
  Our system is a layer model - containing three layers:
    1) Presentation.
    2) Business.
    3) Database.
Most compilcated part of the system is the presentation layer, since it has to
translate between HTML, WML and a self convented language. Furhteron, it is
open to the external network client. It communicates with the Business-layer
via well-defined routines. The Business-layer is our interface to the user.
Regard that there is one part within that is fix (instantiated only once), and
one part that is instantiated for each user. The physical database, of course,
exists only once. On the interface to the application (internal and external
file accession), we have the database class to access the physical database.
  On this point, it became even more clear, that our application needs to be
event-controlled. Otherwise, all the simultaneous logins would conflict with
each other, and waiting-loops will make the system quite inert.


                                                  29th of January 2001.