Semantic Rich Internet Application (RIA) Modeling, Deployment and Integration

Zoran Balkić, Marina Pešut, Franjo Jović

Faculty of Electrical Engineering, Kneza Trpimira 2b, Osijek

, ,

Abstract.

Major goal of the paper is to introduce semantic approach for building RIA, semantically supported from design to exploitation time. Building semantic application would achieve exposure of application computational artifacts as well as data structure and instances itself. Combining ontologies for content, document management, business processes, security and dynamic semantic GUI speeds up application prototyping and integration. Modeling at ontology level leads to uniform implementation, RIA automatic deployment and versioning compatibility. The model based on JCR (Java Content Repository) has been adopted for the application data and metadata storage and retrieval on top of which different semantic engines can be used.

1. Introduction

In this paper we would like to introduce the possibility of semantic Rich Internet Application using ontology which has the potential to facilitate the creation of semantic relationships between various pieces of system components to enhance modeling, deployment and integration.

There are already several approaches regarding rapid RIA application development, but none of them offers semantics during modeling and exploitation time. Furthermore, they all require specialized (IDE) Integrated Development Platforms binding components to proprietary frameworks. Exposure of computational artifacts is purely reserved for specialized services that are built for the exact purpose.

In some simple cases, where using RIA for Website creation, it is possible to expose data in RDF form, but none of these approaches has yet been adopted by the real RIA applications.

Several semantic projects have been started and they do provide some higher level of semantic approach withSWEET using WebML, WSMO, BPMN, etc. They are usefulin modeling and integration of applications using Web Services discovery, orchestration and invocation, but do not address the development issues regarding automatic ("zero" code) RIA application creation and deployment.

2. Modular approach

The role of ontology in this case is to support the effective knowledge acquisition and creation processes in the application/web environment using separate, but well defined and correlated knowledge trees.

Ontology plays the role of a modeling and binding factor that brings various knowledge items and processes together to provide a richer and integrated view of the knowledge domain to application clients as well as aplatform for semantic data mining techniques.

It allows interrelating, combining, and thus reusing RIA application knowledge units. Analyzing existing RIA and their internal structure leads to the conclusion that most of the functionality and design issues are borrowed from the fat client world using well established patterns for RIA GUI creation, data and metadata storing and retrieval as well as business process integration and management. New approach differs from the well-established way of thinking by combining "regular" WWW world of static, semi dynamic and dynamic data, attractive visual interpretation, data modeling, synchronous and asynchronous communication rules with semantic way of representation using ontologies.

2.1. Repository definition

The basic building block is the core of the system for storage and retrieval of data and metadata. In our scenario it is JCR (Java Content Repository) as data manipulation layer, basically built on top of the tree representation for the data structures that corresponds with semantic way of analysis and modeling, emphasizing the use of URIs for data creation/retrieval.

Figure 1: Structure of JCR compliant application

Content repository can be described as a generic application "data store" that can be used for storing both text and binary data (image, video file, Word document, PDF, etc.).

A custom repository reflects one of the fivemodular components (domains) of the system that are ontology defined:

  1. Website / Application tree (navigational data) derived from persisted data;
  2. Document management (for binary data);
  3. Security constraints (for user / groups data);
  4. Business process (for storing BP definitions);
  5. Configuration data (used by all repositories and server for runtime configuration);

Figure 2: Application framework ontology definitions

Resource Description Framework (RDF) and Web Ontology Language (OWL) are used to build a local model from which applications repositories are initialized.

Custom repositories are essential part of the Framework as JCR defines three different compliance levels:

Level 1 defines a read-only repository: This includes functionality for the reading of repository content, export of content to XML and searching using XPath, JCR query. This functionality should meet the needs of presentation templates and basic applications.

Level 2 defines a writable repository: In addition to Level 1's functionality, it defines methods for writing content and importing content from XML. Applications written against Level 2 features include any application that generates data, information or content, both structured and unstructured.

Advanced options: In addition to Level 1 or Level 2 features, the specification defines five additional functional blocks: Versioning, (JTA) Transactions, Query using SQL, Explicit Locking and Content Observation.

In addition to being either Level 1 or Level 2 compliant, any repository can decide on implementing one or more of these functional blocks. A repository that implements all of these features in addition to being Level 2 compliant can be used as a general purpose off-the-shelf infrastructure for content management, document management, code management, or any other application that persist content.

2.2. Website / Application repository

If we consider website tree navigation as simplified Application tree we can see that semantic design can lead to simplified data layer on top of which dynamic navigation is extracted as core component views.

The main distinction from the classic approach is abstraction of the data layer that results in the transparent component design regardless of the type for data storage (RDBMS, file system, XML).

Core component structures are ontology defined, hot deployable by the framework and dynamically described using RDF for Integration purposes. Such data and metadata can be statically exported from the system for usage with various external semantic tools. Among usual application characteristics we should emphasize just a few:

  • managing multilingual content;
  • delivering personalized content;
  • maintaining multiple corporate applications/ websites: public corporate Web sites, global and localized sites, intranets and extranets;
  • publishing distributed and disconnected content from multiple sources using multiple repository synchronization;

2.2.1. Generic RIA Web GUI components

Application ontology defines data structure from which all GUI components are described. Modular Macromedia Flash solution should be used in this scenario. Complete component description is necessary for successful GUI rendering and manipulation.

Considering some other configuration parameters needed for GUI accessibility and Look&feel we have two options to store data, either in the configuration repository or application data repository itself where second choice offers increased performance in some cases.

2.2.2. Application navigation

