Re: WSDL Location Question

[Richard Gregory <ri...@gsf.de>]

Hi Todd,

I know nothing about php or coldfusion clients, but based on my 
experience of axis services and axis/.Net clients, I think the approach 
you have taken of using a custom wsdl, and seperating out the common 
types to your Global.xsd sounds like a good one.

However, I'm not sure why your service needs to access the wsdl or you 
global.xsd? Once the service and all the data types defined in the 
wsdl/global.xsd are generated, and deployed, and the clients have been 
generated based on the wsdl/global.xsd (which I think is the situation?) 
, there should be no need to access these. As long as the correct 
address of the service is specified in the wsdl, and this address is 
used by clients, their relative locations shouldn't matter at all in 
terms of the generated clients invoking the service. If you haven't 
already, check that the service address *you* specified in the wsdl is 
the address used being by the clients. If the wsdl is accessed from axis 
via a http://......./service?wsdl url when generating clients 
automatically using something like WSDL2Java or the equivalents in other 
languages, Axis sometimes changes the address in the wsdl it returns, 
and if the clients use this incorrect address they will not be able to 
invoke the service. This is why I have moved my wsdl files out of axis 
completely and onto a public web server, and just put empty <wsdlFile> 
tags in my wsdd to ensure that axis will not return a wsdl file at all.

Hope this helps,

Richard.


Todd Orr wrote:

> Hey Richard,
>
> Thanks for the reply! Let me give you a little background, maybe my 
> goals will become more clear than my previous explanations. I 
> developed a Web service using java2wsdl. That worked fine, but I 
> didn't like the lack of control over the nillable, min/max, etc 
> attributes. So, I altered the produced WSDL with my changes and 
> specified this to be used in the wsdd file. This worked fine. Then I 
> decided to extract some of the global data types (shared among several 
> services) into an xsd of its own that I then imported into the WSDL. 
> Even though the XML was valid, the Web service didn't work. I believed 
> that this failed because my WSDL specified a Global.xsd file relative 
> to the WSDL file instead of the full path. The service resolved at a 
> different address than the WSDLs' locations. When the service was 
> resolved, it could not see the Global.xsd because it was no longer 
> properly located relative to the WSDL. The next thought was to specify 
> the full URL of the xsd, but this won't work because of deployment 
> uncertainties. So, I thought that if I controlled the location of all 
> the XML files, I could alleviate this problem. So, I moved everything 
> to a publicly accessible directory and pointed the service to the WSDL 
> located publicly via the wsdd config. This doesn't work, 
> unfortunately. Event though the WSDL resolves, the service does not 
> listen at this location. So, my php and Coldfusion test clients could 
> create their stubs, but couldn't send requests. So, here I am 
> wondering how others have resolved this. Maybe the situation I've lead 
> myself into is incorrect. Perhaps there is a better way to define 
> global types thus negating the rest of the steps I took. My noobiness 
> is a hindrance, so I hope that I am not the only one that has tried to 
> do the task described above. Thanks for the input!
>
> Thanks,
> T
>
> On 11/30/05, *Richard Gregory* <richard.gregory@gsf.de 
> <ma...@gsf.de>> wrote:
>
>     Hi Todd,
>
>     I'm not sure whether I'm missing something here in exactly what
>     you want
>     to do - you don't mention why you want to have the wsdl files and
>     services outside WEB-INF. Anyway, I have a set up similar to what you
>     describe. The wsdl files are accessible from a regular web page whiich
>     is completely independent of axis
>     (http://mips.gsf.de/projects/biors/biors_ws.html
>     <http://mips.gsf.de/projects/biors/biors_ws.html>) because the
>     services
>     themselves are deployed on a cluster and the AxisServlet will not
>     return
>     my custom wsdl's, and in particular the service address,as I have
>     written them if I use the ?wsdl or click on the wsdl link in
>     AxisServlet
>     (there's another thread about that, and I've already raised a jira to
>     try to get this rectified). If I point WSDL2Java at these files,
>     it will
>     work fine, as I guess you have found, and I can use these stubs to
>     then
>     access my services within the axis webapp, which works fine for me.
>
>     I think what you are trying to do (if I underatand it correctly) is
>     probably impossible - to have the wsdl files and the service at
>     the same
>     location outside axis/WEB-INF, as I think the services themselves will
>     always have to be within axis/WEB-INF. I tried to have a look at
>     modifying the AxisServlet code to solve the problem I had, but I
>     needed
>     an external jar file to build the axis source and nobody on the list
>     could tell me where to find it, so I gave up and just went with the
>     solution above.
>
>     Cheers,
>
>     Richard.
>
>     Todd Orr wrote:
>
>     > guess not
>     >
>     > On 11/26/05, *Todd Orr* <torr0101@gmail.com
>     <ma...@gmail.com>
>     > <mailto:torr0101@gmail.com <ma...@gmail.com>>> wrote:
>     >
>     >     I've read up on how to tell Axis to use a specific wsdl
>     instead of
>     >     auto-generating them. I still have not found any information on
>     >     altering the public wsdl location. So, I moved my wsdls into a
>     >     publicly accessible (outside of WEB-INF) directory. Now I can
>     >     easily generate client stubs. However, I cannot submit a soap
>     >     request to these locations.
>     >
>     >     Is there a way to configure the public wsdl location, and the
>     >     service's access point? Preferably, they'd be one in the
>     same. The
>     >     big part of the problem is that I find the default inadequate.
>     >
>     >     Thanks,
>     >     T
>     >
>     >
>
>