I've been provided a WSDL file that points to a webservice. I use this webservice to log in and create a session. In addition to the session token, the login response provides a URL I'm supposed to redirect my webservice calls to. Other than the URL I'm addressing, the definitions are the same, so no new WSDL is provided.
What is the best way to handle this? Generate my own altered WSDL? Create and/or alter the webservice object via Java? Some third option I've not thought of?
This is a hack, but you can always download the WSDL as a template, and reference it as a local file. When the login call tells you what URL to hit, simply replace the URL in the template with the new one, and proceed. You could even have a different version of the WSDL for each URL that could be returned, maybe using a hash of the URL as the filename.
Coldfusion webservice invocations always point to WSDL. Be it a local WSDL file, or a remote WSDL file you can access over an HTTP or HTTPs connection. Unless the responding URL points to a new WSDL file to use, it's not going to be that helpful.
-Jay
Related
I am working on web services POC. I need to develop a Spring-based web services, that use XML/HTTP i.e. HTTP binding (NOT SOAP/HTTP) so that I can invoke a web-service with URL parameters like the one example described in the WSDL specification especially a GET with query parameters.
I am unable to map the URL's query-parameter to the end-point's (#EndPoint) method parameter.
Is it possible to develop such a web-service (XML/HTTP bound) with spring-ws?
Is it possible to invoke such a service with GET request + query string?
Let me know for any such examples/tutorials.
Please take a look at this page (http://static.springsource.org/spring/docs/3.0.0.M3/spring-framework-reference/html/ch18s02.html). Assuming that you are using spring 3, I believe you should find some relief there.
Based your question, I assume you already have the DispatcherServlet declared and mapped in web.xml. The trick, then, is to pull out the arguments. The page indicates how to pull arguments from both the URL (which I believe is your goal) and from the request body.
Good luck and write back if anything is unclear.
I need to change the JAX-WS generat WSDL because of a soap:address error (contextRoot it is not correct due to a WebService remapping of the Application Server).
I Read about the WSDLGeneratorExtension system but I can not use it, i placed a com.sun.xml.ws.api.wsdl.writer.WSDLGeneratorExtension file under /META-INF/services with insite de class name of my implementation, but it is never called.
How can i let it work? Or Can i follow another way to corret the soap:address location of the generated WSDL?
Thank you!
Usual practice is not to use (or even include) actual service URL into WSDL (unless it's some sort of public service which is supposed to be 'well known'). Reasons being that different environments running the same service would have different URLs, for example.
As part of WS client initialization you could provide different URL (usually from some sort of config file). So you perhaps should not think in terms of fixing URL in WSDL but instead pass proper URL in your client initialization.
I've created a ColdFusion Web Service, but it's returning WDDX instead of SOAP. How do I make it return SOAP instead of WDDX?
Have the <cffunction> return an XML object, and have the "returnformat" parameter be set to "plain".
<cffunction name="GetData" returntype="xml" returnformat="plain">
For complex objects, you need to setup the CFCs correctly. Read: Using ColdFusion components to define data types for web services
update: Or, you can create the XML representation of your object yourself with <cfxml>, then return the XML object with returnType="xml" in cffunction.
You may check out coldbox's XMLConverter Plugin as code sample for converting built-in CF complex types into XML.
A CFC method with access=remote ought to return soap, rather than WDDX. I'm sure I've used this functionality for years. What I'm suspecting may be happening is that the content-type is based on the request a client makes. I would download Soap-UI and test http://your.server/yourCFC.cfc?wsdl to see whether SOAP-UI gets WDDX thrown back at it. If is does, I'm at a bit of a loss, but do report it here anyway and I'll take a further look.
If Soap-UI sees a proper response, take a look at the headers it's sending and compare them to the request you're making (possibly through the browser?)
You can also use Fiddler to record soap-ui traffic and compare that against any other source of requests.
The http request thing above may be completely off, but it's relatively easy to check and I think it's ringing a bell.
You may also want to check the return type of the function you're writing. In order for CF to generate a good WSDL, it needs to be able to extract metadata from the CFC you're returning.
A bit late to the game but were you hitting it as a plain HTTP request and not as with a SOAP packet?
For example were you doing this:
http://api.example.com/something.cfc?method=test&arg1=val1
instead of an actual SOAP request with envelope, headers, body, etc?
The HTTP request returns WDDX by default or JSON by specifying the returnformat, while a SOAP request will return data in the format you are seeking.
Can I have the soap:address location in a WSDL relative to the WSDL location, or at least relative to the server?
For instance I want to write:
<soap:address location="https://exampleserver.com/axis2/services/ExampleService" />
as:
<soap:address location="/axis2/services/ExampleService" />
This would enable faster deployment to multiple servers, like test servers. Also, in the case of axis2c if I want my service to be used both from HTTP or HTTPS life becomes harder for developers using my service as they can't simply import the WSDL from it's default location "?WSDL".
The WSDL describes to clients the message formats, types, parameters etc needed to interact with the web service. This is then used by tools like WSDL2C to generate the code needed for the interaction.
But even if you expose your service on HTTP or HTTPS, the client stub code will be the same. You don't regenerate your client stubs for each endpoint address. The client stays the same, it's the access point that changes.
This address should not be hardcoded in the generated client code, it must be a configurable URL inside the client application.
Sure, you have an URL specified inside the WSDL and it's a nuisance when you deploy your web service in the dev server, and then to staging and next into production. The endpoints will be different in each environment (maybe multiplied by 2 for HTTP + HTTPS) but at this point your developers are not affected because you don't regenerate the code.
When it comes to access the web service, you would still have different addresses (for dev, staging and prod servers) even if it would be relative to something or absolute. So I don't see how it is helpful to have relative address inside the WSDL since you still have to manage the access points into the client configuration.
There are two ways of getting the WSDL.
One where a hard-coded wsdl is served, for example:
https://hostname/contextname/services/myAPIService/myAPI.wsdl
and another one where a generated wsdl is served, for example:
https://hostname/contextname/services/myAPIService?wsdl
If you use the dynamic option it will use this code:
req.getRequestURL().toString();
to get the URL that will be used in the generated WSDL. This code is in the class ListingAgent (in the package org.apache.axis2.transport.http).
From what you mentioned in your question if you want to have relative location it must be because you want to use it in multiple servers, so you would need to use the dynamic option.
One problem I found with the dynamic options is that if in the original WSDL the location is using HTTP, then in the generated one it will still use HTTP even if you have used HTTPS to access it. (This happens in version 1.5 which is the one my project is using)
Another problem is if you are using a load balancer, because the generated WSDL will be generated with the location of the final server instead of the balancer. An option for this would be to extend the classes AxisServlet and ListingAgent to replace the code mentioned above.
After a long search I'm almost sure that soap:address's location attribute has to be an absolute URL. This gets things more complicated if you work with different environments, such as development, test and production.
Maybe a workaround would be to read, on the client side, the first part of the URL from a config file (e.g. https://exampleserver.com) and the final part from the WSDL (e.g. /axis2/services/ExampleService) and combine them to build an absolute path. The former will allow you to switch among environments.
I am wanting to expose a restful web service for posting and retrieving data, this may be consumed by mobile devices or a web site.
Now the actual creation of the service isn't a problem, what does seem to be a problem is communicating from a different domain.
I have made a simple example service deployed on the ASP.NET development server, which just exposes a simple POST action to send a request with JSON content. Then I have created a simple web page using jquery ajax to send some dummy data over, yet I believe I am getting stung with the same origin policy.
Is this a common thing, and how do you get around it? Some places have mentioned having a proxy on the domain that you always request a get to, but then you cannot use it in a restful manner...
So is this a common issue with a simple fix? As there seem to be plenty of restful services out there that allow 3rd parties to use their service...
How exactly are you "getting stung with the same origin policy"? From your description, I don't see how it could be relevant. If yourdomain.com/some-path/defined-request.json returns a certain JSON response, then it will return that response regardless of what is requesting the file, unless you have specifically defined required credentials that are not satisfied.
Here is an example of such a web service. It will return the same JSON object regardless of from where the request is made: http://maps.googleapis.com/maps/api/geocode/json?address=1600+Amphitheatre+Parkway,+Mountain+View,+CA&sensor=true
Unless I am misunderstanding you (in which case you should clarify your actual problem), the same origin policy doesn't really seem to apply here.
Update Re: Comment
"I make a simple HTML page and load it as file://myhtmlfilelocation/myhtmlfile.html and try to make an ajax request"
The cause of your problem is that you are using the file:// URL scheme, instead of the http:// protocol scheme. You can find information about this scheme in Section 3.10 of RFC 1738. Here is an excerpt:
The file URL scheme is used to designate files accessible on a particular host computer. This scheme, unlike most other URL schemes, does not designate a resource that is universally accessible over the Internet.
You should be able to resolve your issue by using the http:// scheme instead of the file:// scheme when you make your asynchronous HTTP request.