Alexander Kachanov
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 in Lately With Hotmail, has already partially encountered 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:m="http://www.somesite.com/Postcode">
The key elements of a SOAP envelope are quite easy to find out: these are two parameters (
And the answer will look like this:
xmlns:m="http://www.somesite.com/Postcode">
This message is even easier to decipher. Element
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 works 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, it will be enough to turn to only 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: You need to add a zip code check to your 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 the site http://www.uddi.org/, I launch 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 unnecessary waste money just by spending a couple of minutes browsing the UDDI directory.
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), (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.
Annotation: Areas of use. Advantages. Features of developing web services for the .NET platform. Description and discovery of a web service
What is XML Web Service?
As information technology developed, different approaches to writing programs arose: modular programming, event-driven programming, component-oriented programming and design. The logical continuation of these approaches was service-oriented software development.
The use of service-oriented approaches allows us to talk about reuse at the macro level (service level), as opposed to the micro level (object level). The service-oriented approach uses simple and generally accepted standards, which allows a wide variety of applications to share each other's functionality. Services can be written using a variety of programming languages, on various platforms. In addition, services can be deployed separately or as part of a software package anywhere in the world and will thus provide access to their functionality over the network.
Let's call service 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.
A special case of a service is an XML web service.
XML Web service is a special type of web application that:
- deployed on a web server;
- publishes web methods that can be called by external clients;
- waits for the receipt of HTTP requests, which are commands for calling web methods;
- executes web methods and returns results.
Unlike a traditional web application, a web service does not have a user interface. Instead, it has a programming interface, that is, the web service exposes functions (web methods) that can be called remotely (for example, over the Internet). The web service is not intended to serve end users. Its job is to provide services to other applications, be they web applications, GUI applications, or console applications.
A Web service can provide real-time information on stock prices, check credit cards, or report the weather forecast. Web services are as diverse as regular applications.
Web services are not the property of a specific company. It is an industry standard based on open protocols (SOAP, HTTP, etc.). Web services are deployed on various platforms (including servers running Windows or UNIX). Web services can be developed using many development tools (from a text editor to the Microsoft Visual Studio family).
Methods of most web services are called by HTTP requests containing SOAP messages SOAP is an XML language (XML vocabulary) for calling remote procedures over HTTP and other protocols (full description of SOAP http://www.w3.org/TR/SOAP) .
The place of web services among other remote calling technologies
There are quite a few remote invocation protocols and technologies: Microsoft Distributed Component Object Model (DCOM), the Object Management Group's Common Object Request Broker Architecture (CORBA), Sun's Remote Method Invocation (RMI), . NET Remoting, XML Web Services.
All of these component-based technologies (DCOM, CORBA, and RMI) have been used successfully in Intranet applications for many years. They provide a reliable, scalable architecture. However, there are two serious problems with using these technologies on the Internet. Firstly, they do not interact well with each other. All technologies operate on objects, but differ significantly in details: lifecycle management, constructor support, and the degree of inheritance support. The second, more important aspect is that the focus on RPC interactions leads to the construction of tightly coupled systems based on explicit calls to object methods.
In contrast to these technologies, XML Web Services and. NET Remoting are fully implemented object-oriented approach for web programming.
XML Web Service- a component that provides Internet clients with a set of API functions or web methods. XML is included in the name because web services and their clients use it to exchange data. Web services are based on open standards such as HTTP, XML (Extensible Markup Language), SOAP (Simple Object Access Protocol - an Intenet standard that describes how applications can interact, that is, call each other's methods, using HTTP and other protocols ). The main task of web services is to ensure inter-program interaction. Many work on UNIX servers and are accessed by Windows clients. Data sent to web services is serialized in XML and sent in SOAP packets. Metadata about the content of such messages is stored in the web service WSDL contract and XSD schemas. The main advantage of this approach is the readability of metadata. The developer can easily view the entire description of the web service and even create his own module that parses SOAP packets.
.NET Remoting provides infrastructure for distributed objects. It is much more complex than a simple message-passing web services architecture. . NET Remoting includes parameter passing by reference and value, callbacks, multiple object activation, and lifecycle management policies. To use these features, the client application must be proficient in all technologies. Data c. NET Remoting are transmitted in binary or SOAP format. However, in any case, metadata about the structure of the transmitted information is contained in the common language execution environment. Without a common language runtime (CLR), the client application will not be able to parse language-specific ones. NET Remoting SOAP headers. That is. NET Remoting imposes significantly higher requirements compared to web services.
Development of web services on the .NET platform
There are many ways to write web services. They can be developed manually or using SOAP tools provided by Microsoft, IBM, etc. Writing web services using Microsoft. NET has two advantages:
- The .NET Framework greatly simplifies the development process by providing a class library and automating individual development stages;
- Web services written with the .NET Framework are managed applications. That is, such applications do not have problems with memory leaks, incorrectly initialized pointers, and other typical programming problems.
Creation
Let's develop a simple AdditionService web service that adds two numbers. It will have only one Add method, which takes two integers as a parameter and also returns an integer. AdditionService demonstrates several important principles of programming web services using the Microsoft .NET Framework.
- Web services are implemented as ASMX files. ASMX is a special filename extension registered to ASP .NET (more specifically, the ASP.NET HTTP Handler) in the main ASP .NET Machine.config configuration file.
- ASMX files begin with the @WebService directive. This directive must contain at least the Class attribute, which specifies the class of which the web service consists.
- Web service classes can have optional WebService attributes. IN in this example This attribute specifies the web service name and description that is displayed on the HTML page when the user calls AdditionService.asmx in the browser.
- Web methods are declared by assigning the WebMethod attribute to the public methods of the Web service class. For helper methods that are used internally but are not available to external clients, this attribute is simply not specified.
- HTTP, XML and SOAP are "invisible". The .NET Framework handles XML data and SOAP messages.
AdditionService.asmx<%@ WebService language="C#" Class="AddService" %>using System using System.Web.Services class AddService ( public int Add (int a, int b) ( return a + b ) )
Despite its small size, AdditionService.asmx is a full-fledged web service if installed on a web server with ASP.NET. Its methods are called using SOAP, HTTP GET and HTTP POST, and it can return results as SOAP responses or as simple XML wrappers.
Using background code, web service classes can be moved from asmx files into separate files.
Web services support the use complex data types as input or output parameters. Complex data types are supported because XML allows most data types to be easily serialized. However, when automatically testing a web service, ASP .NET does not generate test pages for methods that accept complex types data. This happens because you cannot pass complex data types to a web method using HTTP GET and POST.
Web services allow you to call their methods asynchronously. An asynchronous call returns control immediately, regardless of how long it takes the web service to process the call. Asynchronous calls are useful when processing a call takes a significant amount of time. The application makes the call, then continues running without waiting for the result of the call, and later receives the results of the asynchronous call. The result is obtained by calling the web method again at a time convenient for the application or by subscribing to a notification about the end of processing the call by the web service (delegate mechanism).
Web services can be created using tools such as Microsoft Visual Studio 2005. To create web services it provides separate type ASP .NET Web Service project. Visual Studio generates an asmx file, a file with background code to describe the web service classes, a web service configuration file, etc. When the project is launched for execution, the service classes are compiled and the asmx file is opened in the browser window.
Description of web services using contracts
In order for other developers to use AdditionService, they need to know what methods it provides, what protocols it supports, method signatures, and the web service address (URL). All this and other information can be described in WSDL (Web Service Description language).
Web service discovery
How do other developers know about the existence of AdditionService?
Firstly, using DISCO (short for the word discovery) - a file-based mechanism for searching local web services, that is, a mechanism for obtaining a list of available web services from DISCO files located on web servers. In addition, DISCO files contain records of the location of the WSDL contracts of available services. A DISCO file is an XML file with records.
It is also possible to use VSDISCO files, which are similar to DISCO files, but their contents are the result of a dynamic search for web services in the specified directories and all subdirectories. ASP .NET maps the .vsdisco filename extension to an HTTP handler, which searches the given directory and its subdirectories for asmx and disco and returns a dynamically generated DISCO document. For security reasons, dynamic search is disabled in some versions of the .NET Framework, but you can enable it by editing the entries in the Machine.config file.
How do you search for web services on the global network? To search for web services on the global network, Microsoft, IBM and Ariba jointly developed UDDI (Universal Description Discovery and Integration) - a specification for building distributed databases that allows you to search for web services. UDDI is supported by hundreds of companies. UDDI sites are themselves web services. Anyone can publish their UDDI-based registry. Most developers never use the UDDI API directly. Instead, UDDI registries are accessed by development tools. They also generate wrapper classes for discovered and selected web services.
Results
An XML Web service is a software component that provides functionality that can be used by most different systems, supporting standards such as XML and HTTP. Web service clients can be both local and remote applications. Web services allow you to create structures that make it easier to integrate different systems based on simple, generally accepted standards.
We have reviewed general concepts use of the mechanism « Web-services". Let's refresh some knowledge.
Web services are used to exchange data between a server and a client; The XML format is used to “package” data for the purpose of mutual understanding between both participants in communication.
CHAPTERI
EXAMPLE OF IMPLEMENTATIONWEB- SERVICE IN THE 1C:ENTERPRISE SYSTEM
TASK: It is necessary to create a web service, by accessing which clients can determine all the necessary information on their applications.
The task is a demonstration and serves only as an example for understanding and teaching the mechanismweb-services.
SOLUTION:
Step 1. Let's create a new information base without configuration to develop a new configuration.
Step 2. Let's add several new objects to the configuration
Directory "Clients";
Document "Application";
Enumeration "Request Statuses".
Step 3. Let's create a new XDTO package.
Why and for what purpose are we creating an XDTO package? More information about using the XDTO mechanism can be found in “Chapter 16. Developer’s Guide” and .
Let us briefly note that the XDTO mechanism is a universal way of presenting data for interaction with various external data sources and software systems.
In our case, an XDTO package is created to describe the return value of the web service.
Let’s expand the “General” branch → “XDTO packages” → Add…
Let's specify the name of the XDTO package " DocumentsData"and its namespace http://localhost/request or http://192.168.1.76/request (to facilitate understanding and the learning process, we indicate the local IP address of the computer where the web server is installed (supported web servers: IIS or Apache)). Each Web service can be uniquely identified by its name and the URI of the namespace to which it belongs.
Our package contains two types of XDTO objects:
1) Сustomer- to transfer data from the “Clients” directory element.
- Name ;
2) Document- to transfer data from the “Application” document
This XDTO object type will contain the following properties:
- Сustomer- Customer type from the namespace http://192.168.1.76/request ; represents a reference to the XDTO object we defined above;
- Status- string type from the namespace http://www.w3.org/2001/XMLSchema ;
- Numder- string type from the namespace http://www.w3.org/2001/XMLSchema.
Step 4. Let's add a new Web service to the configuration
Let’s expand the branch “General” → “Web services” → Add…
For the Web service, we specify the following property values:
Name - DocumentsData
Namespace URI - http://192.168.1.76/request
XDTO Packages - DocumentsDataorhttp://192.168.1.76/request
Publication file name - request.1cws
Step 5. For the created Web service we will define the operation “ GetData»
Operation property values:
Return type - Document (http://192.168.1.76/request)
Possibly empty value - True
Procedure name - GetData.
Step 6. At the operation GetData let's define the parameter Сustomer with with the following values properties:
Value type - type string from the namespace http://www.w3.org/2001/XMLSchema;
Transmission direction - input.
Step 7 Let's open the module of the created Web service and place in it the Get() function, which will be executed when this Web service is called.
Function GetData(Customer) // Get the types of XDTO objects ClientType = FactoryXDTO.Type("http://192.168.1.76/request", "Customer"); RequestType = FactoryXDTO.Type("http://192.168.1.76/request", "Document"); // Get the client ClientLink = Directories.Clients.FindByName(Customer); If Not ValueFilled(ClientRef) Then Return Undefined; endIf; Request = New Request; Request.Text = "SELECT TOP 1 | Application.Link, | REPRESENTATION(Application.Status) AS Status, | Application.Number |FROM | Document.Request AS Application |WHERE | Application.Client = &Client"; Request.SetParameter("Client", ClientLink); RequestResult = Request.Execute(); If QueryResult.Empty() Then Return Undefined; endIf; Selection = QueryResult.Select(); Selection.Next(); Document = Selection.Link.GetObject(); // Create an XDTO object of an order Order = FactoryXDTO.Create(OrderType); Application.Numder = Sample.Number; Client = FactoryXDTO.Create(ClientType); Client.Name = ClientLink.Name; Application.Customer = Client; Application.Status = Selection.Status; // Return the request Return Application; EndFunction
Step 8 Let's publish the created Web service on the web server.
Menu item Configurator: “Administration” → “Publishing on a Web server”.
On the “Web Services” tab, set the “Publish Web Services” checkbox and also check the box next to our new Web service.
CHAPTERII
EXAMPLE OF APPEAL TOWEB-TO THE 1C:ENTERPRISE SYSTEM SERVICE FROM A THIRD-PARTY APPLICATION
The main purpose of the Web services mechanism in the 1C:Enterprise system is to transfer the necessary data to third-party applications.
Let's consider an example of developing an application in Delphi calling our web service from the first section of this article.
Step 1. Let's create new project and place several controls on the form
Text field - used to display information received from the web service;
Two buttons - clearing the text field and accessing the web service;
An input field is a parameter passed to the web service.
Step 2. Importing a WSDL file
As a result, we get a new module request(we defined this name directly in 1C). This module contains all the necessary information on the web service.
Step 3. Let's write a web service call handler
The DocumentDataPortType variable is already defined in the module request
Step 4. Launch the application and run the test.
CHAPTERIII
EXAMPLE OF APPEAL TOWEB-SERVICE IN THE 1C:ENTERPRISE SYSTEM
Step 1. Let's create a new external processing with the name "WEB_Service"
Step 2. Let's define a new form for processing
Step 3. We will indicate several details on the form
Client - type "String"
ClientReturn - type "String"
NumberReturn - type "String"
StatusReturn - type “String”.
We will display the details on the form.
Step 4. Let's add a form command " To get data»
Let's specify the command handler
&OnClient Procedure GetData(Command) GetDataOnServer(Client); End of Procedure Procedure GetDataOnServer(Client) // Create a WS proxy based on the link and perform the Get() operation Definition = New WSDefinitions("http://192.168.1.76/WEB_Service/ws/request.1cws?wsdl"); Proxy = New WSProxy(Definition, "http://192.168.1.76/request", "DocumentsData", "DocumentsDataSoap"); Application Data = Proxy.GetData(Client); If Application Data = Undefined Then ClientReturn = "Undefined"; StatusReturn = "Undefined"; ReturnNumber = "Undefined"; Return; endIf; CustomerReturn = Application Data.Customer.Name; StatusReturn = Application Data.Status; Return Number = Application Data.Numder; End of Procedure
The 1C:Enterprise system can use web services provided by other providers in two ways:
By using static links created in the configuration tree;
"plus": high speed;
"minus": re-importing the WSDL description using the configurator and saving the changed configuration.
By using dynamic links created by built-in language tools
(correspondingly, the “cons” of static ones for dynamic ones are “pros”)
CHAPTERIV
DEBUGGING WEB SERVICES IN THE 1C:ENTERPRISE SYSTEM
For a local web service you need:
Step 1. Place the file on the client where the 1C system runs webservicecfg.xml with the following content
Step 2. To file default. vrd publish configuration add line
Step 3. In the configurator, select the menu item
“Debug” → “Connection” → “Automatic connection” → “Web services on the server”
Step 4. Click on the “OK” button
For the server option, you also need to run the 1c server in debugging mode with the key /debug
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 recently worked with Hotmail, has already partially encountered 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:m="http://www.somesite.com/Postcode">
The key elements of a SOAP envelope are quite easy to find out: these are two parameters (
And the answer will look like this:
xmlns:m="http://www.somesite.com/Postcode">
This message is even easier to decipher. Element
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, it will be enough to turn to only one UDDI directory.
How does it all work
So how do I find the right web service?
Let's imagine that I'm a website developer, and my client asked me to add a new feature to the site: I need to add a zip code check on 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), (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 to perform certain functions, we rely entirely on the Internet, 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.
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'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 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.
What is a Web service?
Simply put, a Web service allows computer programs to 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 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 complex structure and can take place in different ways, depending on the number of people communicating, the language of communication used for communication, and 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:
- 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 of a simple XML file.
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 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.
- An XML message is stored in a plain text file, and therefore takes up more space than its equivalent in another format (such as a stripped, 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, 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.
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. Descriptions of the parts of the WSDL file and their collaboration will not be included in this article.
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 among themselves (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 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.
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 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. 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. 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.
