[WS] Web Service series (1) Introduction

The Web Service series plan consists of about 10 posts to introduce various concepts and develop web service tools. In the first article, I will briefly introduce the concept of Web Services and demonstrate the specific application scenarios of a web service. The article will not be too long, because it will be very tiring. Anyway, I am a "impatient" person.

Web Services is a mysterious concept in the eyes of many people. The root cause is that Web services are widely publicized, but they are rarely used, it gives a complicated and hard-to-understand feeling. In addition, Web services are based on XML, and many people do not understand XML itself, although they may write xml configuration files every day.

When talking about the origin of web services, we must first talk about SOA (Service-Oriented Architecture). Like many epoch-making software technologies, SOA is fundamentally designed to solve the software crisis. People who have done projects have such feelings. As the project progresses, the relationship between modules is getting closer and closer. Any small modification may cause instability of the entire system, however, the customer's requirements are constantly changing, and the result is that the project ended with almost failed results.

From the development trend of (distributed) software, the coupling between modules in C/S-> B/S-> SOA is from tight to loose, and the loose coupling is conducive to modification. We often talk about various design patterns, most of which are not to reduce the coupling between classes.

Here I will reference the definition of SOA on the IBM Website:Service-Oriented Architecture is a component model that appliesProgramDifferent functional units (called services) are linked by well-defined interfaces and contracts between these services. Interfaces are defined in a neutral way. They should be independent of the hardware platform, operating system, andProgramming Language. This allows services built in various such systems to interact in a unified and universal manner.(Full text)

To put it bluntly, there are three roles in the system: service provider, service user, and registration center. The provider publishes the service to the Registration Center, and the user discovers the required service through the registration center, then, bind the service provider and call the service.

So what is the relationship between Web Services and SOA? It can be said that Web services are an implementation of SOA, a bit like the relationship between Tomcat and JSP/servlet specifications. SOA is a relatively virtual concept. For example, it only defines some interfaces and protocols. How should we define these things? Then, Web Services will embody them: the protocols used by Web services are based on XML. SOA only requires three roles, and the three roles in Web Services have specific implementation methods. Here, you may ask, what are the implementations of SOA? Both CORBA, DCOM, and J2EE can be considered, but I don't think they are pure. At least they don't all have neutral protocols.

Now we should use a specific example to illustrate the web service. Assume that a function is required in our system to query local weather conditions (the same for world time and currency exchange rates ), obviously, we will not develop a program to search for data from the Meteorological Department database. This requires many procedures and is not necessary. What's more, this will increase the coupling between us and the meteorological department. If the database structure of the meteorological department changes one day, we will have to modify our ownCodeIf they forget to inform us of this change, imagine what the customer will see?

To use web services, we can find weather-related services from a registration center. In the results, we may choose services with lower charges or slightly higher charges but more stable and accurate charges. From the Registration Center, we can get a complete description of the selected service, which contains various data types and calling methods. With this information, you can use tools to generate these necessary classes, as well as the client stub, you can use this stub to call a remote web service. In our example, after the call, the service provider will return a message containing the result. In our system, we can get the desired result from the message and display it to the customer. In this way, a complete Web service call is formed. This call method is called static call, because the address of the service provider (called the call endpoint) in stub is written, and another method is called dynamic call, it will be discussed later.

What are the differences between the Web Service and the previous RPC (Remote Procedure Call? RPC usually requires that the caller and the called are homogeneous, that is, they are written in the same language, and Web services do not have this requirement (the trick is to use XML to encapsulate messages ), this greatly increases the flexibility. In addition to RPC-like methods, Web service calls can also be based on messages. service users can only receive messages, or send messages only. This method is very useful in some applications.

Now, let's sum up the content of this lecture: the Web Service is the implementation of SOA, and the Web service is not RPC.

Next, I will give a detailed description of the structure and protocol stack of Web Services, and the third part.ArticleAt the beginning, we will talk about several concepts closely related to Web Services.I am at a limited level. If there is an error, please point it out. For more information, please indicate the source.Finally, we recommend a good place to learn about Web services. The SOA and Web Services area for IBM developers is suitable for readers of various levels. There are also many latest applications, which are definitely worth mentioning. There are many web service demos at http://www.xmethods.net.