References to localhost in WSDL for CSSDK

This is with 6.7.1SP1 on Windows. In following up to my previous post, I figured I would try to build the .Net example and see if I ran into a similar error. However, I'm not even getting as far as writing the program. When I try to add a web reference to the WSDL in VS2005, it gives me this error:

The document was understood, but it could not be processed.
- The WSDL document contains links that could not be resolved.
- There was an error downloading 'http://localhost:6060/iw/services/cm/2.0/contentservices/AccessService.wsdl'.

Sure enough, looking at the WSDL, the references for all of the different services are to localhost, e.g.

[HTML]

[/HTML]

Find more posts tagged with

Comments

Migrateduser

Oops - sent the previous post too soon, this is a continuation of it...

So, is there something wrong with my cssdk configuration, or am I going about this the wrong way? The CSSDK cookbook appears to only show an example of generating a proxy class on the TeamSite server itself.

ISCBorisB

This is with 6.7.1SP1 on Windows. In following up to my previous post, I figured I would try to build the .Net example and see if I ran into a similar error. However, I'm not even getting as far as writing the program. When I try to add a web reference to the WSDL in VS2005, it gives me this error:

The document was understood, but it could not be processed.
- The WSDL document contains links that could not be resolved.
- There was an error downloading 'http://localhost:6060/iw/services/cm/2.0/contentservices/AccessService.wsdl'.

Sure enough, looking at the WSDL, the references for all of the different services are to localhost, e.g.

[HTML]

[/HTML]

Since you yourself are looking for alternatives...

Why do you insist on this unhappy WSDL/CSSDK marrige? Why not code and register pure CSSDK servlet to obtain extended Attributes
and return them via http Response? Then if you need them from the (Server Side) Perl process simply use LWP::UserAgent and
HTTP::Request / HTTP::Response to communicate. WSDL need not apply.

Migrateduser

What would possibly be the advantage of that? At that point, one is essentially re-implementing the webservice, just with a REST type interface instead of a SOAP interface.

ISCBorisB

What would possibly be the advantage of that? At that point, one is essentially re-implementing the webservice, just with a REST type interface instead of a SOAP interface.

I have not used WSDL. Does it have an API (or perhaps Web Service?) to obtain Extended Attributes?

If it does - you're right, we do not have to reinvent the wheel. If it does not and you'd have to code it anyway - pure
CSSDK approach eliminates one extra layer of API, SomeProcess->CSSDK_Servlet instead of SomeProcess->WSDL->CSSDK_Servlet.

One more aspect of it is that for the process that runs on TS Host (like WF Engine Instantiator for example) you module would
not have to log-in, I used that fact before (not for EAs though). Sure enough, that same consideration may be a disadvantge
if you make an *External* request to the TS Service and have to use SOAP transport and log-in anyway.

Migrateduser

WSDL is the Web Services Definition Language.

It's simply an XML file that defines the contract for a SOAP request. For each service, the WSDL file provides the caller with a list of the methods and their parameters and an indication of what the return message will look like. Where it's really nice (when it works) is that most platforms now provide a means to consume a WSDL and generate a local stub class that acts just like a "real" class on the machine, but it proxies all of the requests to the remote web service.

ISCBorisB

WSDL is the Web Services Definition Language.

It's simply an XML file that defines the contract for a SOAP request. For each service, the WSDL file provides the caller with a list of the methods and their parameters and an indication of what the return message will look like. Where it's really nice (when it works) is that most platforms now provide a means to consume a WSDL and generate a local stub class that acts just like a "real" class on the machine, but it proxies all of the requests to the remote web service.

Ah... My bad. For whatever reason (ignorance?), I've decided that WSDL is some obscure IWOV API/Product/JARs/Packages
Thanks for the explanation

Migrateduser

Oops - sent the previous post too soon, this is a continuation of it...

So, is there something wrong with my cssdk configuration, or am I going about this the wrong way? The CSSDK cookbook appears to only show an example of generating a proxy class on the TeamSite server itself.

I think it might be a problem with the configuration. Not sure where to tweak it. I looked at my AccessService.wsdl and I dont see any references to localhost. Instead the references are to the Teamsite URL, when I make a call to the WSDL through my browser.

Look something like this:
< wsdl : port name="AccessService" binding="tns:AccessServiceBinding" >
< wsdlsoap : address location="http://cms.ad.mydomain.com:6060/iw/services/cm/2.0/contentservices/" />
< /wsdl : port >

Migrateduser

Thanks - that at least confirms what I was thinking. I'm vaguely suspicious that the WSDL files are generated at some point based on settings in iw.cfg (similar to how the httpd.conf for iw-webd is generated from a template), since I do have some localhost references there -

[teamsite_servlet_ui]
servlet_host=localhost
servlet_port=8080

However, I haven't found anything to substantiate that theory.

Just for kicks, I just changed the references in iw.cfg from localhost to the machine's IP (I don't have this particular dev server in DNS) and did an iwreset -ui. The files in the wsdl folder under /cssdk/wsdl did not change, but the result from http://192.168.18.81/iw/services/cm/2.0/contentservices did. It changed the URL in all of the namespace declarations, but all of the service declarations but one still have localhost:

[HTML]

[/HTML]