spacer
technical documents and architecture explanations of technical terms about us and how to get in contact with us our current work offers
    .
spacer
spacer weblicon logo
spacer
start page our product portfolio test drive our applications business-, tech-, finance-, standardizaton partners some of our customers press releases, clippings, screenshots
 
spacer
architecture
techical documents
system architecture
Multi-Tier Architecture
Scalability
Load Balancing
Redundancy
Platform Independency
application architecture
Layers
Applications
Architectural Diagram
Modules
Frameworks
Messaging Architecture
standards
Languages
Protocols
security
Password Encryption
Secure Communication
Data Integrity
and Load
Administration Console
Modules

The applications of the weblicon PIM share common functionality implemented in application modules. The modules provide abstract functionality such as data manipulation and access to the underlying communications infrastructure. Using modules, weblicon achieves a high level of code-reuse among the different applications and thereby increases efficiency of the development cycle and stability of the resulting product.

Calendar

The Calendar module provides an abstract API for manipulating appointments allowing the applications to create, modify and delete appointments. The groupware functionality allows applications to create shared appointments and access other user’s schedule. In addition, the Calendar module contains algorithms for calculation of international holidays and utilities for time-zone conversion.

Address Book

The Address Book module encapsulates all data-manipulation for creation, modification and deletion of contacts and distribution lists stored in the user’s address book. It provides an object-oriented interface for adding and removing contacts to distribution lists, performing complex search operations and completely hides the underlying LDAP storage architecture.

To-Do List

Using the To-Do List module, applications can access and manipulate the user’s to-do items by using an abstract, object-oriented interface. The To-Do List module allows creation, modification and deletion as well as search operations.

Messages

The Messages module implements a unified interface to Email, SMS and MMS messages. Applications using the Messages module can transparently access the underlying communications and storage architecture using an abstract, object-oriented API, which hides the complexity of protocols and data formats. It supports files and folder manipulation allowing the applications to create or move folders and to file messages to folders.

The Messages module uses the Sun JavaMail architecture for accessing IMAP storage when filing and retrieving messages or when sending Email messages using the SMTP protocol. Using the adaptor-architecture of the JavaMail framework, the Messages module supports sending of SMS messages via the SMPP protocol. The Messages module includes utilities for constructing MMS messages according to the SMIL standard and sending of MMS messages using the SMTP protocol and in the future using the MM7 standard.

Files

The Files module provides access to the user’s personal file storage in the Weblicon system. The Files module allows applications to up- and download files and manipulate the file system hierarchy.

The Files module internally uses the industry standard WebDAV protocol to access the file server in the Data layer actually storing the files. Thanks to the WebDAV interface, the Weblicon PIM can access any 3rd party file server providing the interface and is independent from the underlying storage architecture.

Preferences

The Preferences module provides access to the user’s preferences supporting data manipulation of user attributes such as name, telephone numbers or preferred language. In addition, the Preferences module allows manipulation of the application-wide category list, which is used by other modules, such as the Calendar module, for assigning user-defined color labels to appointments, to-do items, contacts and distribution lists.

Localization

The Weblicon Localization module implements a common localization architecture shared by all applications. When displaying text elements, the presentation layer uses translation utilities of the Localization module to retrieve the correct resource translation according to the user’s language preference. All text elements of the user interface are stored in resource files separated from application and user-interface code. The Weblicon PIM applications currently support English, French, German, Italian, Spanish and Dutch. Thanks to the localization architecture, adding a new language can be implemented in a matter of days simply by providing text files containing the text resources of a new language, without requiring code manipulation or recompilation of the applications.

Skins

The Weblicon Skins module implements a very flexible presentation architecture supporting exchange of graphical user-interface elements on the fly without code manipulation. Using the Skins architecture, the weblicon PIM can dynamically exchange all images, colors and layout elements of the user-interface depending on the customer’s CI. By supporting multiple skins per installation, users of the weblicon PIM can even choose from a menu of different skins changing the visual appearance of the applications according to their personal preference.

Extensions

The Weblicon Extensions module supports a unique architecture for implementing customer-specific functionality without requiring modification of the core code base. The architecture clearly separates the code of customer-specific extensions from each other and from the weblicon core application code. Using a factory mechanism, the core application code dynamically determines application classes at run-time allowing the Extensions module to instantiate customer-specific versions of application classes overriding or extending standard functionality.

The Extensions architecture can be used, for example, to instantiate a customer-specific version of a communication class using UCP instead of SMPP when sending SMS messages. Another example would be a customer-specific extension, which introduces additional user-interface elements such as a special button performing functionality unique to the customer’s environment.