Technologies for 2009

As per recent report below are the top 10 technologies for 2009

Virtualisation
Cloud Computing
Servers -- beyond blades
Web-oriented architectures
Enterprise mashups
Specialised systems
Social software and social networking
Unified communications
Business Intelligence
Green IT

I will try to discuss these in my future blogs

Rich Internet Applications - Brief Intro

Recently the term RIA (Rich Internet Application) is used or heard frequently. I was reading different articles, white papers etc on this topic. Also started working on Flex. I am summarizing my readings in this blog.

1. Evolution of web

Computer applications started mainly as desktop applications where whole application code resides on user’s desktop and executed from there. Later we saw emergence of Client-Server architecture which led to web applications. With growing maturity in web model more and more processing is moved to Server and clients became thinner and thinner. In any traditional web applications most of the processing is done on Server. This model looked apt till recently. But with growing complexity of web applications and growing need to improve the user experience, drawbacks of the web model started to surface. One of major drawback is inability to have any processing logic at client side. This necessitates every request to go to Server.

This requirement gave rise to a new model—the Rich Internet Application (RIA), which is “a cross between Web applications and traditional desktop applications, transferring some of the processing to a Web client and keeping (some of) the processing on the application server”

2. Rich Internet Applications (RIA)

There are different technologies available in the market for developing rich Internet applications. Most popular of them are Flex, Java (AJAX etc), SliverLite, JavaFx etc. Before looking at these and other technologies, it is important discuss the crucial aspects of rich client technologies. Rich client technologies should:

Provide an efficient, high-performance runtime for executing code, content and communications. The principle here is that the end-user experience of HTMLbased web applications suffers from a variety performance related challenges. These include the request-response page rendering model; the need to dynamically generate large blobs of text for transmission of simple data; the lack of client-side data storage; the inability to easily invoke and use remote business logic, and even the basic graphics model of HTML. These all must be improved.

Integrate content, communications, and application interfaces into a common environment. The end-user experience of the Internet today is fragmented into the HTML browser for textual content and basic application interfaces; multiple messaging clients for performing communications functions; and multiple media players for handling audio, video, and other forms of media. Rich clients need to provide deep integration for all of these types of interaction.

Provide powerful and extensible object models for interactivity. While web browsers have progressed in terms of their support for interactivity through the Document Object Model (DOM), JavaScript, and DHTML, they still lack the richness needed for building serious applications. Rich clients need to provide a powerful, object-based model for applications and events. This common object model must integrate user interface, communications, and system level services.

Enable rapid application development through components and re-use. Rich clients should support powerful component-driven development, enabling both third party and corporate developers to easily reuse visual components to accelerate development, and give junior developers access to complex functionality. These components should integrate seamlessly into the design time environment for ease of development.

Enable the use of web and data services provided by application servers. The promise of rich clients includes the ability to cleanly separate presentation logic and user interfaces from the application logic hosted on the network. Rich clients should provide a model for easily using remote services provided by back-end components, whether hosted in an application server or accessed as XML web services.

Embrace connected and disconnected clients. While many users have gotten used to having to be online and in a web browser to perform work, the reality is that most applications would benefit from the ability to be used offline on occasionally connected devices such as personal digital assistants (PDAs) and laptops. Likewise, many applications require support for persistent connections with two-way, notification-based communications. Rich clients must enable both of these types of applications to be easily built and deployed.

Enable easy deployment on multiple platforms and devices. Internet applications are all about reach. The promise of the web is one of content and applications anywhere, regardless of the platform or device. Rich clients must embrace and support all popular desktop operating systems, as well as the broadest range of emerging device platforms such as smart phones, PDAs, set-top boxes, game consoles, and Internet appliances.

3. Characteristics of RIAs

• Accessible to the user without a separate installation process
• Supports robust, local application processing on the client side
• Provides a rich, full-featured user interface that closely matches the look and feel of a native desktop GUI
• Allows you to present information more effectively — providing immediate visual feedback
• Can provide greater ease of use — a standard Web browser is used to access the application
• Simplified maintenance — RIAs reside on the application server and there is no client component — update once on your server
• Support a full, event-driven user interface model.

RIAs utilize relatively robust client-side rendering engines that can present very dense, responsive, and graphically rich user interfaces. In addition to offering a wider variety of controls (sliders, date pickers, windows, tabs, spinners, gauges, and so on), RIAs generally allow you to construct graphics on the fly with either Scalable Vector Graphics (SVG) or some other mechanism. Some RIA technologies can even provide full-motion animations in response to data changes.

Another benefit of RIAs is that data can be cached in the client, allowing a vastly more responsive user interface and fewer round trips to the server than with HTML. For wireless and occasionally connected devices, the trend is definitely toward rich clients and away from text-based Web clients. Applications running on laptops can be designed to work offline or to at least degrade gracefully when connectivity is lost.

