Nick Vidal

The Drupal WebOS provides several services to the Ext Webtop. The structure of these services are well described and they can either be static or dynamic in nature. The difference between static and dynamic services is that the dynamic services can be seem more as a stream of information and they can be used to provide users with (almost) real-time updates. If there is a great number of dynamic services being requested at a given time, however, the performance of the application can suffer substantially. To solve this issue, we present the sessionLink.

The sessionLink is a service that follows the publish/subscribe pattern and provides users and applications with updates for subscribed services. For example, when a chat application is loaded in the Ext Webtop, the Webtop subscribes to the user.im service to be kept aware of any updates.

The following is a simplified description of the user.im service:

{"method": "user.im",
"args": [
{"name": "uid", type: "int", "desc": "User ID", "required": "1"},
{"name": "msg", type: "string", "desc": "Message", "required": "1"}
],
“type”: “data”,
"sessionlink": "payload",
"time": "2000",
"sid": "14"
}


The “sessionlink” can either be set to none, payload or timestamp. Services by default are static and there is no need to define sessionlink. A dynamic service on the other hand must have “sessionlink” set to payload or timestamp. When payload is set, the session.link service will return the payload for the subscribed method. Otherwise, if timestamp is set, it will only return a (unix) timestamp, thus requiring the Webtop to make an additional call to receive the update. For applications like chat, where speed is essential and the content is small, it’s recommended to set sessionlink to payload.

The time can also be set. This will help determine how often the Webtop will have to poll the session.link service. The lowest time of the current set of subscribed services is used. For example, if the Webtop is calling session.link every 30 seconds and the user loads the chat application, then the Webtop will start polling session.link every 2 seconds (2000 milliseconds).

The subscriptions are managed automatically by the Webtop by calling the session.subscribe service:

method=session.subscribe
sid=14


The user.im service has a sid (Service ID) of 14. The session.subscribe service actually handles sid as a string, thus enabling the Webtop to subscribe to several services at the same time (just use a comma to separate the sids).

To unsubscribe, there is the session.unsubscribe service that works the same way. If the user closes the chat application and he or she is not talking to anyone else, the Webtop can unsubscribe from the user.im service:

method=session.unsubscribe
sid=14


In conclusion, the sessionLink is a key component that helps the Webtop to be kept aware of any updates in an easy and straight-forward way. This component will help developers create applications that provide real-time collaboration and offer users a more seamless experience.

The Web is evolving rapidly and Web applications are starting to reach the same level of functionality of desktop applications. Perhaps we can even risk to say that Web applications will soon surpass desktop applications in functionality given the interconnected and ubiquitous nature of the Web. Despite the differences among Web browsers, there has been an increasing convergence of standards and practices, mostly promoted by the W3C (World Wide Web Consortium) and the Ecma International. The emergence of powerful JavaScript frameworks has also tremendously helped developers to abstract beyond these differences and create rich internet applications easier and faster. Soon, users will be able to access Web applications much like they access desktop applications by using a Webtop, i.e. a desktop that runs on top of the Web browser.

In the server-side, we have seen a consolidation of the LAMP stack and its derivatives, which consists of an Operating System, a Web Server, a Scripting Language and a Database. On top of this stack we have seen the emergence of Web frameworks for managing content, users, applications and services. Notice that traditionally the management of these has been the responsibility of Operating Systems. However, this responsibility is being delegated up the stack so that it can benefit from the key aspects of the Web. This trend will ultimately lead to a WebOS, i.e. an Operating System that runs on top of the Web server.

The figure below illustrates this evolving architecture. The main goal of this publication is to explain how to develop Web services and applications following this architectural design. More specifically, the objective of this publication is to to explain how to develop Web services and applications using the ExtJS framework as a Webtop and the Drupal framework as a WebOS.

Web Architecture - towards the Webtop and WebOS.

There has been some interesting developments combining Drupal and Flex. Drupal is an excellent CMS (Content Management System), while Flex is a great technology for building RIA (Rich Internet Applications). Using Drupal as a backend and Flex as a frontend, it’s possible to achieve outstanding results.

An alternative to Flex is AJAX. JavaScript libraries are becoming mature, and since JavaScript interpretation is native to browsers, the use of AJAX is an attractive solution. One fine example of what can be accomplished with AJAX is the Ext JS library. With Ext, it’s possible to emulate quite nicely a Desktop on the Web.

To create a Web Desktop using Drupal as a backend and Ext as a frontend, we need to use the Services module. The Services module allows a Drupal site to provide Web services via multiple interfaces while using the same callback code. The AMFPHP module may be used by Flex applications, while the JSON server module may be used by Ext applications.