A brief introduction to WEB services

Services|web Web Services is the foundation of Grid service and the cornerstone of Ogsa and Iogsi (GT3). Understanding the WebService architecture is the basis for using GT3 to write grid services.
There has been a lot of talk about "Web Services" recently and many companies are also starting to respond to their business applications. So what exactly is Web services? Simply put, they are another distributed computing technology (like CORBA, RMI, EJB, etc.) that allows us to create client/server applications.
For example, let's assume that I have to develop a program for a chain store. The chain is distributed all over the country, but my product home directory (master catalog of product) is stored only in my central Office database, and the store's software must be able to access the product catalog. I can publish these directories through a web Service called Shopservice.

It is important that you do not make mistakes when publishing on a Web site. The information on the website (as you are reading) is written by people. The information on the Web service can be accessed by the software and is accessed directly from time to times (although there is a possibility for people to use the software). Although web Service relies heavily on existing Web technologies (like the HTTP we are seeing), they are not associated with Web browsers and HTML. We repeat: The website is for the service of the people, and the Web service is the:-) of the software services

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


Some of us might think: "Hey, wait a minute!" I can through RMI,CORBA,EJBS, and so many other technologies to achieve AH! "。 So. Why do I need a Web Service? Well, Web Service also has a lot better places than other technologies:

Web Service is platform-independent, language-independent because it uses a standard XML language, which means that our clients can write in C + + to run under Windows, while Web service is written in Java and run under Linux
Most Web services use HTTP to transmit messages (like service requests and responses). If you want to build an Internet-wide program, this is a major advantage because most Internet ' s proxies and firewalls do not disrupt HTTP transmissions (unlike CORBA having trouble crossing the firewall)

Of course, the Web service also has some of the following drawbacks:

Too much pressure. It is clear that all the data in the XML is not well defined and the binary code is highly efficient. When you win versatility, you reduce efficiency. In spite of that, this pressure is usually acceptable to most applications,


Narrow use. At present, because they only support a very basic type of service, the Web service is not a lot of use. For example, CORBA provides programmers with many of the services they are supporting (such as continuous service, notification, lifecycle management, transformations, etc.). In fact, on the next page, we can see that grid services can really compensate for the narrow uses.
However, distributed Web Service has a very important feature. Like CORBA and EJB technologies are oriented to tightly knit distributed systems, their clients and services are very dependent on each other. But Web Services is a loosely-oriented system, and clients can know the Web service knowledge, such as grid based applications, until they actually invoke the Web service.

A typical call to a Web service
How does all this work? Let's take a look at all the call steps for a full Web service call. Don't worry about those acronyms now (soap,wsdl,...), so we'll explain them in detail.







As we said earlier, a client can be unaware of how the Web service is invoked. So our first step is to find a place to meet our requirements for the Web Servicede, for example, we want to find a Web service that can tell us the temperature of the city. We can get the location of the Web service by contacting the UDDI registration point.
The UDDI registrar will return to tell us which server can provide us with the services we want (like the temperature of the U.S. city)
We now know the location of the Web service, but we don't know how to use it yet. We do know that it can give us the temperature of the city, but the real service is how to call it? The method we call may be called temperature getcitytemperature (int citypostalcode), but it can also be
int Getuscitytemp (string cityname, bool Isfarenheit). We have to ask how the Web Service describes itself. (Tell us how to use it)
Returns information in a language called WSDL.
We finally know where the Web service is and how to invoke it. The invocation method is implemented through SOAP. That way we would send a SOAP request asking for a city temperature.
The Web Service will gently return a SOAP response that contains the temperature we want, or return an error message when our request information is wrong.

Addressing the WEB service
We just saw a simple Web service invocation process. At one point the UDDI registration service "tells" the location of the client Web service. But.... How do I address the Web Service exactly? The answer is very simple: it's like our web page. We use the simple and easy URIs (uniform Resource Identifiers). If you are familiar with the term URL (uniform Resource Locator), don't worry: The URI and URL are actually the same thing.

For example, the UDDI registration service period may return the following URI:

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

