Archive for November 2006
In a previous post, we discussed the ease of implementation of jws-based web services. In this post, I want to look at the flip side of this argument: deploying wsdd-based web services is more flexible and powerful yet only marginally more complex.
The file server-config.wsdd located in the application’s WEB-INF directory allows the developer to expose a class as a web service. Just like jws-based services, an existing class can easily be retrofitted and exposed as a web service. Unlike jws-based services, the class is compiled at design time (not run time) and can be packaged. But the superiority of this methodology mostly lies in the use of “handler” classes which can be assigned to the request or response flow of the web service. A handler is a class that does pre-processing or post-processing on the web service. A handler might be used to log the service’s activity of maintain state for example.
While a wsdd-based web service is marginally more complex than a jws-based web service, it allows behaviours to be easily added declaratively to the service definition. Developers are encouraged to use wsdd-based web services for any critical or sensitive operation.
Sun Microsystems announced today that it would release Java as open-source under a GPL license. This allows developers to view, fix and expand the Java platform and do so freely as long as the changes are published. This news injects new life into an already thriving platform (see installation base figures below).
In fact considering how successful Java already is, where can it go that it hasn’t gone before? I looked into the Betterdot crystal ball, ;), and this is what I saw… Expect a transition from “Java Anywhere” to “Java Everywhere”. Expect Java in just about all embedded devices from kiosks to mobile devices. Expect most enterprise software to be written in Java or come with a Java API (most likely complemented by a web service back end). The Java ecosystems of free, high-quality enterprise grade applications will continue to grow over the next 24 months with the help of large commercial software vendors like IBM and Sun backing up open source software. Open source is a) good software and b) big business. For companies who have a vested investment in the platform this a very good news and an assurance of continued returns on the Java investment. For others considering core technologies for upcoming development, this is a compelling argument to consider the Java platform.
As a end note, let’s look at the installation base for Java today (figures obtained from Sun Microsystems).
Java is currently installed on:
800 million desktops
1.2 billion phones
1.65 billion smart cards
5 million downloads of Java technology for the enterprise
Axis is Apache’s implementation of SOAP, an XML based object invocation protocol. While SOAP services have been around for some time, what strikes me is how easy and fast it has become to implement a web service using Axis. There are two methods of creating a web service in Axis. The first and by far the fastest is to rename the java “class” containing the business logic you wish to expose from .java to .jws and place this file in the root of the war file. This .jws will be compiled to a .class on first invocation much like .jsp pages are compiled into servlets. Invoking the .jws (programmatic post or even browser get), effectively routes the SOAP request to the SOAP servlet and runs the method specified as a parameter (?method=). That’s it! This is a fast and effective way of exposing a regular class and its methods as a web service. This also allows regular classes to be easily retrofitted/exposed as web services with very little effort. This approach does not yet permit the use of packages although directories are allowed. The second method involves writing a wsdl descriptor for the method which is more involved, more time consuming but arguably more flexible. However I find the ease and speed of the first approach too compelling to pass. In fact, I can’t think of a faster way of exposing business logic as a web service or remote procedure call. Why go with SOAP when you may have an in-house XML over HTTP framework already in place? Any custom solution requires routing and handling code which SOAP elegantly and transparently handles. SOAP and Apache Axis allow the developer to spend less time on the routing and handling of requests and more time focusing on the business logic.
Remote scripting is becoming ubiquitous in the Web2 landscape and offers many possibilities for two way data exchange.