Web Services is the foundation of Grid services, also the groundstock (GT3) of OGSA and IOGSI. Understanding WebService architecture is the basis of using GT3 and writing grid services.
There are a lot of discussions about "Web Services" and many companies have also begun to respond to their business applications. So what is the web service? Simply put, they are another distributed computing technology (like Corba, RMI, EJB, etc.), allow us to create client / server applications.
For example, let us assume that I have to develop a program for a chain store. This chain is distributed across all over the country, but the master catalog of products is only stored in the database of my central office, and the stored software must be able to access this product catalog. I can publish these directories through a Web Service called ShopService.
The important thing is: I can't make mistakes when I was released on the website. Information on the website (like you are reading) is written for people. The information on the Web Service can be accessed by software, and will be accessed directly from time to time (although there are possibilities of this software). Although Web Service relies greatly dependent on existing Web technology (http we are seeing), they are not in contact with HTML with the web browser. We repeat again: the website is serving people, and the web service is serving software :-)
The client (PC in the store) will be connected (on the server) WebService at that time and send a service request that requires a directory. The server will return to directory information through a service response. Of course, this is a very scribble example describing how Web Service works. Wait a minute, we will see a very detailed explanation.
Some people in us may think so: "Hey, wait! I can achieve many other techniques through RMI, CORBA, EJBS, and many other technologies!". Then. Why do you want to Web Service? Well, Web Service also has a lot of places better than other technology:
Web Service is not related to the platform of the platform, which means that the language is independent of the platform, which means that our client can write under Windows with C , and Web Service is written under Linux using Java.
Most of the Web Service uses HTTP transfer messages (like service requests and responses). If you want to build an Internet-wide program, this is a major advantage, because most of the Internet's proxy and firewall do not destroy HTTP's transmission (unlike Corba, it will be troublesome when crossing the firewall)
Of course, Web Service also has the following shortcomings:
overstress. Obviously all data in XML did not define high binary code efficiency. Reduce efficiency while winning versatility. Despite that, this pressure is usually acceptable by most applications.
Uses narrow. Currently, because they only support the very basic type of service, the use of Web Service is not a lot. For example, CORBA provides many services that are supported by the programmer (like continuous service, notifications, lifecycle management, conversion, etc.). In fact, in the next page we can see that the grid service can truly compensate for the shortcomings of the use of stenosis.
However, there is a very important feature of distributed web service. Like CORBA and EJB technology are close-to-face-oriented distributed systems, their clients and serve are very dependent on each other. However, Web Services is a loose-oriented system, and the client can only know the Web Service knowledge until Web Service, such as grid-based applications. A typical call of Web Service
How do these work? Let's take a look at all of the complete calls to the Web Service call. Don't worry about those abbreviations (SOAP, WSDL, ...), let's explain them in detail.
As we mentioned earlier, a client can not know how web service is called. So our first step is to find the location of Web ServiceDe that meets our requirements, for example, we want to find a Web that can tell us US Temperature SERVICE. We can contact the UDDI registration point to get the Web Service location. The UDDI registrar will return to tell us which server can provide us to our service (like the temperature of the US City) We now know the location of Web Service, but we still don't know how to use it. We really know that it can give us the temperature of the US city, but how is the service call? 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 Web Service how to describe yourself. (Tell us how to use it) returns information with a language called WSDL. We finally know the location of the Web Service and how to call it. The calling method is implemented by SOAP. So we send SOAP requests to request a city temperature. The web service will be mild to return a SOAP response that contains the temperature we want, or returns an error message when our request information is incorrect.
Address of Web Service
We have just seen a calling process of a simple web service. At a point in the UDDI registration service, "tell" the location of the client web service. But .... How to accurately add Web Service? This answer is very simple: just like our webpage. We use simple and simple URIS (UNIFORM Resource Identifiers). If you are familiar with this noun by URL (Uniform Resource Locator), don't worry: URI and URL are actually the same thing.
For example, the UDDI registration service period may return as follows URI:
http://webservices.mysite.com/weather/us/weatherservice
This is easy to be considered an address of a web page. However, Web Service is to remember this address through software (no longer remember directly). If you write a web service's URI into your web browser, you may go to an error message or an unpublished code (some web services will show you a beautiful interface, but this interface and usually different ). When you have a web service's URI, you usually need to hand over this URI to a program. In fact, most of our client programs we write will receive the grid service URI as a command parameter.
Architecture of Web Services
Now we have seen different actors in the web service call process, let us know more about the web service's architecture!
Service Discovery: This part allows us to find Web Service to meet the needs. This part is usually processed by UDDI (Universal Description, discovery, and integration). GT3 does not currently support UDDI.Service Description: One of the most interesting features of Web Service is that they can be self-description. This means that once you are positioned with Web Service, you can ask him to "describe yourself" and tell you how to operate and use it. This is processed by Web Services Description Language (WSDL)
Service Invocation: Call a web service (and a generally similar Corba object or distributed service for Enterprise Java Beand), included information transmitted between the client and the server. SOAP (Simple Object Access Protocol) Specifies how we format request information to the server and how to format the response information of the server itself. In theory, we can also use other call languages (such as XML_RPC or Even Some Ad Hoc XML LANGUAGE). However, SOAP is a more happy choice for Web Service.
TRANSPORT: Finally, all of these information can be transferred between the server and the client. Submersions This part of the selected protocol is HTTP (Hypertext Transfer Protocol), the same as the protocol on the Internet on the Internet! We can still use other protocols in theory, but the HTTP protocol is the most widely used.
What does the web service application look?
OK, what is the Web Service already has a concept, you may be expected to start writing WEV Service. Before you do this, you may be like a web service-based application's structural style. If you have written CORBA or RMI, this structure will look
First, you should know that despite a lot of protocols and many languages that surrounded, the web service programmer usually does not need to write a line of SOAP or WSDL code. Once we arrived at our client, we authorized the task called the local stub (a client stub) in the software. Good news is a lot of tools that can be used to automatically generate local stub (a client stub) based on WSDL-based Web Service.
This way you don't need to explain the "Typical Call" dialog process. A Web Service client usually does not pass all steps during a call. A more correct event process is as follows:
We locate a Web Service that meets us needs through UDDI. We get WSDL descriptions about this Web Service. We generate STUB and then contain them in our app. This app uses stub when you call Web Service.
The server is more programming. We don't have to write a complex need to dynamically explain the SOAP request and generate the SOAP-responded service, we can simply implement all the features of our web service, then generate a server stub (The Term Skeleton IS Also Used), this stub is responsible for explaining Requests then transfers these requests to the server's implementation section. When the server implementation part contains a result, it will give this result to server stub, which produces a suitable SOAP response. This server STUB can also be generated by WSDL or from other languages (like IDL). Furthermore, server implementation and server stub are managed by software called the Web Service container through software, which make sure that the subsection is sent to the Web ServviceHTTP request directly to the server stub.
The figure below describes the steps to call a web service. Let's assume that our client has locked Web Service, which generates client stub from the WSDL description, and the server STUB is also generated.
Whether the client needs to call the Web Service, it needs to call client stub. This client STUB converts this local call to the appropriate SOAP request. This step is often referred to as a group process. SOAP requests are sent through the network using the HTTP protocol. The Web Service container is given to the server stub after receiving the request for SOAP. Server STUB puts the SOAP request conversion server to implement the form of the program to understand. This step is often referred to as dissolution. The server implementation section receives the requested job after receiving the request from the server stub. For example, we call the int Add (int A, int b) method, the server implements the addition function. The result of the execution request is converted to the SOAP response by the server STUB. The SOAP response is sent through the network using the HTTP protocol. Client stub receives the SOAP response and converts it to client applications. The final client application accepted the result of calling the Web Service and using this result.
