In general, for Web 1.0 applications , a client-side (e.g., browser) is restricted to rendering and presentation. Logic that executes on the client, if any, is used to support a particular view. All controller logic executes on the server-side, and all model manipulation occurs on the server-side. This so-called “thin-client” approach provides for static client/server partitioning. Although there are client-specific programming models (e.g., HTML/JavaScript) and server-side specific programming models (e.g., Java Servlet), the partitioning between client and server is well defined.
The downside of the thin-client approach is the end-user experience. It is not as engaging as a traditional rich-client approach. Further, the client-side is continually posting and reloading full pages from the server-side, i.e., the client has no autonomy. Since all of the substantive work happens on the server, the approach does not leverage the computer power of client platforms.
So-called Web 2.0 applications attempt to address these problems by broadening the role of the client. However, there are several problems with the Web 2.0 approach. Application development includes “tuning” any partitioning between client and server. Thus, what is client-side and what is server-side is no longer well defined. A given application partitioning (client vs. server) may be appropriate for one device (e.g., browser running on a PC) but not another (e.g., browser running on a cell phone). In particular, regarding enterprise data, a given client may not provide the same Quality of Service (with respect to execution of application code) as the server. There are also issues of trusting that the application code running on the client has not been altered and of providing reliability guarantees, in particular, transaction semantics, for application logic.
The next generation of software applications, such as Web 2.0 applications, is primarily client-side applications. Yet, there are often requirements that cannot be satisfied in a client alone. Such requirements, typically non-functional requirements, may include data sharing, security, reliability, privacy, and memory constraints. To satisfy these requirements, some application logic needs to run on a server.
To satisfy such requirements, applications are implemented using explicit server-side programming models and require special treatment during deployment. This traditional approach imposes a tight coupling of functional and non-functional concerns. Developers are forced to implement their applications in terms of different models (client-side vs. server-side), making it difficult to evolve the implementation as requirements emerge and change. This approach thus stresses both the skills and budgets of application developers.
Accordingly, there remains a need to simplify the development of applications for a client-server environment such that separate programming models for a server and a client are not required. There is also a need for applications that are implemented with flexibility as to where application components may be executed at runtime.
There is a need for a programming model that is client/server agnostic, allowing for automated, just-in-time partitioning of an application based on the specific client-side capabilities of individual users of an application.