Technology
Overview
We build applications using kinodb, which is our own application development and deployment toolset. This allows us to develop web-based applications for deployment to standard browsers with no requirement for any installation at the users' PCs.
kinodb greatly speeds the application development process as it maintains the definition of the application (in terms of the database schema, business logic, user presentation and so on) as data, rather than as code and database generation scripts.
kinodb applications use Oracle for data storage. This means that an application can be scaled to support thousands of users without any change to the application itself.
The kinodb application server is deployed using a Java servlet container, so can be deployed onto just about any server platform - we have customers using Windows Server, IBM AIX, Sun Solaris and various Linux distributions. The application server technology is also inherently scaleable, so kinodb applications can be used across an enterprise of virtually any size.
Architecture
kinodb applications are based on a simple, robust and easily deployed software platform. The following diagram illustrates the standard configuration.
The application and database servers may co-exist on the same physical hardware or may be installed on separate boxes. Any component may be virtualised.
No software is required at the users' desktops other than their normal Internet browser (Internet Explorer, Firefox, Safari etc.). No ActiveX or other application components are downloaded to the desktop machine. This means that applications can be developed and deployed without the requirement for any changes to users' machines, making it easy to provide applications that are used throughout - and externally to - a large organisation.
Application management
A kinodb application's design is represented entirely in data, and kinodb maintains a complete history of all changes made to any aspect of the design. This means that the entire history of any part of the application can easily be viewed.
All internal dependencies are visible to the application developer, so the impact of any change can be assessed instantly in a way that isn't possible in other development environments.
The history of application changes remains with the application permanently, maintaining a complete audit history of every individual change made to the application throughout its development and subsequent maintenance activities or enhancements.
Application updates are propagated between environments under the control of kinodb - this means that a complex set of functional changes to an application can typically be applied in minutes. Where an outage is required, kinodb will manage this process, informing users and disconnecting them safely before placing the application into a read-only mode whilst changes are applied.
Multiple developers can work on the same application concurrently, with their changes being integrated into the 'master' development environment as required.
Session and performance monitoring is built into the server, so you can easily assess the effect of changes in data volumes, patterns of user activity and so on. Detailed timing and other diagnostic information is available to the administrator, allowing identification and diagnosis of performance problems should this be necessary.
An administrative user may view another user's session - this can be very useful for training and support purposes.
Data interchange
A kinodb application is stored in an Oracle database. The data schema is conventionally structured using standard relational database techniques. Where appropriate, kinodb can publish database views onto complex application data to remove the need for duplication of application design logic on the 'far' side of the interface.
Third-party reporting systems (for instance Business Objects, Cognos etc.) are easily coupled to a kinodb data schema, although in most cases we have found that kinodb's reporting capabilities are such that clients ask us to implement reporting functionality within the kinodb application itself rather than externally.
SOAP-based XML data requests are supported; again these can encapsulate complex data in an easily-digestible form.
Inward interfacing is generally most easily accomplished using Oracle's in-built functionality and tools, which allow the population of database tables from a variety of sources (XML, other databases and so on). Where an inward interface is required we will generally implement a set of 'data load' tables to be used as the delivery point for incoming data. Once populated, logic will be incorporated within the kinodb application to validate the delivered information and to integrate it into the application's main data.
Reporting
A full report generator is built into the kinodb development environment, allowing the production of reports that are fully integrated with the application. This level of integration means that it is simple to visualise complex application data, with links to lower levels of detail or data edit screens as required.
Graphing functions (line graphs, pie charts, scatter plots and histograms) are supported with the reporting function. All report output is delivered to the user's browser as HTML, with graphs being rendered by Javascript.
Security
Single sign-on is (optionally) supported via NTLM where users have already authenticated to a trusted domain.
Anonymous use can also be configured, for instance to allow any user to perform simple tasks without identifying themselves to the application. Users can also be created under the control of the application, so that a 'self-service' facility can be provided, allowing a user to request an account and then to receive notification via email of their credentials.
Once connected to the application, the user's capabilities are controlled by the rights that have been assigned to their user ID - these are generally conferred via Group memberships although they may be individually assigned. The application security model is based on 'realms' that are defined as a part of the application - these generally correspond to areas of functional capability, for instance 'Stock control'. Within each realm there are as many realm levels as are required to reflect the differences in levels of access to that function. So a given user might have rights expressed as 'Stock control - administrator' and 'Finance - basic user'.
All application functionality (for instance the visibility of a given field, the ability to delete a record, to see a menu option and so on) is associated with a realm and realm level, so the same application might present very differently to two users with differing access rights. Forms and lists are presented to the user automatically tailored to their rights without any effort on the part of the developer.
Two levels of data encryption are supported - Single-key encryption, preventing access to specified data items via database tools by encrypting data using a single key known only to the application server, and Access Control List - this encrypts data using a key known only to the user that owns the data. Using a system of public and private keys, the owning user may then grant secure access to the data associated with a specified ACL to other users.
Single-key encryption is used in conjunction with the overall application design in order that users are only presented data to which they are granted access. ACL-based encryption operates outside the normal application architecture, meaning that secured data is not vulnerable to compromise in the event of application design error or even malicious developer activity.