A web service is a program that can be accessed by other programs over the Internet (http). For example, let's say you have a function that provides text in HTML format. The purpose of the application is for the web browser to display the results and a person will be able to easily read this text on the page.
On the other side, target audience Web services are other programs or other web services that consume data served by the web service. Usually the withdrawal is made to standard language, which can be understood by other programs. Take the above example, if the web service outputs text in XML format, then other web services that can read or understand XML can use this output.
The main advantage of a web service is that applications can be written in any language, but they can communicate and exchange data with each other through the web service. Software Applications written in different languages programming and running on various platforms, can use web services to communicate over the Internet (HTTP). This is an interaction (for example between Java and Python, or Windows applications and Linux) is associated with the use of open standards (XML, SOAP, HTTP).
- SOAP (Simple Object Access Protocol)
- UDDI (Universal Description, Discovery and Integration)
- WSDL (Web Services Description Language)
How many different types of web services are there?
Primarily, there are two types of web services, Simple Object Access Protocol (SOAP) and Representational State Transfer (REST).
- The SOAP web service accepts a request in XML format and generates output in XML format.
- REST web service is more versatile and can accept XML as well as JSON as a request and generates output in XML as well as JSON or even HTML
This issue can be studied in more detail on ours.
Let's call service a resource that implements a business function and has the following properties:
is reusable;
defined by one or more explicit technology-independent interfaces;
is loosely coupled to other similar resources and can be invoked through communication protocols that allow resources to interact with each other.
Web service called a software system identified by the string URI, whose interfaces and bindings are defined and described by XML. The description of this software system can be found by other software systems that can interact with it according to this description through XML-based messages transmitted using Internet protocols.
1.1 Web Services Basics
Web services is a new promising architecture that provides a new level of distribution. Instead of developing or purchasing components and embedding them into an IS, it is proposed to buy their operating time and form a software system that makes method calls from components that are owned and supported by independent providers. Thanks to Web services the functions of any program on the network can be made available via the Internet. The simplest example Web service- system Passport on Hotmail, which allows you to create user authentication on your own site.
Web services are based on the following universal technologies:
TCP/IP– a universal protocol understood by everyone network devices, from mainframes to mobile phones and PDA;
HTML– a universal markup language used to display information on user devices;
XML(Extensible Markup Language) – a universal language for working with any type of data.
The versatility of these technologies is the basis for understanding web services. They are based only on generally accepted, open and formally vendor-neutral technologies. Only through this can the main advantage of web services be achieved as a concept for building distributed IS - their universality, i.e. the ability to be used for any operating systems, programming languages, application servers, etc.
Thus, web services solve the original problem - the problem of integrating applications of various natures and building distributed IS. This is the main fundamental difference between web services and their predecessors.
Web services - This XML applications, linking data with programs, objects, databases, or entire business transactions. XML documents formatted as messages are exchanged between the web service and the program. Web service standards define the format of such messages, the interface to which the message is sent, the rules for binding the message content to the application implementing the service and vice versa, as well as the mechanisms for publishing and searching for interfaces.
XML(EnglisheX tensible M arkup L anguage- expandable markup language; pronounced [ x-em-el]). Recommended World Wide Web Consortium(W3C). The XML specification describes XML documents and partially describes the behavior of XML processors (programs that read XML documents and provide access to their content). XML was designed as a language with a simple formal syntax, convenient for creation and document processing programs and at the same time convenient for humans to read and create documents, emphasizing the focus on use on the Internet. The language is called extensible because it does not fix the markup used in documents: the developer is free to create markup according to the needs of a particular area, being limited only syntactic rules language. Combination of simple formal syntax, human friendliness, extensibility, and encoding based Unicode for representing the content of documents has led to the widespread use of both XML itself and many derivative specialized languages based on XML in a wide variety of software tools.
Standard XML Applications
XML can be used for more than just describing a single document. An individual, company, or standards committee can define the required set of XML elements and document structure to be used for a particular class of documents. A similar set of elements and description of the document structure is called XML application or XML dictionary. For example, an organization might define an XML application to create documents describing molecular structures, multimedia presentations, or containing vector graphics.
Web services can be used in many applications. Regardless of whether web services run from customers' desktops or laptops, they can be used to access Internet applications such as pre-ordering or order tracking.
Web services suitable for B2B integration (business-to-business), closing applications performed by different organizations into one production process. Web services can also address the broader problem of enterprise application integration (Enterprise Application Integration, EAI), linking multiple applications from one enterprise to multiple other applications. In all of these cases, web services technologies are the “glue” that connects the various pieces of software.
As can be seen from Fig. 1, Web services are a wrapper that provides a standard way of interacting with application software environments such as database management systems (DBMS), .NET, J2EE (Java2 Platform, Enterprise Edition), CORBA (Common Object Request Broker Architecture), resellers of enterprise resource planning packages ( Enterprise Resource Planning, ERP), integration brokers, etc.
Fig.1. Web services interact with application systems
Web service interfaces are obtained from the network environment standard XML messages, transform XML data into a format “understood” by a specific application software system, and send a response message (the latter is optional). Software implementation of web services (base software, lower level) can be created in any programming language using any operating system and any middleware ( middleware).
A simple example: searching for information
Currently, most services are called over the Internet by entering data into HTML forms and sending this data to the service by adding it to the Uniform Resource Locator string ( Uniform Resource Locator, URL):
http://www.google.com/search?q=Skate+boots&btnG=Google+Search
This example illustrates the simplicity of web interactions (such as searching, buying stocks, or requesting driving directions) where parameters and keywords are embedded directly in the URL. IN in this case a simple search request for skate boots (boots with skates) is presented in the query string to the Google search engine. Keyword search represents the service that will be accessed, and the Skate+boots parameter is the search string that was entered into the HTML form on the Google website page. Service Google search will pass this request to various search engines, which will return a list of URLs for pages that match the search parameter Skate+boots. This ineffective method of searching the Internet is entirely based on matching the specified text string with indexed HTML pages.
XML - The best way sending data. XML provides significant advantages when transmitting data over the Internet. Now the previous query can be represented as XML document:
xmlns:s="www.xmlbus.com/SearchService"> Sending a request in the form XML document has the following advantages: the ability to define data types and structures, greater flexibility and extensibility. XML can represent structured data or data of a specific type (for example, it is acceptable to specify the value of the size field as a string of numbers or as a floating point number) and contain more information than a URL allows. This example is presented in the form of a SOAP (Simple Object Access Protocol) message, a standard form of XML message exchange that is one of the technologies underlying web services. In a SOAP message, the name of the requested service and the input parameters are represented as separate XML elements. This example also illustrates the use of XML namespaces (xmlns:), another important element of web services. Because XML documents support multiple data types, complex structures, and schema aggregation, modern web services technologies provide significant advantages over existing capabilities for accessing software applications through HTML and URLs. 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. It can be seen that for some people Web services are needed and important, however, having encountered definitions like “XML grammar for defining sets endpoints for messaging," you decided that such complex things are 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 enough useful information, and 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. Simply put, a Web service allows computer programs communicate with each other in a standardized way. 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: 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. 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 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. 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: 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: But these problems are insignificant compared to the benefits of the XML format. You know that Web services communicate in XML format, but 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. 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. 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. 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. We've already covered the basic terms, but you may hear a few more when talking about Web services. 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 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. 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: 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. 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: 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. 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. 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 does 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. Where do we start? And straight from the customer-performer contact: the phone rings in the Internet studio. The account manager picks up the phone and greets you. From that side it sounds something like: - Good afternoon. I need a website, a simple one. What is the price? (same story with web applications). This is truly a headache for every account. But he is not nervous and explains that sites vary in complexity, functionality, etc. Clarifies what the client needs and what “simple” means in his understanding. For example, he receives the following response: - Well, you see, I have a business selling windows. It would be nice to make a website so that you can create a “virtual” window for yourself. Choose color, materials, sizes. Specify quantity. See what it will look like. Well, then our specialists would go to the place. Agreed? This is already interesting. But that is not all: - And yes, I have another wish. We have a division in Moscow, St. Petersburg and Novosibirsk. The staff is large, there is paperwork, well, you understand. You can do something like... a small social network inside the site, or what? It will be more convenient for us to communicate this way, without any “ases”. And store documents in one “cloud” - I heard that they do this. The account manager writes down everything, makes a rough estimate, and names the cost. The potential client rolls his eyes (you can hear this even over the phone), says “your prices are just out of this world” and politely hangs up. Of course, this is a mega-exaggerated situation, but this happens all the time both when programming Internet applications and when creating websites. Our goal is to figure out why this happens. Development of a web service is, by and large, the same development of a website. But there is one big “BUT”: unlike the promotional sites and corporate events already familiar to everyone, the online service has unique functionality. This could be a product designer (as in the example above), photo hosting, a closed social network for corporate use, an open social network (danedaiboh), a bulletin board... Mostly those who decide to create a web service are those who rely on innovation, convenience, and modern web technologies. In this case, the unique functionality acts as the “trump card” of the business, with its help it is supposed to stifle competitors and increase the customer base. And all this means is that: As a result, the price of creating a web service (along with its programming) will fluctuate. But it will always be higher than that of a site with a “typical” set of functions. For our example: when the client mentioned internal social network, cloud storage for data and a window designer - all together it became possible to call it a web service. That is why the cost was called “unexpected” for the customer. “Space” prices when developing Internet services is a justified measure. This is objectively difficult and lengthy work. Whether a business needs such a service is a task for your marketers. Quite funny things happen here. Moreover, these comedies are played with a serious face. For example, a certain active percentage of schoolchildren, “advanced” VKontakte users, constantly want their own game. To dizzying success. And so as not to bother. As a result, we receive tons of letters in our inbox and in the community with the text “sell/develop a business application/game/something else for us.” Something like this: Yes, 5,000 rubles for several weeks of work - ok. We are now talking only about suitable copies, and not about those that gain an audience of 200 users and wither away. If you are nevertheless overtaken by the mania to make a successful clone, then at least think about how much it cost the authors of the original to promote and promote a web application or service (usually this is the development budget multiplied by ten). Don't make mistakes. Calculate your strength. Launch successful Internet projects. Amen. 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. 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. The principles behind web services are surprisingly simple. And they add nothing new to the world of distributed computing and the Internet: 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. 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"> 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" 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 have created a request that does for us useful work. In response via the network, we receive a certain type of response in XML. 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. 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. 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. 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 tools ( 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. 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: 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. 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
What is a Web service?
Communication between three or more machines
Some terminology: publishing and using Web services
XML: native language
Figure 1. Basic XML structure
SOAP: messages sent
Figure 2. Basic SOAP message structure
SOAP instructions
Protocols: how messages are sent
Other Web services terms you may encounter
Weak ties
UDDI
Web Services Security
Middleware and Enterprise Service Bus
Service-oriented architecture
Why is it important?
What is a web service?
A special and favorite topic for everyone is social networks.
What is a web service?
Basics
Standards at the core
xmlns:m="http://www.somesite.com/Postcode">
WC1A8GH
UK
xmlns:m="http://www.somesite.com/Postcode">
YesNow about UDDI
How does it all work
It's worth your time
Service development
Minuses
Translation: Alexander Kachanov (http://webmascon.com)