With a hardware LoadBalancer, you can configure sticky sessions which will make sure the same session will always go to the same server.
But will this work with webservices also (rather than webservers)?
i.e. I have WebServices hosted behind a Load Balancer.
Will Webservice calls coming from different native clients (not browser clients) always go to the same webservice server?
These are very old style Webservices - uses RPC/Encoding - the native client program uses Axis 1.4 for the client stubs.
Webservice calls coming from different native clients (not browser clients) always go to the same webservice server should be possible.
To maintain the session stickiness, mostly load balance inject the server identifier in cookie while responding back to the client(kindly note cookie is not a browser feature it is HTTP feature defined by this specification) and should be supported by the HTTP client which is used by Axis 1.4 underneath).
I suggest you to to analyze how your load balance works and based on that you may have to change your needs to change your clients. If your load-balance uses the cookie based approach, this answer you may found useful.
Hope this helps.
If you can keep your application stateless,make it it's good in both performance and scalability.
Benefits of stateless :
Scalability. You can have as many servers as we want without having to share a user session. Each of them can process request (e.g. load balancing via round robin).
Saves server resources. We do not need to allocate memory on the server side (again - scalability).
No need to recover after a server restart.
Session stickiness can be tricky to get right. For example, if your web servers are running on multi-core machines, and you have several processes handling web traffic, you'll need a way to be sticky to both a specific machine and a single process on that machine. So make sure your system degrades well in cases where stickiness doesn't work correctly.
Good discussion you can find here : Sticky and NON-Sticky sessions
Sticky session pro and cons :
Pros and Cons of Sticky Session / Session Affinity load blancing strategy?
Now come to your question :
Will Webservice calls coming from different native clients (not
browser clients) always go to the same webservice server?
Yes in sticky session .
These are very old style Webservices - uses RPC/Encoding - the native
client program uses Axis 1.4 for the client stubs.
Session configuration you need load balancer/server and it can handle any old or new type of applications
this work with webservices also (rather than webservers)?
No its configuration you need to make on server level.
It will work as long as your native client correctly manage the session, ie. set the correct http header for each request.
Generally sticky session is managed by the load balancer by modifying the session cookie to add the server identity.
HA-proxy example
There must be a dedicated documentation for your load balancer.
Related
I am new to RESTful webservice. Whatever I have read over the internet about RESTful webservice, I came to know that REST works similar to servlet + webservice.
Our traditional webservice looks like JSP-> Servlet -> Service -> DAO -> Database.
Will REST replace Servlet in this heirarchy?
My ultimate goal is that my web application should support mobile application and normal browser also. Is it good idea to use REST in that case. If not, in what situation we should use REST?
I hope my question is clear.
Please help me.
Thanks in advance.
There are many ways we can achieve Machine to Machine communication.
Web services also helps communicating between applications made in different platforms.
For example a .net GUI can call a java server side program for data.
REST is one of that kind, based on HTTP protocol.
SOAP web service is heavy weight (using lots of XML) where as REST is simple and you can expose any of your APIS simply using REST.
A services exposed as REST services can be invoked by a client using on of the HTTP verbs GET, POST, PUT, and DELETE with their meaning same as in HTTP.
RESTful Web Services expose the state of its resources.
An 'Employee' data can be queried and represented in any format (Json, XML ...) using REST.
Rest won't replace the Servlet in your hierarchy, actually the HTTP based REST methods are written on this servlets.
Please go through this URL : http://docs.oracle.com/javaee/6/tutorial/doc/gijqy.html
Using REST is not related to browser experience on mobile or other devices. It totally depends on the client side technology used and your browser compatibility with those technologies.
Using REST is a good idea to access data at client side using simple AJAX calls.
REST means Representational State Transfer. It is a way of thinking about architecting network communication between client and server, with the focus being on transferring a resource from server to client and back again.
To understand the significance of this first consider a different architecture, Remote Procedure Call. This is where the client calls a function on the server as if the function existed on the client.
So you want to edit a photo that exists on the server. Your client is a photo editing app that uses RPC to achieve this. You want to blur the photo so your client calls the blur() function using RPC, and the server blurs the image and sends back the updated image. Then you want to rotate the image, so your client calls the rotate() function and the server rotates the image and sends the rotated image to your client.
You might have noticed two issues. Firstly, every time you carry out an action on the photo the server needs to do some work and send you back the updated image. This uses a lot of bandwidth.
Secondly what happens if tomorrow the server developers (who might be nothing to do with the client developers) decide that rotate() is the wrong function name, it should really be rotate_image(), and they update the server. Your client continues to call rotate() but this now fails because such a function doesn't exist on the client.
REST is an alternative way of thinking about client/server communication. Instead of telling the server to carry out an action on the resource (eg rotate the photo), why doesn't the client not just get a representation of the resource and carry out all the actions it wants to (blur, rotate etc) and then send the new state of the resource back to the server.
If you did it this way the protocol to communicate between client and server can be kept very simple and will require very few updates. All you need is functions for the client to get the resource and functions to put it back on the server. The client will have to know how to blur the image and rotate the image, but it doesn't need to know how to tell the server to do this, it just needs a way of telling the server to save the updated image.
This means that the developers of the client can work away implementing new features independently to the developers of the server. Very handy if the developers of the client are nothing to do with the server (the developers of Firefox have nothing to do with the New York Times website and vice versa)
HTTP is one such protocol that follows this architecture pattern and it allows the web to grow as it has. There are a small set of verbs (functions) in HTTP and they are concerned only with transferring a representation of the resource back and forth between client and server.
Using HTTP your photo client simply sends a GET message to the server to get the photo. The client can then do everything it wants to to the photo. When it is finished it sends the PUT message with the updated photo to the server.
Because there are not domain specific actions in the protocol (blur, rotate, resize) this protocol can also be used for any number of resources. HTTP doesn't care if the resource is a HTML document, a WAV file, a Javascript script, a PNG image. The client obviously cares because it needs to understand the resource it gets, and the server might care as well. But the protocol between the client and server doesn't need to care. The only thing HTTP knows is that there is a variable Content-Type in the HTTP header where the server can tell the client what type of resource this is.
This is powerful because it means you can update your client independently to updating your server without updating the transfer protocol. HTTP hasn't been updated in years. HTML on the other hand is updated constantly, and web servers and web browser are updated constantly (Chrome is on version 33). These updates can happen independently to each other because HTTP never (rarely) changes.
A web browser from 10 years ago can still communicate with a modern web server over HTTP to get a resource. The browser might not understand the resource, say it gets a WebM video that it can't understand, but it can still get this resource without the network communication failing.
Contrast that with the example of RPC above where the client server communication will break if the server changes rotate() to rotate_image(). Every single client will have to be updated with this new function or they will crash when trying to talk to the server.
So REST is a way of thinking about client server communication, it is an architecture design/pattern. HTTP is a protocol that works under this way of thinking that focuses on simply transferring state of a resource between server and client.
Now it is important to understand that historically a lot of people, including web developers, didn't get this. So you got things like developers putting verbs into resource names to try and simulate Remote Procedure Call over HTTP. Things like
GET http://www.mywebsite.com/image/blur_image
And they would hard code the URI /image/blur_image into their client and then try and make sure the guys developing the server never changed the URI blur_image. You get back to all problems of RPC. As soon as the server guys move the resource blur_image (which is not really a resource to start with) to /image/blur_my_image the client falls over because it has that hard coded as an action to perform, rather than simply getting /image and doing what ever it wants to it.
So there are lot of examples on the web of doing REST wrong. Anything that tightly couples client and server communication is doing REST wrong. Your client should be able to survive URIs changing, or Content-Types being updated, without falling over. It can complain it doesn't understand a resource (eg Netscape Navigator 2.0 complaining it has no idea what a HTML5 document is), but it should complain that a URI has changed. This is the discoverability aspect of REST, which I haven't gone into too much, but basically your client should be able to start at the root of the server http://www.mywebsite.com and if it understand the content types it should be able to continue on to the resource it wants. You should never need to hard code a URI into your client other than the root of the server.
I could write a book about this stuff (and many have), but I hope that serves as a good introduction about what REST actually is.
#javafan I just checked the mykong example you provided. Please note that that is not standard http servlet implementation, it is a Jersy way of implimentinmg rest. So when you map all your URIs goes through this servlet com.sun.jersey.spi.container.servlet.ServletContainer and you write classes with annotation #path etc the Jersy runtime environment will do the necessary processing for you like converting the input and output objects to necessary formats (json, xml etc) depending on your configuration. You can write a simple servlet and add methods in it with #path annotation in it and that will be invoked inturn when you make the corresponding request. but the doGet and doPost methods are standard servlet methods that processes GET and POST method by default. You can ad another methods to the same servlet and add more qualifiers to process your request.
#GET, #Produces("xml") etc.
I hope this helps.
Say we have hosted a few webservices over over https://mycompany.com/Service
e.g.
https://mycompany.com/Service/Service1
https://mycompany.com/Service/Service2
https://mycompany.com/Service/Service3
As you can see on mycompany.com we have hosted 3 webservices each having their distinct urls.
What we have is a Jboss instance with 3 different web wars deployed in it. When someone hits the service it gets past our firewall and then teh load balancer redirects to Jboss on port 8080 on the requried path and it gets serviced.
the 3 services are consumed by 3 different clients. My question if say Client1 using Service 1 is only given out the url corresponding to it can they use some kind of scanner that can also inform them that Service2 and Service3 are alaso available on mycompany.com/Service?
Irrespective of clients - can anyone simply use some scanner tool to identify what Service Endpoints are exposed on the host?
Kindly note they are a mix of SOAP (WSDL) and Rest based services deployed on same instance of Jboss.
Yes, someone can scan for those endpoints. Their scanner would generate a bunch of 404s in your logs, because it would have to guess the other URLs. If you have some kind of rate limiting firewall, it might take them quite a long time. You should be checking the logs regularly anyway.
If you expose your URL to the public internet, relying on people not finding it is just security via obscurity. You should secure each URL using application-level security, and assume that the bad guys already have the URL.
You may want to consider adding subdomains for the separate applications (e.g. service1.mycompany.com, service2.mycompany.com) - this will make firewalling easier.
I need to set up a web service. Server is in DMZ, so I thought about putting web service in IIS (asmx) cos only port 80 is available to comunicate. But information it provides should be secured. What choices do I have when it comes to what .NET / IIS can offer ?
Or maybe I should dispense with asxm web service and switch to something else. But once again, I only have port 80 available.
Thanks,
Pawel
You should checkout WCF
When it comes to securing web services you have to main action paths:
go for communication over HTTPS and leave the web service messages in plain text (no problem since the data is over HTTPS and you can't see inside): transport level security;
go for communication over HTTP but secure the messages of the web service (WS-Security fits this role): message level security.
WS-* specifications are not an easy thing to digest (especialy WS-Security which relies on other specs like WS-Policy, WS-Addressing, XML Signature, XML Encryption etc). But since you say you only have port 80 available for communication I think you don't have a choice (don't even think of implementing your own security mechanism :D).
So, if you have to use WS-Security then go for WCF. You have a bunch of communication mechanism you can choose from and WCF takes a lot of the heavy lifting for you, abstracting away the "bare metal" of SOAP and WS-*.
Within IIS, if you wish to only allow a specific IP address to access the web service, do the following:
Within IIS, right click on the file with asmx extension. Click “Switch to features view”
Click the “IP Address and Domain Restrictions” icon.
Click “Edit Feature Settings”, Select Deny All, Add Allow Entry.
Type in the IP you want the service to access.
I have an ASP.NET application which talks to a third-party SOAP web service. My application uses an ASMX client proxy (i.e. System.Web.Services.Protocols.SoapHttpClientProtocol). The third-party service uses WCF, although I don't expect that makes much difference.
I should note that we're using .NET 3.5 SP1.
We haven't customised the proxy or done anything unusual - we're just making standard web service requests and getting back the results. We have encapsulated the proxy reference within a using block so it will get disposed after the response is received.
We've been told that our application is behaving strangely in its use of TCP sessions. Instead of opening a new TCP session for each request from a new proxy instance (which is what I would have expected it to do), it's apparently keeping several connections alive and re-using them. This is causing some issues at the third party end, as they are expecting us to be using multiple sessions.
Is this a known behaviour for the SoapHttpClientProtocol client proxy? If so, is there any way we can override it so that each request results in a new TCP session?
Thanks,
John
See "Ways to Customize your ASMX Client Proxy". You'll see how to set the KeepAlive property of the HttpWebRequest used to make your requests.
I asked the question before but didn't phrase it quite right. I'm using RESTful principles to build a secure web-app that uses both transport authentication/encryption and message level security.
The message level security is essentially client-independent (still encrypted though), and hence this allows the individual messages to be cached, or stored on an intermediary server without significant risk of exposing private data.
Transport level security is needed to authenticate both end-points using TLS client-authentication. The situation is analogous to having a central mainframe where messages originate, and caches at each branch where the clients are located. I want the client->cache and cache->mainframe connections to be secured using TLS and the individual X509 Certificates. Hence, the client will know it is talking to a proxy, and the mainframe will know it is talking to the proxy and not directly to the client.
Is there some way of doing this using HTTP standards, and not through some hack?
Essentially, I want the client to try and access the mainframe URI, to know it has to go through the proxy, and use TLS with the proxy (with the proxy having its own certificate), and then for the proxy to proceed to connect to the mainframe (with each having their own certificate) on behalf of the client. The proxy can cache the data the mainframe returns, and use that instead of having to connect to the mainframe each time.
Does anybody know proxy/caching software or a method that will allow this?
Would this get more responses on serverfault.com as it's essentially a server software/config question rather than a programming problem per se?
Basically, it sounds like you want a standard SSL reverse proxy with caching. You could do this without writing any code with Apache + mod_cache, configured as a reverse proxy.
The kicker is the message security. It'd only work if your requests are 100% cacheable based only on path/querystring, and if they were "unique by client" (eg, a client ID in the QS or something). Something tells me that one or both of these are not true. This would be pretty trivial to build in ASP.NET, or by extending mod_cache (basically just standard response caching, bucketed by the client cert thumbprint).