This is easily considered to be a web address. However, Web Service is the software to remember this address (no longer let people directly remember). If you write a Web service URI into your Web browser, you may have an error message or an incomprehensible code (some Web service will show you a nice interface, but this interface is not the same as usual). When you have a URI for a web Service, you usually need to give the URI to a program. In fact, most of the client programs we write will receive the grid service URI as a command parameter.

Schema for Web Services
Now that we have seen the different actors in the Web service invocation process, let's get a better idea of the architecture of the Web service.


Service Discovery: This section allows us to look for Web service to meet our needs. This section is typically handled by UDDI (Universal Description, Discovery, and integration). GT3 currently does not support UDDI.


One of the most interesting features of service Description:web service is their ability to describe themselves. This means that once you've positioned the Web Service, you can ask him to "describe himself" and tell you how to manipulate and use it. This is handled through web Services Description Language (WSDL)


Service invocation: The process of invoking a Web service (and generally any of a distributed service similar to a CORBA object or Enterprise Java Beand) contains information that is transmitted between the client and the server. SOAP (Simple Object Access Protocol) regulates how we format the request information sent to the server and how to format the response information for the server itself. In theory, we can also use other calling languages (such as XML_RPC or even some ad hoc XML language). However, soap is a more willing choice for Web service.


Transport: Finally, all of this information can be transmitted between the server and the client. The protocol selected in this section of the schema is http (hypertext Transfer Protocol), the same as the protocol for accessing regular web pages on the Internet! In theory we can still use other protocols, but the HTTP protocol is currently the most widely used.
What does the Web Service application look like?
OK, now that you have a concept of what a Web service is, you may be expected to start writing Wev service immediately. Before you do this, you might be like the structure of a web-based service application. If you've ever written CORBA or RMI, this structure will look

First of all, you should know that although there are many protocols and many languages emerging around, Web Service programmers do not usually have to write a line of soap or WSDL code. Once we arrive at the moment when our clients need to call a Web service, we authorize a task called a local stub (a client stub) in the software. The good news is that there are a number of tools available to automate the creation of a local stub (a client stub) describing a WSDL based Web service.

This way you do not need to interpret the typical call dialog process verbatim. A Web service client typically does not pass through all the steps in a single call. A more correct event flow is as follows:

We use UDDI to locate a Web Service that meets our needs.
We get a WSDL description of this Web service.
We generate stubs and then include them in our applications.
This application uses stubs every time the Web Service is invoked.
Server-side programming is relatively easy. Instead of having to write a complex service program that needs to dynamically interpret SOAP requests and generate SOAP responses, we can simply implement all of the functionality of our web service and then produce a server stub (the term skeleton is also used), The stub is responsible for interpreting the request and then forwarding the requests to the server's implementation section. When the server Implementation section contains a result, it will give the result to the server stub, thus generating the appropriate SOAP response. This server stub can also be generated through WSDL, or interfaces defined from other languages (like IDL). In addition, server implementations and server stubs are managed by code called Web Service containers in the software, which ensures that the Web Servvicehttp request is delivered directly to the server stub.

The following figure describes the steps to invoke a Web service.



Let's assume that our client has positioned the Web service, generated a client stub from the WSDL description, and that the server-side program also generates a service stub.

Whenever a client needs to invoke a Web Service, it needs to invoke the client stub. This client stub converts this local call into an appropriate SOAP request. This step is often referred to as the marshalling process (marshalling processes).
SOAP requests are sent over the network using the HTTP protocol. The WEB service container receives a request for soap and hands it to the server stub. The server stub transforms the SOAP request into a form that the server implementation program can understand. This step is often referred to as dissolution.
The server Implementation section receives a request from the server stub to perform the requested work. For example, we call the int add (int a, int b) method, and the server implements the addition function.
The result of the execution of the request is converted to a SOAP response by server stub processing.
The SOAP response is sent over the network using the HTTP protocol. The client stub receives a SOAP response and converts it to a form that the client application can understand.
The end client application accepts the result of invoking the Web service and uses the result.