Primarily,application navigation represents two different types of data rendering, one as static data retrieval as it is defined in the repository tree and the other as dynamic semantic linking between data nodes in the repository. Data storage and retrieval layer is built as dynamic repository tree that represents model/view independence where each node of the tree can hold any type of data, either as direct entity instances, dynamic links or transparently reused data preserving semantic linking.

2.3. Document management

Analysis of the binary data requirements leads to the conclusion that separate document management tree can be created which holds specific types of binary data that do not belong to the application/website tree but are essential for specific semantic component creation (e.g. video, audio, extended document mapping).

The DMS provides storage for large binary data which should be separated from the application/website data due to performance, backup and future changes. Furthermore separate DMS based components are represented as a structural part of application components where one unique DMS document can be semantically annotated with alternate meaning within different application components.

Semantic Document Management is characterized by:

  • managing the document lifecycle, from creation to publication and to archive;
  • documents indexing;
  • managing documents, attributes (metadata);
  • managing context links and semantic relationships between documents' types;
  • documents routing for processing tasks, approvals, and distribution (event-driven architecture);
  • streamlining document workflows and document publishing cycle times;
  • easy, secure and smart access to enterprise documents;
  • supporting timely decision-making throughout an organization;
  • documents follow-up action;
  • integration with enterprise applications;
  • semantic full-text search.

2.4. Security constraints repository

Adopting security mechanism within the framework is essential. Being semantically enabled, application changes the usual security requirementsusing implementation of so called Semantic Firewall, that provides adaptive and dynamic protection of the application domain. Such protection should not be based on inflexiblerules, but on an understanding of the expected series ofinteractions between parties within and outside the protecteddomain. Security support isessential for creating asmart computing environment where a number of servicesoperating within different domains can be employed inunion to achieve wider goals.

By using services such as uniform access control it is possible to restrict access to specific data nodes in the application/website repository. It leads to specific aggregated data with fine grained security rules that can span up to each individual'sretrieval and manipulation.

2.5. Business process / Workflow repository

Business Process Management (BPM) is the approach of managing the execution of supportedbusinessoperations from a managerpoint of view. However, the degree of automation in BPM is still unsatisfying. Also, BPM does not provide a uniform representation of an organization’s process space at a semantic level, accessible to semantic queries or for compliance checks and for the discovery of processes or process fragments that can be used for process composition.

Therefore, sBPM (semantic BPM)introduces a new way of verification if a process description satisfies the consistency constraints defined by business rules. In addition to providing services for storing and retrieving data, most content repositories provide advanced services such as uniform access control, searching, versioning, (JTA) transactions, observation, explicit locking, and more. These functionalities are convenient for business process definition storage.

Basic features:

  • new task notification;
  • automatic tasks and documents routing for creation, changing, exception and approval processing;
  • management of unfulfilled tasks;
  • parallel workflow processing;
  • auto-delegation;
  • dynamic routing;
  • monitor the status of any workflow across the enterprise;
  • workflow versioning;
  • collaborative decision-making and exception-handling in structured workflows;
  • closed-loop environment for executing, monitoring, analyzing and optimizing workflows and business processes.

2.6. Configuration repository

Essential part of the system that insures application infrastructure is configuration repository. Following the same scenario as all other repositories,it offers flexibility for the application configuration parameters which can be static ordynamically updated to the current state in the repository with or without application restart.

Main ontology nodes:

  • server configuration;
  • functional modules configuration which includes templating mechanism, component description and structure;
  • application framework metadata.

3. Discussion

On the present Web, the lack of semantics prevents computer systems from being able to interpret Web information automatically. For a task such as Web-based RIA generation and delivery we have introduced the overall model blocks for building such an application.

Deployment features are built in application ontology, thus, providing us with the flexibility and 'zero' code development. Integration techniques are built in the system as a native part from the modeling stage to the exploitation. Modular architecture provides separated computational artifacts that can be, lately, deployed as standard generic Web services models used with other semantic approaches to this solution.

The hypothesis that a Semantic Web based modeling might be particularly suitable for knowledge aggregation in a dynamic RIA environment should be evaluated with a prototype implementation. The stated task is not simple as it combines quite large and complex solutions in application assembly.

We would like to emphasize just a few benefits that would arise from this approach:

  • Semantic way of abstracting during application lifecycle;
  • Use of semantic Visualization tools to ease understanding of complex systems;
  • "Hot deployable" GUI components that represent classic OO (Object oriented) models;
  • Dynamic Data layer modeling with backward and forward compatibility including versioning;
  • Integration with other semantic initiatives such as Semantic Desktop.

Possible drawbacks of the proposed approach:

  • Performance in process-intensive Web applications;
  • time invested in the framework modeling, development and deployment is longer than in usual approach to problem using conventional methods.

We fully agree with Charles Petrie’s words: “If semantic technology has a future — and I’m sure that it does — it’s in software engineering”.

4. References

  1. WebML.org:. 2006.
  2. Semantic Business Processs Management Working Group
  3. Tim Berners-Lee. Semantic web road map, 1998.
  4. Tim Berners-Lee. Web architecture at 50000 feet, 1998.
  5. Tim Berners-Lee. What the semantic web can represent, 1998.
  6. Tim Berners-Lee, R. Fielding, U.C. Irvine, and L. Masinter. Uniform resource identifiers (URI): Generic syntax, August 1998.
  7. Webratio: 2006.
  8. Digital Enterprise Research Institute (DERI)
  1. OMG: Ontology Definition Metamodel (ODM).
  2. JCR Implementations

Communique –

Apache Jackrabbit –

  1. Protégé approach and toolset
  2. OWL delivery language
  3. Organization for the Advancement of Structured Information Standards