The Accelerator Database
The storage layer incorporates the Accelerator Database as well as accessing other repositories. These other repositories (or databases) do not need to reside on the same physical equipment and in fact may reside in completely different physical locations.
The Accelerator Database is divided into two:
- Application Data
- Interface Data
Application Data
The Accelerator Application’s storage requirements include:
- Profile information about customers, prospects, contacts, suppliers, agents and staff
- A full audit trail of interactions between users and customers across every touch point
- Current and Historical Sales Opportunities and Service Issues
- User access rights, job roles and audit trail
Interface Data
Accelerator Interfaces are also stored in the Database. These include:
- The rules and interfaces for each connected repository
- Accelerator can be configured to meet many requirements. This configuration is stored in these interfaces
- MGC Manager Data and Functionality are integrated with Accelerator. The interfaces and mappings required to support this integration are also stored in the database
- The mapping of business processes to system workflows
The Accelerator Application Server
The Application Server sits in the middle-tier of the architecture and contains the Accelerator Rules Engine. The Application Server:
- Provides connectivity to both users and servers
- Contains Accelerator’s business logic
- Builds Business Objects on demand
The Accelerator Rules Engine is built using Open Communication standards, the Rubicon Software Generic Business Object Server (GBOS) and a sophisticated rules system configured specifically for Accelerator.
Business Objects
A Business Object is a set of attributes grouped logically together. It contains the rules for how these attributes are maintained: how new data is inserted, modified, deleted and can also contain rules for running a process on the attributes.
For example a Business Object for Name and Address information would have attributes: forename, surname, title, town, county, postcode and rules for calculating derived fields such as full name and initials.
The core of the server is the ability to serve Business Objects that can aggregate data from the connected database repositories. Using the communication layer, it can serve large numbers of clients securely, minimising the necessary network bandwidth.
The Business Objects are defined using the Accelerator Configurator that sets up the entire schema in the database. This allows for rapid development and customisation without the need for code changes. A security layer gives a highly flexible range of user access control to Business Objects by field and row constraints.
Communication Layer
The Communication Layer manages all connections to the GBOS. It is responsible for identifying the purpose of any requests, passing those requests on to the GBOS and returning the response. It does this whilst transparently managing user sessions and dealing with packet encryption and compression.
Generic Business Object Server (GBOS)
GBOS provides a single, metadata-based, interface to a set of business objects. These business objects encapsulate top-level business logic, whilst providing an abstraction from the underlying repositories.
The repositories can be anything from databases to web services and third-party application servers. To ensure that its data is up-to-date, the GBOS performs heterogeneous cross-repository joins to allow it to retrieve data from its source. Optimisation of the order and content of each repository query ensures that this is performed in the quickest possible time.
The Accelerator Clients
Most users of Accelerator use the Rich Client application rather than a pure HTML user interface.
Rich Client solution
The Rich Client approach takes the best of the old 'Thick Client' (traditional client-server approach) and the more recent 'Thin Client' (browser) solutions. The rich client takes advantage of the user interface, resilience and communication capabilities of the Thick Client but delegates most of the business logic to the server, as in a Thin Client solution.
The Rich Client knows exactly what type of data is to be displayed so the Application Server only needs to send this data. In Thin Clients the layout and formatting information also has to be sent as HTML. This means less information is sent with Rich Clients so less bandwidth is consumed.
“Clever” Rich Clients (like Accelerator) also contain local caching techniques. This means that data that is commonly requested is copied to the client machine to avoid unnecessary use of bandwidth.
Rich Clients (like Thick Clients) take full advantage of the Operating System’s Graphical capabilities. This ensures that “Drag and Drop” features, expanding/contracting trees etc. are all supported with no impact on bandwidth (unlike Thin Clients). Some User Interface Functionality can also be compiled into the Rich Client. The resulting application is significantly more usable than the “Lowest Common Denominator” approach offered by HTML.
