Practical use of Web services in IBM Lotus Domino 7
What are Web services and why are they important?
Content Series:
This content is part # of a series of # articles: Practical use of Web services in IBM Lotus Domino 7
https://www..jsp?series_title_by=Practical+use+of+web-services+in+ibm+lotus+domino+7
Stay tuned for new articles in this series.
You may have come across references to Web services in technical articles, descriptions software products or even in dialogues with colleagues. Apparently, Web services are necessary and important for some people, however, when you came across definitions like “XML grammar for defining sets of endpoints for messaging,” you decided that such complex things were not worth touching.
Fortunately, Web services can be explained in a way that everyone can understand without going into the details of how it all works. You should try to understand what Web services are, since the scope of their (and related service-oriented architecture, SOA) application in the IT world is constantly expanding.
Web services can be perceived as a car: you don’t need to know at a technical level how pistons, camshafts and fuel injectors work - you can buy a car, drive it and talk about cars with friends (unless, of course, they are mechanics) . It’s the same with Web services; as an IT specialist, you just need to understand what they are and how they work in order to understand why you need them.
It has become much easier to work with Web services without touching hidden low-level technologies, because software vendors and the community of people who write programs with open source, have done a lot over the past few years to separate the Web services interface from low-level tasks. This will allow you to work by simply connecting components together, without having to delve into lengthy documentation about formatting XML messages.
This series of articles will help Domino developers understand and use Web services in IBM Lotus Domino V7.0. This introductory article contains a lot of useful information that will be useful to anyone who wants to understand what Web services are. The technologies in Lotus Domino V7.0 make it easy for developers to create and use Web services, and we'll go into more detail about this later.
First, let's understand what a Web service is.
What is a Web service?
Simply put, a Web service allows computer programs communicate with each other in a standardized way.
Communication between three or more machines
Although in the examples we consider transactions within one or two machines, Web services can also be used for communication between big amount computers. For example, forwarding or storing transactions may be performed by an intermediate device, or a call to a Web service on one server may result in a call to a service on another.
At the end of this article, when we look at true SOA, we'll talk about Web services communicating across multiple machines, since that's what SOA always does.
A Web service is an abstract component, just as the concept of dialogue between people is abstract. A dialogue involves two or more people speaking a language known to them. Their language defines the words they use and how those words are used to form sentences. Typically, a dialogue has a question-answer structure, when someone asks a question or makes a statement, and the interlocutor answers it. People can be nearby, communicate on the phone, send messages to each other by mail or chat.
In any case, the dialogue has a complex structure and can take place in different ways, depending on the number of people communicating, the language of communication, the technologies used for communication, of course, if any are used.
The structure of communications using Web services includes many of the elements that we will touch on in this article. However, the idea remains the same as regular dialogue - programs communicate using a language they are familiar with, sometimes over a network. Programs can either be located on one computer or placed on different machines in different parts of the world, connected via the Internet by routers and servers. The good thing is that programs and computers don't have to be the same. Thanks to Web services, two people can communicate Microsoft programs.NET on one laptop, and a Java program on a Canadian iSeries server with a C++ program on a Linux computer from China.
The following standard technologies are used in communications via Web services:
- XML. The language (data format) used by Web service components.
- SOAP protocol. XML messages exchanged between programs
- Web Services Description Library (WSDL). XML file that defines the format of SOAP messages and how to send them
A standard technology known as Universal Description, Discovery, and Integration (UDDI) can also be used to communicate between Web services. We'll look at this later in the article, but since using UDDI is not required, many Web services don't use it.
Some terminology: publishing and using Web services
Before we get into explaining our terms, let's look at some of the terminology associated with Web services.
When we talk about publishing a Web service, we are talking about a program that publishes a WSDL file and allows other programs to use the corresponding service. Programs that publish Web services are called providers.
When we talk about using a Web service, we mean a program that makes a call to a Web service on another machine. Users of Web services are called clients.
XML: native language
XML is used to communicate between Web service components. Messages sent between applications, as well as files defining the Web service, are in XML format. Figure 1 shows the structure simple file XML.
Figure 1. Basic XML structure
As you can see, some information in the file (such as first name, last name) is surrounded by tags enclosed in triangle brackets. The name John is shown as
There are many benefits to writing Web services in XML, including:
- The structure and grammar of XML is similar to that of other programming languages, so programs that interact with Web services do not need to perform structural analysis of XML files directly.
- XML files are text and human readable (in other words, if you know XML, you can open an XML file in a text editor and understand its contents). This may help with debugging.
- XML allows you to use any standard encoding in messages, so you can write messages in English, Russian or Japanese.
- XML allows you to take advantage of what is called a namespace, in which you can predefine the desired structure of a file element with a specific name. For example, you could define a Price element, which must always be a float, or a PersonName element, which includes two string subelements, FirstName and LastName.
Also, if necessary, namespaces allow multiple elements with the same name to have different definitions. For example, a StockPrice element in one namespace might include a ticker symbol and price, while in another namespace it might consist of a ticker symbol, price, daily low and high, and 12-month high.
The only disadvantages of XML, if indeed they are disadvantages, are:
- XML is a rigid language, so any incorrect formatting of an XML message will cause parsing of the entire message to fail (even if the problem is easy to interpret or miss). However, if you use the standard library to generate XML files (which is what you do when creating Web services), the library itself checks for correct formatting.
- The XML message is stored in a regular text file, and therefore takes up more space than its equivalent in another format (such as a split, binary, or "homemade" format).
But these problems are insignificant compared to the benefits of the XML format.
SOAP: messages sent
You know that Web services communicate in XML format, however, this only solves half the problem. Applications can parse the message, but how do they know what to do with the result obtained after analysis?
The instruction that describes the rules for formatting XML messages for Web services is known as SOAP. It defines a message structure so programs know how to send and interpret data. The basic structure of a SOAP message is shown in Figure 2.
Figure 2. Basic SOAP message structure
In XML it would look something like this:
In the base case, you have a SOAP packet that includes a SOAP body and a body that contains the data to be transferred. Sometimes there is also an optional SOAP header (inside the packet before the body) containing additional information.
SOAP instructions
Although the SOAP format is standard and has the same instructions, it must be remembered that different manufacturers may implement these instructions slightly differently. For example, the structure of namespaces and XML in a SOAP message generated by Apache Axis may be very different from the structure generated by Microsoft .NET. However, a properly written client or server can process any message that is properly written according to SOAP instructions.
Additionally, there are some important differences between WSDL 1.1 and WSDL 2.0 statements. Although instruction 2.0 is still in its final stages at the time of writing, it will soon begin to take the place of version 1.1.
If you have never encountered a WSDL file before and try to open one and read it, you will have a hard time getting all the information out of it, since the structure of such a file can be quite complex. All information about the method (name, parameters, protocol, etc.) is scattered across different sections of the file, and in order to construct a SOAP message, it must be collected by the client application. This article will not describe the parts of the WSDL file and how they work together.
This is where technology comes to our aid again. As a developer, you do not need to read, parse, or understand the contents of the WSDL file. The tools will get this information for you, so you just need to figure out what to send to the service and where to put the results. You are not only you can use libraries and tools, but also for sure you will. There are quite a few exceptions, quirks, and complexities in all Web services components that you should look into. using Web service, rather than disassembling it followed by a detailed study of each component.
Protocols: how messages are sent
We have not yet touched upon the question of how all these messages are transmitted via SOAP?
And they are usually transmitted over the network (and/or the Internet) using the HTTP protocol, almost in the same way as pages are transmitted from the server to your browser. HTTP is not always used (its main competitor is SMTP, but it is far behind). The protocol used by the Web service is defined in the WSDL file.
Typically, the WSDL file defines the protocol used to transport the SOAP message as HTTP. The SOAP client sends messages according to the specified protocol.
Other Web services terms you may encounter
We've already covered the basic terms, but you may hear a few more when talking about Web services.
Weak ties
Programs that use Web services usually have weak connections with services, that is, the services necessary for the program to operate are not directly tied to it, just as the program is not tied to services. The program can easily use any services it needs, and they wait for a call from the program - from any program that needs their response.
A real-life example of weak ties is having lunch with friends. Several friends somehow agree with each other (in person, by phone, through email etc.). Everyone gets to the restaurant on their own, and after lunch everyone pays for their own food. No matter how the lunch went, the end result is the same - it was a friendly lunch.
But driving a car is an action with more rigid connections. You have a fixed set of tools with which you need to achieve predefined goals. When leaving the garage, you put the car in reverse and step on the gas. When you turn left, you turn the steering wheel to the left. You do not have the opportunity to do the same thing in different ways, since the entire system is very precise and coherent, and each of its elements is connected to the others.
UDDI
UDDI is a standard for creating a catalog of Web services delivered by any number of programs. It's sort of like a phone book for Web service providers. Clients can look up the information they need in the UDDI registry, and the registry returns them the necessary data to connect to the service.
Although UDDI is a fairly important standard for defining Web services, its significance is greatly diminished by the fact that it is an optional element of Web services, and when given the choice of whether to use it or not, many choose not to use it.
Most organized enterprise environments with a large number of internal Web services have UDDI registries. It's great to have a corporate UDDI website that contains information about the Web services available in your company. By bringing all services together, UDDI allows you to seamlessly and seamlessly change service providers. If clients seek services via UDDI, then SOAP calls are automatically sent to the new provider.
However, this component is not required in a Web services architecture.
Web Services Security
As you read about SOAP and WSDL, you may notice that the topic of security is not covered. How is authentication performed for service calls if the provider works with sensitive information? It’s clear that not all Web services are available to the general public, right?
This is an important question that is not easy to answer definitively. There are various schemes that you can use, depending on the situation, for example:
- Can SOAP messages arrive as text or must they be encrypted?
- Is simple login and password authentication enough for you, or should it be strong and token-based?
- If tokens are used, are they required to be signed, and what is the correct way to include them in a SOAP message?
- What if the client sends SOAP messages not directly, but through some intermediate structure, such as a message queue or some other Web service?
Additionally, messaging may not always use HTTP, so you won't be able to simply use Web services security systems in addition to existing HTTP security systems.
There are several guidelines that cover these and other aspects of Web service security: WS-Security, WS-Policy, WS-Trust, and WS-Privacy. Some software vendors and committees have been working on these issues for several years. Although not all Web services implementations support all security guidelines, available security standards typically implement at least a few basic security paths.
Middleware and Enterprise Service Bus
There is another rather large set of standards for Web services, collected together into one rather large lump, which are usually called WS-* instructions. Together they address many of the design considerations that arise when you assemble many Web services into one environment. The WS-* standards address issues such as:
- Safety
- Reliability
- Message exchange
- Transactions
- Quality of service
This number of standards is necessary because the exchange of messages between a Web service client and server in an industrial environment can be much more complex than simple request/response. For example, how do you ensure that the message reaches the provider and gets back to the customer? What if a SOAP request has multiple parts? How do you manage processes that involve Web services accessing other Web services? What if the program sends a sequence of requests with response time requirements?
For large software companies, working with these standards presents both challenges and opportunities. Some vendors market entire Web services middleware packages, often called Enterprise Service Buses, or ESBs, that can handle all or at least some of the above tasks. These ESBs are also valuable because they can tie together multiple Web services within the same organization and provide their functionality, recording their actions, and storing messages in queues.
Service-oriented architecture
And finally, service-oriented architecture. In most cases, it is simply a combination of all of the above: loosely coupled Web services from different vendors, interacting in accordance with accepted standards (possibly with the participation of the ESB) and collected together by different programs that take data from the services and use it in different ways.
Since SOA is a software architecture, a huge amount of coordination and planning work is associated with its construction. It's not just a bunch of services thrown together; it is the organization of how services are put together and published, what management tools and middleware are used, and how services and the entire system are monitored and managed.
If you look more globally, SOA is also a type of thinking. It makes you think not about independent workers large programs, but to perceive everything as possible components published and used in production. Instead of feature-rich applications, you think about specific and well-defined services - which is what Web services are.
Why is it important?
Now you already know something about how Web services work - the client reads the provider's WSDL file, formats and sends a SOAP message according to it, and receives another SOAP message in response. So why is this so important? What's the matter?
Part of the importance of services is that they provide a standard way for programs to communicate, regardless of the languages they are written in or the platforms they run on. Previously, we had to work with data formats that were unique to different programs, or with API-level functions that programs in other languages could not work with. The use of XML in all Web services standards means that all services are accessible and clearly defined.
In fact, this allows completely different programs to easily communicate with each other in a language that they all understand. One of the main difficulties when working with different technologies from different manufacturers there was always a need to force all these different programs communicate with each other and exchange data. Now that all your applications can deliver and/or consume Web services, interoperability between them is incredibly simple.
Another advantage of Web services is that clients and suppliers can be on different machines, using different hardware and software, and this will not interfere with communication. Programs can be used by other programs within the same machine, or from other machines, but using a specific data transfer format. Web services only need a network connection and an XML processor.
If all these factors are taken into account together, the result is significant. Once we have standard remedy For communication between applications over the network, we can build our programs differently. Instead of writing monolithic programs that reinvent the wheel every time, we can write programs that consist of modules.
For example, instead of a large program that collects information about several processes, turns it into graphs and shows them to users, we can create a dashboard that displays data received from several Web services. The compiled data is received from one or more services, and the resulting graphs are created by another Web service that accepts the data and produces a graph.
The dashboard transforms from a large program into a simple interface. If we want to add new components, we simply turn to additional services. If we need a different chart, we turn to another charting service. If we need a more interactive dashboard, with training or sorting capabilities, then the dashboard can transmit messages from the user to the appropriate service. We can even completely change the services being called so that users won't notice (as long as the WSDL file doesn't change), and the panel will remain the same.
As an IT professional, you can develop both interface and services, or both. Understanding how it all works together (or at least knowing what it is) is important when working on a project like this.
It's also good that there are many tools that will help you deliver and use Web services and can do a lot of the heavy lifting for you. In the following parts of the article, we will understand how using IBM Lotus Domino V7.0 you can easily deliver Web services to clients or systems.
We released new book"Content marketing in in social networks: How to get into your subscribers’ heads and make them fall in love with your brand.”
Web service (service) is a program that organizes interaction between sites. Information from one portal is transferred to another.
For example, there is an airline. She has many flights, which means she has a lot of tickets. It transmits information through a web service to a travel aggregator site. A user who accesses the aggregator will be able to buy tickets for this airline directly there.
Another example of web services is a weather tracking site that contains information about weather conditions in a specific city or country as a whole. This information also often used by third parties.
Information on the Internet is varied. Sites are managed different systems. Different transmission and encryption protocols are used. Web services simplify the exchange of information between different sites.
Web services architecture and protocols
You can define 3 authorities that interact with each other: catalogue, contractor and customer. After creating the service, the contractor registers it in the catalog, and the customer finds the service there.
The data exchange mechanism is formed in the description Web Services Description. This is a specification covering forwarding formats, content types, transport protocols that are used in the process of exchanging information between the customer and the service transporter.
Today, several technologies are most often used to implement various web services:
- TCP/IP is a protocol that is understood by almost any network equipment, from mainframes to portable devices and PDAs.
- HTML is a universal markup language used to display content on consumer devices.
- XML is a universal tool for processing all types of data. Other information exchange protocols can work on its basis: SOAP and WSDL.
- UDDI is a universal source of recognition, integration and description. It works, as a rule, in private networks and has not yet found sufficient distribution.
The versatility of the presented technologies is the basis for understanding web services. They operate on standard technologies that are independent of application providers and other network resources. Can be used in any operating systems, application servers, programming languages, etc.
Advantages
- Creating the necessary conditions for the interaction of software components, regardless of the platform.
- Web services are based on open standard protocols. Due to the introduction of XML, the creation and configuration of web services is simplified.
- The use of HTTP guarantees the interaction of systems through internetwork access.
Flaws
- Low performance and large volume of traffic, in comparison with RMI, CORBA, DCOM systems, due to the use of XML messages in the context of text.
- Security level. All modern web services must implement coding and require user authorization. Whether HTTPS is enough here or more reliable protocols are needed, such as XML Encryption, SAML, etc., are decided during development.
Web Services Tasks
Web services can be used in many areas.
B2B transactions
Integration of processes occurs immediately, without the participation of people. For example, updating the online store catalog with new products. They are brought to the warehouse, and the storekeeper notes the arrival in the database. The information is automatically transferred to the online store. And the buyer, instead of marking “Out of stock” on the product card, sees its quantity.
Integration of enterprise services
If the company uses corporate programs, then the web service will help set up their joint work.
Creating a client-server system
Services are used to configure the operation of the client and server. This provides benefits:
- you can't sell it yourself software, but make access to the web service paid;
- It’s easier to solve problems using third-party software;
- it is easier to organize access to the content and materials of the server.
A web service is an application that makes it easy technical setup interaction of resources.
The idea of web services was developed by computer industry giants such as Sun, Oracle, HP, Microsoft and IBM. This idea is nothing new, but it is a big step forward towards easier access to programs over the web. Based on standard communication formats, web services could completely change the way we think about how we should make websites.
What is a web service?
Thanks to web services, the functions of any program can be made available over the Internet. Thus, programs such as PHP, ASP, JSP scripts, JavaBeans, COM objects and all our other favorite programming tools can now access some program running on another server (i.e. a web service) and use the response received from her on her website, or application.
Let's say, if I need to perform some programming task, and I'm too busy (or out of my mind to reinvent the wheel myself again), I can use the services of a web service that my site will access via the Internet. By passing a request with parameters to the web service, I expect to receive a response containing the result of executing my request.
Anyone who has ever worked with Hotmail recently has already been somewhat exposed to web services: the Passport user authentication system is one of the services included in the Microsoft .NET initiative. It's currently available for free, so website creators can easily implement user authentication on their site.
Basics
The principles behind web services are surprisingly simple. And they add nothing new to the world of distributed computing and the Internet:
- the person responsible for the web service determines the format of requests to his web service and its responses
- any computer on the network makes a request to a web service
- a web service processes a request, performs some action, and then sends a response
This action could be, for example, displaying a stock quote, displaying the price of a particular product, saving an entry in an appointment calendar, translating text from one language to another, or checking a credit card number.
Standards at the core
The reason we are all suddenly interested in web services is that they are based on standards, open protocols for data exchange and transfer.
Before this, many companies developed their own proprietary standards and formats. And now to work we only need to know simple XML (eXtensible Markup Language), which is transmitted over the old familiar HTTP protocol. This means that information about how web services work is available to everyone, and web developers who are familiar with these technologies by profession can start playing with web services today.
The difference between web services and other technologies that developers have encountered (for example, DCOM, named pipes, RMI) is that web services are based on open standards, they are easy to learn, and these standards are widely supported across the world. Unix and Windows platforms.
The Simple Object Access Protocol (SOAP) is a standard protocol developed by the W3C. It defines the format of requests to web services.
Messages between a web service and its user are packaged in SOAP envelopes. Messages contain either a request to perform some action, or a response - the result of performing this action. The envelope and its contents are encoded in XML and are fairly easy to understand. This is what a simple SOAP request looks like when sent via HTPP to a web service:
Xmlns:env="http://www.w3.org/2001/06/soap-envelope">
xmlns:m="http://www.somesite.com/Postcode">
WC1A8GH
UK
The key elements of a SOAP envelope are quite simple to recognize: these are two parameters (("postal code") and ("country")), which are contained inside the element under the name. This element is the name of the web service to which we are making the request. Other data in the envelope, such as the text encoding and SOAP version, helps the web service process the request correctly.
And the answer will look like this:
Xmlns:env="http://www.w3.org/2001/06/soap-envelope" >
Env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
xmlns:m="http://www.somesite.com/Postcode">
Yes
This message is even easier to decipher. The element in our request has changed to the element in the response to the request. This element contains only one element, the value of which indicates whether our zip code is correct or not. So, through the magic of SOAP, we've created a query that does a useful job for us. In response via the network, we receive a certain type of response in XML.
Now about UDDI
Even though the SOAP protocol is simple, web services would be of little use if we had no way to find them. Fortunately, IBM, Microsoft and Ariba stepped up and created the Universal Description, Discovery and Integration (UDDI) project, which they hope will become a common catalog of all web services on the Web.
The UDDI system allows companies to expose their web service to the public. This directory acts as a phone book for all web services. Registration in the UDDI directory is free, and the founders of the project hope that this directory will contain descriptions of all, all, all services throughout the Web, so that to find the desired web service, you will only need to turn to one UDDI directory.
How does it all work
So how do I find the right web service?
Let's imagine that I am a website developer, and my client asked me to add to the site new feature: need to add validation check postal code in the registration form.
To perform this check, I would need to create a database of all zip codes in all 30 countries where our company does business, and then check that the zip code corresponds to the city specified in the registration when registering. But I don’t have this data, and I think that collecting such data will have to spend a significant amount of money.
Instead of shelling out money to buy a database, write the code myself, ensure the integrity and correctness of all the data and debug the scripts, I just go to the UDDI directory and see if there is a web service that can do the job for me . Arriving at www.uddi.org, I run a search and find an excellent service from XYZ Corp.
I carefully review the web service format definition (the definition is written in WSDL (Web Services Description Language), making sure that the service does exactly what I need. Then I check with my colleagues about the reputation of XYZ Corp., and find out that it is solid , and then contact XYZ Corp. about pricing. If the price for accessing the service is within my budget, I write a simple JSP page for my site that calls XYZ Corp.'s web service, and lo and behold, instant verification appears on the site postal code.
It's worth your time
Even if you have nothing to do with programming or website development technologies, web services are worth learning more about. Imagine a picture of how you are discussing a new website with a client, discussing all the functions of the new project. Everything is going great: the budget meets the customer’s expectations, he liked the sketch of the site plan, and liked the interface examples. Everything seems to be working.
And suddenly they remember some very complex function. At the mere mention of it, your web developer’s face turns green and he begins to choke and cough. This is the developer giving you a signal that developing this feature will require a lot of money and time or is simply not feasible with such a budget.
Drop your fear! I am ready to guarantee that there is already a web service on the Internet that is ready to provide you with the required function, and the cost of using this web service will be much lower than the cost of independently developing its analogue. This way you save your developer from unnecessary headaches, your client from wasting money by just spending a couple of minutes browsing the UDDI catalog.
Service development
Of course, developers don't have to be content with just web services created by others. Using one of the following toolkits, you can create your own web service and provide its services to other Internet users.
The choice of tools for developing web services is extensive. It includes tools from companies such as Sun (Open Net), Microsoft (.NET), HP (e-services), and IBM (Web Services). There are also open source frameworks. For example, the Mono Project aims to replace Microsoft's .NET toolkit by providing compilers, runtime, and libraries to run the same web services on all platforms, including Unix.
Despite the variety of servers and web service development tools, they all support the same SOAP protocol, XML language and UDDI system.
Minuses
Before I completely abandon my career as a programmer and devote myself to using web services, I have to ask myself the question: “It’s too rosy a picture. What’s wrong with it?” Unfortunately, the great potential of web services comes at a price:
- Using XML as a data transfer format means that your messages will be very large in size: the XML tags themselves take up a lot of space, and this puts a certain burden on us to create, transmit and interpret messages.
- Since we use remote computers We rely entirely on the Internet to perform certain functions, which creates too many unreliable links in the chain between our web server and the web service.
- Today, few companies create web services, and few companies use them. Debugging and improving the web services system still requires a long time.
- The system of licensing and charging for the use of web services has yet to be accepted by developers. Due to the fact that there are still too few web services, most companies try to make a good impression on their potential clients by deliberately reducing the cost of services and offering favorable licensing terms. It will still be some time before the real cost of web services becomes clear.
When web services take their place and become available to everyone, they will become an invaluable help for web developers. They will give us flexible access to the full power of all computers on the Network. It's time for website builders to become interested in web services and learn more about what they can get from them.
Translation: Alexander Kachanov (http://webmascon.com)
Web service, web service - a software system identified by a web address with standardized interfaces.
Web services can communicate with each other and with third party applications via messages based on specific protocols =
- XML-RPC
- etc.
A web service is the unit of modularity when using a service-oriented application architecture.
In common parlance, web services are services provided on the Internet.
In this usage the term requires clarification, whether we are talking about search, webmail, storing documents, files, bookmarks, etc.
Such web services can be used regardless of where you access the Internet, computer or browser.
Architecture
As shown in the figure, there are three instances that interact within the web service. Let's translate their names as customer, contractor and directory (Service Requestor, Service Provider and Service Broker).
When a service is developed, the contractor registers it in a directory where potential customers can find it. The customer, having found a suitable service in the catalog, imports its WSDL specification from there and develops his software in accordance with it. WSDL describes the format of requests and responses exchanged between the customer and the contractor during the work process. The following standards are used to ensure interoperability:
- An extensible markup language designed for storing and transmitting structured data;
- XML-based messaging protocol;
- : A language for describing external interfaces of a web service based on XML;
- Universal Discovery, Description and Integration interface.
A directory of web services and information about companies that provide web services to the public or to specific companies. So far, UDDI exists, however, only in small proprietary networks and has not yet found widespread use on the open Internet.
Development Methods
There are tools for automating the development of web services, divided into two main groups.
In bottom-up development, implementing classes are first written, and WSDL files that document the service are generated from their source code. The disadvantage of this method is Java classes are subject to frequent changes. In the top-down approach, the WSDL is first prepared, and from it the skeleton of a Java class that implements the service is generated. This path is considered more difficult, but leads to cleaner and better protected solutions. As long as the format of the messages exchanged between the customer and the contractor does not change, changes in each of them do not disrupt the interaction. This technique is sometimes called "contract first", since the starting point is the WSDL (the "contract" between the customer and the contractor).
Advantages
- Web services provide interaction software systems regardless of platform. For example, a Windows C# client can communicate with a Java server running under Linux.
- Web services are based on a base of open standards and protocols. Thanks to the use of XML Ease of development and debugging of web services is achieved.
- The use of Internet protocol provides HTTP interaction of software systems through a firewall. This is a significant advantage over technologies such as CORBA, DCOM or Java RMI. On the other hand, web services not tightly tied to HTTP - other protocols can be used.
Flaws
- Less performance and larger network traffic compared to RMI, CORBA, DCOM technologies due to the use of XML text messages. However, some web servers can be configured to compress network traffic.
- Security Aspects. Responsible web services should use encryption and possibly require user authentication. Whether using HTTPS is sufficient here, or whether solutions such as XML Signature, XML Encryption or SAML are preferable, must be decided by the developer.
Examples
Cooperation between airlines and travel agencies. The former are provided via web services useful information, which the latter use when searching for optimal offers to their clients.
Google, from 2002 to 2009, provided a web service that allowed customers to search for information on the Internet in the same way they do regular users. In terms of convenience, this is incomparable, for example, with the automatic parsing of HTML text on Google pages.
Amazon.com has a web service that provides various web-based services (something "as a service" - cloud technologies)
The topic title is really a question, because... I myself don’t know what it is and for the first time I will try to work with it within the framework of this article. The only thing I can guarantee is that the code presented below will work, but my phrases will only be assumptions and guesses about how I myself understand all this. So, let's go...
Introduction
We need to start with why the concept of web services was created. By the time this concept appeared in the world, technologies already existed that allowed applications to interact at a distance, where one program could call some method in another program, which could be launched on a computer located in another city or even country. All this is abbreviated as RPC (Remote Procedure Calling). Examples include CORBA technologies, and for Java - RMI (Remote Method Invoking). And everything seems to be good in them, especially in CORBA, because... You can work with it in any programming language, but something was still missing. I believe that the disadvantage of CORBA is that it works through some of its own network protocols instead of simple HTTP, which will fit through any firewall. The idea of the web service was to create an RPC that would be inserted into HTTP packets. Thus began the development of the standard. What are the basic concepts of this standard:- SOAP. Before calling a remote procedure, you need to describe this call in an XML file in SOAP format. SOAP is simply one of the many XML markups that are used in web services. Everything we want to send somewhere via HTTP is first converted into an XML SOAP description, then stuffed into an HTTP packet and sent to another computer on the network via TCP/IP.
- WSDL. There is a web service, i.e. a program whose methods can be called remotely. But the standard requires that this program be accompanied by a description that says that “yes, you’re right - this is really a web service and you can call such and such methods from it.” This description is represented by another XML file, which has a different format, namely WSDL. Those. WSDL is just an XML file describing a web service and nothing more.
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, end point, where SOAP messages from the client arrive). We need to do the following:- Describe the interface of our web service
- Implement this interface
- Launch our web service
- Write a client and remotely call the desired web service method