How to generate a correct WSDL for a service with overloaded methods ?

[Kumar Raja]

Hello All,

I was reading through the objective "Endpoint Design and Architecture" of the certification from Mikilai's notes and I found a note on what to use when a service is having overloaded methods. The author recommends to use RPC style or Document Style - UnWrapped.

So I coded my class as follows

package org.learning.ws;

import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;

@WebService (
		name = "CalculatorPortType",
		serviceName = "CalculatorService",
		portName = "CalculatorPort",
		targetNamespace = "http://ws.learning.org/calculator"
		     )
@SOAPBinding(
		style = SOAPBinding.Style.RPC,
		use = SOAPBinding.Use.LITERAL
		    )

public class Calculator {
	public void method(int a, int b) throws Exception{
		
	}
	
	public void method(int a) throws Exception{
		
	}
}
       

Before I tried RPC/Literal style, I tried to use DOCUMENT/LITERAL/BARE, but WSGEN scolded me not to use BARE, as it has more than one parameter bound to body. Which I did not understand quite well. I knew that I had this question before and would refer back there.

But when I used RPC/LITERAL, it did generate WSDL, but with errors.

Because I have two methods with same name

 <message name="method">
    <part name="arg0" type="xsd:int"/>
    <part name="arg1" type="xsd:int"/>
  </message>
  <message name="methodResponse"/>
  <message name="Exception">
    <part name="fault" element="tns:Exception"/>
  </message>
  <message name="method">  [b]// It points an error here[/b]
    <part name="arg0" type="xsd:int"/>
  </message>
  <message name="methodResponse"/>
...................................
..................................

Obviously the operation bindings also refer to same operation name. I believe, unless I fix this error in WSDL, I may not be able to use this to generate client artifacts. But If I start renaming the messages, operations to make them unique, it would no longer correspond to my implementation...

So what needs to be done here, to make sure I can still use overloaded methods and generate a good WSDL with out any later corrections.

One more question which I wanted to include regarding the Document style vs Procedural style (This has been questioned and answered multiple times), but unfortunately it is still not clear to me.

I read through the post published in IBM regarding "which WSDL to use" and I understood how it differs for WSDL and SOAP messages. But my understanding is, it has nothing to do with how the service is written or how the service is invoked. For both RPC or Document, you can invoke a service either through artifacts or through Dynamic invocation using Dispatch. Similarly, a service can be written either as SEI or by implementing Provider. This does not change with RPC/DOCUMENT style.

In the Ivan's notes of the section 12.1 (Endpoint Design and Architecture), it is mentioned under Procedural style

To avoid the complexity of creating and manipulating XML documents.
Requests and responses will still contain XML data, but it will be transformed to Java
objects by, for instance, JAXB. The client and server applications thus do not need to be
aware of the representation (XML) use to pass the Java objects over the wire.

I tried couple of examples where client invokes the service using artifacts which were generated for both RPC and DOCUMENT style WSDL. In either case, I really do not deal with raw XML. So in either case, I'm invoking the method as a plain method and it works. Then why would this be a difference between Procedural and Document style.

A synchronous transport protocol, like HTTP, is used.

The above point is mentioned for Procedural style. We saw examples where we can invoke service Asynch using polling and callback, which are examples of Document style. But is not the underlying protocol HTTP.

I'm totally confused on this part. Did the author mean to differentiate between JAX-RPC vs JAX-WS? Please show me some light.

[Ivan Krizsan]

Hi!
A quick answer:
The WS-I Basic Profile 1.1 disallows overloaded operations in a WSDL:
http://www.ws-i.org/Profiles/BasicProfile-1.1.html#Distinctive_Operations
Best wishes!

[Kumar Raja]

Ivan Krizsan wrote:Hi!
A quick answer:
The WS-I Basic Profile 1.1 disallows overloaded operations in a WSDL:
http://www.ws-i.org/Profiles/BasicProfile-1.1.html#Distinctive_Operations
Best wishes!

Thanks Ivan.

Could you also please look into my other part of the question given below
"
One more question which I wanted to include regarding the Document style vs Procedural style (This has been questioned and answered multiple times), but unfortunately it is still not clear to me.

I read through the post published in IBM regarding "which WSDL to use" and I understood how it differs for WSDL and SOAP messages. But my understanding is, it has nothing to do with how the service is written or how the service is invoked. For both RPC or Document, you can invoke a service either through artifacts or through Dynamic invocation using Dispatch. Similarly, a service can be written either as SEI or by implementing Provider. This does not change with RPC/DOCUMENT style.

In the Ivan's notes of the section 12.1 (Endpoint Design and Architecture), it is mentioned under Procedural style


