So … if you haven’t heard about Web Services by now, then you must be living under a rock… pretty much like I have. 🙂 But have no fear, we’ll get to the bottom of it. Get it? The “bottom”… ah.. nevermind.
|This topic will discuss Web Services in general and will not cover SOAP or REST.|
Web Services emerged in the beginning of 2000 and slowly became the most popular way in modern web development for applications to communicate with each other. They are basically taking Web Applications to the next level by being platform independent and available from anywhere.
What are they good for? Well, your application can use Web Services to outsource “small” bits work that requires resource that you don’t currently have or wish to maintain.
Timewise, in 2002 the W3C Web Services Architecture Working Group defined a standardized implementation of Web Service Architecture that will be know as SOAP Web Services. This architecture includes web service interface in XML format a.k.a. WSDL file that describes service’s API and is able to function only with Simple Object Access Protocol messages (thus it’s name) over HTTP.
Later, in 2004 W3C extended their definition, identifying two distinct type of web services:
- REST compliant that will manipulate representation of objects thru stateless Web API calls;
- Arbitrary Web services, in which the service may expose an arbitrary set of operations;
Regardless of their type, the Web Services way of machine-to-machine communication is different that the traditional human-to-machine architecture where you have human user interacting with the server app thru UI in a browser.
Web Services don’t serve human users, but the calling applications instead. So they don’t need fancy HTML or CSS code, but instead exchange machine readable file formats such as XML and JSON. The applications that consume Web Services (known as Client) requests data from them that may or may not be included in the final HTML representation for the user. There may not be any HTML involved at all. Some Web Services may be used to simply update records in the database or change account status.
For example, all major social platforms like Facebook, Twitter, Google+, etc. are now using Web Services to create, pass, and post updates on your wall or timeline. If you ever wondered how does Facebook posts on your wall whenever you complete new game level on a completely separate website, not designed by Facebook, then wonder no more.
Here is a simple explanation of how such workflow may behave: The game website will be the Client Web App. When the Client Web App needs to post to FB it will make a call to FB’s web service. The call will first hit Web Service 1 that will be FB’s Authentication Web Service. Once user identity is confirmed, Web Service 1 will make subsequent call to Web Service 3 that will be FB’s Wall Posting Web Service which will post the update on your wall.
Or it all may happen by calling just one Web Service 2 that does both authentication and posting, though that may be considered as bad design.
“In practice, the web service typically provides an object-oriented web based interface to a database server, utilized for example by another web server, or by a mobile application, that provides a user interface to the end user. Another common application offered to the end user may be a mashup, where a web server consumes several web services at different machines, and compiles the content into one user interface.”
The most important aspects of Web Services:
- Usability – No need to reinvent the wheel when it comes to regular or business specific operations that you don’t want to burden you code with. Especially if someone has already created, tested, improved, and shared them on the web. You app just needs to consume the Web Service that it needs and that is already available, publicly or in the company. You can actually choose the Web Service that best fits your app’s needs.
- Interoperability – This is the most important benefit of Web Services. Web Services typically work outside of private networks, offering developers a non-proprietary route to their solutions. Since the Web Services are browser, language, and platform independent you are free to develop your project without concerning yourself with those restrictions.
- Loosely Coupled – You app will share little dependencies with the Web Services that it consumes making changes to your app more safe in term of impacting unrelated or unexpected areas.
- Deployability – Web Services are deployed and accessed over standard web technologies making them very easy to deploy to servers running anywhere on the globe.
Web Service have the two general uses reusable application-components and Connect existing software. Let’s quickly examine both:
Reusable application-components: thanks to the Interoperability feature common functionality can be extracted into single Web Service that can be accessed by different platforms (Windows, Unix, Linux, etc.) written in different languages (Java, .NET, Python, etc.). Take for example the below diagram: different platforms can call the same Web Service and execute central generateReports() method instead of having to implement it separately.
Connect existing software: yet again thanks to the Interoperability feature system has the ability to link their data regardless of the underlying language. Previously, two web apps written in different languages could not exchange data so easily. Take for example below diagram. There you have two web containers implemented with different programing languages: Java and .NET. In the past, if the Java App wants to get list of users to generate reports for from the .NET App it will have to either take an XML export or fetch the list directly from the Database. Both solutions are heavy and involve third party APIs. With the introduction of the User Web Service however the Java App can get decoupled from the DB and a single request over HTTP will return the list of users. This way the process less error prone, not to mention more elegant.