1 Introduction

Today, the number of existing Web sites is huge. What is the role played by these Web sites? What do these Web sites provide to end users? Although a large portion of Web sites are document-oriented, that is, they are actually electronic documents delivering information to target users, some are not. Some Web sites, such as google bookmark, evernote, or online calendar provides, are actually Web-based tools helping users complete their tasks. These Web sites are application-oriented rather than document-oriented. Additionally, if carefully designed, functionalities provided by application-oriented Web sites can be integrated to complete more complex jobs. Compared with the power provided by application-oriented Web sites, the infrastructure support today is in fact very poor. To utilize the information delivered by document-oriented Web sites, there are various information extraction mechanisms and algorithms. To construct document-oriented Web sites, there is tons of HTML authoring tools. However, to the best of the author’s knowledge, there are no globally-adoptable tools and platforms for building application-oriented Web sites, not to mention proven mechanisms and paradigms. The lack of infrastructure support results in poor compatibility and low reusability between application-oriented Web sites.

What is the best approach to construct application-oriented Web sites? Perhaps some paradigms and generic guidelines will be helpful. Considering how a normal desktop application is built, one will find that the object-oriented paradigm is the most popular. The core concepts of the object-oriented paradigm are modularization and reusability. Therefore, the goal of this research is to develop a sound framework for designing reusable application-oriented Web components. The goal is not easy to achieve since both syntax and platform supports will be needed.

The remaining of the paper is as the following: first, the result of the survey of existing works will be listed. Then, the core concept will be explained and a prototype implementation will be introduced. After that, some discussions about the current implementation will be presented, and finally, the conclusions and future works.

2 Related Works

2.1 Web Application Development

According to Jazayeri [1], in just one decade, the Web has evolved from being a repository of pages used primarily for accessing static, mostly scientific, information to a powerful platform for application development and deployment. The evolving of usage scenarios of Web applications results in the evolving of design principles for them. As shown in his survey, there was a continuing “desktop-to-Web” trend, which refers to the observation that there was a trend to move desktop applications to Web. Since the distinctions between desktop-based and Web-based applications have been getting blurred, the trend to apply existing software engineering approaches, which were mainly developed for desktop-based applications, to the development of Web-based applications appears reasonable and needed.

The research of Wang and Zahadat [2] emphasized that most Web applications and Web sites have emerged and transpired over recent years and the newly emerged Web applications are fundamentally different from traditional Web applications. The authors also mentioned that a new type of software development life cycle had emerged and promised to affect Web design and development. As stated in the paper, the Web had changed from a medium to a platform for delivering software. Different from traditional Web site designers, what Web developers do today is developing Web applications instead of authoring simple Web contents.

In [3], the concept of “Web native interactive applications” was proposed. The paper stated that the initial design of Web technologies which was based on “Web of documents” did not accommodate the requirements today. The paper also proposed AgentWeb, which was an environment for building Web-based interactive computer games. The environment was built following the Model-View-Controller (MVC) architecture. The authors emphasized that current open Web standards were sufficient to support sophisticated interactive applications.

2.2 Object-Oriented Web

“Object-Oriented Web” is not a brand-new terminology. In [4], object-oriented Web is viewed as the next step of the semantic Web and is depicted with the following example:

Look at the blogs for instance, they usually have a “comment” feature and it would be interesting if this feature was available wherever the posts appear, whether it is on the original blog, a RSS aggregator like Google Reader, or a social network. Just consider the blog articles as objects capable of ubiquity composed of data (properties) as well as actions (methods) and you’ll start to envision what I mean by the Object Oriented Web.

The term is also mentioned in [5], and the article also viewed object-oriented Web as the extension of the semantic Web. None of these articles gave a formal definition of the object-oriented Web. Despite of the missing of a formal definition, however, the blueprint of the object-oriented Web had already been sketched by several earlier research works. For example, Gaedke and Rehse developed a component-based Web engineering methodology [6] based on the object-oriented concept. In their research, a WebComposition repository system was proposed for maintaining Web components and a markup language, WCML, was used as a convenient way to define the representation of components. WCML was introduced in [7] for defining reusable Web components. The definition of a “component” in the research was almost identical with the definition of an “object” today. In [8], the author tried to improve the “Web object model” by providing a richer base representation than HTML, an API to the state of components, and an enhanced ability to define relationships between state and behaviour.

2.3 Cloud Computing

