Hello there. In this lesson, we will talk about web services. So, let's start. Although the term web service has various imprecise and evolving meanings, a working definition should be enough for the upcoming code example which consists of a service and a client also known as a consumer or requester. As the name suggests, a web service is a kind of webified application. An application typically delivered over HTTP, hypertext transport protocol. HTTPS, HTTP secure adds a security layer to HTTP. Hence a service delivered over HTTPS likewise counts as a web service. Until the main topic of interest is web service security, HTTP should be understood to include HTTPS. Amazon, a pioneer in web services is well known for its various websites, among which is the e-commerce site for shopping. Amazon has other popular websites as well. Of interest here is that the data and functionality available at Amazon websites are likewise available as Amazon Web Services. For example, someone can use the browser to shop interactively at the Amazon e-commerce site, but this person could also write a program as later example show to do the shopping through the corresponding Amazon e-commerce web service. 

Amazon is particularly good at pairing off its websites with web services. Web services can be programmed in a variety of languages, old and new. The obvious way to publish a web service is with a web server. A web service client needs to execute on a machine that has network access usually over HTTP to the web server. In more technical terms, a web service is a distributed software system whose components can be deployed and executed on physically distinct devices. Consider, for example, a web server host 1 that hosts a web service and a mobile service host 2 that hosts an application issuing requests against the service on host 1. Web services maybe more architecturally complicated than this, of course. For one thing, a service may have many clients issuing requests against it and the service itself may be composed of other services.

 For instance, a stock picking web service might consist of several code components each hosted on a separate commercial grade web server and any mix of PCs, handhelds, and other network to devices might host programs that consume the service. Although the building blocks of web services are relatively simple, the web services themselves can be arbitrarily complex. We've talked about this before, but it's worth repeating. An HTTP request goes by definition from client to server, and an HTTP response goes also by definition from server to client. For web services over HTTP, the HTTP messages are the infrastructure and these HTTP messages can be combined into basic controversial patterns that characterize a web service. For example, if the web service conversation starts with an HTTP request that expects an HTTP response, the pattern is the familiar request response conversation. By contrast, if the conversation starts with an HTTP message from the server, a message that expects a message from the client in return, then the pattern is solicit response. Richer conversational patterns can be composed out of such basic two message patterns. 

Indeed, these two message patterns are composed of even more primitive ones. A message from client to server without a response is a pattern known as one way. And the reverse pattern from server to client without a response is known as notification. Web services tend to be simple in structure. The four conversational patterns enumerated just now cover most modern web services and request response is the pattern that still dominates. Web services come in two popular flavors. SOAP-based and REST style. SOAP is an XML dialect with a grammar that specifies the structure that a document must have in order to count as SOAP. In a typical SOAP-based service, the client sends SOAP messages to the service and the service responds in kind with SOAP messages. REST style services are hard to characterize in a sentence or two but with respect to pattern, these services tend to be request response. The same holds for SOAP-based services. For now, a REST style service is one that treats HTTP not only as transport infrastructure, but also as a set of guidelines for designing service requests and service responses. In a REST style service, HTTP itself can be seen as an API. SOAP has standards, tool kits, and bountiful software libraries. REST has no official standards, comparatively few tool kits and uneven software libraries among programming languages. 

Yet there is growing support for REST style services across programming languages. Hence, it seems only a matter of time until tool kits and libraries for REST style services mature. From a historical perspective, the RESTful approach to web services can be viewed as an antidote to the creeping complexity of SOAP-based web services. SOAP-based services are designed to be transport neutral. As a result, SOAP messaging may seem overly complicated if the transport is in fact HTTP. At present, the distinction between the two flavors of web services is not sharp because a SOAP-based service delivered over HTTP can be seen as a special case of a REST style service. HTTP remains the dominant transport for SOAP-based services. SOAP originally stood for Simple Object Access Protocol and then by serendipity but never officially might have stood for Service Oriented Architecture, SOA protocol. The World Wide Web Consortium currently oversees SOAP, and SOAP is officially no longer an acronym. Except in test mode, the client of either a SOAP-based or REST style service is rarely a web browser, but rather usually an application without a graphical user interface. The client may be written in any language with the appropriate support libraries. Indeed, a major appeal of web services is language transparency. The service and its client need not be written in the same language. 

Language transparency is a key contributor to web service interoperability, that is, the ability of web services and their consumers to interact seamlessly despite differences in programming languages, support libraries, operating systems and hardware platforms. There is no magic in language transparency of course, if a web service written in Java can have a Python or Ruby consumer, there must be an intermediary layer that handles the differences in data types between the service and the client languages. XML technologies which support structured document interchange and processing act as such intermediary level. Another intermediary level is JSON, JavaScript Object Notation. XML and JSON are both data interchange formats but JSON clearly has the upper hand with data receivers written in JavaScript because a JSON document is the text representation of a native JavaScript object. Web service clients are increasingly JavaScript programs embedded in HTML documents and executing in a browser. Such clients process JSON with less fuss than they do XML. Even among non-JavaScript clients, JSON has gained in popularity. 

