Warning: Declaration of action_plugin_authad::register(Doku_Event_Handler &$controller) should be compatible with DokuWiki_Action_Plugin::register(Doku_Event_Handler $controller) in /home/clients/0de9ff9beee4541cf1f61437ce7bce2b/web/hec/lib/plugins/authad/action.php on line 89

Warning: Declaration of action_plugin_editsections::register(&$controller) should be compatible with DokuWiki_Action_Plugin::register(Doku_Event_Handler $controller) in /home/clients/0de9ff9beee4541cf1f61437ce7bce2b/web/hec/lib/plugins/editsections/action.php on line 72

Warning: Declaration of action_plugin_importoldchangelog::register(&$controller) should be compatible with DokuWiki_Action_Plugin::register(Doku_Event_Handler $controller) in /home/clients/0de9ff9beee4541cf1f61437ce7bce2b/web/hec/lib/plugins/importoldchangelog/action.php on line 157

Warning: Declaration of action_plugin_tag::register(&$contr) should be compatible with DokuWiki_Action_Plugin::register(Doku_Event_Handler $controller) in /home/clients/0de9ff9beee4541cf1f61437ce7bce2b/web/hec/lib/plugins/tag/action.php on line 79
Chapter 4 The Technology Behind [HEC 4 ALL]

Chapter 3 Design of The Prototype

Chapter 4 The Technology Behind

In this chapter we cover the technical details of the prototypes and explain the technical choices made. The presentation of the technical and architectural aspects of the prototypes is followed by the limitation discovered during development and also an overview of different alternatives which could have been chosen.

A quick reminder of the challenges presented by this software:

  • A dynamic user interface supporting drag and drop interaction between most of its elements.
  • A complex data structure in which each element depends on the others.
  • The possibility to change attributes of an element or event to add new types of elements as the tool and the underlying model it has to support evolves.
  • Provide the possibility of a future integration of additional modules or tools which could provide statistical, financial or other data to different elements.
  • Provide extension to further analyze a business model by comparing it to other models, applying patterns or evaluate it with a survey.

Figure 4.1: Overview of both prototype’s architecture

4.1 Prototype 1

4.1.1 Architecture

