Re: request always calls the first operation defined in server-config.wsdd

2006-08-16 Thread Richard Jones 

Hi Anne,

Sorry for my slow response - I wanted to spend some time playing with 
the settings and code to see if I could make some headway.


I have, now, two solutions to this particular problem, which I'll detail 
here for the purposes of list archive:


1) Switching from doc/lit to rpc/lit and rebuilding client and server 
code with WSDL2Java immediately solves the problem.


This is done by switching/inserting 'style=rpc' into the binding 
declaration:


soap:binding transport=http://schemas.xmlsoap.org/soap/http; 
style=rpc /


and leaving 'use=literal' in the soap:body declaration.

I had not understood that signature in the frame of a web service is 
defined by the body, and that in doc/lit form that this signature is 
different to the way that signature is traditionally defined in OOP.  It 
appears that using rpc/lit recovers the more traditional definition of 
signature.


2) The operation that is called can be specified as a soapAction and 
passed in the HTTP header in doc/lit form.  My WSDL did not define a 
default soapAction, but the addition of the relevant attribute, along 
with a rebuild of all the client and server code does the job.  So here 
is a snippet from the WSDL which uses doc/lit, but which can distinguish 
between different operations at the end of the service while using the 
same soap body:


soap:binding transport=http://schemas.xmlsoap.org/soap/http; 
style=document /

wsdl:operation name=RequestFileDetails
  soap:operation soapAction=RequestFileDetails/
wsdl:input
  soap:body use=literal /
/wsdl:input
wsdl:output
  soap:body use=literal /
/wsdl:output
/wsdl:operation


According to your WSDL, you have five request messages that have
identical signatures:
- ArticleUpdateNotificationRequest
- UnsetLicenseRequest
- ViewLicenseRequest
- LicenseStatusRequest
- RequestFileDetailsRequest

A SOAP message signature is determined by the child element of the
soap:Body. When using document style, that message signature element
is the element referenced in the wsdl:part definition.


This is what scuppered me.  In doc/lit, the message names are basically 
irrelevant unless you specify a soapAction.  I would say this is very 
counter intuitive, since the traditional definition of the signature 
would include at least the operation name, as well as the parameters.



But you have four other request messages that look exactly the same.
There is absolutely no way for Axis to determine which operation you
want to invoke, therefore it always invokes the first operation.  So
as I said in my first response, you must define unique signatures for
each operation -- that means that each operation request message must
reference a unique element name in its message part.


Although there actually is a way for Axis to determine which operation 
you want to invoke, which is to do exactly what it does do when you 
specify a soapAction, and look in the HTTP headers.



I recommend that you define a type called singleGuidType and then
define five separate elements, each with a name corresponding to the
method name, e.g.:

xsd:complexType name=singleGuidType
  xsd:sequence
  xsd:element maxOccurs=1 minOccurs=1 name=guid 
type=xsd:string/

  /xsd:sequence
/xsd:complexType

xsd:element name=ArticleUpdateNotification type=singleGuidType/

wsdl:message name=ArticleUpdateNotificationRequest
wsdl:part element=tns:ArticleUpdateNotification
  name=body/
/wsdl:message


I think this is overly complicated, and misses the crux of the problem, 
since the addition of the relevant soapAction did the job.


The problem that I encountered was due to a number of factors: first 
(and foremost), I was fairly clueless about how the deep internals of 
Axis worked with regard to mapping requests onto operations; second, 
that doc/lit when implemented using axis does not behave as you might 
expect (i.e. in this situation, it would probably make more sense for 
WSDL2Java to throw an error if no soapAction is defined, or at least 
generate a warning); and third that Eclipse web tools doesn't enforce, 
or recommend the addition of the relevant soapAction in the UI.


Anyway, I don't want to be a bad workman blaming his tools, so really 
it's down to me not understanding doc/lit fully before using it. 
Hopefully this post will help other people who get confused about the 
same thing ;)


Thanks for all your help,

Richard


 I am starting to really get to grips with my web services now, with 