Cloud computing is internet-based computing, whereby shared servers provide resources, software, and data to computers and other devices on demand, as with the electricity grid. Although by most standards, cloud computing is still in the early stages of adoption by midsize and larger organizations, but the pace is increasing as users look for additional cost savings and technology perks, such as scalability [9]. Cloud computing technologies have shifted people’s concentration on computer technology from single machine to the internet centering on Web by using storage and services from Web [10]. Cloud computing can be viewed as the evolution of distributed computing, however, due to the mature of virtualization technologies, cloud computing appears more adaptable [11].

3 Application-Oriented Web Sites

An application-oriented Web site is a Web site which acts like an application. Rather than simply reading information presented on them, people execute functionalities provided by application-oriented Web sites to complete their tasks. Typical application-oriented Web sites are online-dictionaries, online calendars, and online office applications, etc. These Web sites are valuable, however, since there is almost no infrastructure and tool support for building such type of Web sites, creating application-oriented Web sites today is not easy. A lot of technologies such as AJAX, DHTML, and JSON etc. are involved. Furthermore, the lack of infrastructure support makes it even more difficult to integrate application-oriented Web sites. Imagine that how can the functionalities provided by two application-oriented Web sites be integrated. Nowadays, there is in fact no promising approach to achieve that unless all involved Web sites provide standard-compliant application interfaces such as SOAP or Restful. Otherwise, most solutions depend on page scraping, which suffers from unstability. In this paper, the researcher proposes preliminary results on some guidelines and infrastructure supports of application-oriented Web sites construction.

There are several aspects to consider if developers are building interoperable application interfaces for their Web sites:

  1. 1.

    Object definition versus object instances.

  2. 2.

    How to define application interfaces?

  3. 3.

    Which functionalities are included in the application interface?

  4. 4.

    How to interpret results returned from function invocations?

  5. 5.

    How to manage instances of applications?

In this and later sections, we propose our solutions to these questions followed by some discussions.

3.1 Object Definition versus Object Instances

In this research, we consider Web pages and javascript functions associated with them. A Web page contains information. Thinking of a Web page as an object in the object-oriented paradigm, for application-oriented Web sites, the information can be regarded to as member data of an object. On the other hand, javascript functions form the functional layer and can be regarded to as member functions. During execution, member functions can definitely have access to member data and client applications access member data through member functions, so this definition fits the object-oriented paradigm well. One thing to be noted is that we have to distinguish between object definitions and object instances. Conceptually, the set of static files, i.e., Web pages, external javascript files, embedded javascript functions, etc., forms the definition of an object. At runtime, what client applications interact with are object instances. These instances are created based on the specified Web resources and there can be more than one instance for one definition. The current implementation handles constructions of object instances and manages mappings between instances and definitions but does not handle instance sharing between client applications.

3.2 How to Define Application Interfaces?

Interoperability can only be achieved if application interfaces that can be understood by involved applications do exist. Today, to access functionalities provided by a Web site, no matter it is application-oriented or not, the most commonly used tool will be Web browsers. However, Web browsers are interfaces between human beings and Web sites and can hardly be regarded to as application interfaces. Only few Web sites provide application interfaces. Examples are google docs and delicious bookmarking services. These Web sites typically provide application interfaces compliant with protocols such as SOAP or Restful. To “invoke” functionalities exposed by these Web sites is easy since one simply builds applications that can exchange messages with these Web sites (or more specifically, the servers hosting them) according to the protocols. The problem is, for most Web sites that do not follow these protocols, one can simply rely on ad-hoc solutions that thus the resulting applications will be unstable and rarely usable.

To address the issue, the researcher’s previous research result, the virtual Web browsing environment (VWBE [12]), is adopted and extended. Originally, VWBE simply simulates the behavior of a real Web browser. Accepting a URL as the input, VWBE loads the targeted Web resource and related resources into it, constructs a document object model (DOM) reflecting the Web page, and wraps javascript functions declared in the Web resource as Web services adopting the SOAP protocol. After that, client applications can access exposed javascript functions through Web service calls. This architecture suffers from several problems: first, many javascript functions declared on Web pages are used for presentation only and it will not be reasonable to expose these javascript functions. Second, in some cases, exposing only javascript functions declared on Web pages is not enough. To meet requirements of client applications, some additional functions may be needed. As a result, enhancing the original VWBE is needed.

In this research, we extend the original VWBE by allowing the injection of external javascript functions at runtime. This version of VWBE accepts a URL (the main Web page) and a set of javascript files as input parameters. At runtime, VWBE automatically merge these files. During execution, these augmented javascript files have a reference to the DOM of the main Web page and thus can access the full functionalities provided by the original Web sites. These javascript files form the application interface and will be exposed through VWBE’s Web service interface.

