You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Raghavan <ra...@solutionnet.net> on 2007/09/28 06:14:34 UTC
RE: [NEWSENDER] - RE: Exposing JAVA Overloaded methods as service - Message is from an unknown sender
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:Jeff.Walker@fmr.com]
Sent: Thursday, September 27, 2007 6:22 PM
To: axis-user@ws.apache.org
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
[Santosh_Bhojraj@ustrust.com] 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:raghavan@solutionnet.net]
Sent: Thursday, September 27, 2007 1:38 AM
To: axis-user@ws.apache.org
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 <ma...@solutionnet.net>
postmaster@solutionnet.net.
------------------------------------------------------------------------
-----------------------------
RE: [NEWSENDER] - RE: [NEWSENDER] - RE: Exposing JAVA Overloaded methods as service - Message is from an unknown sender - Message is from an unknown sender
Posted by Raghavan <ra...@solutionnet.net>.
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:Jeff.Walker@fmr.com]
Sent: Friday, September 28, 2007 7:30 PM
To: axis-user@ws.apache.org
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:raghavan@solutionnet.net]
Sent: Friday, September 28, 2007 12:15 AM
To: axis-user@ws.apache.org
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:Jeff.Walker@fmr.com]
Sent: Thursday, September 27, 2007 6:22 PM
To: axis-user@ws.apache.org
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
[Santosh_Bhojraj@ustrust.com] 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:raghavan@solutionnet.net]
Sent: Thursday, September 27, 2007 1:38 AM
To: axis-user@ws.apache.org
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 <ma...@solutionnet.net>
postmaster@solutionnet.net.
------------------------------------------------------------------------
-----------------------------
RE: [NEWSENDER] - RE: Exposing JAVA Overloaded methods as service - Message is from an unknown sender
Posted by "Walker, Jeff" <Je...@fmr.com>.
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:raghavan@solutionnet.net]
Sent: Friday, September 28, 2007 12:15 AM
To: axis-user@ws.apache.org
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:Jeff.Walker@fmr.com]
Sent: Thursday, September 27, 2007 6:22 PM
To: axis-user@ws.apache.org
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 [Santosh_Bhojraj@ustrust.com] 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:raghavan@solutionnet.net]
Sent: Thursday, September 27, 2007 1:38 AM
To: axis-user@ws.apache.org
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 postmaster@solutionnet.net
<ma...@solutionnet.net> .
------------------------------------------------------------------------
-----------------------------