To avoid the complexity of creating and manipulating XML documents.
Requests and responses will still contain XML data, but it will be transformed to Java
objects by, for instance, JAXB. The client and server applications thus do not need to be
aware of the representation (XML) use to pass the Java objects over the wire.



I tried couple of examples where client invokes the service using artifacts which were generated for both RPC and DOCUMENT style WSDL. In either case, I really do not deal with raw XML. So in either case, I'm invoking the method as a plain method and it works. Then why would this be a difference between Procedural and Document style.


A synchronous transport protocol, like HTTP, is used.



The above point is mentioned for Procedural style. We saw examples where we can invoke service Asynch using polling and callback, which are examples of Document style. But is not the underlying protocol HTTP.

I'm totally confused on this part. Did the author mean to differentiate between JAX-RPC vs JAX-WS? Please show me some light.
"

[Ivan Krizsan]

Hi!
Admitted, my study notes does not contain any really good example of a document based service.
I want to attempt to clarify with the following example:
Imagine an order that you can place at a shopping website. The order is a piece of data made up by other, smaller, piece of data like:
- Personal information about the person ordering.
- Billing address.
- Delivery address.
- Items ordered.
- Payment information.
- Etc.

The order can be represented as a document and the format may be XML.
The company may have different services that performs different duties related to an order, for instance:
- Person verification service.
Verifies that the person ordering is allowed to order and is not on some kind of blacklist etc.
- Payment verification service.
Verifies that the means of payment is valid for the order. May verify validity of credit cards, availability of funds for advance payments etc.
- Inventory service.
Verifies that the items in the order is in stock and ready for delivery.
- Etc.

All the different services accepts an order document as a parameter. They are thus document-based services.
Compare this to, lets say, an addition service that takes two numbers, add them together and return a third number. Such a service is perhaps more likely to be implemented as a RPC service.
Enough for today - hope this clears your doubts!
Best wishes!

[Dan Drillich]

Kumar Raja wrote:

I read through the post published in IBM regarding "which WSDL to use" and I understood how it differs for WSDL and SOAP messages. But my understanding is, it has nothing to do with how the service is written or how the service is invoked. For both RPC or Document, you can invoke a service either through artifacts or through Dynamic invocation using Dispatch. Similarly, a service can be written either as SEI or by implementing Provider. This does not change with RPC/DOCUMENT style.

I agree with you and Which style of WSDL should I use? makes it very clear (after reading it multiple times ) -

The terminology here is very unfortunate: RPC versus document. These terms imply that the RPC style should be used for RPC programming models and that the document style should be used for document or messaging programming models. That is not the case at all. The style has nothing to do with a programming model . It merely dictates how to translate a WSDL binding to a SOAP message. Nothing more. You can use either style with any programming model.

So, the style has nothing to do with a programming model. It's an internal configuration issue that probably got a bit hyped up.

Regards,
Dan

[Ivan Krizsan]

Hi!
Some thoughts that came to me when reading this thread. Not really answers to anything:
Something I feel is often overlooked in discussions like this is the data model.

RPC Style
With an RPC-style web service, you mostly have operations that take primitive data types like integer, string etc as parameters and produce a result.
This is more suitable for fine grained services.
The has the advantage that the datatypes you expose can be understood by all clients, but the drawback that if there is a new version of the operation that needs, for instance, additional parameters then the clients need to upgrade as the service changes (unless of course you publish both the old and the new version of the service at the same time).

Document Style
With a Document-style web service the service can, as in my previous post, operate on larger, more complex data structures.
This may be more suitable for coarse-grained services.
Advantages are that the interface of the service is less likely to change, even if there are changes in the parameter data structure.
Example: Additional payment information is added to orders. This change, most likely, only affects, for instance, the payment verification service but is less likely to affect other services processing other aspects of the order.
Admitted, it is not entirely fair to compare coarse grained services operating on complex data structures with fine grained service operating on primitives.
Drawbacks include the fact that you expose a complex data structure which may, to some extend, expose the inner workings of the service. If the inner workings change, the changes are more likely to cause ripples that affect clients of the service. Versioning issues are likely to occur as the service evolves over time.

As with many other choices I feel that it is not a question about selecting one or the other, instead it is a question about selecting the most appropriate for the situation at hand. Both RPC and Document style are justifiable and usable. Also there are no simple solution to, for instance, service integration issues. I rather feel it is about striking a balance between different aspects.
Best wishes!

[Kumar Raja]

I think, after reading this thread and discussing with you guys, I feel more comfortable with RPC and Document style. I will have this bookmarked as a reference point for any future clarification.


You guys rock... thank you Ivan/Dan.