WS::Client and WSDL imports
in [TCL]
|
From: Donal K. Fellows on 6 Jul 2010 15:56 I'm working with an existing (and rather rococo) web service that has a very particular model of how it publishes its WSDL. In particular, it publishes its service address in one WSDL, its service definition in another WSDL, and the types and elements used in a whole slew of XSDs. It's frankly a mess, but I'm stuck with it (unless I can prove that it is wrong, which I doubt). The problem? The WS::Client package (version 1.1.1, in the teapot) chokes on this complexity when I use GetAndParseWsdl, only managing to identify that there is a service on the port and not how to send it any messages. If I try using ImportNamespace to add the extra definitions in, then things also fall apart for the apparent lack of a "targetNamespace" even though I can read that attribute on the top-level element in the various documents when I download them manually. What, if anything, am I doing wrong? (If you want the URL of the parent WSDL for testing, email me privately; I'd rather not expose the service to arbitrary searching from the whole world as it's still experimental.) Donal.
From: tom.rmadilo on 7 Jul 2010 10:19 On Jul 6, 12:56 pm, "Donal K. Fellows" <donal.k.fell...(a)manchester.ac.uk> wrote: > I'm working with an existing (and rather rococo) web service that has a > very particular model of how it publishes its WSDL. In particular, it > publishes its service address in one WSDL, its service definition in > another WSDL, and the types and elements used in a whole slew of XSDs. > It's frankly a mess, but I'm stuck with it (unless I can prove that it > is wrong, which I doubt). > > The problem? The WS::Client package (version 1.1.1, in the teapot) > chokes on this complexity when I use GetAndParseWsdl, only managing to > identify that there is a service on the port and not how to send it any > messages. If I try using ImportNamespace to add the extra definitions > in, then things also fall apart for the apparent lack of a > "targetNamespace" even though I can read that attribute on the top-level > element in the various documents when I download them manually. > > What, if anything, am I doing wrong? (If you want the URL of the parent > WSDL for testing, email me privately; I'd rather not expose the service > to arbitrary searching from the whole world as it's still experimental.) Probably nothing. I usually get queries about web services when they don't follow the standard very well. There may have been an initial client which was developed at the same time. Another source of many problems is export of operations which work well as an internal API in a language like Java or C#, but don't export well automatically. Also, some web service development platforms divide WSDL, schema and interface generation. I stopped further development of my own client because WS::Client works well with well defined services and decided to focus more on the idea of a client/server proxy. It is easy to generate an integrated server in TWiST, then there are two options: just use the generated WSDL, but re-map the tiny details you are talking about, or use the body of the operations to perform any translations of the incoming message and query the actual server. TWiST actually has a built in example with the operation testing API, which takes an HTTP GET and performs a POST back to the same server. Here's another example with the freshbooks XML API: http://www.junom.com/ws/freshbooks/index.txt
From: Georgios Petasis on 14 Jul 2010 10:09 στις 6/7/2010 22:56, O/H Donal K. Fellows έγραψε: > I'm working with an existing (and rather rococo) web service that has a > very particular model of how it publishes its WSDL. In particular, it > publishes its service address in one WSDL, its service definition in > another WSDL, and the types and elements used in a whole slew of XSDs. > It's frankly a mess, but I'm stuck with it (unless I can prove that it > is wrong, which I doubt). > > The problem? The WS::Client package (version 1.1.1, in the teapot) > chokes on this complexity when I use GetAndParseWsdl, only managing to > identify that there is a service on the port and not how to send it any > messages. If I try using ImportNamespace to add the extra definitions > in, then things also fall apart for the apparent lack of a > "targetNamespace" even though I can read that attribute on the top-level > element in the various documents when I download them manually. > > What, if anything, am I doing wrong? (If you want the URL of the parent > WSDL for testing, email me privately; I'd rather not expose the service > to arbitrary searching from the whole world as it's still experimental.) > > Donal. > Dear Donal, Have you resolved the issue? George
From: tom.rmadilo on 14 Jul 2010 15:59 On Jul 14, 7:09 am, Georgios Petasis <peta...(a)iit.demokritos.gr> wrote: > ÏÏÎ¹Ï 6/7/2010 22:56, O/H Donal K. Fellows ÎγÏαÏε: > > > > > > > I'm working with an existing (and rather rococo) web service that has a > > very particular model of how it publishes its WSDL. In particular, it > > publishes its service address in one WSDL, its service definition in > > another WSDL, and the types and elements used in a whole slew of XSDs. > > It's frankly a mess, but I'm stuck with it (unless I can prove that it > > is wrong, which I doubt). > > > The problem? The WS::Client package (version 1.1.1, in the teapot) > > chokes on this complexity when I use GetAndParseWsdl, only managing to > > identify that there is a service on the port and not how to send it any > > messages. If I try using ImportNamespace to add the extra definitions > > in, then things also fall apart for the apparent lack of a > > "targetNamespace" even though I can read that attribute on the top-level > > element in the various documents when I download them manually. > > > What, if anything, am I doing wrong? (If you want the URL of the parent > > WSDL for testing, email me privately; I'd rather not expose the service > > to arbitrary searching from the whole world as it's still experimental.) > > > Donal. > > Dear Donal, > > Have you resolved the issue? I doubt there is any solution other than hand coding. The only part of a WSDL where imports work is the schema, and this is part of XSD. Although the XML schema can be in total disarray, the WSDL elements must appear in a fixed order, actually the reverse order that you would expect as a programmer. So you can't import service addresses and use a different service definition. If I'm wrong, don't expect web services to ever become portable across client/server implementations. (Oh, we are probably already there...)
From: Donal K. Fellows on 14 Jul 2010 17:39
On 14/07/2010 15:09, Georgios Petasis wrote: > Have you resolved the issue? There were bugs in WS::Client's handling of complicated patterns of schemas (and also in some of the error messages which made it hard to determine the problem as a user of the code). The problem was that I had a graph of inter-schema references that wasn't a strict tree (and I think that the engine I was using to generate the schema doesn't work that way either). I understand that Gerald Lester is working on improving things (though not full-time :-)) Donal. |