Semantic Rich Internet Application (RIA) Modeling, Deployment and Integration
Zoran Balkić, Marina Pešut, Franjo Jović
Faculty of Electrical Engineering, Kneza Trpimira 2b, Osijek
zoran.balkic@etfos.hr, marina.pesut@etfos.hr, franjo.jovic@etfos.hr
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 with SWEET using WebML, WSMO,
BPMN, etc. They are useful in 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.
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.
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 a platform for
semantic data mining techniques.
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 five
modular 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 requirements
using implementation of so called Semantic
Firewall, that provides adaptive and dynamic
protection of the application domain. Such
protection should not be based on inflexible rules,
but on an understanding of the expected series of
interactions between parties within and outside the
protected domain. Security support is essential for
creating a smart computing environment where a
number of services operating within different
domains can be employed in union 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's retrieval
and manipulation.
2.5. Business process / Workflow repository
Business Process Management (BPM) is the
approach of managing the execution of supported
business operations from a manager point 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 exceptionhandling 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 or dynamically
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 Webbased 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:. http://www.webml.org, 2006.
2. Semantic Business Processs Management Working
Group http://www.sbpm.org
3. Tim Berners-Lee. Semantic web road map, 1998.
http://www.w3.org/DesignIssues/Semantic.html.
4. Tim Berners-Lee. Web architecture at 50000 feet,
1998.
http://www.w3.org/DesignIssues/Semantic.html.
5. Tim Berners-Lee. What the semantic web can
represent, 1998.
http://www.w3.org/DesignIssues/Semantic.html.
6. Tim Berners-Lee, R. Fielding, U.C. Irvine, and L.
Masinter. Uniform resource identifiers (URI):
Generic syntax, August 1998.
http://www.ietf.org/rfc/rfc2396.txt.
7. Webratio: http://www.webratio.com, 2006.
8. Digital Enterprise Research Institute (DERI)
http://www.deri.org
9. OMG: Ontology Definition Metamodel (ODM).
http://www.omg.org/cgi-bin/doc?ad/06-05-01.pdf.
10. JCR Implementations
Communique – http://www.day.com
Apache Jackrabbit – http://jackrabbit.apache.org
11. Protégé approach and toolset
http://protege.stanford.edu/
12. OWL delivery language
http://www.w3.org/2004/OWL
13. Organization for the Advancement of Structured
Information Standards
http://www.oasis-open.org/