Some notes on web services, REST & Fluent Interface. Theoretically we can make use any language to write web service client, & of course that's the exact reason web service was invented offering loose coupling for implementing distributed computing environment for businesses. But there were many requirements (schema definition/validaion, security,performance, service discovery, SLAs,BLAs, language etc..) to achieve high cohesion, hence SOAP, XML, UDDI & WSDL were necessary. I guess for most of integrations these technologies make developer's life un-necessarily tougher & are forced to learn/unlearn these vocabulary.They are all XML-RPC in disguise & may not be much better than the existing binary RPC solutions (RMI,CORBA, COM...). I am leaning towards REST proponents who are arguing that this complexity is not really worth of benefits it offers & is really waste of time, bandwidth & finally money. These are looking similar to EJBs as I am going through this book (considered as first printed book on REST)
If we see the existing web service landscape (I am referring WSDL, SOAP only), most of them are giving SDK for different languages (eBay SDK, Google Data API...) proving that SDK is more important than the WSDL. SDK always beats the SOAP toolkit hands down.

SOAP prevent independent evolution of client & server. For exampleSOAP toolkits provide (Jax-ws,Axis) code generation with strongly typed APIs, even adding new optional parameter, system will break until we generate thte stub again,Which basically diefies the logic of loose coupling.

With REST,HTML forms provide default & hidden variables,Service end point change is effortless, we can have re-directs based on situation & also partition, scale well depending on the requirements.Means don't have redeploy & test specifically for this.

separating reads from writes. SOAP has no inherent support for this, although we can design.
caching GET requests including hardware solutions, Caching @ HTTP always yields better results.
compression: Since REST uses HTTP, you can use compression such as gzip.
No need for additional jars or library
explorability -clicking around a RESTful API in their browser & use right away.
REST architecture serves as the basis for the most biggest and most successful information system the world has ever seen

Cons of REST
security: Though, security considered as weakest area of REST not sure why (HTTPS, authentic)
Tools will make working with SOAP just simple, IDE & tools cannot provide same kind features as SOAP to REST.
(Anyway we had same arguments for using EJB in the past as well)


Here is a sample Java APIs for web service APIs to help out developer community to directly working java instead of WSDL. I noted following points from going through the code.

• Contains 28 methods & 768 lines



• Expects user to update the Source code or use the properties file to inject startup values (Namely username, password, AccountID so on & so forth) & is not easy to pass/change these values @ runtime.



• Uses Exception, RemoteException providing little recovery options from service faults & forcing client code to become ugly, clearing suggesting RuntimeExceptions are better suited here to use.



• One single class for many APIs, making shpping client API size bigger if we want to deal with single API only



• No way to see the SOAP XML files that get handshaked b/w client & server.



• Uses Axis for marshalling/unmarshiling, We have Sun benchmarks suggesting latest jax-ws API/implementaion beat Axis/xfire hands down.



• The API is not fluent (or user friendly) & does not make use latest JDK1.5 APIs



• Uses lot of Array values as input/output params making client code uglier

Before providing my solution for this I do understand that I don't have much knowledge of the context (of client applications) using the APIs. So please be adviced I might have over-looked many issues.

I generated stub code using jax-ws APIs & netbeans. JAX-WS is the successor to JAX-RPC. It requires Java 5.0, and is not backwards-compatible to JAX-RPC.Netbeans has amazing plugins for about everything! I also wrote some wrappers around the campaign service API & here is how client code looke in the JUnit test case. (BTW JUnit4 has amazing features with POJO annotations & I guess this unit testing library is the best testimonial of effective usage of the java annotations.)

Now JDK6 users can turn their normal POJO in to web services and deploy it with ease without getting to deal with different web services stack. Before JDK6 one had to download some webservices toolkit and learn how to use

@Test
public void testGetCampaigns() {

List<Campaign>campaigns = new CampaignServiceTemplate() {
@Override
public YAccount getYAccount() {
return YAccount.builder.userName("uyiui")
.password("test123")
.license("uyiuu7687687gg")
.masterAccountID("988533")
.accountId("2086880350")
.build();
}
}.getCampaigns(13897897l,797897l, 89678l);
Assert.assertNotNull(campaigns);
}

Above code definately looks much cleaner easy to use. It makes use of generics, varargs, SOAPHandler java-ws interceptor,template pattern & fluent interface to make code look simpler & robust by validating all the inputs that takes care of all the issues I listed above sample code.

One task which I wanted to avoid was generating the source using tools Axis/jax-ws, if I want to write some adhoc testing I don't think doing in java make really sense. Ruby, Groovy where dynamic class reference options are amazing solutions here.

For stock quote client Groovy code looks something like this.

import groovyx.net.ws.WSClient
proxy = new WSClient("http://www.webservicex.net/stockquote.asmx?WSDL", this.class.classLoader)
quote = proxy.GetQuote('YHOO')
print quote

We, Java programmers are unable to make use of Groovy APIs like this, we will be the losers. Coding can't be simpler/easier than this :-)

But don't get me wrong, Java has a place & will continue to occupy the major portions of software development as Joshua Bloch says "One thing that makes Java such a pleasure to use is that it is a safe language."

So when we stick to Java,fluent interface or easy to use APIs have lot of importance.A fluent interface is a DSL embedded in a language,it consists of a set of classes that have been organized to allow you to write code that nearly reads as English essay. Beautiful Code is often associated with essay-writing.

Reference:

Immutable objects improves the code reliability.

Joshua bloch discusses about the design consideration

Jax-ws faster than Axis - Benchmarks

Java options for writing web service clients

SoapUI has wonderful set of applications & plugins to make web service testinf very easy task. I tried out their NetBeans plug in , It's simply amazing.SoapUI is a great tool for any developer who wants to test web services to verify that they are working correctly.

Good DZone link explaining functional testing using these APIs. I will update my experience after trying these out.

GoAPI -> Good for searching APIs.
Restas Architecture - "Simpler is better, and REST is generally simpler than SOAP"