The data structure has been created in MySQL. Then the data itself was quickly input through a web page built with CakePHP and its powerful scaffolding feature. The remainder of the code uses the predefined database access methods and conventions provided by the framework to generate HTML/CSS pages as well as XML call endpoints for the JavaScript queries. Most of the dynamic functionality is done via JavaScript with libraries like [http://extjs.com/|ext js]] and script.aculo.us who call the aforementioned endpoints.

The data structure can be seen in figure 4.2. Product is the first name given to the layer feature before it was identified as such. Also in this version of the prototype there is a table for the building block, this allows for renaming of the blocks and provides the possibility to add new blocks for further evolutions of the model. This possibility has been replaced in the second prototype by the fact that a block is defined as an aggregation of sub classes of elements.

Figure 4.2: Prototype 1 database schema

4.1.2 Comments

A modern MVC framework can largely reduce the number of lines of code that have to be written, mainly conventional code which can be replaced by naming and usage conventions.

The fact that the HTML structure has to be altered through DOM each time new information is received is not near to the business object model. It is therefore a better solution to create these graphical elements through helper widgets in JavaScript like some JavaScript libraries provide.

However, the use of JavaScript especially the combination of different effects quickly renders the code un-maintainable. Patterns should therefore be applied to avoid problems especially with dynamic language like JavaScript. Otherwise, existing code will become very difficult to be debugged or altered.

In this prototype, there is no separation of concerns between client and server, but its rapid development has allowed to generate new ideas for a future version and also proved the feasibility of such a tool.

4.2 Prototype 2

4.2.1 Intention

The first prototype has a data structure created for a relational database, for this second prototype the goal was to try a more object oriented solution. Also, since the prototype was to be recreated from the ground up, an implementation of a separation of concern between client and server was tried. For the client side the choice was to find an alternative for not having to manage the low level technical details that are required when doing HTML/CSS/JavaScript coding.

4.2.2 Architecture

In this version, the client is a flash application loading and saving data from a server. The server is a Java application server that persist the data to a database. The client and the server share a domain class object model of the BMO, which is close to the real model.

Server

As with the previous prototype, the choice was to use a framework which uses convention over code to facilitate integration of Java Enterprise products like Spring and Hibernate without losing too much time in initial configuration. In this case the choice was Grails , like other framework of its kind (RubyOnRails, Django), it is build around the MVC pattern and uses strongly the specificities of the dynamic language which it is built on. Grails is programmed in Groovy, which provides the advantage that it does execute in the Java Virtual Machine. This way the proven enterprise products and their APIs which are available to the Java Language can be relayed upon.

Grails allows defining domain classes and their relationships between each other, its Object Relational Mapping engine (GORM) will then take care of doing the proper mapping to Hibernate. This allows to persist and retrieve the objects without having to write custom SQL queries, and reduces time and coding when working with persistent data. Appendix C.185Prototype 2 server domain classes and attributesfigure.C.1 contains a figure of the domain classes with their attributes and relationships.

There is also a plugin that allows transformation of methods into RPC services for Flex, this by automatically configuring object conversion through BlazeDS’s Java API. This part takes care of transforming the Java object into an ActionScript object and vis versa.

Client

Having already prior knowledge of Flex, the idea was to be able to work directly with the objects received from the server. Flex also has a large number of visual components that facilitated the creation of interfaces. Therefore, it seemed that it would be a good alternative to the combination of HTML/CSS/JavaScript. In addition with the support system provided on the server side, the configuration of the remoting access points is largely simplified.

Flex also has a system of databinding and proxy on collections which facilitates the real-time modification and filtering of data without having to be concerned with the display objects. On the other hand to avoid passing references to the data between the different visual elements, it is advisable to use some patterns (singleton for the data model holder, events, commands and controllers). Adobe offers an additional library called Cairngorm to address this problem. For a more detailed structure of the client see appendix ??.

4.3 Features Details and Choices

In this next section are covered some of the implementations and the reason behind their choices.

4.3.1 User System Implementation Possibilities

Table 4.132Comparison of user management systemstable.4.1 displays four alternatives systems which can be used to implement user management. Scenarios range from simple to complex in their feature spread and implementation difficulty.

Table 4.1: Comparison of user management systems
Simple Profile Sharing Collaboration
Stateless Stateful
User logs in to access his BMs User logs in to access his BMs User logs in to access his BMs User logs in to access his BMs
No sharing (only uncontrolled through using same account twice) User can share his BM with other users User can share his BM with other users User can share his BM with other users
Two users editing the same document will result in unknown behavior Two users editing the same document is impossible due to a lock system Edits on a BM will be sent to all other views connecting to the same BM
Like: Desktop application profile, computer login Like: - Like: wiki, file access Like: google docs, chat
Impact: a BM belongs to a user Impact: a BM has many users Impact: a BM has many users, a user can get a lock on a BM for editing Impact: a BM has many users, publish/subscribe messaging model, a message for each action
Use case: used like an application, works in group if looking at one screen Use case: Use as central place for BM, sharing mainly usable for viewing A BM should have only one User with write permissions to minimize errors Use case: same as stateless, but multiple users can have write permissions due to lock security Use case: Online collaboration, without needing additional desktop sharing software except voice/chat comm. Message bus could be used to connect other editing views
Table 4.2: Options available for sharing and collaboration systems
Options
ACL user and BM relation can be augmented with permissions (view, edit),groups. Components under the BM can be tracked separately (track annotations to a specific user, last edit on object by…)

Since the user system was only added in the last iteration of the project only the simple stateless sharing options has been chosen. The choice was more about the ability to clean up the listing of the front page, which was becoming quite long, than to offer new possibilities. But because the model had already an edit and a view mode adding different permission was an easy task and has been implemented. Comment tracking was not implemented since it would have required too much code changes. Instead, a user can simply add his name to the comment itself if he wants to identify himself.

4.3.2 Snapshot and Merging

Snapshot is implemented using a somewhat controversial borderline effect produced by the conversion of java objects into ActionScript. If when mapping the java object to their ActionScript version the version and id attributes are omitted, and then the objects are sent back to the server to be saved, the whole graph gets saved as a new object by the ORM system. This enables to create recursive deep copies of the objects without having to code anything. The disadvantage being that the snapshot cannot be produced only on the server side, but has to roundtrip through the client.

Merging also occurs on the client side for the same reasons, except that the client asks for multiple models and joins them into one before sending it back to the server for saving.

4.3.3 Example Roundtrip of a Query

For this example, let’s take the action of creating a link between two elements. The action is decomposed into different events: first there is the drag operation, then the hover and the drop who will initiate an interaction with the server. Once the server responds, this will in turn initiate some actions on the client configuring the right data to be able to display the newly created link. For a more detailed description see figure and explanation in Appendix C Technical Supplements.

4.4 Problems Encountered

4.4.1 Prototype 1

JavaScript libraries: there is no single library which can do everything, each has its own methods, but between them there are many redundancies.

The successive nesting of JavaScript effects makes the maintainability of the code very difficult.

The common problem of schema evolution when using relational database cannot be avoided even when using framework that generates most of the SQL code. When transforming schema with existing data in it, the cumbersome operations of manually extracting, converting and importing has still to be done.

4.4.2 Prototype 2

The choice to move to a more object oriented data structure has made the structure closer to the real representation of the model, but not necessarily simplified the project, mainly due to all the looping dependencies between elements. This adds complexity saving the data and also exchanging it between the client and the server. The implementation used requires to send a complete object graph with all its dependencies to the client. In addition, the client has to have corresponding domain classes to the server’s, thereby creating a strong dependency between the client implementation and the server’s. In the end, the possibilities to navigate from one object to another through their object relationships comes at a high cost, perhaps an other solution using REST services and xml data structure (source) would have been better.

On the server side some beginner mistakes have created some problems. For example choosing the enum data type to represent some of the element’s attributes is very limiting and not flexible for future changes. A better solution would have been to create a modifiable list or just store the information in a text field and let the client side impose some restrictions in the user interface. During deployment of the server to a real database, some of the chosen attribute names where too generic and therefore were in conflict with reserved words of the database language. It is advised to not use generic words like for example type or date for future naming of attributes.

The client implementation posed not so much problems except its complexity of numerous events firing at the same time or in a chained way. But the debugging possibilities offered by flex are very good and helped in identifying bugs rapidly. The greatest workaround that had to be done is a custom implementation of the double click since for some odd reason on touch devices the existing implementation is too restrictive to detect a double click on an approximate location.

4.5 Tradeoffs

4.5.1 Web vs Desktop

Web applications and desktop applications both have their advantages and disadvantages. Most of the time, the advantages of one are the disadvantages of the other. A short overview of some respective advantages is given in table 4.3. It is also noteworthy that the separation between web and desktop application is blurring. There exists on the one hand technologies to bring web applications to the desktop, and on the other hand features of web applications are directly integrated into desktop applications. For example, there is respectively the possibility to use Google docs in an offline mode, or to have Microsoft Office Live directly integrated into the Microsoft Office desktop applications.

Table 4.3: Advantages of the Web and the Desktop over each other
Web [advantages] Desktop (standalone) [advantages]
Multiplatform Offline work
Without installation Response time (no delay between client-server)
Always up to date Possibility to use older versions
Social sharing Interaction with the desktop (D&D)
Automated backup (server-side) Privacy

4.5.2 Client-Server

In a client-server architecture there is always the question on which side to put the business logic. In order to support a large number of clients, it is advisable to keep the states and most part of the logic on the client side. The server’s role is limited to persisting and synchronizing the client’s data. However, unlike when the business logic is centralized on the server, all different clients have to be updated individually whenever changes occur.

One advantage of putting the logic on the client side is to leave the opportunity open to allow, in a future version, to work in an offline mode.

4.6 Framework

As experienced with the two prototypes, the new kind of web framework can help accelerate the creation of web applications by replacing many lines of code through convention. Moreover, these conventions require a fairly clean architecture. This makes the code reusable and easier to evolve from. Nevertheless, the conventions have still to be learnt when being used for the first time, a hurdle which has to be crossed before being productive.

Certain limitations linked to the conventions have to be taken into account, but if the framework is mature enough, there are few exceptions which do not already have a documented workaround. A good framework should also allow direct access to its underlying components to be able to circumvent these limitations.

4.7 Data Persistence

In my opinion it seems that the key part to allow an application to evolve freely is to find an optimal compromise concerning data persistence.

4.7.1 Traditional Methods

Object serialization: allows simple saving of a graph of objects, but does not allow easy retrieval of only parts of it, plus it prevents the evolution of objects.

Relational database: provides a good way to store data, but is heavily dependent on its schema.

Object Relational Mapping: allows storing objects in a relational database in order to level the limitations of serialization, but the limitations of the relational database remains. In addition, there is the added complexity of mapping the objects to tables.

Schema evolution: In an attempt to solve the limitation of schema evolution, there exist solutions of change tracking and migration of schema like liquidebase. Efficiency of such solutions has yet to be proven.

4.7.2 Non-conventional methods

Google AppEngine: Is the new python based Cloud Computing solution offered by Google. In my opinion the services is, at the moment, not evolved enough to handle the client side application’s needs. Nevertheless, the datastore API has some interesting features for a server side. The data is represented by classes, but unlike with ORM, storage is not done in relational databases. In addition to standard class attributes the systems also allows for dynamic defined attributes, thereby the schema could evolve. From the start the system is design to be scalable, which in itself is a positive point, in this first version it does however not allow for joins when executing a query. Therefore there is no way to take advantage of the knowledge acquired on relational databases.

CouchDB: Is a prototype of a new type of data store specially design for web applications. It is based on the JSON data model which is used by more and more websites for their data transfers.

Recently the project has gotten support from the Apache Software Foundation, the project defines itself as: distributed, fault-tolerant and schema-free document-oriented database accessible via a RESTful HTTP/JSON API. What I find of particular interest is the fact that it is schema free and that it could be access directly from the client without having to through a backend server.

F2 Python DBMS: prototype of a schema less database, the data defines the schema. If there were a JDBC driver to connect it with hibernate it could be a solution that could even work with a framework like Grails

Jena & SPARQL: Another idea is to use a semantic solution and store the data directly in the owl file which defines the structure. A Java server using the Jena API could store the data and queries could be done in SPARQL on the triplet store. This solution would need some testing, but I am not convinced of its scalability, as well as the technical difficulties it involves.

Generic database: A relational database could also be used in a more abstract way, creating only tables for meta objects with which the needed object can be constructed. For accessing data as with a normal schema, there could be views which assemble the required information, but the problem is for storing new data, on the server side there will have to be quite a lot of code to decompose each information into its basic parts which then can be stored in this generic system which would not need to be changed. The evolution problems is in this solution transferred from the database schema to the application implementation which has to manage the decomposition of the information before saving it, taking away development time of business code, but giving the opportunity to quickly change the business items themselves.

4.8 Other technologies

4.8.1 Clients

Silverlight: Microsoft has developed their own alternative to Adobe’s Flash/Flex, but judging by some small tests their product is not mature enough to allow for a rapid development. In addition, other than giving access to the .Net framework it has for now, no special functionalities over its alternatives.

Google Web Toolkit: GWT is a very promising technology which allows the creation of HTML/JavaScript based client applications written entirely in Java. Google’s compiler takes care of generating the necessary changes. This solution has the major advantage to ease debugging, and imposes stronger controls at compilation time instead of runtime, mainly due to the usage of Java which is a static typed language unlike JavaScript. At the moment, the main effort is focused on the compiler technology. There are still high level features or a nice framework missing, which would allow for developer friendly usage without having to create a lot of classes to build simple operations.

4.8.2 Offline

Google Gears: Gears is a plug-in for the web browser that extends the possibility of JavaScript to provide offline solution for dynamic web pages. This way entire web application can be made available offline. Choosing this solution implies that the business logic will have to be on the client side.

Adobe Air: Is a solution that enables to program for the desktop using web technologies like HTML/JavaScript and Flex/Flash. Like with gears this allows to create offline web applications, but unfortunately there is no synchronization mechanism to go back online. Another difference is that being in a dedicated standalone container the application, contrary to web applications hosted in a browser, can interact with files from the desktop and the drag and drop operations of the operating system.

As in the last Firefox version, both Google Gears and Adobe Air rest on a local SQLite database to guarantee persistence.

4.9 Comments

The separation of concern between client and server and especially the usage of framework and their patterns requires an extra investment in time, but should prove to be more flexible for future changes and improvements. The modular structure of the frameworks used for the second prototype will easily allow adding custom sub modules, different clients and more attributes. But changes in the domain class objects will always require changes in the client and server side, a more xml/services API oriented solution would have limited this problem. Also the deletion or modification of existing data structure is still a hard problem. Nonetheless, continuing to pay attention to problems emerging from future evolutions of the prototype can still bring insightful knowledge for further research.

From the overview emerges the observation that web application or desktop application, for the most part relay on a relational database to guarantee the persistence of their data. There is also a trend of standardization of methodologies across the languages, temporary trend or ongoing optimization has still to be seen, but one certain thing is the convergence between web and desktop.

The question, if in this world of complexity, change and reuse of services, the relational database still is a good solution to guarantee data structure and persistence, remains.

Chapter 5 Validating The Prototype

tm/chapter4.txt · Dernière modification: d-m-Y H:i par boris
chimeric.de = chi`s home Creative Commons License Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0 Fristcher.ch