much

 thanks to Axis.  This morning, though, I have encountered a problem
 which I can't work out whether is my fault (likely) or a potential
 problem.

 I have two requests defined (in the scope of this problem):

 public void requestFileDetails(String guid)
throws ServiceException, RemoteException
 {
// make the request
SpiralTestSoapService service = getService();
SingleGUID sguid = new SingleGUID(guid);
RequestFileDetailsResponse response =

Re: request always calls the first operation defined in server-config.wsdd

2006-08-16 Thread Anne Thomas Manes 

Richard,

Although adding a SOAPAction parameter will solve your problem with
Axis2, this solution may not work with other systems, and therefore is
not a good practice to adopt. In addition, the SOAPAction parameter is
being deprecated in SOAP 1.2. (It is being replaced by the Action
parameter in WS-Addressing.)

See Section 4.7.6 of the WS-I Basic Profile [1] for guidance on how to
define unique message signatures. The profile requires that you rely
only on the on-the-wire message signature, and that you not rely on
SOAPAction.

I think the reason it doesn't feel intuitive to you is that you're
thinking in terms of the Java method signature rather than on-the-wire
signature. And you're also thinking of Document style as something
that's basically the same as RPC style. When using RPC style, you are
sending a set of parameters (defined by their types). But when you are
using Document style, you are sending a document (an element). Axis2
can automatically bind the element to a Java object for you, but it
really helps if you switch your thinking to a message-oriented
perspective.

The reason why switching to RPC style works is that RPC style will
automatically generate a wrapper element around your input parameters.
That wrapper element has the same name as your operation, and
therefore provides a unique signature. When using RPC style, you can
specify multiple message parts, because each part represents a
parameter, and all the parameters get turned into child elements of
the wrapper element. (When using Document style, your message can
contain at most one message part.)

But note that you can't simply change the style attribute from
document to rpc and expect it to work. (If it does, then that's a
bug, so please file a JIRA.) In order to switch to RPC style, you must
change the message parts and have them reference types rather than
elements, and you must add a namespace attribute to the soap:body
definition to the binding.

Here's an example of the pertinent bits when using Document style:

 xsd:element name=getFile type=simpleGuidType/

 wsdl:message name=getFileRequest
  w:part name=request element=getFile/
 /wsdl:message

 wsdl:operation name=getFile
  soap:operation style=document
soapAction=urn:example:getFile /
  wsdl:input
  soap:body use=literal /
  /wsdl:input
  ...
  /wsdl:operation

And here's the pertinent bits for an RPC style service:

 xsd:complexType name=simpleGuidType
   
 /xsd:complexType

 wsdl:message name=getFileRequest
  w:part name=simpleGUID type=simpleGuidType/
 /wsdl:message

 wsdl:operation name=getFile
  soap:operation style=getFile
soapAction=urn:example:service:getFile /
  wsdl:input
  soap:body use=literal namespace=urn:example:service/
  /wsdl:input
  ...
  /wsdl:operation

If switching to RPC style solves your problem, then go with it. But I
strongly encourage you not to get in the habot of relying on
SOAPAction to route your message. You should follow the advice given
in the WS-I Basic Profile and define a unique on-the-wire signature.

There's a WSDL convention for document style known as wrapped, and
this is what I always recommend. I've written up a description of the
wrapped convention in my blog. [2] The wrapped convention supports a
programming model for document style that's essentially identical to
RPC style. When using the wrapped style, you define wrapper elements
for your input parameters (essentially what RPC style does for you
automatically), and you reference these wrapper elements from your
message parts. Most SOAP toolkits can automatically wrap and unwrap
the parameters for you so that you can use an RPC-style method
invocation. The developers are building support for the wrapped
convention as we type.

[1] http://www.ws-i.org/Profiles/BasicProfile-1.1.html#Operation_Signatures
[2] http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html

Anne

On 8/16/06, Richard Jones [EMAIL PROTECTED] wrote:

Hi Anne,

Sorry for my slow response - I wanted to spend some time playing with
the settings and code to see if I could make some headway.

I have, now, two solutions to this particular problem, which I'll detail
here for the purposes of list archive:

1) Switching from doc/lit to rpc/lit and rebuilding client and server
code with WSDL2Java immediately solves the problem.

