| QUESTION & ANSWER |
RIA needs to build on, not replace SOA |
 |
By Rich Seeley, News Writer
27 May 2008 | SearchSOA.com |
|
|
The software industry needs to stop marketing one three-letter acronym such as RIA as a replacement for the previous three-letter acronym SOA, says Jeremy Chone, the new CTO of Nexaweb Technologies Inc. He comes to Nexaweb from Adobe Systems Inc., and has also worked at Oracle Corp. and Microsoft, all of which are focused on Web 2.0 technologies. In this interview, he discusses Web 2.0 as an evolutionary step within service-oriented architecture (SOA), and not as a revolution that will replace it.
Read part two.
How do you see the increasing focus on Web 2.0 technologies impacting SOA and backend legacy applications?
Jeremy Chone: Enterprise Web 2.0 is mainly two things. The first is it brings more social capabilities to the enterprise. It offers the same social networking capabilities as the consumer social networks. So enterprise Web 2.0 is bringing this concept into the enterprise so people can work more effectively. The other side of enterprise Web 2.0 is the technology, which includes rich Internet applications. The concept here is that now Web applications -- with the maturity of browsers, client plug-ins and desktop runtime -- can be much richer than they used to be. Before it was request-response based and most of the logic had to be run on the server side. Now, you can have logic on the client side.
Where does the new RIA technology fit in with SOA?
Chone: Now you have two technology approaches. The first is to be additive and bring rich Internet applications about without removing anything. You go to your SOA application and you add rich Internet capabilities within the current architecture. So you don't have to change the architecture. The other is to have an exclusive approach, which goes into the SOA application and removes all the UI and business logic on the server side, and puts this logic on the client side. With runtime on the client side that means most of the application is going to run on the client side. The only connection between the client and the server side is going to be either data connection or service connection for some of the business logic on the server side.
Is that second approach doable?
Chone: The problem you have is that to have an architecture that supports the second approach, you have to rethink your SOA application. And because it's usually not the same language and not the same runtime, you have to throw away your application and UI code to make it more client-centric. What has been appealing about the SOA approach is you take an approach that is distributed architecture where you can decide to keep some of the application business logic on the server side and sometimes offload some onto the client side. That is a really unobtrusive way to add RIA to the architecture.
The first approach sounds like throwing the SOA baby out with the bath water, is that correct?
Chone: The first approach is to re-architect your application from scratch and keep only the service and data backend of your SOA. The other approach is to choose a framework that allows you to have a distributed architecture and allows you to retain some of the application and UI logic on the server side if you wish to.
So you're focused on the second approach?
Chone: Yes, because the second option brings the benefits of the first option. You can still have the logic run on the client side, but the framework also supports retaining some of the logic on the server side. So the second option is a superset of the first one.
For architects and developers looking to include RIA/Web 2.0 capabilities to their existing SOA applications, why is the second choice the better one in your opinion?
Chone: The second one is better because you can keep the investment that you have made in your current application, in your current architecture. For example, if you are using JavaServer Pages, JSP, you have the option of keeping that on the server side if you want. You also have the option of putting it on the client side if you want. It's about choice.
So you don't throw out your existing technology?
Chone: There is an issue here for the entire industry. Every few years, we come up with a new three-word, three letter, RIA, SOA and everything. We need to get some perspective here. We can't go back to the customers and say: "Ha, ha, ha, we have a new three letters. Now you have to reinvent and re-architect with our new products, and rethink how you build applications." This is wrong for two reasons. One, it is not fair to the enterprise customers who are buying solutions. They feel that the technology is changing too fast and they are being forced into new runtimes and new paradigms all the time. Secondly, if you step back and look at the Web 2.0 technology, RIA and everything, there is actually no big revolution. Everything is very evolutionary in many ways. So good architecture needs to be inclusive and not exclusive. Good architecture needs to give choice to the users and shouldn't remove on the pretext of adding something. We should be able to add RIA without having to remove applications that were already SOA-based.
So your recommended approach is to maintain SOA while adding RIA?
Chone: Yes. SOA was a critical step for the enterprise in abstracting the UI, the service and the data. That was a huge step. What we need to realize in the software industry is that RIA is an evolution on top of that. It shouldn't in any way replace or remove any of the components that have already been done in the SOA architecture. We shouldn't ask the enterprise to re-implement their application and, in some cases, do it in another language. That isn't a viable option because then I have to have new skills and I have to change my architecture once again. Then in two years from now, you are going to come back with three new letters and I am going to have to re-architect yet again. It is the duty of the software industry, the technology providers, to make sure everything is additive not exclusive.
In the second part of this interview tomorrow, Chone discusses compatibility issues with RIA platforms and the need for Web 2.0 developers to understand the business and the business applications.
|
|
|
|
