Question about expose overloaded session bean method as web service.

[Mellon Sun]

package com.mellon;

import javax.ejb.Stateless;
import javax.jws.WebMethod;
import javax.jws.WebService;

@Stateless
@WebService
public class NewSessionBean implements NewSessionRemote, NewSessionLocal {

@WebMethod(operationName="sayHello")
public String sayHello(String name){
return "Hello, "+name;
}
@WebMethod(operationName="sayHello2")
public String sayHello(String name,String location){
return "Hello, "+name+", welcome to "+location;
}
}

I wrote the EJB like above, everytime I deployed it, I got errors.
If I change the second method name from sayHello to sayHello2, it works well. Is that operationName attribute used to solve this?

[Mellon Sun]

http://msdn.microsoft.com/en-us/library/byxd99hx(VS.71).aspx

MessageName
The MessageName property of the WebMethod attribute enables the XML Web service to uniquely identify overloaded methods using an alias. Unless otherwise specified, the default value is the method name. When specifying the MessageName, the resulting SOAP messages will reflect this name instead of the actual method name. For more information, see WebMethodAttribute.MessageName Property.

I supposed the operationName in Java acts the same as MessageName in .Net.

[Peer Reynders]

WS-I Basic Profile 1.1

4.5.3 Distinctive Operations
Operation name overloading in a wsdl:portType is disallowed by the Profile.
R2304 A wsdl:portType in a DESCRIPTION MUST have operations with distinct values for their name attributes.

So even though WSDL 1.1 allows operation overloading (WSDL 2.0 doesn't by the way) the Basic Profile disallows it for interoperable web services.

So, Method Overloading

is a commonly accepted practice in Java

but is strictly disallowed in interoperable SOAP web services

"Interoperable" does not mean "supports all the features and idioms of my favorite programming language" (which may not be supported by somebody else's favorite programming langauge) ...

Sometimes the table is turned. WSDL supports multiple return values, Java has to create a container object for multiple return values. WSDL supports OUT parameters, Java has to use javax.xml.ws.Holder<T> to emulate that.
[ November 19, 2008: Message edited by: Peer Reynders ]

[Mellon Sun]

Thanks for your help. I get it.

[Chintan Rajyaguru]

Originally posted by Peer Reynders:

So even though WSDL 1.1 allows operation overloading (WSDL 2.0 doesn't by the way) the Basic Profile disallows it for interoperable web services.

So, BP (and WSDL 2.0 for that matter) disallows overloaded operations. What I don't understand is why should Java implementation disallow it (which is where the original question came from). They figured out holder classes, I am sure they can figure out a way to map overloaded operations to different operation names in wsdl and workout JAXB stuff with respect to request and response types. May be I am missing something...

[Peer Reynders]

Originally posted by Chintan Rajyaguru:
What I don't understand is why should Java implementation disallow it (which is where the original question came from).

They do allow it as you can see in the original post - as long you supply the alternate WSDL operation name yourself.

They wanted "meaningful" names in the WSDL - that is why they didn't automate it. You obviously have never seen the awful names that a C++ compiler name mangling algorithm comes up with in order to support overloads in an environment (the linker) that doesn't support them.

[Chintan Rajyaguru]

The posted code will generate the following exception even with separate names for operationName attributes:

com.sun.tools.ws.processor.modeler.ModelerException: [failed to localize] Request wrapper bean names must be unique and must not clash with other generated classes.

This is what I meant when I raised the question, "Why Java implementations don't allow it..." BTW, I got the same error in multiple toolings.

Ideally, specifying operationName attribute in the @WebMethod annotation should signal the code generation tool to assign separate bean names for request wrapper classes.

Although I haven't tried it, I think this can be fixed using JAXB compiler customizations (which is what I believe tools should have done).

[Peer Reynders]

Hmmm ... I misunderstood that part of the original post. JSR-181 Web Services Metadata for the Java Platform shows in "4.4.3 Example" operationName being used on three overloaded "ping" methods on a "PingService" class which suggests to me that it is supposed to work. PingService isn't an EJB but still ...

[Chintan Rajyaguru]

Aah. This is because the example you referred to uses RPC style. The example posted here and the one I had used Document style, which didn't allow overloading like this. Again, since the default is Document wrapped, it should have worked with different values in operationName attributes.

[Peer Reynders]

Originally posted by Chintan Rajyaguru:
Again, since the default is Document wrapped, it should have worked with different values in operationName attributes.

Especially considering that the wrapped document/literal convention serves the same function as RPC/literal. Personally I am finding that convention rather "dishonest" - you shouldn't be able to use it and claim to have a "document-oriented" web service. You are pretending to be on a "document-oriented" diet but having your RPC cake while nobody else is looking.