This is done by switching/inserting 'style=rpc' into the binding
declaration:

soap:binding transport=http://schemas.xmlsoap.org/soap/http;
style=rpc /

and leaving 'use=literal' in the soap:body declaration.

I had not understood that signature in the frame of a web service is
defined by the body, and that in doc/lit form that this signature is
different to the way that signature is traditionally defined in OOP.  It

Re: request always calls the first operation defined in server-config.wsdd

2006-08-14 Thread Richard Jones 

Hi Anne,


Please post the WSDL.


Please find attached.  This was written in Eclipse using the Web Tools 
plugin.


Thanks for your help,

Richard


Hi Folks,

I am starting to really get to grips with my web services now, with much
thanks to Axis.  This morning, though, I have encountered a problem
which I can't work out whether is my fault (likely) or a potential 
problem.


I have two requests defined (in the scope of this problem):

public void requestFileDetails(String guid)
   throws ServiceException, RemoteException
{
   // make the request
   SpiralTestSoapService service = getService();
   SingleGUID sguid = new SingleGUID(guid);
   RequestFileDetailsResponse response =
 service.requestFileDetails(sguid);
}

public void articleUpdateNotification(String guid)
   throws ServiceException, RemoteException
{
   // make the request
   SpiralTestSoapService service = getService();
   SingleGUID sguid = new SingleGUID(guid);
   service.articleUpdateNotification(sguid);
}

these in turn call the relevant operations on the port type (The
xxx_BindingImpl class).

When either of the above methods are called in the client, the server
/always/ processes the request to requestFileDetails.  I discovered
that I could fix this so that it always processed the request to
articleUpdateNotification by reversing the order that these two
operations are specified in the server-config.wsdd:

operation name=articleUpdateNotification
 qname=ArticleUpdateNotification mep=oneway 
   parameter qname=pns:SingleGUID
   xmlns:pns=http://[...]/SpiralWebService/; type=tns:SingleGUID
   xmlns:tns=http://[...]/SpiralWebService//
/operation
operation name=requestFileDetails qname=RequestFileDetails
 returnQName=retNS:RequestFileDetailsResponse
 xmlns:retNS=http://[...]/SpiralWebService/;
 returnType=rtns:RequestFileDetailsResponse
 xmlns:rtns=http://[...]/SpiralWebService/; 
   parameter qname=pns:SingleGUID
   xmlns:pns=http://[...]/SpiralWebService/;
   type=tns:SingleGUID
   xmlns:tns=http://[...]/SpiralWebService//
/operation

I upped log4j to DEBUG, and observed that the body of the request seems
only to contain the data type, not the operation name:

2006-08-11 12:39:00,795 DEBUG org.apache.axis.providers.java.RPCProvider
@ body is SingleGUID xmlns=http://[...]/SpiralWebService/;guid
xmlns=1234567890/guid/SingleGUID

The two above methods both take the SingleGUID data type as an argument,
so I defined this type in the WSDL and re-used it all over the place.
My current guess (and it is only a guess) is that Axis is just looking
for the first operation that takes this data type, and executing it, no
matter which operation it was intended for.

Can anyone see what I might have done wrong?  Am I misappropriating the
data types and the way that axis uses them, or have I missed something
in the way to call the web service, or is there something else?

Any help much appreciated,

Cheers

--
Richard
---
Richard Jones
Web and Database Technology Specialist
Imperial College London
t: +44 (0)20 759 41815
e: [EMAIL PROTECTED]



