]project-open[ is based on a standard Web application architecture, consisting of an open-source Web server with an underlying open-source PostgreSQL database.
(Schematic ]po[ architecture.)
Supporting both Windows and Linux, ]po[ consists of four main components:
The PostgreSQL open-source database. Support for Oracle is available on request.
The AOLserver open-source Web server for handling Web requests.
The OpenACS community system provides the basic application infrastructure.
The ]project-open[ packages implement the particular project management and finance functionality.
All ]po[ functionality is contained in packages that can be installed and uninstalled at runtime. Packages define a number of GUI elements such as menu tabs, portlets, dynamic fields and categories that can all be enabled, disabled or restricted per user group:
Menu tabs can be enabled, disabled or restricted to certain user groups.
Portlets can be enabled and restricted like menus. The user can define their placement, with a default location definable by the System Administrator.
Dynamic fields allow for standard objects to be extended with custom fields. Field read/write permissions can be set per user group.
Categories allow for all types and states in the system to be extended.
Numerous other GUI elements are also customizable:
Most "lists" in ]po[ pages can be extended by the System Administrator to add new columns and to restrict the visibility of columns to certain user groups.
A number of powerful "horizontal services" in ]project-open[ have been developed generically for all important business objects. Using these services multiple time allows reducing code redundancies, reducing errors and reducing the learning time for users.
(A number of powerful "horizontal services" apply to most business objects.)
The most important horizontal services are:
(A simple project approval workflow. The task "Approve" automatically appears in the user's Workflow inbox.)
A [graphical workflow editor] allows modifying workflows at runtime. Workflows are started once a new object is created. Assigned users are notified via email, and the assigned task will appear in the user's Workflow inbox.
Workflows are implemented using the Petri-Net formalism , allowing for advanced modeling techniques such as parallel paths and N out of M conditions. Callback functions allow users to modify the associated business object and the ]po[ data model in general.
(The ]po[ User Permission Matrix defines the (V)iew, (R)ead, (W)rite and (A)dmin rights between
user groups. Bold capital letters indicate set permissions, normal letter indicate no permissions.)
Package permissions allow administrators to control general access to ]po[ on a per-package level.
Privileges control the actions that different user groups are able to perform, such as creating or modifying certain objects. There are a total of 184 different privileges.
The user permission matrix determines how user groups can relate to each other. For example, customers in ]po[ shouldn't see the presence of providers in the same project room, while it is OK to see all in-house project members. This matrix also makes it possible to define sub-administration rightsâfor example, the right of the âsalesâ group to create new members of the group âcustomersâ.
Menu permissions allow to reduce the system's capabilities for certain user groupsâcustomers or providers, for example.
Portlet permissions allow to limit the visibility of object information.
DynField permissions allow to define access permission for each field of an object type.
Taken together, these rich permission options make it possible to adapt ]po[ to the trust relationships within most companies without having to customize the system.
(An "indicator" tracks a critical performance measure over time.)
]po[ provides a large number of options to extract information from the system:
The reporting engine formats hierarchical reports with groups and subtotals. It is fully integrated into the Web application and its permission system.
]po[ includes its own data warehouse engine based on ROLAP technology.
Indicators track critical performance measures over time and allow for defining Balanced Scorecards.
External Reporting Tools:
Thanks to the open and documented data model and the ODBC interface, it is easy to create reports using third-party tools including Crystal Reports, MS Access, Pentaho and others.
]po[ and its underlying OpenACS platform have been designed from the beginning to operate in the hostile Internet environment. A number of security features allow ]po[ to be run safely with direct access from the Internet:
Parameter Check via âPage Contractsâ:
Every Web page in ]po[ contains a âpage contractâ that checks any values coming from the hostile Internet environment and determines whether they match the defined data type. Page contracts are obligatory, so the developers can't âforgetâ this check.
In other words, ]po[ includes an integrated Web application firewall.
SQL Injection Blocker:
SQL injection is one of the most common vulnerabilities in Web applications. To avoid such attacks, ]po[ includes a special database driver that transfers parameter values separately from their SQL statement to the database.
Cross-Site Scripting (XSS) Blocker:
The âpage contractâ mechanism above also acts as a filter against cross-site scripting attacks. By default, no HTML tags are allowed in âstring values,â so a developer must explicitly allow for HTML tags. But even âHTML stringsâ are prevented from containing potentially malicious HTML tags.
Buffer Overflow Protection:
]po[ is written in the TCL programming language, with arbitrary length strings, avoiding buffer overflows. (Buffer overflows are possible in the AOLserver component; however, no such vulnerability has been reported since 2001.)
âObscureâ but Well-Maintained:
The combination of AOLserver and the TCL programming language is not commonly found in the Internet, so a potential hacker will need to expend a considerable amount of criminal energy in order to reverse-engineer the application stack. In addition, this code is very well-maintained: AOLserver is the core of the AOL infrastructure, and OpenACS/]po[ is developed as open-source by senior developers.
Semi-Automatic Security Reviews:
]po[ includes a semi-automatic security checker that identifies weak code and potential security threats.
Together, these features have convinced many ]po[ customers that the benefits from seamless Internet collaboration exceed the potential cost of a security breach. A prominent figure amongst this group includes VAW arvato (Bertelsmann group).
Benchmark results show that ]po[ can serve organizations with up to 250 active users using a single quad-core processor Intel/AMD server in a typical setting. Up to 1,000 active users can be served using a 4-processor Intel/AMD server.
Higher performance can be achieved by using load balancing and clustered application servers. For this purpose, ]po[ and its underlying OpenACS platform allow the separation of database and application servers. Only the database server limits such a configuration.
Even higher scalability can be achieved using different hardware platforms. For example the Business University Vienna is serving 23,000 users using OpenACS on an IBM Power5 mainframe, with up to 1,200 users concurrently active (please see: Who is using OpenACS?).
In order to provide business continuity, a combination of two physical servers has proven to be simple and effective:
A âproduction serverâ executes the productive ]po[ instance.
A âbackup serverâ serves for backup, development and testing. The backup server should be located in a different building then the production server.
A backup procedure takes a full snapshot of the ]po[ database three times a day (5am, 1pm, 9pm) and copies the snapshot to the backup server. This way, the customer will loose max. 4 hours of work in a worst-case situation.
The data can be accessed directly via SQL and modified from external applications using an API written in the PL/SQL database language. This way, advanced users can write reports or import data directly, without having to learn about the higher layers of the application.
The object-oriented structure of the data model allows for advanced features:
Powerful and standardized access permissions per object and user group (see above).
Full-Text Search Engine:
The search engine indexes all important business objects, considering application permissions.
Dynamic Fields Extensions:
Users can extend business objects with new fields without modifying the application code. New fields automatically appear in search forums and data-warehouse cubes.
]po[ includes a large number of functioning integration links with external applications.
The large number of already existing integrations is at least in part due to the existing infrastructure that simplifies system integration:
ODBC allows external applications to access the ]po[ PL/SQL API, allowing for full control of the application.
Web Service XML-RPC Protocol:
A built-in XML-RPC server makes it possible to expose the ]po[ TCL API to external applications.
Web Service SOAP Protocol:
A SOAP server module exposes the ]po[ PL/SQL API to external applications.
tDom libraries allow for parsing and constructing XML documents.
A number of libraries support the creation and parsing of CSV documents.
A surprising number of ]po[ objects exhibit a hierarchical structure, reflecting the nature of the real business world and allowing ]po[ to report on data at various levels of detail:
Projects can have sub-projects of any level.
Customers may be part of a group structure and holdings.
A company's departments and cost centers structure is hierarchical.
Groups may have multiple subgroup levels. Members of subgroups automatically become members of the supergroups.
The types of projects, customers, help desk tickets or other objects may contain subtypes of any level. For example, a âProviderâ company might contain the subtypes âIT Provider,â âOffice Equipment Providerâ and so on. Establishing these subtypes make it possible to generate reports and analyze spending among the unique provider subtypes.
The states of projects, customers, help desk tickets or other objects may contain substates of any level. For example, a âclosedâ project could be classified as âDeleted,â âCanceled by the Customer,â âUnpaid,â etc. Bear in mind, however, that timesheet hours should only be logged on âopenâ projects.
Configuration items in the ]po[ configuration database (=inventory) may have sub-elements. A âServerâ may be the home of several applications, which in turn consist of different modules, and so on.
Discussions threads may contain replies at any level.
Files may be located in folders and subfolders.
Menus in ]po[ allow for any level of submenus.
The object types in ]po[ themselves form a class hierarchy.
Permissions in ]po[ are hierarchical. For example the âadminâ permission of one object allows the admin to execute âread,â âwrite,â âcreateâ and âdelete,â which in turn may include additional subpermissions.
Hierarchical structures provide customers with a wealth of options to model the real world, as opposed to simplifying or tweaking the reality to match a rigid system. This is one of the most unique characteristics of ]project-open[ and the source of its configuration flexibility.
]po[ includes a number of advanced techniques to speed up hierarchical SQL queries, so there are no performance penalties to using hierarchies.