Problem solve Get help with specific problems with your technologies, process and projects.

End-to-end flow

Anne Thomas Manes discusses in detail the complete end-to-end flow for building both client and service.

I am not new to Web services, using for 3 months or so, but still I am not clear about the end-to-end flow, from getting WSDL files to implementing the Web service to accessing the Web service from Client. I am using Tomcat/Axis, SOAP, XML/HTTP. Can you provide me in depth details of complete flow?

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.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.