Thanks a lot jeff. We will try to implement ur suggestion of having unique names. Thanks once again, Raghavan.V. -----Original Message----- From: Walker, Jeff [mailto:[EMAIL PROTECTED] Sent: Friday, September 28, 2007 7:30 PM To: [email protected] Subject: [NEWSENDER] - RE: [NEWSENDER] - RE: Exposing JAVA Overloaded methods as service - Message is from an unknown sender - Message is from an unknown sender Hi Raghavan, again, the more typical solution from the web services community is to simply change operation names and then you can leave your parameters alone. (i strongly recommend this). But there are a few things about your approach you might want to think about. Do's: 1. Move from RPC to Doc/lit web services. (Doc/lit-wrapped is even better since it works best with .NET). 2. When writing a web service interface, don't think of sending fields like username and status strings. think in terms of sending and receiving a message. In that message, there is one object. that object maps to a compexType in schema. That complexType can then extend another complexType (single inheritance). Each of these types contain fields. That is where username and status get defined as xsd:string types. Don'ts: 1. Don't pass language specific objects (like the Connection class in Java) as parameters in web service calls. There is no way in soap or wsdl to enforce that only Java clients call the appropriate Java-oriented method on the interface. All operations should be callable by all clients at all times. (This forces the web services interface to be very generic). 2. Don't overload methods. Just have a second method with a unique name. If you still insist on sending the Connection object, might I suggest the names getmessages(userrname, status0 and getMessagesWithConnection(username, status, Connection). My previous suggestions b) and c) were mere technical sleigh-of-hand XML Schema approaches to simulate overloaded methods. ------------------------------------------------------------------------ ----------- Still, both b) and c) require an XML Schema to be constructed, and then move to Doc/Lit wrapped web service format. Doc/Lit wrapped requires that you pass in just one object in both the request and the response. That object (a complexType defiend in the schema) then contains the fields and any other objects that you require. See: <http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/> http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/ This article is an excellent summary of what I mean. The complexType will look something like: <xs:complexType name="GetMessages"> <xs:sequence> <xs:element name="username" type="xsd:string"/> <xs:element name="status" type="xs:string"/> <xs:element name="connection" type="tns:Connection" minOccurs="0"/> </xs:sequence> </xs:complexType> <xs:complexType name="Connection"> <xs:sequence> <!-- in here, you need to add every field that you need as a minimum to construct the Connection object on the server. --> </xs:sequence> </xs:complexType> Notice the "connection" field has minoccurs="0". This makes it optional. So, a single operation exists in the web service now, called GetMessages. It takes a single object as a parameter, that is also called GetMessages (see above article as to why the operation and parameter name is the same). That object is based on a complexType in schema called "GetMessages" and it has three fields, of which two are required and the 3rd is optional. The 3rd field is another complexType called "Connection", that contains all of the data you need to create a Java Connection object on the server. Suggestion c). is another way to do it in Schema. Instead of having an optional field, have a base type with the two required fields. Extend that type with another type that adds in the connection fields. When you declare the operation in the wsdl, refer to the base class. When the client actually calls it, they can pass in either an instance of the base type, with just username and status, or an instance of the subclass, which contains username, status and connection fields. In the service implementation class, you can use instanceof operator to determine if you got a sublass or not. Hence, type derivation. -jeff
_____ From: Raghavan [mailto:[EMAIL PROTECTED] Sent: Friday, September 28, 2007 12:15 AM To: [email protected] Subject: RE: [NEWSENDER] - RE: Exposing JAVA Overloaded methods as service - Message is from an unknown sender Importance: High Thanks Jeff for the solution. The reason for the overloaded methods is that the service can be called from either a .NET client or a java web service. In the case of .NET client I could'nt pass the SQL connection but where as I could pass a connection from a java web service. That's why we opted for the overload method. This is the first time we are using web service. So it would be very helpful, if you could elaborate the points B & C.. How can I make the parameter optional in schema and where can I find info abt type derivation? Thanks in advance Rgds, Raghavan.V. -----Original Message----- From: Walker, Jeff [mailto:[EMAIL PROTECTED] Sent: Thursday, September 27, 2007 6:22 PM To: [email protected] Subject: [NEWSENDER] - RE: Exposing JAVA Overloaded methods as service - Message is from an unknown sender You can't use overloaded methods using soap 1.2. They are also not condoned by the WSI, for interoperability reasons. (A previous poster claims to have it working, search for an email from Bhojraj, Santosh [EMAIL PROTECTED] on 08-10-07. He used wsdl 1.1 and doc/lit web service format). I would suggest you either: a). change the operation names to be unique b). keep the 2nd version and make the connection paramater optional in schema. c). get smarter about the parameters passed in (ie. you could use type derivation). (The standard accepted practice is to change the op names to be unique). -jeff _____ From: Raghavan [mailto:[EMAIL PROTECTED] Sent: Thursday, September 27, 2007 1:38 AM To: [email protected] Subject: Exposing JAVA Overloaded methods as service Importance: High Hi All, I have created a class which has two over loaded methods. The method signature is as follows public String getMessages(String username, String status) The overloaded method signature is as follows public String getMessages(String username, String status,Connection con) where the Connection is a SQL connection If I expose this class as a service, Im able to view only one method in the WSDL. The other overloaded method is not viewable in the WSDL. Can some one help me out with this.. Rgds, Raghavan.V. ------------------------------------------------------------------------ ----------------------------------------------- Disclaimer : Confidentiality Notice This communication and the information it contains:- (a) Is intended for the person(s) or organisation(s) named above and for no other person(s) or organisation(s). (b) May be confidential, legally privileged and protected in law. Unauthorised use, copying or disclosure of any of it may be unlawful.If you have received this communication in error, please contact us immediately by email at <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED] ------------------------------------------------------------------------ -----------------------------