3.3 Which Functionalities Are Included in the Application Interface?

As stated above, many javascript functions declared on Web pages are used for presentation only. These functions should not be included in the application interface. As a result, this version of VWBE uses annotations to specify needed javascript functions. Annotations are small pieces of information that can be attached to javascript functions and are used as meta-information of the attached function. To prevent interfere with execution of normal javascript functions, VWBE annotations are written in javascript comments. For example,

/*

* @export()

*/

function multiply(a, b){

return a*b;

}

VWBE looks for the “@export()” annotation to determine javascript functions to be exported. Note that/* … */is ordinary comment syntax of javascript and thus will not cause interference.

3.4 How to Interpret Results Returned from Function Invocations?

Executing a JavaScript function has two different types of returns. One of them is normal function return. The other is reflecting the result in the DOM. The former is simple to deal with. VWBE simply transforms returned javascript objects into corresponding SOAP objects. However, due to the fact that a Web page itself can be viewed as an information source, it is possible that the execution of a javascript function results in modification in the Web page hosting it. In such scenario, the Web page itself should be included in the returning results. For simplicity, VWBE allows a javscript function to return a DOM node. In case data on the hosting Web page should be included in the returned result, one simply returns the DOM node containing the result. During the transmission across the Internet, the DOM node is serialized into string representation and will be reconstructed in the invoker’s memory space. The returned DOM result can be messy since there are data nodes mixed with presentation nodes. A possible solution is to apply transformation technologies such as XSLT or H2X to the returned DOM node but this is beyond the scope of this paper.

3.5 How to Manage Instances of Applications?

Managing instances and states of applications is a further issue. Considering Web pages and associated javascript functions as definitions of applications, what VWBE manages are actually instances of these applications. As stated in previous sub sections, execution of javascript functions can results in modifications in DOM. Hence, we have to distinguish between different application instances and manage their states separately. By assigning ids to client sessions, this can be easily achieved. However, things can be even more complicated if the execution of javascript functions results in page transition. Navigating to a new URL causes the loading of new Web pages, associated resources, javascript functions, and hence the instantiating of a new application instance. Page transitions happen in several different forms:

  1. 1.

    through anchor links

  2. 2.

    through javascript manipulation (e.g. window.location.href)

  3. 3.

    through form submission.

VWBE thus intercepts these events, instantiates new application instances, and puts application instances into the execution context of client applications.

Another issue will be how to switch between application instances involved in a client session. In this version of VWBE, the concept of client context is introduced. Before accessing a Web application, client program has to acquire a client context in advance. From the client context object, references to involved Web application instances can be accessed.

4 Discussions

4.1 Annotations on JavaScript Functions

The annotation functionality deserves more discussions. For now, it is only used for specifying javascript functions to be exported. However, the functionality is generic and thus can be used in other scenarios. For instance, parameters of javascript functions are weakly-typed but SOAP-based Web services are strongly-typed and annotations can be used to overcome the incompatibility. Furthermore, annotations can be used for associating semantic information with application interfaces. Such information will be useful if automatic discovery of suitable functions is desired.

4.2 Complex Web Application Modularization

Current implementation of VWBE only allows one-to-one mappings between Web pages and Web applications. Such granularity can be overly rough. There are cases in which a Web page contains more than one Web applications. For example, a Web page can contain both a calendar component and a notebook component. It appears reasonable to create two Web applications based on such Web page. On the other hand, some complex Web applications require more than one Web page or even more than one Web site. Due to the diversity of design patterns for Web applications, current implementation of VWBE can hardly support these scenarios directly. However, if meta-information is available, supporting complex Web applications is still possible.

5 Conclusions and Future Works

In this paper, a framework and a tool set supporting the development of application-oriented Web sites are proposed. The solution shown in this paper is based on an enhanced version of VWBE, the virtual Web browsing environment. The environment is capable of wrapping existing Web pages into Web applications. With some extensions, VWBE becomes a suitable framework for Web application development.

The capability of creating Web applications based on existing Web sites is convenient, but there are certainly limitations. Perhaps an important issue that has to be solved is the lacking of commonly-adoptable module system for development of application-oriented Web sites. The very popular template-based mechanisms are good for modularization of document-oriented Web sites but not for application-oriented Web sites. In the future, the goal is to develop a more complete module system that can be used to search modules, manage modules, and perhaps orchestrate modules. With the system, better design patterns for developing application-oriented Web sites can be developed.