Position Paper for Workshop on Declarative Models of Distributed Web Applications (http://www.w3.org/2007/02/dmdwa-ws/) Lasse Pajunen, Nokia Research Center, Nokia Corporation (lasse.pajunen@nokia.com) 1. Introduction Within Nokia Research Center, we have studied web technologies from various perspectives. Based on our studies on the client side, the key challange is how to render web pages and make them user friendly with various clients with different capabilities, especially considering some limitations on available input controls, screen space, memory, computing power, and network bandwidth. On the server side, the key challenge is how to design sites and web applications that will make the best out of the client and its delivery context. In the end, it is the end user experience that matters most. The designers and systems provide the end user experience using two things: explicit and implicit features. By explicit features, we mean capabilities inside the service description languages like layout options in CSS and drawing capabilities of SVG. By implicit features, we mean capabilities on the system that are implied by the actual system implementation. For example, speed of HTML rendering, support for enhancements in CSS layout scaling, and security features of application sandbox are provided by the implementation, not by explicit request by the application designer. However, the implicit features are enabled by proper language design. In the end, we want to make web site and application design as easy as possible, where the least amount of information is needed by the service designer and the system does as much as possible by default. The important and difficult task is to design description languages in such a way that they allow enough capabilities for designer to describe the service in proper way and at the same time allow context sensitive optimizations to be done by the client. Simplicity and direct execution are important goals here. In order to design good services, the service designer needs to understand the underlying system and focus on the places that produce the most value. Here, the system and its technologies must be as simple as possible and there must be as few separate technologies as possible. In addition, all indirections make things more difficult. For example, having a separate language for device independent descriptions, having separate language for content filtering and device dependent language transformation, and finally a separate language for content presentation is not a good direction. Rather, we must reduce the complexity by standardization and not unnecessarily increase it. In order to tackle the aforementioned issues, we will now analyze client side issues and ways how to model server side issues in a bit more detail. Then finally, we will give some considerations on how to proceed. 2. Client Classification for User Interface Generation To understand our options, we will divide typical clients into three classes. Each class will have different properties and therefore allow different ways to go forward. The first class is named as small (and typically the most restricted) clients. One classification criterion is that these clients are lacking support for street HTML, CSS, and other similar standards. In addition, they typically have more restrictions on memory, computing power, and network bandwidth. Often, these limitations on this category prevent complex services in practise. In addition, because these clients generally are not compliant to Full Web standards, designers are required to make specialized versions for each different client. However, due to technology evolution, the main problems of this class will disappear over time as these clients upgrade to the next classes. The second class is named as normal clients. They are characterized as having Full Web standards support. They may have limitations in memory, computing power, and bandwidth. Screen sizes and use contexts vary. Client-side optimization should be enabled based on execution context. This is propably the most important class and most of the clients will belong to this one. The key challange in this class is to enable "adaptivity options" for client side optimization. For example, sometimes clients in this class are used with fast network connections like WiFi and sometimes with slower ones like GPRS. Based on the use context, the client should be able to retrieve appropriate content for the user. In a same way, the screen size may vary when user resizes the window or switches to different size screen while browsing. Therefore, dynamic scalability of content is very important property here. The third class is named as large (and typically least restricted) clients. They often have Full Web standards support plus additional functionality and extensions. These clients often do not have restricted memory, computing power, or bandwidth. This means that large clients can support most complex user interfaces, as sometimes normal clients may lack capability to support them properly. The screen sizes and use contexts also vary with large clients. Therefore, this class is very similar in technology as the normal class. The main difference is that the normal class is scaled towards smaller screens, more restricted input controls, and device capabilities, whereas the large class is scaled towards bigger screens, larger keyboards, and more capable devices. However, dynamic content scalability is an important challenge here too because the use contexts may change. Based on this classification, we can see that the service description languages should offer lots of richness and flexibility and allow use context sensitive optimizations. However, the language should be directly executable in order to ease the service design. There should be no need for translations, except in very special cases (e.g. fixing small issues in some client implementations). Since the technology support in all clients will be equal rather sooner than later, the key challenge is to make this commonly shared technology scalable from one use context to another. 3. Modeling Interaction Logic for Web Applications The usage scenarios for many web applications can be modeled as simple processes. There, a user launches the service (such as browse to a site by selecting a bookmark) and does something first (like register and select a blog from a personal blog list). Then based on that, she can do something else (like post a comment to the selected blog entry), and finally she will leave the service (browse to another site). Available options depend often on the other decisions made previously. They are not fully independent. However, because the available options and possible execution paths can be described beforehand, this information can be directly used in desiging the application. One way to do this is to model the user interaction as a process or as a workflow. Modeling just user interaction is not often sufficient. In fact, plain user interaction modeling is valid only for sites having purely static information. For sites with dynamic information, the connection to this dynamic data and computation needs to be linked to this user interaction model. Otherwise, the user interaction model is like a "not really needed" service description that is thrown away when the real implemention starts. In order to fix this, to make this description really executable, the user interaction process description must contain capabilities to link user interface, data, and computation. Web services technologies offer ways to publish data and computation for these user interaction processes. In addition, web service technologies can be used to do the linking between these components. For example, WSDL can be used to describe data and computation services. Then WS-BPEL can be used to link these services together. By using (X)HTML, WS-BPEL, and WSDL in the proper way, it is possible to describe how browser and web technologies can be applied in declarative service development. In practice, the service designer can describe independent "pages or screens" using (X)HTML and then she can describe flow between the pages and "data and computation" services by using WS-BPEL. In this kind of model, the process description will - Describe the connection to back end data and calculation services, - Use the browser as a rendering and interaction service, and - Describe the interaction model for the service. In some cases, user interaction logic needs to be completely separated from the application logic. This can happen if different user interaction models are needed for different classes of clients. In these cases, it is possible to use an application / service framework that consist of business processes and user interface processes. User interface processes are used for separating user interface behaviour from actual business logic. The business process describes in a device independent manner the application logic by composing existing component services. The device dependent user interface process describes the actual user-viewable application user interface flow. Of course, both device independent and device dependent parts can be again combined if needed and they can be deployed on servers or to clients in any combination based on client capabilities and service needs. 4. Considering Future Work within W3C Understanding different client classes and their evolution is important when planning future standardization efforts. While more and more clients are upgrading to support Full Web standards, there are fewer needs to standardize new features for small clients. However, differences between devices supporting Full Web will increase. Therefore, need for scalability of the content and need for implicit context sensitive optimizations will increase. Content adaptivity options of current web markup languages are quite good. However, there are still problems; especially some AJAX-based services do not scale well enough. Asumptions on certain screen sizes, on fixed element positions, and on input controls do not properly enable implicit optimizations. Here, we need to further work on these technologies to guarantee that services can scale on devices from having very small to very large screens and having different input controls. Currently, only services are typically described using WSDL. However, it would be good to have these descriptions also for clients (browsers). Especially nowadays, more and more sites are using asynchronous background information retrieval to mimic server side push. Standardizing the browser as a web service and providing its interface using WSDL would allow leveraging the browser as a service similar to the others in combining together user interfaces, data, and computation services. Browser as a service is a concept of having a client service that renders (X)HTML pages when a service requests it do so. A service will request to show a page based on events such as start application request from the user, update state after the user filled a form or selected a link, or when some external event happens and the user interface needs to be updated. In practice, this pushing information could still be implemented as a pull style. For example, it can be implemented as a client side pull inside a script, or a refresh property in a page header. To enable this pull a "proxy" could be used. There, a service sends "new pages" for this proxy and the client pulls updated pages from there. However, this pull needs to be done allowing keeping the user interface state. For example, if a user is filling a form and a new pushed version of the page is coming, the currently filled entries must be copied to this new updated page. One key idea here is the simplicity for the designer. In designer's view, she sends a complete new page to the user interface. This is not like a REX where partial changes are sent. REX or similar technologies can be used on the background, but the designer should use higher abstraction level approach. Another way to proceed is to describe user interaction logic as a workflow based service. This allows unified user interface and back end logic integration. Here, the key requirement is to use the same technologies in all of the integration work and not invent new partial solutions. Using WS-BPEL for this can be considered as one appropriate way to go forward. To conclude, this paper proposes future work on three areas. At first, the current work on making Web more scalable must continue. Full Web standards must be further developed in order to offer more scalability options in order for client side optimization based on use context. At second, updating pages from the server must be simplified. Here, browser as a service concept could be used and standardized. That allows easy asynchronous way for service designer to update user interfaces. And finally, use of process modeling as a way to design services should be encouraged. Here, user interface extensions on top of WS-BPEL could be standardized.