Introduction to Web Services

Web services are the foundation of grid services and the cornerstone of OGSA and iogsi (GT3). Understanding the WebService architecture is the basis for compiling grid services using GT3.
Recently there have been many discussions about "Web services" and many companies have begun to respond to their enterprise applications. So what is Web Services? Simply put, they are another distributed computing technology (such as CORBA, RMI, and EJB) that allows us to create client/server applications.
For example, let's assume that I have to develop a program for a chain store. This chain store is distributed across the country, but my main product catalog (Master catalog of product) is only stored in the database of my central office, and the store's software must be able to access this product catalog. I can publish these directories through a Web service called shopservice.

It is important that errors do not occur when the website is published. The information on the website (as you are reading) is compiled by people. However, information on web services can be accessed by software and accessed from time to time directly by people (despite the possibility of using the software ). Although Web services rely heavily on existing web technologies (such as the HTTP we are seeing), they are not associated with the web browser and HTML. We repeat it again: websites serve people, while web services serve software.

The client (the PC in the store) will connect to (the WebService on the server) at that time and send a service request that requires a directory. The server returns the directory information through a service response. Of course, this is a very sloppy example of how the Web service works. Wait, we will see a very detailed explanation.

Some of us may think like this: "Hey, wait! I can use RMI, CORBA, ejbs, and many other technologies! ". So. Why do we need web services? Well, there are many advantages over other technologies in Web Services:

Because the Web Service uses the standard XML language, it is platform-independent and language-independent. This means that our client can run in Windows using C ++, web services are written in Java and run in Linux
Most Web services use HTTP to transmit messages (such as service requests and responses ). If you want to establish an Internet-wide program, this is a major advantage, because most of the Internet's proxies and firewalls do not disrupt HTTP transmission (unlike the troubles that CORBA may encounter when it passes through the firewall)

Of course, Web services also have the following Disadvantages:

The pressure is too high. It is obvious that binary code that is not defined for all data in XML is highly efficient. It reduces efficiency while winning versatility. However, this pressure is generally accepted by most applications,

Narrow purpose. Currently, they only support basic service types, so there are not many web services. For example, CORBA provides programmers with a lot of services that are currently supported (such as continuous services, notifications, lifecycle management, and conversion ). In fact, we can see that the grid service can actually compensate for the disadvantages of narrow usage.
However, distributed Web services have an important feature. For example, the client and the server are very dependent on each other because the technology of CORBA and EJB is oriented to closely related distributed systems. However, Web services are oriented to loose systems. The client can only know the knowledge of web services until the Web Service is actually called, such as grid-based applications.

A typical web service call
How does this work? Let's take a look at all the call steps for a complete Web service call. Do not worry about the acronyms (SOAP, WSDL,...). We will explain them in detail later.

As we mentioned earlier, a client does not know how the Web Service is called. so our first step is to find the location of the Web servicede that meets our requirements. For example, we want to find a web service that can tell us the temperature of the U.S. cities. We can contact the UDDI registration point to obtain the location of the web service.
The UDDI registrar will return a message indicating which server can provide us with the services we want (like the temperature in American cities)
We now know the location of the web service, but we do not know how to use it. We do know that it can give us the temperature of American cities, but how is the real service called? The method we call may be called temperature getcitytemperature (INT citypostalcode), but it can also be
Int getuscitytemp (string cityname, bool isfarenheit). We must ask how the Web Service describes itself. (Tell us how to use it)
Return information in a language called WSDL.
We finally know the location of the web service and how to call it. The calling method is implemented through soap. Then we will send a SOAP request to request the temperature of a city.
The Web Service gently returns a soap response containing the temperature we want, or an error message when our request information is incorrect.

Web service addressing
We just saw a simple web service call process. At one point, the UDDI registration service "tells" the location of the client web service. But how can we accurately address Web Services? The answer is very simple: Just like our webpage. We use simple and simple Uris (Uniform resource identifiers ). If you are familiar with the term URL (Uniform Resource Locator), don't worry: URI and URL are actually the same thing.

