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.
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`m working on a SAP project, where i have to call a non-sap service with jsessionid in binding url. I already generated a proxy class out of the wsdl and defined a logical port with my URL. In my case it should be dynamic like: {host}/service/foo/binding;jsessionid={xxx} but its static like: {host}/service/foo/binding
How can i achieve that session handling?
EDIT: The problem here is, its not only for authentification its also for load balancing. The jsessionid MUST be submitted via URL rewriting. Any ideas?
You should be able to configure this with the soamanager transaction:
Go to the service configuration screen and select your consumer proxy
Edit the existing, or create a new logical port
Go to the transport settings tab and change the URL access path
Once saved, you can find the logical port as a destination in transaction SM59. It's one of the generated ones in the external HTTP connections tree.
Providing a value for the parameter will probably require a modification of the SAP software though. The system uses the cl_http_client=>create_by_destination method to obtain a client object to perform the http call, so maybe you can implement some custom code there.
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.
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