Menu
Premising that I'm a newbie in Web Services technologies, and am just beginning to study them, I wasn't able to understand in a precise way why should I implement a Web Service rather than a standard Client/Server protocol.
1 - Can anybody please help me understand?
I found on the web some indications but would like you to confirm / extend them, in order to help me put all pieces together.
2 - Are the following statement correct and could you please explain them to me?
1.
A guideline that I was told:
If you plan on reaching out to multiple clients (Linux, Windows, etc.),
then use Web Services; otherwise, use Client / Server.
2.
If your application needs to be run on machines that would access the data
over a public network (internet) then you should go with web services because
the traditional client/server model is not acceptable due to not wanting
to expose your server publicly.
The web services you would expose publicly could be secure (HTTPS),
require some kind of authentication and only expose what you WANT to expose,
versus exposing a whole database
3.
One of the better reasons to use remoting is that it gives a large increase in
performance. But one of the down falls is that it is a good bit more complicated
to program than Web Services.
4.
The proper use of web services is really based on your "remote connectivity"
needs. If your application is going to be run in a controlled environment such as
a LAN/WAN where you can see the server thru a private or secure (VPN) network,
then you can build a traditional client/server application
5.
Web Services:
Though there are no major differences in the output of service with both these
models, the mobility and accessibility is definitely an advantage.
However, the lack of a great deal of personalization does come as a con against
the web-server based model.
Client Server:
The added security of client server is definitely a one up and it also gives the
option of controlling the updates and upgrades if any.
Initially though, client servers may come with a higher front-end cost.
Statements were extracted from the following links:
210
Some time has passed, and after studying many tutorials on the argument I can finally answer my own question:
1. Why should I implement a Web Service rather than a standard Client/Server protocol
Actually Web Services are yet another distributed computing technology (like CORBA, RMI, EJB, etc.). They allow us exactly to create client/server applications, and so are not alternative to them.
Clients (programs that want to access the Web Service) contact the Web Service (in the Server), and send a service request asking for the some information. The Server returns the wanted information through a service response.
Of course, this is a very sketchy example of how a Web Service works, but you can see it is exactly the same concept of how a normal Client/Server protocol works.
So, what makes Web Services special?
Well, Web Services have certain advantages over other technologies:
Web Services are platform-independent and language-independent, since they use standard XML languages. This means that my client program can be programmed in C++ and running under Windows, while the Web Service is programmed in Java and running under Linux.
Most Web Services use HTTP for transmitting messages (such as the service request and response). This is a major advantage if you want to build an Internet-scale application, since most of the Internet's proxies and firewalls won't mess with HTTP traffic (unlike CORBA, which usually has trouble with firewalls).
Of course, Web Services also have some disadvantages:
Overhead. Transmitting all your data in XML is obviously not as efficient as using a proprietary binary code. What you win in portability, you lose in efficiency. Even so, this overhead is usually acceptable for most applications, but you will probably never find a critical real-time application that uses Web Services.
Lack of versatility. Currently, Web Services are not very versatile, since they only allow for some very basic forms of service invocation. CORBA, for example, offers programmers a lot of supporting services (such as persistency, notifications, lifecycle management, transactions, etc.). Fortunately, there are a lot of emerging Web services specifications (including WSRF) that are helping to make Web services more and more versatile.
However, there is one important characteristic that distinguishes Web Services. While technologies such as CORBA and EJB are geared towards highly coupled distributed systems, where the client and the server are very dependent on each other, Web Services are more adequate for loosely coupled systems, where the client might have no prior knowledge of the Web Service until it actually invokes it. Highly coupled systems are ideal for intranet applications, but perform poorly on an Internet scale. Web Services, however, are better suited to meet the demands of an Internet wide application.
2. Are the following statement correct and could you please explain them to me?
1) If you plan on reaching out to multiple clients (Linux, Windows, etc.), then use Web Services; otherwise, use Client / Server.
TRUE
As stated above:
Web Services are platform-independent and language-independent, since they use standard XML languages. This means that my client program can be programmed in C++ and running under Windows, while the Web Service is programmed in Java and running under Linux.
If instead your distributed system architecture is known and homogeneous over all the nodes, you can write simpler and more coupled client/server applications in a fixed programming language.
2) If your application needs to be run on machines that would access the data over a public network (internet) then you should go with web services because the traditional client/server model is not acceptable due to not wanting to expose your server publicly. The web services you would expose publicly could be secure (HTTPS), require some kind of authentication and only expose what you WANT to expose, versus exposing a whole database
TRUE
With Web Services what the only thing you publicly expose to the outer world is a standard Web Server (to which clients can send HTTP requests). All the precious data and methods are instead protected at not accessible.
If instead you provide an access endpoint to your server process (e.g. IP address and service port number) directly to the internet, this would make your data and methods accessible by any process.
3) One of the better reasons to use remoting is that it gives a large increase in performance. But one of the down falls is that it is a good bit more complicated to program than Web Services.
TRUE
Remoting allows you to build more versatile services, and avoid the passing of lots of XML data, being therefore more performing.
4) The proper use of web services is really based on your "remote connectivity" needs. If your application is going to be run in a controlled environment such as a LAN/WAN where you can see the server thru a private or secure (VPN) network, then you can build a traditional client/server application
TRUE
Quoting again from the first part of the answer:
Web Services are more adequate for loosely coupled systems, where the client might have no prior knowledge of the Web Service until it actually invokes it. Highly coupled systems are ideal for intranet applications, but perform poorly on an Internet scale. Web Services, however, are better suited to meet the demands of an Internet wide application.
5) Web Services:
Though there are no major differences in the output of service with both these models, the mobility and accessibility of Web Services is definitely an advantage over standard C/S paradigm. However, the lack of a great deal of personalization does come as a con against the web-server based model.
Client Server:
The added security of client server is definitely a one up and it also gives the option of controlling the updates and upgrades if any. Initially though, client servers may come with a higher front-end cost.
TRUE
The first part of this statement refers to the fact that Web Services are more platform and language independent, and therefore more accessible, but as stated more times less versatile.
The second part remarks the fact that with more versatility you can more easily control and hide updates and upgrades.
As an example, if the maintainers of the Web service decide to change the service's interface and, thus its WSDL description, the client must go through the discovery phase again. This would not happen if using a standard C/S protocol.
113
webservices are client/server "apps".
with your browser , when you connect a website , the server outputs html or anything else readable by your browser. html can be generated from an application layer like php or .net. You browser is a client.
a web application(php / java /etc... ) itself can be a client of another webapplication. Imagine your app need to display , weather reports , to serve it to a browser.
your app on the server will connect another app through a protocol ( rest / soap / xml-rpc / etc ... ) to push or pull data from a server app , the server app can be anything php java , dotnet , your client app doesnt care because they talk through a defined protocol.
so a webservice allows a client and a server to talk together.
and there is no webservice vs client server , because webservices are all about client/server communication.
edit : i really dont know what your quoted text is talking about ... please give the source of that text.
45
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