4. Application of RIA

The six key business applications that are motivating overall RIA spending consisting of

• Enhancement of existing web applications
• High-transaction and event-driven Internet applications
• Next-generation portals
• Enhanced business intelligence solutions
• Application modernization
• Peer-to-peer or mashup solutions.

5. Choosing an RIA solution

New Interviewer Syndrome

Referring to context of my previous blog…

What is the difference between Model-2 and Model-3 architectures? This is the question one of my colleague faced in is job interview.

One more question I was informed.. What are the different actions available in Struts? Expected answer was DispatchAction, ForwardAction, IncludeAction, DownloadAction, EventDispatchAction, LocaleAction, MappingDispatchAction etc.

How relevant are these questions in a job interview for a lateral? I call these questions as Text book questions which are intended to test the memory. I will refer asking this kind of questions in interview as “New Interviewer Syndrome”. Why? As I observed with most of interviewers including myself, in initial interviews interviewer will get tempted to do some show off and aim to ask questions which interview doesn’t even heard of. Most of the times these questions will be irrelevant. Just as in above examples, in first scenario there is nothing like Model-3 and in second case with my experience we rarely use the any thing other than DispatchAction. Ofcourse maturity will come with experience and will start asking relevant questions. Same is the case with me, now with experience of near century of interviews I concentrate only on basics that too practical things. So friends, please don’t get into this “New Interviewer Syndrome” and be good interviewers. All the best...

Model-3 Architecture?

What is the difference between Model-2 and Model-3 architectures? This is the question one of my colleague faced in is job interview. Never before I came across Model-3 architecture, so I googled for it. Soon I realized there is nothing official about Model-3 but I could find two references to it. One is a blog and other one is a mail-archive related to a project in sourceforge.

After studying these links I felt like any framework/application using JSF and EJB 3.0 is a Model-3 app. Let me explain why…
As per one of the links the below are the main properties of Model-3 architecture.

1. An improved event model.
2. A new scope that encourages efficient memory usage.
3. Standardized create, read, update, and write support between model and controller.
4. Supports cooperation and interaction between multiple MVC components ( portlets ).

Let’s take the Seam framework which uses JSF and EJB 3.0 and analyze about requirements. As we know JSF is a component based framework with support for different events and listeners like ActionListeners, ValueChangeListeners etc. So the first requirement is fulfilled. Seam introduces a context called Conversation context which is between Session and Request, which is the 2nd point. In 3rd point Author talks about simplified CRUD operations and easy linking of UI and persistence layer. This is in a way achieved with EJB 3.0’s entities which follow JPA.

Based on the above discussion can we conclude MVC with added events and JPA type persistence is Model-3?

JBoss Seam - Overlapping responsibilities?

Right now I am working on a project using JBoss Seam. I am getting queries about its advantages and differences. So like to discuss few of them in my blogs.

JBoss claims that Seam will shorten development life cycle. It’s true to some extent as it’s easy to create UI, EJBs, entities etc with help of JBoss developer studio. One reason JBoss gives for fast development is that Seam reduces the glue code required in application using JSF and EJB 3.0. This is done by enabling direct invocation of EJB methods from JSF. In other words EJB or entities can be used as backing beans. No business delegates in Seam. This is becoming arguing point for architects and designers from traditional 3 tier apps and frameworks.

As there are no POJO backing beans in Seam, the EJBs are becoming the first choice to include the code for ActionListeners, ValueChangeLiserners etc. These essentially will contain the presentation logic. This one way combines business logic with presentation logic. Seam also enables JSF to communicate with DB through entities. We can persist or query database using entities from JSF itself.

I advice people planning to use Seam keep the above point in mind and design classes accordingly.

Developer O Developer

For a long time I was thinking of being part of blog-world. Finally I could start on..

In the first blog I like to write on few of my thoughts after recent SunTech days.

I am envied by the information, tools and opportunities that current day developer got. There are very good opportunities and tools being provided by the open source movement. I was also amazed by the amount of participation and contribution by the student community thorough open source communities. Either it by providing documentation for netbeans or by submitting bug fixes for opensolaris or by other means.

I also had a chance to find out new frameworks and tools available. I feel recent IDEs and frameworks especially those I came across are making development easy. I still remember the pain we went through to get a page up and working using jsp and early spring framework some 4yrs ago. But is simple and straightforward using frameworks and IDEs like seam and RedHat developer. There are tools to manage requirements, to generate prototype from requirements, to do automated builds and run tests and so on. I envision a day when a requirements are captured in a tool, a language is selected and the deployable archive is generated. While in first case I envied developer here I pity them. With more and more coding and testing being done by tools, the role of developer is expanding. Your are no more good enough of you know one language and can code in it. He should posses skills to be agile.. learn and adapt new frameworks and tools. That's why I say, Developer O Developer grab the opportunist when you are young and energetic...