We should start with what the concept of web services was created for. By the time this concept appeared, there were already technologies in the world that allowed applications to communicate at a distance, where one program could call some method in another program, which could be run on a computer located in another city or even country. All this is abbreviated as RPC (Remote Procedure Calling). As examples we can cite CORBA technologies, and for Java – RMI (Remote Method Invoking). And everything seems to be good in them, especially in CORBA, since it can be worked with in any programming language, but something was still missing. I guess the disadvantage of CORBA is that it works through its own network protocols instead of just HTTP, which will get through any firewall.
The idea behind the web service was to create an RPC that would be stuffed into HTTP packets. That’s how the development of the standard started. What are the basic concepts of this standard:
- SOAP. Before you can call a remote procedure, you need to describe that call in a SOAP XML file. SOAP is just one of the many XML markups that are used in web services. Anything we want to send somewhere via HTTP is first turned into an XML description of SOAP, then stuffed into an HTTP packet and sent to another computer on the network over TCP/IP;
- WSDL. There is a web service, i.e., a program whose methods can be remotely invoked. But the standard requires that this program be accompanied by a description that says “yes, you are not mistaken – this is indeed a web service and you can call such and such methods from it”. Such a description is represented by another XML file that has a different format, namely WSDL. That is, WSDL is just an XML file describing a web service and nothing else.
So, in Java, there is such an API as JAX-RPC. In case you don’t know, when people say that Java has such and such an API, it means that there is a package with a set of classes that encapsulate the technology in question. JAX-RPC took a long time to evolve from version to version and eventually evolved into JAX-WS. WS obviously stands for WebService and one might think that this is a simple renaming of RPC into the now popular buzzword. This is not the case, as Web Services have now moved away from the original idea and allow not just calling remote methods, but simply sending SOAP-formatted messages-documents. Why this is needed I don’t know yet, the answer here is unlikely to be “just in case you need it”. I myself would like to know from more experienced comrades. And lastly, then there is also JAX-RS for so-called RESTful web services, but this is the topic of a separate article.
General approach
In web services there is always a client and a server. The server is our web service and is sometimes called the endpoint (like, the endpoint where SOAP messages from the client go). What we need to do is the following:
- Describe the interface of our web service;
- Implement this interface;
- Run our web service;
- Write a client and remotely call the required method of the web service.
You can run a web service in different ways: either describe a class with the main method and run the web service directly as a server, or you can depopulate it on a server like Tomcat or any other server. In the second case, we don’t start a new server ourselves and don’t open another port on the computer, we just tell the Tomcat servlet container that “we’ve written the web service classes here, please publish them so that everyone who comes to you can use our web service”.