Read part one.
How does RIA relate to business and business applications?
The problem here is that sometimes the people providing technology get over excited about the technology. We see that a lot in the RIA space where developers are asked to re-architect this new technology and forget a little bit what they have been doing in terms of good practices. SOA is definitely a good practices kind of architecture paradigm. RIA doesn't really have a good practices focus. Is this due to the nature of RIA?
It's not black and white, but you have in RIA two types of applications. There are the emotional ones and the functional ones. The emotional ones are like YouTube, applications that are really driven by emotions. I'm going to feel some sort of emotion and the provider of this application wants the emotion. So you want this application to be very pleasing to the end user. It's a consumer application. Many of the RIA frameworks are focused on this sort of thing.
Enterprise RIA is more focused on the functional space. Yes, you still want to have some emotion because it's better to have people working when they are happy and pleased, because people work better when they are happy and pleased. However, the main focus of an enterprise RIA application is business functionality, not driving emotions. Those sound like very different concepts, can you explain the difference?
There is a big difference here. For a business application you need an RIA framework that is a complement to SOA architecture and current frameworks. For example, the RIA framework for business applications needs to have the option of running on the server side as well as the client side. If you change the business rules such as a price, you need have the complex business rules on the server side to check if the user has the authorization to make a change in price. You have to realize that even if you put the business logic on the client side, you'll still have to have it on the server side because there is no way that you are going to trust the client. You have to do validation on the server side. So in the end you could have a lot of code duplication. You might want to exclusively run the business logic on the server side so you have to have a framework that allows you to do that. Sometimes you want to run it on the client side for more efficiency for the user experience, but you want to be able to reuse this library, this logic. So you want the code to be in Java or .NET, which are the enterprise languages. You don't want it in yet another language so you have to re-code the logic for the RIA application.
Most of the RIA frameworks now are focused on the emotional applications and the consumer experience, but for enterprise business applications you have many other things to consider such as fitting into the current architecture and leveraging the current programming language skills, and making sure you have a distributed architecture. I think slowly the RIA market is going to realize that.
What challenges do you see in incorporating legacy applications into both SOA and RIA?
Architecture and the talent pool for programming languages are very important for enterprises to consider when choosing a new framework. A very strong trend we see in the enterprise and the software industry is that very critical applications run on PowerBuilder and other legacy technologies. The problem here is that there are no new skills for these legacy applications and frameworks because they are not really SOA-oriented and usually new skills develop around new technologies. So the talent pool for legacy applications is becoming smaller and smaller, but the value of the application remains the same. The challenge here for the enterprise is how can I make sure these legacy applications can be managed at the same time as I transform these applications in a more future-proof – to use a buzzword – architecture? So I have a better talent pool in my organization and the legacy is easier to manage with the rest of my applications. The big IT skills challenge here is to move these applications into a modern application architecture so you can leverage the current talent pool in the industry. One thing that is a critical point is the need to embrace a framework that support widely adopted technologies and languages. Specifically in terms of the current talent pool for developers, what does IT need to focus on?
For the enterprise there are two main languages: Java and .NET. Enterprises need to make sure all of their investments are around these two domains. Make sure you don't go too far from the enterprise languages. Should they be looking at rewriting legacy applications in Java?
The problem is right now the J2EE space and the Java space have a hole. They don't have enough semantics, enough abstraction to support applications like PowerBuilder. This leaves the enterprise with two choices. One is to rebuild the infrastructure that makes the PowerBuilder application possible. They rebuild the framework and then they have people re-composing the application on top of the new system framework. What Nexaweb provides to the market is a framework, a language, which is based on XML and CSS and is very Web-oriented, but allows the developer to have the same support in the Java world and in the Ajax world that they would have had in a PowerBuilder world. Now we have Nexaweb Advance which allows customers to transform an application from PowerBuilder to an SOA/RIA application. What Nexaweb is focusing on is having an SOA/RIA architecture and a transformation solution that allows enterprises transform a legacy application for a modern architecture. What specifically are the holes you see in Java?
For example, one thing the Java and J2EE world doesn't really take care of with JSP and JSF is we have customers that really want to have a rich client in a browser or even on a desktop and that is not something that is very well supported by J2EE that usually assumes more traditional Web applications. With the Nexaweb technology we can bring rich interfaces with J2EE in an SOA way. There are a lot of platforms for building RIAs, where do you fit in?
There are three categories. One is the Ajax toolkits, which allows you to take a Web application and making it more appealing to the user, having some of the interaction on the client side. Facebook is a good example of this kind of approach. Most of the Facebook application is page-based. I have my profile page, my front page. It's different pages. It's not everything in one page. However, I have some very useful interaction where I can organize my menu and organize my preferences and that is much more Ajax-like. I don't have to go back and forth to the server. It is something I can drag-and-drop. For that kind of thing, the Ajax toolkit fits the need.
The next category is the RIA framework and Nexaweb is one of them. The RIA framework allows the developer to put an application into the browser.
The third category is enterprise applications, which is the next wave, where the developer wants to work in an SOA way. Because of our approach of Java and Ajax, we have a pretty good footprint over there. With the RIA framework you have different solutions and the ones from the major vendors tend to provide an RIA framework that pushes a runtime as well. So they push the framework and language and the runtime as well. Now, our approach is not to push a runtime but to embrace different runtimes, allowing people to have a rich Internet framework using HTML and Ajax. We're also working with Dojo and extending Dojo too, and we are about to release an open source project for that. At the same time, on the client side for the enterprise with the same philosophy of Java and .NET being the enterprise languages, we're actually leveraging the Java runtime to provide a rich Internet application framework.
So in a way today, you have a lot of RIA frameworks. Most of them are pushing their runtime. Then you have fewer RIA frameworks that are runtime agnostic.