Web vs. Smart Client – How to sell Eclipse RCP Technology?
18. October 2007
With the development of the RCP Framework a new and elegant possibility to develop client applications was created. The Eclipse licensing model allows you to create commercial applications based on the RCP Platform. However, the question must to be asked under which conditions and with which requirements a computer-based solution based on RCP is the best option.
Starting point
Often you’re faced with a software-environment that’s completely based on web-applications, regardless of which business process is mapped with an application. Experience also frequently shows that people have a very different picture in mind, when you’re talking about Java client-applications. A slow ugly swing application or an applet is the most frequently encountered association. At this point, it gets very difficult to convince somebody of a technical RCP-based solution, especially if that technology is still completely unknown.
Possible solution
The approach I use here is not based on listing all the advantages brought about by Eclipse RCP, but rather on the analysis of the requirements you have to meet and which are relevant to opting for a technical solution. Thus, the business specific requirements are the crucial criteria that indicate technical architectures/methods/frameworks/etc, not vice versa, as is often the practice.
Accordingly, the characteristics of RCP and web applications play a comparably important role. Basically, all you have to do is “map” the requirements to the characteristics of technical systems.
This approach will enable you to achieve several goals: First of all, you’ll get a clearer picture of your project goal. Secondly, it’ill force a “re-consideration” of the given requirements.
Poster
The poster, which was also shown at the Eclipse Summit in Ludwigsburg, can be seen as a help for guidance within such a decision-making process. Its focus is on different requirements which are brought into the context of a decision for a system. The important aspects are:
- Target audience (power user, casual user)
- Online/offline capabilities
- Availability
- Existing software systems
- Hybrid applications
- …
Ideally, this should make it easier to decide between a web application or rich client application.
RAP?
Based on the aspects mentioned above, a 1:1 replication of application types, as it is done with the Rich Ajax Platform, is a suboptimal way of modifying applications. This is because there are further aspects which need to be considered when the decision to move an application to the web is made.
Also worth mentioning here are the expectations concerning usability, layout, response time, etc. that are mostly completely different, so that a 1:1 porting from an RCP application to a web application (and also vice versa) will not meet the changed requirements. Please, do not get me wrong, this is no RAP bashing, I think it’s really cool software, but from my experience, I couldn’t find any scenario where a 1:1 porting would deliver a satisfactory result.
Conclusion
With the RCP Framework, you can build an application based on a specified set of business requirements. Pure web applications continue to be first choice for specific requirements.
I fully agree with the points you are making. I think we need to provide a way to write the buisness-logic/model once and deploy it to different platforms whereas the UI has to stay configurable (maybe 90% can stay the same on all deployment platforms so we have to invent solutions to share those common parts)
Comment by Tom Schindl — 18. October 2007 @ 17:24
As you are mentioning RAP I can not resist to reply
There is no disagreement from our side that 1:1 replicas of RCP apps in the web are often not a great idea. But nobody forces you to go down that path. When we started the RAP project single-sourcing was not our major concern. But our users pushed us very hard into that direction, and we think it is a good idea to listen to your adopters. Now, even with many things still missing, we enable you to re-use a large parts of your code for both desktop and web.
In a commercial project we experienced ourselves that being able to have a single code base is extremely valuable, but we needed to diversify the UI between web and desktop. We ended up with the following plugin architecture:
foo.bar.core
foo.bar.ui.base
foo.bar.ui.rcp
foo.bar.ui.rap
In our project we are able to share about 80% of the code, after we made the core multi-user aware. Before using RAP (and OSGi on the server side) we had a reuse factor of 10%. Your mileage may vary in your project.
With respect to technology decisions I am taking a different perspective. By no means I disagree that you should choose the technology that suits your requirements and not the other way around. I think that is a pretty common knowledge, even if it is not always practiced. My perspective is about platforms: Enterprises are choosing (one or multiple) platforms with respect to their consolidated requirements, and in a second step they are mapping those requirements to the available platforms. Having server-side Equinox, and RAP, and Riena, and EclipseLink, and Swordfish, and eRCP is just expanding the capabilities of the platform by a large degree - thus making it a better platform for enterprises.
A last word about “the characteristics of technical systems”. Those are changing over time, and even if misused with respect to the original use cases the web technologies have made a lot of progress that need to be considered.
Jochen Krause
Comment by Jochen — 19. October 2007 @ 10:24