I have different Spring Web Services, which are included into the context by the
Endpoint Annotation, so there are no dependencies despite the Annotation (no interface etc.). Therefore, no "context" information is present.
Now I want to chain a web service request, ie. an Endpoint is called which itself should call a web service on the same server. I can use Spring's WebServiceTemplate, however, I need the current server url for this request.
Is there any way how this url can be injected during application startup into the Endpoints? Since the Endpoints do not extend some class, there is no way to get this information anywhere inside the Endpoints, also the request parameters do not have this information (these are simple JAXB-classes, which are marshalled on request).
I believe the best option is to send the URL as part of the request.
This also enables you to dynamically change the URL to a third server later.
Related
I am new in the area of SOAP Based web services. I am using TomEE server. The server is a bit customized according to my organization's need.
Few days back, when I was trying to run the web services example from TomEE website, I was able to generate the wsdl and calling the web service by a client.
Now, when I need to use the customized version of TomEE plus (by the organization), I can see that the request does reach to the server and hence there is a log entry also but my #WebMethod is not getting executed.
Does any one has any idea about any configuration which can prevent the request from reaching to the webservice method? Is there any pointer around how can I debug further to reach out to the root cause of this issue?
Without further information about what is customized it's like fishing in the dark.
I would guess that perhaps the global web.xml or the server.xml of tomee server is changed so that some URI context mappings are not forwarded or ignored. But it's only a lucky tip.
We are building a web application where we are following SAAS model using RESTful services for internal communication between modules.
There is a scenario where we want to resolve the host name of the server for RESTful service through one of the parameter value passed in the URL of service. In our architecture, each server instance wants to provide it's service for a set of values of a particular parameter in the URL.
In a dynamic environment, such responsibility can change from server to server. How can the client resolve dynamically which IP address it should contact to get a particular request served? Is there some sort of URL service registration and resolution facility similar to DNS, which can take into consideration some metadata like parameter's value in the resolution procedure? Any links to some existing solution or ideas for implementing such thing are welcome.
You can use a reverse-proxy as front-end of your service (all worker servers). It must be capable of directing request to appropriate back-end server based on some knowledge about application-level semantics in URLs, including parameters.
Here is the list of the most commonly used reverse-proxies:
Nginx (specifically about reverse-proxying)
Squid
Apache with mod_proxy
The main thing to note is that these general purpose products may not meet your needs well, in the sense of how flexible they can be congifured. This is why I wrote a custom reverse-proxy for a similar web-service myself (the project was implemented in Delphi, and I can provide some further details on this if needed).
I have a standalone web-service client. When invoking any of the web-methods an additional "cookie" string must be implicitly(not as a web-method parameter) passed to the WS. The WS on the other end must be able to obtain the string and use it. How can this be achieved?
I invoke the service in the following way:
Service srv = Service.create(new URL(WSDL), QNAME);
myClassPort = srv.getPort(MyClass.class);
What I need is to put some code before the first line, which would make the client send this "cookie" string every time I invoke some remote method via myClassPort. Thx.
By default JAX-WS web services and clients are stateless. When a client makes a request, the server responds and sets a cookie on the connection, if it participates in a session. But, the JAX-WS client ignores that cookie and the server treats subsequent requests as new interaction. When the session is enabled, JAX-WS client sends the same cookie with each subsequent request so that server can keep track of the client session.
So you should not be using either cookies or HTTP sessions with web services. Return a token ID as part of the response; then the client can send that along with the next request.
Anyway:
JAX-WS web service clients must be configured to maintain session information (such as cookies), using the javax.xml.ws.session.maintain property.
Other web service stacks may have similar mechanisms.
On the Server Side
JAX-WS uses some handy annotations defined by Common Annotations for the Java Platform (JSR 250), to inject the web service context and declaring lifecycle methods.
WebServiceContext holds the context information pertaining to a request being served.
You don't need to implement javax.xml.rpc.server.ServiceLifecycle. With JAX-WS Web Service all you need to do is mark a field or method with #Resource. The type element MUST be either java.lang.Object or javax.xml.ws.WebServiceContext.
#WebService
public class HelloWorld {
#Resource
private WebServiceContext wsContext;
public void sayHello(){
MessageContext mc = wsContext.getMessageContext();
HttpSession session = ((javax.servlet.http.HttpServletRequest)mc.get(MessageContext.SERVLET_REQUEST)).getSession();
}
}
There are some misleading answers to this question, so I will attempt to highlight current best practices. Most of these suggestions are part of the OWASP security guidelines, which I strongly recommend anyone working on web development to review.
1) ALWAYS use temporary (session scoped) cookies.
2) All cookies should be protected and encrypted.
3) Do not pass tokens in request payloads
4) For any requests which return data that may be sent back to the server, include a nonce (single use token) in your responses.
5) later requests should (must) include the nonce and the cookie
Again, my recommendation is to review the OWASP guidelines and proceed accordingly.
You may want to look into using a service provider for authentication - this is much smarter than brewing your own solution as there are literally a million details that all must be correct. Auth0.com is one of these.
Let's say a client gave me this URL to access a webservice to GetQuotes:
http://www.somecompany.com/services/myservice.asmx
If I tried to access the web service and I get redirected to:
http://new.location.somecompany.com/theservice.asmx
Will this affect the ASP.NET client calling this web service?
Where both service URLs have the exact same GetQuotes method.
[Edit]
The reason for this question is because we are trying to access a web server which keeps rerouting requests to different servers depending on the load.
In general a redirect shouldn't adversely affect your client (provided it handles HTTP responses correctly).
However if it's a 302 permanent redirect you might want to just update your link and save yourself the extra DNS request...
That can also be a common way for a company to provide an unchanging external link for a service while still being able to move their backend around.
We have a web service that is deployed on 2 separate machines in different locations. Is it possible to monitor the url that a person used to call our webservice using java code? We have a 3DNS url set up and we want all clients to use this url as oppossed hitting the boxes directly with the correct port numbers in the url.
Thanks
Damien
Have you taken a look at:
#Resource
WebServiceContext wsContext;
This will return the context of the current message sent to your webservice. I've been able to get the IP address of the user from that.
This is assuming that you are using Java.
You might look into something like OWSM (Oracle Web Services Manager)... there may be open source alternatives.
OWSM creates a virtual endpoint that it handles and routes to the actual service hosts. This way, your service hosts can be hidden behind the firewall, with only the OWSM host visible to the world. When a user hits the virtual endpoint, OWSM can authenticate and pass them along to the balanced service host.
An alternative might be to use servlet filters on the real endpoints. The filter could do a couple of different things. It could simply log the requested URL from the HttpServletRequest, or it could even redirect to the correct URL for you (I'm not sure what the implications of that are for a web service, though).
All you would have to do is have the filter mapped to the same context path as the web service (axis uses /services/* for example).