System Model Overview: Overall System Model
The PAID system consists of an arbitrarily deep hierarchy of almost identical PAID servers. The top PAID server is located at DaimlerChrysler headquarters and is connected to the main STAR NETWORK database. For intelligent caching and replication of data, each PAID server has a local database which contains frequently accessed subsets of the main database. The bottom PAID servers are located at the dealers' and contain a modified version of the existing STAR NETWORK server. Existing STAR NETWORK clients will connect to this STAR NETWORK server.
The following figure shows an example hierarchy of PAID servers with four dealers on two continents. Each dealer in this example has three clients.
When a dealer requests information using his STAR NETWORK client, the request is sent via the STAR NETWORK server into the PAID system. If the dealer's own PAID server can answer the query, it does. If it cannot, it forwards the request one step upwards in the hierarchy, for example to a regional PAID server. Now this regional PAID server tries to answer the query, and so on. For improved fault tolerance, a PAID server can also be configured to send requests to an alternate PAID server if its own parent server is not available.
When a PAID server notices that a certain subset of the database is being accessed frequently, and it does not have this subset in its own local database, it subscribes to this subset from its parent server. This way, frequently required data migrates downwards towards the dealers requesting it, speeding up requests. For an additional performance gain, answers to queries get cached for a short time in case the same query is asked twice in a row.
The top PAID server feeds updates to the main database into the PAID system and forwards them downwards to its child servers which have subscribed to the relevant data. The updates migrate down to all the PAID servers which need them. This ensures that all queries are answered with up-to-date data.
The following figure shows the configuration of clients and servers at a dealer. Since the existing STAR NETWORK clients only work when they have network access to a STAR NETWORK server, a mobile client must either have wireless network access or locally installed STAR NETWORK and PAID server software.
System Model Overview: Internal System Model
The PAID server software is divided in five
functional units:
Network & Event
Service
It enables the network connection to an upper PAID
server or to a lower server. Incoming requests are received and
given to Authentication & Security for decryption and
authentication issues. It is responsible for building an event
object that can be used within the event service.
Authentication &
Security
This module allows encryption and signing of
messages before they are sent over the network. It can also check
signatures from incoming messages and decrypt them. Furthermore it
will receive the event object built by the Network & Event
Service and check whether it contains a database query and if it
is one, whether the sender of the request is allowed to view this
kind of data subset or if he might have to pay for it (billing). It
can also authenticate a user's login on a STAR NETWORK user
interface.
Database
The database module
enqueues all queries it receives and tries to answer them. If a
requested information is not part of the local database, a new
request to an upper server will be issued while the enqueued query
waits. The module has the ability to subscribe to a whole data
subset on an upper server and to receive these subsets and updates.
The database can also filled by CD-ROM.
STAR NETWORK / UserInterface
It
has to ensure that the query asked by a user is transformed to
standardized query format, and, if it is necessary, to send it to
the next upper server. If the PAID server resides on the same
machine, it can directly issue a query event on the Event System
and bypass authentication and encryption/decryption for better
performance. It has to provide integration into the existing STAR
NETWORK system and particular user dialogs to meet the needs for
all user interaction.
Learning & Adaption
If
several incoming requests belong a particular subset, it might be
sensible to fetch the whole subset and subscribe to regular updates.
The task to determine when this should take place belongs to the
Learning & Adaption module. It directly notifies the
Database module to subscribe a subset. It uses special
learning algorithms for that and logs all incoming database queries.
For testing purposes, another functional unit will be created. It is not necessarily a part of the final running PAID server:
Application Testbed
It will be used to check the
contents of the events on the Event Service. Thus it can
subscribe to any events of interest. It may also use special methods
provided by the modules to explore internal states of them.
The communication between the units is based on the event service provided by the Network & Event Service and a supporting middleware based on CORBA. Only the communication between the Network unit and the Authentication unit relies on functions calls so that unauthenticated messages from the network do not occupy the event bus mechanism.
An example for this might be the following scenario. It describes the actions when an incoming network message arrives. This message contains a database query in the example.
The Network unit has received the message and calls a Authentication module function for decryption and authentication of this message. If the message appears to be all right, the Network unit creates an event for the database query and passes this event to the Authentication module again. There is checked whether the client has the right to view this particular data subset or if it perhaps has to pay for the answer. When access is granted the Authentication module issues the query event on the event bus system. The Database module has subscribed to those query events and receives our query. Then, the event is enqueued and processed. The answer is carried back on the same way.