I guess that the name “Rich Client Platform” should be a tip-off that applications built using RCP technology can extend beyond the desktop. Essentially… if you have a client, it seems that you should probably also have a server.
Last night, I started build a collection of views (with an underlying model, of course) that display the value of a handful of stocks I hold. I’m sure that this kind of functionality exists somewhere else, but I’m going through a period where pretty much everything I do is in Eclipse (that is, Eclipse has more-or-less become my desktop) and I wanted to display this sort of information on my desktop. Besides, I’ve been looking for reasonably interesting things to implement as RCP components. The calculation is not completely trivial (mostly trivial, but not completely): as a Canadian, I am interested in the value of these holdings in my national currency and all of my current holdings are valued in US dollars. It was with some excitement that I realized that there is potential here to make use of two different web services: one to obtain the current trading price of a stock, and one to obtain the current exchange rate.
From a web services point-of-view, this is pretty simple RPC stuff. No attachments. No security. No transactions. Dead simple stuff, really. I’m certainly not what I might consider a web services expert, but I assumed that it would be pretty easy to put together what I needed. I used Google to find a couple of service providers. I discovered the BindingPoint site which provides a searchable index of web services and even allows you to dynamically test web services. Like I said, I’m no expert in web services, but this seems like a pretty handy resource (anybody out there have any experiences–positive or negative–with BindingPoint?)
So, I obtained the WSDL for the web services and used the Web Tools (WTP) feature in Eclipse to build a web services client. I stumbled a little bit at the discovery that I needed to actually define an application server before I could generate a web service client; it seems odd to me that you need to have a server in order to define a client (but maybe that just shows how little I know about web services). Anyway, I installed Tomcat 5.5 and configured a server instance for it in the WTP preferences. After that, the generation of the client was a snap. With one hitch (okay, more of a cascading series of hitches)…
WTP generates client code into a web project only. That is, it only generates clients that run in the servlet container of an application server (which may be why a server must be defined). “No problem”, I thought as a I copied the generated package into a new plug-in project. “Big problem”, I thought as I watched the little red Xs appear. The generated code, it turns out, requires access to Apache Axis (if I had more experience with web services, I might have expected this). After a couple of minutes of poking around (and a little moping) I found an org.apache.axis plug-in which was included with WTP. “Great!”, I thought as I added this plug-in to my dependencies. “Rats!”, I muttered as I watched most–but not all–of the little red Xs disappear.
The org.apache.axis plug-in doesn’t export all the classes that the generated code uses. In particular, it doesn’t export the javax.xml.rpc, or javax.xml.namespace packages. I decided on a two-pronged assault on the problem: first, I created a new version of the org.apache.axis package and exported the required packages in it; second, I created a bug report asking for it to be changed. With the change in place, everything works perfectly.
I decided to generalize the problem a little in the bug report. What I’d really like to do is be able to generate a web service directly into a plug-in. If you’re curious, it’s bug #109625.
Strictly speaking, I haven’t actually turned this into an “RCP” application yet. However, my next step is to roll this little collection of plug-ins into another RCP project I have in the works.
[Updated on Sept. 20/05 to fix the title.]
