Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Clean up your wire protocol with SOAP, Part 4

Dynamic proxies make Apache SOAP client development easy

By Tarak Modi, JavaWorld.com, 07/06/01

I will now introduce you to a framework based on these classes that will make the creation of SOAP (Simple Object Access Protocol) clients easy and intuitive. SOAP is a wire protocol that uses XML for data encoding. While building SOAP services in Parts 2 and 3 of this series, you discovered that client developers end up doing a lot of extra work that they wouldn't normally have to do. If you need a refresher, take a look at the SOAP service code in Part 2. See how insignificant the SOAP code is when compared to the client code? The simple services created in earlier articles in this series demonstrate that SOAP-based services only contain code that they would have had irrespective of SOAP. The service developers have little extra code to produce, while the client developers have much more work to complete on their end. The classes introduced in this article will alleviate most of that work.

Read the whole series on SOAP:

• Part 1: An introduction to SOAP basics
• Part 2: Use Apache SOAP to create SOAP-based applications
• Part 3: Create SOAP services in Apache SOAP with JavaScript
• Part 4: Dynamic proxies make Apache SOAP client development easy

Introducing the SOAP Proxy class

First, let me show you what the client code would look like using the framework that you'll create in this article:

package hello;
import soapproxy.*;
public class Client
{
   public static void main(String[] args)
   {
       try
             {
                 Class[] interfaces = new Class[] {hello.Hello.class};
                 Hello hello = 
(Hello)(Proxy.newInstance("urn:Hello",interfaces));
                 // Invoke the sayHelloTo method that takes a String 
name.
                 System.out.println(hello.sayHelloTo("John"));
                 // Invoke the sayHelloTo method that takes a Name 
JavaBean.          
                 Name theName = new Name();
                 theName.setName("Mala");
                 System.out.println(hello.sayHelloTo(theName));
             }
             catch(Exception e)
             {
                 e.printStackTrace();
             }       
    }
}

Now, I might be a bit biased, but I think the client code above looks much better than the client code in Parts 2 and 3. It's okay if you don't follow the code right now. Believe me, you will by the end of this section.

To understand the client code, you must delve deeper into the SOAP Proxy class, which is in the soapproxy package, available in the Proxy.java file (see Resources below). That class has a private constructor, which means that a Proxy instance cannot be created from outside Proxy. The only way to retrieve a new Proxy instance is through the static newInstance() method. That method takes two parameters: the SOAP service's object ID and an array of interface names that this proxy will implement. The object ID parameter is straightforward, but what are the interface names, and where did they come from? The SOAP service developer defines these interfaces by simply lumping together all the methods that a client can invoke on the service into a Java interface. Pretty easy, no?