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

1. 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

2. 1. Introduction 2. Modular approach 2.1. Repository definition 2.2. Website / Application repository 2.2.1. Generic RIA Web GUI components 2.2.2. Application navigation 2.3. Document management 2.4. Security constraints repository 2.5. Business process / Workflow repository 2.6. Configuration repository 3. Discussion Presentation outline

3. possibility of semantic Rich Internet Application using ontology • potential to facilitate the creation of semantic relationships between various pieces of system components to enhance modeling, deployment and integration • several approaches regarding rapid RIA application development, but none of them offers semantics during modeling and exploitation time • several semantic projects have been started and they do provide some higher level of semantic approach with SWEET using WebML, WSMO, BPMN, etc. 1. Introduction

4. 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. 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. 2. Modular approach

5. In our scenario, basic building block, that isis the core of the system for storage and retrieval of data and metadata, 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.1. Repository definition

6. Repository schema 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: • Website / Application tree (navigational data) derived from persisted data; • Document management (for binary data); • Security constraints (for user / groups data); • Business process (for storing BP definitions); • Configuration data (used by all repositories and server for runtime configuration);

7. Repository schema

8. WHY JCR? 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.

9. 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). • 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. Website / Application repository

10. 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.1. Generic RIA Web GUI components

11. 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.2.2. Application navigation

12. Semantic Document Management is characterized by: • managing the document lifecycle, from creation to publication and to archive; • documents indexing;semantic full-text search. • 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; 2.3. Document management

13. Provides infrastructure for sucessful security policies adoptation: • based on inflexible rules, but on an understanding of the expected series of interactions between parties within and outside the protected domain • uniform access control restricts access to specific data nodes in the application/website repository • aggregated data with fine grained security rules that can span up to each individual's retrieval and manipulation. 2.4. Security constraints repository

14. One of the most complex parts of the model embeds core application logic and business repository: • 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; 2.5. Business process / Workflow repository

15. Standard part of any application wheather it is RIA, Web application or fat client: • server configuration; • functional modules configuration which includes templating mechanism, component description and structure; • application framework metadata. 2.6. Configuration repository

16. Thank you for your attention Discussion All questions and comments on: zoran.balkic@etfos.hr