For one thing, JSON is more readable than XML because JSON has relatively less makeup. Several features distinguish web services from other distributed software systems. Here are three: Open infrastructure. Web services are deployed using industry standard vendor independent protocols and languages such as HTTP, XML, and JSON, all of which are ubiquitous and well understood. Web services can piggyback on networking, data formatting, security and other infrastructures already in place, which lowers entry costs and promotes interoperability among services. Organizations that publish websites with production grade web servers such as Apache 2, IIS and nginx can publish web services with these very web servers. Firewalls and other security mechanisms that defend websites, thereby defend web services as well. Platform and language transparency. Web services and their clients can interoperate even if written in different programming languages. Languages such as C, C Sharp, Go, Java, JavaScript, Perl, Python, Ruby and others provide libraries, utilities, and even frameworks in support of web services. 

Web services can be published and consumed on various hardware platforms and under different operating systems. Web services are an excellent way to integrate diverse software systems while allowing the programmer to work in the programmer's language of choice. The web service approach to software development is not to rewrite but rather to integrate. Modular design. Web services are meant to be modular in design so that new services can be composed out of existing ones. Imagine, for example, an inventory tracking service integrated with an online ordering service to compose a service that automatically orders the appropriate products in response to inventory levels. Web services are the small software parts out of which arbitrarily large systems can be built. A guiding principle in web service design is, to begin with very simple service operations, essentially uncomplicated functions, and then group these operations into services, which in turn can be orchestrated to work with other services and so on indefinitely. What good are web services?

This obvious question has no simple answer, but let's try to explain the benefits and promises of web services can be clarified with two examples. The first example underscores how the distinction between websites and web services continues to blur. The data and functionality available at one can be available at the other. The second example focuses on how web services can be used to integrate diverse software systems and to make legacy systems more widely accessible. A visit to a website such as the Amazon e-commerce site is often interactive. A shopper uses a browser to search the Amazon site for desired items, places some of these items in a shopping cart, checks out the cart, finalizes the order with a credit card or the equivalent, and receives a confirmation page, and usually an email. Pioneers and web services such as Amazon expose the information and functionality of websites through web services as well.

Searching and shopping against Amazon are tasks that are automated readily because Amazon makes a point of coordinating its websites with its web services. In any case, here's a sketch of how a search and shop experience might be automated. A shopper has a database table or even a simple text file wishlist.txt that contains items of interest such as books, movies, or other search and shop category that Amazon supports. The database table or text file which acts as a wish list with constraints provides pertinent information such as the ISBN of a desired book, the maximum price the shopper is willing to pay, the number of items to order, and so on. The shopper programs a client in whatever language the shopper prefers that reads the database table or text file, opens a connection to Amazon, searches Amazon for wishlist items, checks whether the items are available under the constraints in the wishlist, and orders the items that meet the constraints. The client program checks an email account for the confirming email. If all goes well, the client places confirmation information in a data store such as a database table or another simple text file. An interactive shopping experience thus gives way to an automated one. Of course, some shoppers derive as much pleasure from the activity as from the outcome.

The point is not that shopping should be automated, but rather that web services open up this possibility for many tasks, shopping included. At one time, HTML screen scraping was a popular way to have applications other than browsers, hit a website, download HTML documents, and then parse the HTML for its informational content. As more sites follow the Amazon practice of exposing the same or at least nearly the same data and functionality as both websites and web services this screen scraping is becoming increasingly unnecessary. The second example of what makes web services attractive focuses on a major challenge in modern software development, systems integration. Modern software systems are written in a variety of languages, a variety that seems likely to increase. These software systems will continue to be hosted on a variety of platforms. Institutions large and small have significant investment in legacy software systems whose functionality is useful and perhaps mission-critical. Few of these institutions have the will and resources, human or financial to rewrite their legacy systems. How are such disparate software systems to interact? That these systems must interact is taken for granted nowadays, it's a rare software system that gets to run in splendid isolation.

A challenge then is to have a software system interoperate with others which may reside on different hosts under different operating may be written in different languages. Interoperability is not just a challenge, but also a current requirement of production software. Web services provide a relatively simple answer to question of how diverse software systems written in many languages and executing on various platforms under different operating systems can interoperate. In short, web services are an excellent way to integrate software systems. Web services address the problem of interoperability directly because such services are first and foremost, language and platform neutral. If a legacy COBOL system is exposed through a web service, the system is thereby interoperable with service clients written in other currently more widely used languages. Exposing a legacy COBOL system as a web service should be significantly less expensive than say, writing the system from scratch. Legacy database systems are an obvious source of data and functionality, and these systems too can be made readily accessible beyond the local machine that hosts the database through web services. In the past, data sources for applications were usually data stores such as relational database management systems, RDBMS, or even local file systems.

Nowadays, web services also serve as data sources, at least as intermediate ones that are backed up ultimately with persistent data stores. Indeed, web services integrate readily with RDBMS and other data storage systems as front ends that are easier conversational partners than the data storage systems themselves because web services at least ones have APIs that publish their functionality in high-level language-neutral and platform-independent terms. A web service thus can be viewed as a uniform access mechanism for divergent data stores. A web service can act as the front end of a database system, a front end that exposes through a published API, the data and functionality of the database. Web services are inherently distributed systems that communicate mostly over can communicate over other popular transports as well. The communication payloads of web services are typically structured text, usually, XML or Jason documents, which can be inspected, transformed, and otherwise proceeded with widely and even freely available tools. When efficiency demands it, however, web services can also deliver compact binary payloads. Finally, web services are work in progress with real-world distributed systems as their test bed. For all of these reasons, web services are an essential tool in any modern programmer's toolbox. So, that's it for now. Hope to see you in our next lesson. Have a nice day.