--
Richard
---
Richard Jones
Web and Database Technology Specialist
Imperial College London
t: +44 (0)20 759 41815
e: [EMAIL PROTECTED]
?xml version=1.0 encoding=UTF-8?
wsdl:definitions xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
	xmlns:tns=http://[...]/SpiralWebService/;
	xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
	xmlns:xsd=http://www.w3.org/2001/XMLSchema; name=SpiralWebService
	targetNamespace=http://[...]/SpiralWebService/;
	wsdl:types
		xsd:schema
			targetNamespace=http://[...]/SpiralWebService/;
			xmlns:xsd=http://www.w3.org/2001/XMLSchema;
			xmlns:tns=http://[...]/SpiralWebService/;
			xsd:element name=RequestFileDetailsResponse
xsd:complexType
	xsd:sequence
		xsd:element name=RequestFileDetailsResult
			maxOccurs=1 minOccurs=1
			xsd:complexType
xsd:sequence
	xsd:any /
/xsd:sequence
			/xsd:complexType
		/xsd:element
	/xsd:sequence
/xsd:complexType
			/xsd:element
			xsd:element name=SingleGUID
xsd:complexType
	xsd:sequence
		xsd:element name=guid type=xsd:string minOccurs=1 maxOccurs=1
		/xsd:element
	/xsd:sequence
/xsd:complexType
			/xsd:element
			xsd:element name=SuccessFailResponse
xsd:complexType
	xsd:sequence
		xsd:element name=guid
			type=xsd:string minOccurs=1 maxOccurs=1
		/xsd:element
		xsd:element name=success
			type=xsd:boolean minOccurs=1 maxOccurs=1
		/xsd:element
		xsd:element name=message
			type=xsd:string minOccurs=0 maxOccurs=1
		/xsd:element
	/xsd:sequence
/xsd:complexType
			/xsd:element
			xsd:element name=SetLicenceRequest
	xsd:complexType
		xsd:sequence
			xsd:element name=guid
type=xsd:string minOccurs=1 maxOccurs=1
			/xsd:element
			xsd:element name=LicenceMets minOccurs=1 maxOccurs=1

Re: request always calls the first operation defined in server-config.wsdd

2006-08-14 Thread Anne Thomas Manes 

Richard,

According to your WSDL, you have five request messages that have
identical signatures:
- ArticleUpdateNotificationRequest
- UnsetLicenseRequest
- ViewLicenseRequest
- LicenseStatusRequest
- RequestFileDetailsRequest

A SOAP message signature is determined by the child element of the
soap:Body. When using document style, that message signature element
is the element referenced in the wsdl:part definition. Therefore,
for the following definition:

   wsdl:message name=ArticleUpdateNotificationRequest
 wsdl:part element=tns:SingleGUID
   name=ArticleUpdateNotificationRequest/
   /wsdl:message

will produce a message on the wire looks like this:

soap:Envelope xmlns:soap=...
   soap:Body xmlns:ns1=...
   ns1:SingleGUID.../ns1:SingleGUID
   /soap:Body
/soap:Envelope

But you have four other request messages that look exactly the same.
There is absolutely no way for Axis to determine which operation you
want to invoke, therefore it always invokes the first operation.  So
as I said in my first response, you must define unique signatures for
each operation -- that means that each operation request message must
reference a unique element name in its message part.

I recommend that you define a type called singleGuidType and then
define five separate elements, each with a name corresponding to the
method name, e.g.:

xsd:complexType name=singleGuidType
  xsd:sequence
  xsd:element maxOccurs=1 minOccurs=1 name=guid type=xsd:string/
  /xsd:sequence
/xsd:complexType

xsd:element name=ArticleUpdateNotification type=singleGuidType/

wsdl:message name=ArticleUpdateNotificationRequest
wsdl:part element=tns:ArticleUpdateNotification
  name=body/
/wsdl:message

Anne



On 8/14/06, Richard Jones [EMAIL PROTECTED] wrote:

Hi Anne,

 Please post the WSDL.

Please find attached.  This was written in Eclipse using the Web Tools
plugin.

Thanks for your help,

