Page 3 of 3   « previous page

These two examples accomplish the same thing, but in very different ways.  The first example requires more code and it’s all in Javascript.  The second example uses a simple expression language to do the same thing.  Let’s take a closer look at the syntax.

on=”change then r:load.combo2.request” 
 

In this expression, the Ajax request message r:load.combo2.request will be sent when the <select> gets a “change” event – pretty simple. Now, let’s look at the second expression:
 

on=”r:load.combo2.response then value[property=rows,text=text,value=value]”
 

When the Ajax response message r:load.combo2.response is received, the contents of the second combo box are set based on data in the response message.
 

Let’s take this example one step further by adding a visual queue when the response message is received. 

<select id=”comboTwo”

on=”r:load.combo2.response then value[property=rows,text=text,value=value]

and effect[Highlight]”>

</select>

By adding and effect[Highlight] to our expression, we are able to  incorporate a subtle effect that lets the user know that the combo box values have changed. 

These code examples demonstrate the power and simplicity of a fully integrated approach to event handling, DOM manipulation and Ajax.   Developers that have little to no Javascript experience will find it easy to learn an expression language like the one above.  It will enable them to get productive quickly, since they don’t have to climb a steep learning curve.  Of course, there are developers that are comfortable with Javascript and would prefer to use it.  As a result, an integrated RIA programming model should also support the use of Javascript, specifically in a way the supports the separation of behavior from markup.  This is commonly referred to as unobtrusive Javascript.  Let’s look at an example:

<img id=”progress_image” src=”images/indicator.gif”/>
 

$(“progress_images”).on(“r:login.request then show”).on(“r:login.response then hide”);
 

In this example, the <img> markup is separate from the Javascript code that defines its behavior – i.e., “show” when the login request message is received and “hide” when the login response is received.  This type of programming model is good for developers that prefer to do their RIA programming in Javascript.

An Integrated RIA Programming model is a fundamental component of an RIA + SOA platform.  It provides developers with a single integrated mechanism for handling the major RIA programming activities.  The net result is that developers can build rich user interfaces faster and with significantly less code than is required today.

Provide an Integrated Services Platform

RIA only gets us halfway to our goal of building a rich application.  We still need to provide an answer for the SOA piece of RIA + SOA.  Unfortunately, the current crop of Web 2.0 toolkits and frameworks primarily focus on RIA; they provide little to no support for building services.   This is problematic because developers are, once again, left to bridge the gap, which makes application development and maintenance unnecessarily more time consuming and difficult than it should be. 

A next generation RIA + SOA platform must address this gap by providing an integrated services platform that provides the following:

• Support for creating services in any programming language
• Seamless interoperability between the RIA and SOA tiers
• Ability to consume local mock services

Historically, web-based frameworks have been built around a particular programming language, but in the world of RIA + SOA this practice seems outdated and unnecessary.  RIAs only need to exchange application data with services, so they should be programming language agnostic.  The only required link between an RIA and its SOA-based services should be a lightweight message-based contract.  This loose coupling between the RIA and SOA tiers opens the door to a integrated services platform that enables developers to use any programming language for service creation without impacting the RIA tier of the application. 

An integrated services platform should also provide seamless interoperability between the RIA and SOA tiers.  Specifically, it should handle service routing and data marshalling on behalf of the developer. Here’s an example of a simple integrated approach to building a service.  This particular example uses Java:

@Service (request = ‘login.request’, response =’login.response’)

protected void loginRequest (Message req, Message resp)

                                throws Exception

{

     String username = req.getData().getString(“username”);

     String password = req.getData().getString(“password”);

     User user = UserDAO.login(username,password);

     if (user !=null)

     {

     response.getData().put(“success”,true);

     response.getData().put(“user”,user);

     return;

}

response.getData().put(“success”,false);

} 

In the example above, there are two things to notice.  First, a plain Java object is turned into a service by simply adding a “Service” annotation to a Java method.  This annotation contains both the service request and service response message that this method handles, which makes routing configuration easy.  Second, working with service request and response data is simple and straightforward.  In the example, the entire User object is placed into the response message.  The service platform handles the data marshalling.  The result is that developer can focus on writing service logic instead of writing glue code, which ultimately results in faster development with less code.

Finally, if the contract between the RIA and its services is message-based, then it becomes possible to create local mock services.  Local mock services respond to remote requests but they exist locally within the RIA.  This is a powerful capability because it opens the door to creating fully functional RIA prototypes without writing a single line of service code.  These local mock services can be placed in a single file and removed once user interface development is complete.  Let’s look at an example.

<!-- Progress indicator -->

<img src=”images/indicator.gif” style=”display:none

on=”r:login.request then show or r:login.response then hide”/>

<!-- Login form -->

Username: <input type=text” fieldset=”login” id=”username”/>

Password: <input type=”password” fieldset=”login” id=”password”/>

<input type=”button” value=”Login”

on=”click then r:login.request”/>

Login Form

<app:script on=”r:login.request then execute after 1s”>

     $MQ(‘r:login.response’,{‘success’:true,’username’:’foo’});

</app:script>

Mock Service

In the example above, we have a login form that generates the service request r:login.request. We also have an image that will show when r:login.request is received and hide when r:login.response is received.   The second part of the example is the mock service.  The mock service listens for the r:login.request service request and responds with a r:login.response message after one second in order to simulate service latency.  The login form has no knowledge of the service location; it simply responds to messages.  This simple example demonstrates how an entire RIA prototype can be built without writing any service code.  This prototype would be 100% reusable, and it has the added benefit of enabling developers to define the service contracts in advance of service creation.  The result is that service creation is greatly simplified because service developers not only have a fully functional prototype as a reference; they have a complete set of service interfaces.

Conclusion

Developers are currently caught in the middle of a fundamental shift in web application development.  We are moving away from the server-side MVC frameworks of Web 1.0 and towards a client/server architecture for the web, or more specifically RIA + SOA.  As a result of this shift, developers have been left to piece together their web development platform for rich web applications.  Of course, change creates opportunity.  The opportunity in this case is to build a next generation web platform that provides end-to-end support for building Web 2.0 applications.  At Appcelerator, we saw this shift coming well over a year ago.  Our response was to build the Appcelerator Platform; a platform built from the ground up to support RIA + SOA.  The examples used in this article are based on Appcelerator.  Of course, many different approaches will be taken to create the next generation of web platforms, but while the specific implementations may differ the general characteristics should remain the same.

Page 3 of 3   « previous page