For example, the following URI may be returned during the UDDI registration service period:

Http://webservices.mysite.com/weather/us/WeatherService

This is easily considered a webpage address. However, Web services use software to remember this address (it is no longer directly remembered ). If you write a Web Service URI into your web browser, you may get an error message or code that is hard to understand (some Web Services will show you a beautiful interface, but this interface is different from the usual one ). When you have a web service Uri, you usually need to give it to a program. In fact, most of the client programs we write will receive the Grid Service URI as a command parameter.

Architecture of Web Services
Now we have seen different activists in the Web service calling process. Let's have a better understanding of the web service architecture!

Service Discovery: This part allows us to find the Web service that meets our needs. This part is usually handled by UDDI (Universal Description, discovery, and integration. Currently, GT3 does not support UDDI.

Service Description: One of the most interesting features of web services is that they can describe themselves. This means that once you locate the web service, you can ask it to "Describe yourself" and tell you how to operate and use it. This is handled through Web Services Description Language (WSDL ).

Service invocation: The process of calling a web service (and any general distributed service similar to a CORBA object or Enterprise Java beand) contains information transmitted between the client and the server. Soap (Simple Object Access Protocol) Standardizes how to format the request information sent to the server and how to format the response information of the server. Theoretically, we can also use other calling languages (such as xml_rpc or even some ad hoc XML language). However, soap is a more desirable choice for Web Services.

Transport: Finally, all the information can be transmitted between the server and the client. The protocol used for this part of architecture is HTTP (Hypertext Transfer Protocol), which is the same as the protocol used to access common web pages on the Internet! Theoretically, we can still use other protocols, but HTTP is currently the most widely used.
What does a Web Service Application look like?
OK, you have a concept about what Web service is, and you may be expected to write WEV service immediately. before you do this, you may be like what kind of structure of the web service-based application is. If you have written a CORBA or RMI, this structure will look like

First, you should know that although there are many protocols and many languages emerging around you, Web service programmers generally do not need to write a line of soap or WSDL code. Once we reach the moment that our client needs to call a web service, we authorize the software a task called local stub (a client stub. The good news is that many tools are available to automatically generate local stub (a client stub) based on the WSDL Web Service Description for us ).

In this way, you do not need to explain the "typical call" dialog process literally. A Web service client generally does not go through all the steps in a call process. A more correct event process is as follows:

We use UDDI to locate a web service that meets our needs.
We get the WSDL description about this web service.
We generate stub and include them in our application.
This application uses stub every time it calls web service.
Programming on the server is relatively easy. We don't have to write a complex service program that needs to dynamically interpret SOAP requests and generate soap responses. We can simply implement all the functions of our web service, then a server stub (the term skeleton is also used) is generated. This stub is responsible for interpreting requests and then forwarding these requests to the server's implementation part. When the server implementation part contains a result, it will deliver the result to the server stub, which produces a suitable soap response. This server stub can also be generated through the WSDL description, or interfaces defined from other languages (such as IDL. In addition, both the server implementation and the server stub are managed through the code in the software called Web Service container. This container will ensure that the Web servvicehttp request is submitted directly to the server stub.

Describes how to call a web service.

Let's assume that our client has located the Web Service, and the client stub is generated from the WSDL description, and the server program also produces the server stub.

No matter when the client needs to call web service, it needs to call the client stub. This client stub will convert this local call to an appropriate SOAP request. This step is often called grouping alling process ).
SOAP requests are sent over the network using the HTTP protocol. The Web Service container receives the SOAP request and delivers it to the server stub. The server stub converts the SOAP request to a form that can be understood by the server implementation program. This step is often called disband.
The server executes the requested work after receiving requests forwarded from the server's stub. For example, we call the int add (int A, int B) method, and the server implements the addition function.
The result of the execution request is converted from the server stub to the soap response.
The soap response is sent over the network using the HTTP protocol. The client stub receives the soap response and converts it to a form that can be understood by the client application.
The client application finally receives the result of calling the web service and uses the result.