Richard

 Hi Folks,

 I am starting to really get to grips with my web services now, with much
 thanks to Axis.  This morning, though, I have encountered a problem
 which I can't work out whether is my fault (likely) or a potential
 problem.

 I have two requests defined (in the scope of this problem):

 public void requestFileDetails(String guid)
throws ServiceException, RemoteException
 {
// make the request
SpiralTestSoapService service = getService();
SingleGUID sguid = new SingleGUID(guid);
RequestFileDetailsResponse response =
  service.requestFileDetails(sguid);
 }

 public void articleUpdateNotification(String guid)
throws ServiceException, RemoteException
 {
// make the request
SpiralTestSoapService service = getService();
SingleGUID sguid = new SingleGUID(guid);
service.articleUpdateNotification(sguid);
 }

 these in turn call the relevant operations on the port type (The
 xxx_BindingImpl class).

 When either of the above methods are called in the client, the server
 /always/ processes the request to requestFileDetails.  I discovered
 that I could fix this so that it always processed the request to
 articleUpdateNotification by reversing the order that these two
 operations are specified in the server-config.wsdd:

 operation name=articleUpdateNotification
  qname=ArticleUpdateNotification mep=oneway 
parameter qname=pns:SingleGUID
xmlns:pns=http://[...]/SpiralWebService/; type=tns:SingleGUID
xmlns:tns=http://[...]/SpiralWebService//
 /operation
 operation name=requestFileDetails qname=RequestFileDetails
  returnQName=retNS:RequestFileDetailsResponse
  xmlns:retNS=http://[...]/SpiralWebService/;
  returnType=rtns:RequestFileDetailsResponse
  xmlns:rtns=http://[...]/SpiralWebService/; 
parameter qname=pns:SingleGUID
xmlns:pns=http://[...]/SpiralWebService/;
type=tns:SingleGUID
xmlns:tns=http://[...]/SpiralWebService//
 /operation

 I upped log4j to DEBUG, and observed that the body of the request seems
 only to contain the data type, not the operation name:

 2006-08-11 12:39:00,795 DEBUG org.apache.axis.providers.java.RPCProvider
 @ body is SingleGUID xmlns=http://[...]/SpiralWebService/;guid
 xmlns=1234567890/guid/SingleGUID

 The two above methods both take the SingleGUID data type as an argument,
 so I defined this type in the WSDL and re-used it all over the place.
 My current guess (and it is only a guess) is that Axis is just looking
 for the first operation that takes this data type, and executing it, no
 matter which operation it was intended for.

 Can anyone see what I might have done wrong?  Am I misappropriating the
 data types and the way that axis uses them, or have I missed something
 in the way to call the web service, or is there something else?

 Any help much appreciated,

 Cheers

 --
 Richard
 ---
 Richard Jones
 Web and Database Technology Specialist
 Imperial College London
 t: +44 (0)20 759 41815
 e: [EMAIL PROTECTED]


--
Richard
---
Richard Jones
Web

request always calls the first operation defined in server-config.wsdd

2006-08-11 Thread Richard Jones 

Hi Folks,

I am starting to really get to grips with my web services now, with much 
thanks to Axis.  This morning, though, I have encountered a problem 
which I can't work out whether is my fault (likely) or a potential problem.


I have two requests defined (in the scope of this problem):

public void requestFileDetails(String guid)
  throws ServiceException, RemoteException
{
  // make the request
  SpiralTestSoapService service = getService();
  SingleGUID sguid = new SingleGUID(guid);
  RequestFileDetailsResponse response =
service.requestFileDetails(sguid);
}

public void articleUpdateNotification(String guid)
  throws ServiceException, RemoteException
{
  // make the request
  SpiralTestSoapService service = getService();
  SingleGUID sguid = new SingleGUID(guid);
  service.articleUpdateNotification(sguid);
}

these in turn call the relevant operations on the port type (The 
xxx_BindingImpl class).


When either of the above methods are called in the client, the server 
/always/ processes the request to requestFileDetails.  I discovered 
that I could fix this so that it always processed the request to 
articleUpdateNotification by reversing the order that these two 
operations are specified in the server-config.wsdd:


