RSS
 

Archive for the ‘SOA’ Category

RIA : inside or outside the browser ?

05 nov

The Paris JUG this time was devoted to GWT and implementation of Restlet for GWT. Two presentations greatly performed by Didier Girard and Jerome Louvel. I was impressed by the number of participants, thinking that GWT was already in the soul. Bravo to Didier continue to promote this technology and Jerome to put the concept of REST.
Still, I am astonished at the vision that people have of the RIA. For many I have the impression that RIA means rich web application. But the notion of « rich » is simply a reconsideration of the user experience and this does not necessarily by the browser. GWT, Ajax, AppletFX, Flex or Silverlight do not have the monopoly of RIA simply because they run in a browser.
Javascript enabled to overcome the limitations of HTML in the browser and gave a new dimension to Web applications. The browser now becomes a runtime JavaScript and uses HTML as graphics library. Like Java with Swing, C# with WPF or Silverlight, AS3 with Flash and Flex.
iTunes is probably one of the first RIA and this is not a web application. As I said already we must differentiate Rich Web Application and Rich Desktop Application. A RWA runs in the browser, a RDA runs in an OS.
There are advantages and disadvantages in both approaches but the distribution and maintenance which have long been the strengths of Web applications are no longer true today.
As you do more surprised to have your Windows automatically updated it is now also possible for an RDA to be maintained and transmitted via the Web. Java Web Start is a good example and Adobe AIR knows how to do too. But i herer what you say : to run Java or Air, you have to respectively install the JVM and runtime AIR. Yes it’s true like you do it recently when you installed Chrome or previously installed Firefox. The difference is that Windows come with its own browser and when you buy a PC with Windows you have it. At one time you install a runtime and except if you are terribly lazy person you aren’t obliged to be use Windows/IE only.
Where we must be vigilant with a RDA is to not go back to the old client/server model. The RDA must remain a UI layer and not shipping business that must always be server side.<br /> Apple had already experimented this with WebObjects Java Client and continues today to offer similar APIs for Cocoa and now IPhone SDK.
To the slogan « the browser is the platform » I answer « the browser is a platform ». Future architectures should not be dependent on UI layer because it must be developed in the best technology to meet the objectives of application and customer needs by focusing on ergonomics and performance.
Our application ResUrgences is in web for 8 years now in a sector (health) where applications are often client/server. Now the extension from the emergency department to the mobile emergency department (say SMUR in France) forces us to reconsider the web architecture because using a web application on a Tablet PC offline, although not impossible, is not appropriate. Especially when you have to interconnect with monitoring and electro-cardiogram equipment.
So what choice between RWA and RDA ? The first step is to think RIA, so to have a SOA server side architecture and services accessible through various formats via various protocols. At this point different criteria have to be focus on: ergonomics, performance, accessibility, environment (OS and hardware), openness, security, compatibility with existing … So there is no obvious answer. I’m looking for a long time on a table that defines what technology for what needs and now I think it’s impossible.
What should be considered is :

  • access to local resources (files, applications, USB, serial, Bluetooth) is an argument to look to the RDA. Although this can be remedied with an applet and increasingly with Gears (but it’s a RWA/RDA mix, why not is what I do) and that the Flash plugin already allows access to the camera.
  • the concept of « push » to send data to a client from the server is now possible with RWA (Comet, reverse Ajax) and soon standarize in HTML 5 (WebSocket).
  • exchanges via asynchronous MOM with queues client side cannot yet be in RWA. Gears should propose an API and LifeCycle Data Service does not really do it because the queue is server side.
  • uniformity of application with a single platform deployment independent of the OS is probably the most powerful argument for the SI to choose a RWA
 

Server-side OSGi, is it really useful ?

19 oct

The recent Paris JUG was an opportunity to talk about OSGi technology, already mentioned several times in this blog, and continues to hear about it. Although OSGi is present on the client side with Eclipse, the development of the server side and especially in Java EE environment sometimes leaves developers not convinced. Spring Source (Spring DM server), ObjectWeb (JOnAS), Sun (Glassfish) and IBM (WebSphere 6.1) have clearly made the choice. What are the real benefits for our applications on server side?
First don’t forget OSGi is a specification designed for the embedded domain. This make an implementation without the new Java 5 features : annotations, generics, etc … and that makes us appear OSGi like an old technology. But OSGi stay attractive because what is important above all is the concept: modularization. Concept that on each ear of OOP developer can not be ignored. By development on development we have tried to improve the way we write code, trying to organize it to not create inter-dependencies and go over possible reusability. The arrival of the DI pattern help us to do that and the success of Spring is a good example. OSGi creates a continuity in offering us an infrastructure that obliges us to respect the rules and allows us to dynamically manipulate our components. The dynamic aspect and hot deployment is the icing on the cake but this is not what makes OSGi essential on server side, the current deployment technics with clustered servers, or even with the simple WebObjects Monitor tool, help us to update applications gracefully. What is interesting it’s how the code is organized and the hierarchy throw the management of dependency imposed by OSGi, in application servers and applications themselves.
So in fact this specification is not suited to Java EE and remains technically difficult to understand, but the concept of modularization is a good approach to improve the quality of our developments. That is why Spring focused on because it fits with their framework.
Moreover reconciliation between JCP and OSGi promises well, I hope in the right direction, to make the best of 2 worlds, i.e. all existing OSGi in one hand and the server aspect and Java 5 new features for Sun on the other.
However, we must not forget the dynamic aspect because although users are not insist to see a new button dynamically appear at each time thez need a new functionnality, the fact is with OSGi it is technically possible. But is it really an improvement, actually with a web application it is also possible in PHP, in Java (must reload session). For RIA this becomes more complicated because part of the functional is deported on the client side and update requires complete reloading. This is typically what Chris Brind has managed to improve by combining Flex and OSGi with Solstice. This framework show the potential of modular approach in this domain.
Again what is important is the concept, the modular approach will bring us more quality in our development and greater flexibility in deployment. Let the community choose the best technology to do it…

 
 

Composite oriented programming

24 août

What lack in the object-oriented programming to invent a new concept ? According to Rickard Öberg, best practices and design patterns are not completely respond to all modelling problematics. The domaine driven design shows that the objects have different behaviour according to the contexts in which they are used. An object model must be adaptable in the environment where it live. Read the rest of this entry »

 
No Comments

Posted in Anglais, Java, SOA

 

News on OSGi

26 jan

I really believe in the OSGi technology, i think it’s an innovative element in application. Although a lot of us believe in it, the implementation in applications is not a common way. In fact we must have have to make our applications services oriented to use the advantages of OSGi.

Interface21 began to invest in this technology with Spring OSGi, now the 1.0 is out and i think it’s a good news for OSGi community. It’s time to use it.

OSGi on the server side

A webinar tuesday 18h with Neil Bartlett : Getting started with OSGi

The news of Costin Leau and Adrian Coyler on v1.0 Spring OSGi

 
No Comments

Posted in Anglais, SOA