What is a web service? What is a Web service? How many different types of web services are there?
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 all network devices, from mainframes to mobile phones and PDAs;
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 the documents: the developer is free to create markup according to the needs of a particular domain, limited only by the syntactic rules of the 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 this case, a simple search request for skate boots is presented in the query string to the Google search engine. The search keyword 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. 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 to send 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. 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's 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 an internal social network, a cloud storage for data and a window designer - all of this together became possible to call 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. 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 seen references to Web services in technical articles, software product descriptions, or even in conversations with co-workers. 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's now much easier to work with Web services without touching the hidden low-level technologies, as software vendors and the open source community have done a lot over the past few years to separate the Web services interface from the 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. Simply put, a Web service allows computer programs to 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 communications between a large number of 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 Microsoft .NET programs on one laptop can communicate, as can 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 of a simple XML file. 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: Additionally, 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, via 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 issues that arise when you put many Web services together in 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 large programs running independently, but to perceive everything as possible components that can be 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 challenges when working with different technologies from different manufacturers has always been the need to get all these different programs to talk to 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. Since we have a standard means 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. When 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. Valentin Kolesov Demonstration of how SOAP works using the example of writing a Web server The currently widespread technologies for remote method calling (DCOM, CORBA/IIOP and RMI) are quite difficult to configure and organize interaction. This entails difficulties in the operation and functioning of distributed systems (security problems, inconvenience of transport through firewalls, etc.). Many problems were solved by the creation of SOAP (Simple Object Access Protocol), a simple XML-based protocol for exchanging messages in distributed environments (WWW). The protocol is designed for creating Web services and calling methods remotely. SOAP can be used in combination with various transport protocols, including HTTP, SMTP, and others. We call web services active content that implements some functionality, and data located on Web servers and made available for use by external applications. Web services are completely independent of the implementation language and platform. External applications interact with services using standard protocols and data formats. Web services technology is the cornerstone of Microsoft's .NET programming model. To demonstrate the capabilities of SOAP, this article uses the recently released implementation of SOAP Toolkit version 2.0 from Microsoft. It should be noted that the current version of Toolkit is noticeably different from the previous one (Microsoft SOAP Toolkit for Visual Studio 6.0) and from the beta version of SOAP Toolkit 2.0. The SOAP Toolkit object model provides both low-level and high-level interfaces (SOAPClient, SOAPServer), which hide from the programmer the entire “internal kitchen” - parsing and generating packages, calling methods, etc. Using these interfaces, you can use Web-based tools in a very elegant way. services in developed applications. The SOAPClient object acts as a proxy, providing a Web service interface and allowing you to work with it as with a regular COM object (Fig. 1). A WSDL file is an XML document that describes the methods exposed by a Web service, as well as the method parameters, their types, names, and location of the Listener service. The SOAP Toolkit wizard automatically generates this document, an excerpt of which is shown below: The Envelope tag must be the root element of the package. The Header element is optional, but the Body element must be present and be a direct child of the Envelope element. If a method execution error occurs, the server generates a package containing a Fault element in the Body tag, which contains a detailed description of the error. If you use the high-level interfaces SOAPClient, SOAPServer, then you do not have to go into the intricacies of the package format, but if you wish, you can use low-level interfaces or even create a package “manually” using any programming language. The SOAP Toolkit object model makes it possible to work with low-level API objects: Using high-level API objects, you can only transfer data of simple types (int, string, float, etc.), but the SOAP 1.1 specification allows you to work with more complex data types, such as arrays, structures, lists, and combinations thereof. To work with such types, you have to use the IsoapTypeMapper and SoapTypeMapperFactory interfaces. To demonstrate how SOAP works, let's write a simple Web service that can add and subtract numbers. To run the server application, you will need IIS 5 on Windows 2000 or IIS4 on Windows NT 4.0 Service Pack 6, as well as SOAP Toolkit 2.0 installed. Client application requirements: Microsoft Windows 98/Me or Windows NT 4.0 Service Pack 6/2000 Service Pack 1, as well as SOAP Toolkit 2.0 installed. Open a new ActiveX DLL project in VB. Change the class name to SOAPClass and the project name to SOAPProj. In the class, create the following methods: In the next Wizard window, you can select methods that will be included in the Web service. In this case, select all methods. Then specify where the Web application will be located (for example, http://wsd010/soap/), set the Listener application type (ASP or ISAPI), select ASP, schema format (default). Specify the path where the Web service description files will be located and the encoding. After finishing the Wizard, ASP, WSDL and WSML files will appear in the Web directory - this is the Listener for ASP and service descriptions (see Listings 1-3). All that remains is to configure access rights to the Web application - it is advisable to install NT Challenge/Response authentication. This completes the work of creating the server. Open a new Standard EXE project in VB. In the Project/References menu, make a link to the Microsoft SOAP type library. Create a button on the form, write the following code in the button click handler: Don't forget to change the Web server address and path to the WSDL file in the second line to the address and path to your Web service. After creating the SOAPClient object, it must be initialized - specify the path to the Web service description document. After initialization, the object will have Web service methods. You can work with them as with a regular COM object. Using the excellent MsSoapT.exe (Trace Utility) included in the Toolkit, you can view packets going from client to server and back in real time. To do this, you need to find a tag in the WSDL file and instead of a line like http://wsd010/soap/SOAPService.ASP write http://wsd010:8080/soap/SOAPService.ASP, that is, specify port 8080. After this you need to run the utility trace and accept the default settings, then create a new Formatted Trace object. Now all SOAP packages for working with the Web service are available for quick viewing. If the tracer is not loaded, then you need to remove the port 8080 indication. In Fig. Figure 4 shows the contents of the request packet for executing the SubstractNumbers method. And the response package looks like this: This is what the server packet looks like when it came in response to a request of an incorrect format: http://msdn.microsoft.com/webservices/ and http://msdn.microsoft.com/soap/ - the latest news about SOAP and Web services from Microsoft. You can also find the latest software versions there. http://www.vbxml.com/soap/ - a lot of useful information for developers. There are presentations and tutorials on SOAP. http://www.w3.org/TR/SOAP/ - SOAP specification from W3C. http://www.w3.org/TR/wsdl - information about the Web Services Definition Language (WSDL) 1.1 standard/ http://microsoft.public.xml.soap - in this conference, experts will help solve complex SOAP programming problems. Web service is a software system identified by a web address with standardized interfaces. Web services can communicate with each other and with third-party applications through messages based on specific protocols. In common parlance, web services are services provided on the Internet. FTP (File Transfer Protocol) FTP (File Transfer Protocol) is a standard protocol designed for transferring files over TCP networks (for example, the Internet). FTP is often used to download web pages and other documents from a private development device to public hosting servers. SSH (Secure Shell) SSH (Secure SHell) is an application-level network protocol that allows remote control of the operating system and tunneling of TCP connections (for example, for file transfer). Similar in functionality to the Telnet and rlogin protocols, but, unlike them, it encrypts all traffic, including transmitted passwords. SSH allows a choice of different encryption algorithms. SSH clients and SSH servers are available for most network operating systems. TELNET (English TERminaL NETwork) is a network protocol for implementing a text interface over the network (in its modern form - using the TCP transport). Some utilities that implement the client part of the protocol also have the name “telnet”. SMTP (Send Mail Transfer Protocol) SMTP (Simple Mail Transfer Protocol) is a widely used network protocol designed for transmitting email over TCP/IP networks. DNS (Domain Name Service) DNS (English: Domain Name System) is a distributed computer system for obtaining information about domains. Most often used to obtain an IP address by host name (computer or device), obtain information about mail routing, serving hosts for protocols in a domain (SRV record). DHCP (Dynamic Host Control Protocol) DHCP (Dynamic Host Configuration Protocol) is a network protocol that allows computers to automatically obtain an IP address and other parameters necessary to operate on a TCP/IP network. This protocol operates on a client-server model. For automatic configuration, the client computer, at the network device configuration stage, contacts the so-called DHCP server and receives the necessary parameters from it. The network administrator can specify the range of addresses distributed by the server among computers. This allows you to avoid manual configuration of network computers and reduces the number of errors. The DHCP protocol is used on most TCP/IP networks. HTTP (HyperText Transfer Protocol) HTTP (English: HyperText Transfer Protocol) is an application-level protocol for data transfer (initially in the form of hypertext documents). The basis of HTTP is the client-server technology, that is, it assumes the existence of consumers (clients) who initiate a connection and send a request, and providers (servers) who wait for a connection to receive a request, perform the necessary actions and return a message with the result. POP3 (Post Office Protocol, version 3) POP3 (Post Office Protocol Version 3) is a standard Internet application protocol used by email clients to retrieve an email message from a remote server over a TCP/IP connection. SFTP (Secure File Transfer Protocol) SFTP (SSH File Transfer Protocol) is an application-level protocol designed for copying and performing other operations with files over a reliable and secure connection. The protocol was developed by the IETF as an extension to SSH-2, but SFTP can also be implemented using other session-level protocols. NNTP (Network New Transfer Protocol) NNTP (Network News Transfer Protocol) is a network protocol for distributing, requesting, posting and receiving newsgroups in interaction between a newsgroup server and a client. NTP (Network Time Protocol) Network Time Protocol (NTP) is a network protocol for synchronizing a computer's internal clock using networks with variable latency. NetBIOS (Network Basic Input/Output System) is a protocol for working in local networks on personal computers such as IBM/PC, developed as an interface that does not depend on the manufacturer. It was developed by Sytek Corporation for IBM in 1983. It includes a session level interface (NetBIOS interface) and uses TCP and UDP as transport protocols. IMAP (Internet Message Access Protocol) IMAP (Internet Message Access Protocol) is an application-level protocol for accessing email. SNMP (Simple Network Management Protocol) SNMP (Simple Network Management Protocol) is a standard Internet protocol for managing devices in IP networks based on UDP/TCP architectures. Devices that support SNMP include routers, switches, servers, workstations, printers, modem racks, and others. The protocol is commonly used in network management systems to monitor network-connected devices for conditions that require administrator attention. SNMP is defined by the Internet Engineering Task Force (IETF) as a component of TCP/IP. It consists of a set of standards for network management, including an application layer protocol, a database schema, and a set of data objects. LDAP (Lightweight Directory Access Protocol) LDAP (Lightweight Directory Access Protocol) is an application layer protocol for accessing the X.500 directory service, developed by the IETF as a lightweight version of the ITU-T DAP protocol. LDAP is a relatively simple protocol that uses TCP/IP and allows for authorization (bind), search (search) and comparison (compare) operations, as well as operations for adding, changing or deleting records. SSL (Secure Socket Layer) SSL (Secure Sockets Layer) is a cryptographic protocol that ensures the establishment of a secure connection between a client and a server. SSL was originally developed by Netscape Communications. Subsequently, based on the SSL 3.0 protocol, an RFC standard was developed and adopted, called TLS. NFS (Network File System) Network File System (NFS) is a network file system access protocol originally developed by Sun Microsystems in 1984. Based on the remote procedure call protocol. Allows you to connect (mount) remote file systems over the network. MySQL is a free database management system. MySQL is developed and supported by Oracle Corporation, which acquired the rights to the trademark together with the acquired Sun Microsystems, which previously acquired the Swedish company MySQL AB. The product is distributed under both the GNU General Public License and its own commercial license. In addition, developers create functionality at the request of licensed users; it was thanks to this order that the replication mechanism appeared in almost the earliest versions. Virtual Network Computing (VNC) is a system for remote access to a computer desktop using the RFB (Remote FrameBuffer) protocol. Control is carried out by transmitting keyboard keystrokes and mouse movements from one computer to another and relaying screen contents through a computer network.
What is a web service?
A special and favorite topic for everyone is social networks.
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 this important?
developer of the Krasnoyarsk branch of the St. Petersburg company "Astrosoft", certified Microsoft specialist (MCSD, MCSE, MCDBA)
[email protected]What is SOAP
What are Web services
Example
Creating a server
Creating a client
Dim SoapClient As New SoapClient SoapClient.mssoapinit "http://wsd010/soap/SOAPService.wsdl" MsgBox SoapClient.AddNumbers(4, 3) MsgBox SoapClient.SubtractNumbers(3, 2)
Additional information on the topic
Listing 1. Listener code for ASP
<%@ LANGUAGE=VBScript %>
<%
Option Explicit
On Error Resume Next
Response.ContentType = "text/xml"
Dim SoapServer
If Not Application("SoapServerInitialized") Then
Application.Lock
If Not Application("SoapServerInitialized") Then
Dim WSDLFilePath
Dim WSMLFilePath
WSDLFilePath = Server.MapPath("SOAPService.wsdl")
WSMLFilePath = Server.MapPath("SOAPService.wsml")
Set SoapServer = Server.CreateObject("MSSOAP.SoapServer")
If Err Then SendFault "Cannot create SoapServer object. "
& Err.Description
SoapServer.Init WSDLFilePath, WSMLFilePath
If Err Then SendFault "SoapServer.Init failed. "
& Err.Description
Set Application("SOAPServiceServer") = SoapServer
Application("SoapServerInitialized") = True
End If
Application.UnLock
End If
Set SoapServer = Application("SOAPServiceServer")
SoapServer.SoapInvoke Request, Response, ""
If Err Then SendFault "SoapServer.SoapInvoke failed. "
& Err.Description
Sub SendFault(ByVal LogMessage)
Dim Serializer
On Error Resume Next
" "URI Query" logging must be enabled for AppendToLog to work
Response.AppendToLog " SOAP ERROR: " & LogMessage
Set Serializer = Server.CreateObject("MSSOAP.SoapSerializer")
If Err Then
Response.AppendToLog "Could not create SoapSerializer object. "
& Err.Description
Response.Status = "500 Internal Server Error"
Else
Serializer.Init Response
If Err Then
Response.AppendToLog "SoapSerializer.Init failed. "
& Err.Description
Response.Status = "500 Internal Server Error"
Else
Serializer.startEnvelope
Serializer.startBody
Serializer.startFault "Server", "The request could not
be processed due to a problem in the server. Please contact
the system administrator. " & LogMessage
Serializer.endFault
Serializer.endBody
Serializer.endEnvelope
If Err Then
Response.AppendToLog "SoapSerializer failed. "
& Err.Description
Response.Status = "500 Internal Server Error"
End If
End If
End If
Response.End
End Sub
%>
Listing 2. WSDL file code
Listing 3. WSDL file code
