Originally posted by thomas Fuchs:
My question is I want to subclass or override some methods in a class that was generated from the wsdl file. How can i do this so that a client will actually be referred to my overloaded class rather than the server side stub ?
As much as many people want it to be,
SOAP web services are not an Object Access or Object Transfer Protocol - this is the reason why the orignal name "Simple object Access Protocol" was dropped. The WSDL is the contract (interface) between the service provider (server) and the service consumer (client). The WSDL describes the accepted XML (SOAP) requests and the provided XML (SOAP) responses. Beyond that the clients are on their own to figure out how they are going to assemble the requests and how they will use the responses. So there is no way that you can influence what object model - if any - is being used on the client side
I know i can just add the code to the generated stub but for those who know .net you can create a class that derives from a generated class & then add basically an annotation [webmethod] ...
Well, for that you don't even need a pre-existing stub. See this
topic for a simple example that uses Java SE 6. The equivalent "annotation" is @WebMethod - however in either case (Java OR .NET) that simply marks the method to be exposed through a web service endpoint on the server - it doesn't mean that the class will now magically appear on the web service client. The classes that appear on the client side are simple object representations of the XML structures found inside the requests and responses described by the resulting WSDL, which often only have a passing resemblance to the classes that exist on the server side. Remember that the exchanged requests and responses are "plain data" - behavior only exists inside the Web methods
on the server.
so i'm not sure what the proper way is in java
You were already on the right track. The fact that the web service is implemented in Java (or .NET, Perl, PHP, etc.) is
supposed to be irrelevant to the web service client. So whenever you need to make a change
for the client you are supposed to update the WSDL - then use your code generation tool of choice to generate a new server stub that you can "hook up" to your service implementation. That is what
Contract First web service development is all about.
You can use whatever objects you want in your server implementation but any objects that appear in the web methods signature will simply have their data sent over the HTTP/SOAP link and it is entirely up to the web service clients to decide what they will do with that data.