operation name=articleUpdateNotification
qname=ArticleUpdateNotification mep=oneway 
  parameter qname=pns:SingleGUID
  xmlns:pns=http://[...]/SpiralWebService/; type=tns:SingleGUID
  xmlns:tns=http://[...]/SpiralWebService//
/operation
operation name=requestFileDetails qname=RequestFileDetails
returnQName=retNS:RequestFileDetailsResponse
xmlns:retNS=http://[...]/SpiralWebService/;
returnType=rtns:RequestFileDetailsResponse
xmlns:rtns=http://[...]/SpiralWebService/; 
  parameter qname=pns:SingleGUID
  xmlns:pns=http://[...]/SpiralWebService/;
  type=tns:SingleGUID
  xmlns:tns=http://[...]/SpiralWebService//
/operation

I upped log4j to DEBUG, and observed that the body of the request seems 
only to contain the data type, not the operation name:


2006-08-11 12:39:00,795 DEBUG org.apache.axis.providers.java.RPCProvider 
@ body is SingleGUID xmlns=http://[...]/SpiralWebService/;guid 
xmlns=1234567890/guid/SingleGUID


The two above methods both take the SingleGUID data type as an argument, 
so I defined this type in the WSDL and re-used it all over the place. 
My current guess (and it is only a guess) is that Axis is just looking 
for the first operation that takes this data type, and executing it, no 
matter which operation it was intended for.


Can anyone see what I might have done wrong?  Am I misappropriating the 
data types and the way that axis uses them, or have I missed something 
in the way to call the web service, or is there something else?


Any help much appreciated,

Cheers

--
Richard
---
Richard Jones
Web and Database Technology Specialist
Imperial College London
t: +44 (0)20 759 41815
e: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: request always calls the first operation defined in server-config.wsdd

2006-08-11 Thread Anne Thomas Manes 

Each operation must have a unique signature, i.e., you must specify a
different qname for your two input parameters. (They can be the same
type, but they must have different names.)

Anne

On 8/11/06, Richard Jones [EMAIL PROTECTED] wrote:

Hi Folks,

I am starting to really get to grips with my web services now, with much
thanks to Axis.  This morning, though, I have encountered a problem
which I can't work out whether is my fault (likely) or a potential problem.

I have two requests defined (in the scope of this problem):

public void requestFileDetails(String guid)
   throws ServiceException, RemoteException
{
   // make the request
   SpiralTestSoapService service = getService();
   SingleGUID sguid = new SingleGUID(guid);
   RequestFileDetailsResponse response =
 service.requestFileDetails(sguid);
}

public void articleUpdateNotification(String guid)
   throws ServiceException, RemoteException
{
   // make the request
   SpiralTestSoapService service = getService();
   SingleGUID sguid = new SingleGUID(guid);
   service.articleUpdateNotification(sguid);
}

these in turn call the relevant operations on the port type (The
xxx_BindingImpl class).

When either of the above methods are called in the client, the server
/always/ processes the request to requestFileDetails.  I discovered
that I could fix this so that it always processed the request to
articleUpdateNotification by reversing the order that these two
operations are specified in the server-config.wsdd:

operation name=articleUpdateNotification
 qname=ArticleUpdateNotification mep=oneway 
   parameter qname=pns:SingleGUID
   xmlns:pns=http://[...]/SpiralWebService/; type=tns:SingleGUID
   xmlns:tns=http://[...]/SpiralWebService//
/operation
operation name=requestFileDetails qname=RequestFileDetails
 returnQName=retNS:RequestFileDetailsResponse
 xmlns:retNS=http://[...]/SpiralWebService/;
 returnType=rtns:RequestFileDetailsResponse
 xmlns:rtns=http://[...]/SpiralWebService/; 
   parameter qname=pns:SingleGUID
   xmlns:pns=http://[...]/SpiralWebService/;
   type=tns:SingleGUID
   xmlns:tns=http://[...]/SpiralWebService//
/operation

