Web Services: Just Say No (for Now)
Just got back from JavaOne. The show was interesting this year primarily because there was nothing interesting this year. I suppose that’s what happens when a technology becomes mainstream. To be honest, I can live with less hype, fewer overblown and useless technologies, and more performance speed-ups and bug fixes. No news is sometimes good news, indeed.
I suppose that the one interesting technology discussed this year is “web services,” though not because I expect anyone to actually build a successful web service as hyped by both Microsoft and Sun. The official story is that a “web service” provider in Poughkeepsie sells the local weather; you look up the service in a public “yellow pages” directory (using UDDI as the protocol). You then download a description of what the remote-procedure-call interface to the service looks like (in WSDL format) and then automatically build a stub that makes the call over the wire (using the SOAP protocol). The remote call returns the weather somehow.
This pie-in-the-sky scenario begs a lot of questions, though. What standard formats will you use to request and receive the weather? How will you pay for the service? (We’ve been unsuccessfully trying to solve the micropayment problem for ten years now.) How do you know that you can trust the service provider? What recourse do you have if the information is incorrect and you lose money as a consequence? How do you guarantee that the service that you’re connecting to is actually the service that you think it is, and how does the service provider guarantee that you’re who you say you are before they send you their valuable information? How do you guarantee that the entire transaction is confidential? (You might be able to get confidentiality by using SSL or HTTPS, but only if you have a direct connection between the service and the customer.) I hope you’re beginning to see the problem. Some of these issues are being addressed by “emerging standards,” but who knows when they’ll come out of hiding. In any event, the problems are nowhere near to being fixed now.
On the bright side, Sun is, horror of horrors, actually supporting UDDI/WSDL/SOAP — the web technology of the evil empire. In practice, this adoption means that you can painlessly expose Java remote procedure calls on your server to a client application built using Visual Basic, C#, or whatever language Microsoft is pushing this week as a Java killer.
Interoperability has both good and bad sides, though. Certainly, it’s a good thing for Java servers running on real operating systems like AS/400, Linux, or Solaris to be able to communicate with clients running on some flavor of Windows. (Okay, Allen, tell us what you really think about Microsoft operating systems.) On the other hand, all this interoperability is achieved by using HTTP tunneling. Port 80, on which web servers run, is often the only hole open in a corporate firewall.
Believe me, HTTP tunneling is not a good thing. Yes! You too can get around that pesky firewall and single handedly exploit potential security holes by calling server-side procedures that can do everything from trashing a database to bringing down a whole network! Remember that great ad from the Olympics where a cute seven-year-old Japanese girl named Suki hacks into an automobile manufacturing plant and paints her name on the side of a car? If you don’t think that web-service security holes are an issue, you’re looking at your own future. Any corporation that would permit its programmers to expose a security hole as massive as this one in order to create a web service deserves what’s coming to it. There are, of course, fixes for all of the problems that arise when you expose public interfaces to your enterprise, but security is not very well understood. And though Sun and Microsoft both have good people that understand the issues thoroughly, the public (that’s you and me) isn’t screaming for it loudly enough, so security is pretty low priority — a sorry state.
So, for the time being, we’re back to the usual solution: either fix fundamental architectural problems by kludging a nonstandard solution into our own code, or blithely go along as if the problem doesn’t exist and let some seven-year-old hacker bring down the enterprise. On the other hand — and I suppose this is the point of this editorial — if you know that the problems exist, you can start screaming for a solution. Who knows, given enough noise, one might actually appear.
Allen Holub
Senior Editor