Requires Free Membership to View
When you register, you'll begin receiving targeted emails from my team of award-winning writers. Our goal is to keep you informed on recent service-oriented architecture (SOA) and SOA-related topics such as integration, governance, Web services, Cloud and more.
Hannah Smalltree, Editorial Director
This is not the forum for "in depth" details, but I'll give it a shot.
Keep in mind that a developer may not be, and often is not responsible for building both client and service.
When building a client:
1. Get the WSDL from the service provider. You might do that by calling someone (who'll either send you the WSDL or provide a URL to it) or you might look it up using a registry or repository.
2. Build a client to invoke the service using the WSDL. When using Axis, you can compile the WSDL using wsdl2java (producing a stub), or you can invoke the service using the Call interface – pulling the appropriate bits of information from the WSDL to set the necessary values in the Call object.
3. Run the client.
When building a service:
1. Develop the WSDL: There are two popular approaches – code-first or WSDL-first.
1.a. Code-first: Using Axis, you technically don't need to develop the WSDL – instead you write a class, define your service using WSDD (Axis's deployment descriptor), and deploy it. Axis will generate a WSDL dynamically at runtime. (If you have a very simple class with only primitive parameter types, you don't even need the WSDD – just deploy it using the JWS option.) It's very easy, and many developers prefer this route. Unfortunately, it's not a very good practice, because it leads to tight binding between your interface and implementation, and often the implementation's object model leaks into the interface. It's a bad practice if your object exposes language-specific collections.
1.b. WSDL-first: You're lucky if someone hands you a WSDL and says "build me a service that implements this interface." If not, you need to write one. One popular approach to building a WSDL is to write a Java interface for your service and run java2wsdl. That will generate a WSDL that corresponds to your Java interface. Next customize the WSDL so that it does exactly what you want and it adheres to corporate policies and guidelines. Alternatively, you can use another WSDL as a template or develop the WSDL from scratch. (I strongly encourage you to use a WSDL editing tool that has a "validate" feature – even better if it has a WS-I compliance validator.) After you have the WSDL that you want, run wsdl2java. That will generate a WSDD and a service skeleton. Implement your class using the service skeleton and deploy it using the generated WSDD.
2. Use the WSDD to configure additional features, such as security, session management, logging, etc.
3. Register the service in your corporate registry or repository.
This was first published in December 2006