I upped log4j to DEBUG, and observed that the body of the request seems
only to contain the data type, not the operation name:

2006-08-11 12:39:00,795 DEBUG org.apache.axis.providers.java.RPCProvider
@ body is SingleGUID xmlns=http://[...]/SpiralWebService/;guid
xmlns=1234567890/guid/SingleGUID

The two above methods both take the SingleGUID data type as an argument,
so I defined this type in the WSDL and re-used it all over the place.
My current guess (and it is only a guess) is that Axis is just looking
for the first operation that takes this data type, and executing it, no
matter which operation it was intended for.

Can anyone see what I might have done wrong?  Am I misappropriating the
data types and the way that axis uses them, or have I missed something
in the way to call the web service, or is there something else?

Any help much appreciated,

Cheers

--
Richard
---
Richard Jones
Web and Database Technology Specialist
Imperial College London
t: +44 (0)20 759 41815
e: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: request always calls the first operation defined in server-config.wsdd

2006-08-11 Thread Richard Jones 

Hi Anne,


Each operation must have a unique signature, i.e., you must specify a
different qname for your two input parameters. (They can be the same
type, but they must have different names.)


I'm not sure I understand, sorry.  Each operation in my WSDL has a 
different name, but some of them take the same argument (I didn't see a 
reason to define a bunch of different data types to encapsulate the same 
information).  According to my WSDD file, the operations do have unique 
signatures/qnames:


 operation name=articleUpdateNotification
  qname=ArticleUpdateNotification mep=oneway 

 operation name=requestFileDetails qname=RequestFileDetails ...

Likewise, the server implementation has fully unique methods 
implementing each of these operations.


I think the confusion is something to do with actually sending the 
request, rather than the server end.  So for some reason the client code 
is not making it clear what the operation being requested is. 
Unfortunately, I don't understand the way that Axis produces the request 
in the first place, and none of the tools that should help me monitor it 
seem to work at my end (e.g. SOAPMonitor).


Cheers,

Richard


Hi Folks,

I am starting to really get to grips with my web services now, with much
thanks to Axis.  This morning, though, I have encountered a problem
which I can't work out whether is my fault (likely) or a potential 
problem.


I have two requests defined (in the scope of this problem):

public void requestFileDetails(String guid)
   throws ServiceException, RemoteException
{
   // make the request
   SpiralTestSoapService service = getService();
   SingleGUID sguid = new SingleGUID(guid);
   RequestFileDetailsResponse response =
 service.requestFileDetails(sguid);
}

public void articleUpdateNotification(String guid)
   throws ServiceException, RemoteException
{
   // make the request
   SpiralTestSoapService service = getService();
   SingleGUID sguid = new SingleGUID(guid);
   service.articleUpdateNotification(sguid);
}

these in turn call the relevant operations on the port type (The
xxx_BindingImpl class).

When either of the above methods are called in the client, the server
/always/ processes the request to requestFileDetails.  I discovered
that I could fix this so that it always processed the request to
articleUpdateNotification by reversing the order that these two
operations are specified in the server-config.wsdd:

operation name=articleUpdateNotification
 qname=ArticleUpdateNotification mep=oneway 
   parameter qname=pns:SingleGUID
   xmlns:pns=http://[...]/SpiralWebService/; type=tns:SingleGUID
   xmlns:tns=http://[...]/SpiralWebService//
/operation
operation name=requestFileDetails qname=RequestFileDetails
 returnQName=retNS:RequestFileDetailsResponse
 xmlns:retNS=http://[...]/SpiralWebService/;
 returnType=rtns:RequestFileDetailsResponse
 xmlns:rtns=http://[...]/SpiralWebService/; 
   parameter qname=pns:SingleGUID
   xmlns:pns=http://[...]/SpiralWebService/;
   type=tns:SingleGUID
   xmlns:tns=http://[...]/SpiralWebService//
/operation

I upped log4j to DEBUG, and observed that the body of the request seems
only to contain the data type, not the operation name:

