Mar
2008
Creating a rich application involves both RIA and SIO. In all the previous three parts we have seen that integrating the RIA programming is simply the half of the whole task. Other half requires integration of SIO to make it a complete platform for web development.
All the existing sets of web 2.0 toolkits and other frameworks have been focusing upon RIA and have almost negligible support for creating serves and other applications. In such a situation, it has become more complex for web developers who would be required to make extra efforts for SIO integration. This complexity in turn leads to additional application development and maintenance which is much time consuming and not easy.
It becomes very important that the next generation RIA+SIO should bridge this gap in an efficient manner and only then it will be providing an integrated services platform for the future web developers. There are three such important features which will be helpful in bridging this gap by providing;
1. <!–[if !supportLists]–>
This is the support for web developers for creating applications and specific
services with the application of any available programming language.
2. ??????????????
It is simply the “Seamless Interoperability” which links the different RIA and
SIO represented as ?
3. <!–[endif]–>
It is the ability of a functional unit in the platform to consume any local mock service.
Conventionally, almost all the existing web-based frameworks have been woven around some particular programming language. This traditional approach seems to be obsolete now. This is why the RIA+SIO have no such specifically developed programming language. RIAs are completely programming language agnostic and simply require an exchange of application data with the services. A lightweight message-based contract forms a basis for only required link between the RIA and its SOA based services. The link however is quite open. This loose hook between RIA and SIO facilitate developers with an integrated service platform which will enable them to apply any programming language for creating a service. Such creations would not affect the RIA tier of the application in any way.
Seamless interoperability between the RIA and SIO tiers is essential for any future integrated service platform. A developer should feel comfortable with handling the service routing and data marshalling.
Let’s understand this concept with the help of another example demonstrating a really simple integrated approach for creating a particular service using JavaScript;
@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);
}
You could easily notice two different aspects in the above example. Firstly, a “service” annotation was added to Java for transforming a plain Java object in to a specific service. This changed annotation encompasses service request and service response message both. Doing this makes the routing configuration comfortable.
Secondly, it is very simple and comfortable while working with service request and response data. You could easily spot out that the response message contains complete user object. This way handling with data marshalling becomes easy with service platform.
All this helps a web developer lot. There is no need to focus on writing glue code. Instead, a web developer may only write the service logic. Such transformation would facilitate them with faster development while writing minimum codes.
Coming to the final step would be creating a local mock service. It becomes easy when the link between RIA and its service is based upon message. Local mock service will create responses for remote requests while remaining local in the RIA only. This powerful function will create fully functional RIA prototypes and for this a web developer does not require writing even a single line of service code. Depending upon the requirements, all such mock services may be put in to even a single file which can also be deleted when the process of interface development is completed.
Let’s understand it with 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>
All the examples used in this four part concept presentation were based on “Appcelerator” and written by Nolan Wright. There could be many other approaches for creating such a next generation web platform. There may be different sets of specific implementations and approaches but finally the general characteristics of a web platform would remain the same.