2006-08-11 12:39:00,795 DEBUG org.apache.axis.providers.java.RPCProvider
@ body is SingleGUID xmlns=http://[...]/SpiralWebService/;guid
xmlns=1234567890/guid/SingleGUID

The two above methods both take the SingleGUID data type as an argument,
so I defined this type in the WSDL and re-used it all over the place.
My current guess (and it is only a guess) is that Axis is just looking
for the first operation that takes this data type, and executing it, no
matter which operation it was intended for.

Can anyone see what I might have done wrong?  Am I misappropriating the
data types and the way that axis uses them, or have I missed something
in the way to call the web service, or is there something else?

Any help much appreciated,

Cheers

--
Richard
---
Richard Jones
Web and Database Technology Specialist
Imperial College London
t: +44 (0)20 759 41815
e: [EMAIL PROTECTED]



--
Richard
---
Richard Jones
Web and Database Technology Specialist
Imperial College London
t: +44 (0)20 759 41815
e: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: request always calls the first operation defined in server-config.wsdd

2006-08-11 Thread Anne Thomas Manes 

Please post the WSDL.

On 8/11/06, Richard Jones [EMAIL PROTECTED] wrote:

Hi Folks,

I am starting to really get to grips with my web services now, with much
thanks to Axis.  This morning, though, I have encountered a problem
which I can't work out whether is my fault (likely) or a potential problem.

I have two requests defined (in the scope of this problem):

public void requestFileDetails(String guid)
   throws ServiceException, RemoteException
{
   // make the request
   SpiralTestSoapService service = getService();
   SingleGUID sguid = new SingleGUID(guid);
   RequestFileDetailsResponse response =
 service.requestFileDetails(sguid);
}

public void articleUpdateNotification(String guid)
   throws ServiceException, RemoteException
{
   // make the request
   SpiralTestSoapService service = getService();
   SingleGUID sguid = new SingleGUID(guid);
   service.articleUpdateNotification(sguid);
}

these in turn call the relevant operations on the port type (The
xxx_BindingImpl class).

When either of the above methods are called in the client, the server
/always/ processes the request to requestFileDetails.  I discovered
that I could fix this so that it always processed the request to
articleUpdateNotification by reversing the order that these two
operations are specified in the server-config.wsdd:

operation name=articleUpdateNotification
 qname=ArticleUpdateNotification mep=oneway 
   parameter qname=pns:SingleGUID
   xmlns:pns=http://[...]/SpiralWebService/; type=tns:SingleGUID
   xmlns:tns=http://[...]/SpiralWebService//
/operation
operation name=requestFileDetails qname=RequestFileDetails
 returnQName=retNS:RequestFileDetailsResponse
 xmlns:retNS=http://[...]/SpiralWebService/;
 returnType=rtns:RequestFileDetailsResponse
 xmlns:rtns=http://[...]/SpiralWebService/; 
   parameter qname=pns:SingleGUID
   xmlns:pns=http://[...]/SpiralWebService/;
   type=tns:SingleGUID
   xmlns:tns=http://[...]/SpiralWebService//
/operation

I upped log4j to DEBUG, and observed that the body of the request seems
only to contain the data type, not the operation name:

2006-08-11 12:39:00,795 DEBUG org.apache.axis.providers.java.RPCProvider
@ body is SingleGUID xmlns=http://[...]/SpiralWebService/;guid
xmlns=1234567890/guid/SingleGUID

The two above methods both take the SingleGUID data type as an argument,
so I defined this type in the WSDL and re-used it all over the place.
My current guess (and it is only a guess) is that Axis is just looking
for the first operation that takes this data type, and executing it, no
matter which operation it was intended for.

Can anyone see what I might have done wrong?  Am I misappropriating the
data types and the way that axis uses them, or have I missed something
in the way to call the web service, or is there something else?

Any help much appreciated,

Cheers

--
Richard
---
Richard Jones
Web and Database Technology Specialist
Imperial College London
t: +44 (0)20 759 41815
e: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]