Wsdl description. Standards for web services SOAP, WSDL, UDDI
WSDL (Web Services Description Language) version 1.1 was published on March 15, 2001. WSDL is an XML-based format used to describe web services using messages containing information on how to access a specific web service. WSDL we expand, which allows us to describe services (services) and their messages, regardless of what message formats or network protocols are used for transport, however, the most commonly used is WSDL 1.1 along with SOAP 1.1, HTTP GET/POST and MIME. Because the WSDL was developed jointly with SOAP, the same people participated in its development Microsoft, Ariba and IBM. If we consider the document WSDL intuitively, we can say that it allows answer 4 questions:
1) what are you doing? The answer to this question is given in a form suitable for both human perception and machine-perceivable form. Answer for the person in the tags:<name/>, <documentation/>, for car -<message/>, <pointType>
2) what language do you speak? (what types are you using?) Answer in the tag:<types/>
3) how will I communicate with you? (how will the client access the web service?): HTTP or SMTP. The answer lies in<binding/>
4) where can I find you? (where can I find this web service or what is its URL?). The answer is:<service/>
Structure:
Each WSDL document can be broken down into three logical parts:
1. defining data types - determination of the type of sent and received XML service messages
2. abstract operations - list of operations that can be performed with messages
3. service linking - the method in which the message will be delivered
Documentation WSDL can be created manually, but the language is strictly formalized WSDL allows you to automate the writing process WSDL-documents. Many Web service authoring tools contain utilities that automatically create WSDL-files describing ready-made Web services. For example, Web Services Authoring Tool Apache Axis contains a class Java2WSDL, creating WSDL- a file of a Java class or interface that describes a Web service. The IBM WSTK package, which includes Axis, contains the utility java2wsdl, which creates and runs an object from this class. She works from command line.
WSDL Document Elements
Let's describe the most commonly used WSDL tags:
Tag
1)target Name space is the namespace of our web service
2) xmlns – standard WSDL document namespace
3)xmlns: SOAP_ENC – namespace used to describe the SOAP encoding
4) xmlns: impl and intf – the namespace of the implementation and definition of our web service
· Web Service Definition Document
· Document for implementing a web service
For simplicity, as a rule, they use 1 file that contains all the information
Element
To describe an RPC call, you must create an input message and an output message.
Within this element, you can specify method parameters using the element
Element
Operations can have input messages as well as error messages.
Element
Element
Element import . Very often the service element is allocated to its wsdl document for reasons of practicality.
In order to allow combining several wsdl documents into one, the import element is used. It allows you to include one wsdl document into another.
Element types allows you to specify the types of data transmitted if they are not standard.
WSDL supports 4 modes of operations:
· one-way or one-way operations. The message is sent to the service endpoint. In this case, the operation is described by only one input message.
· Request-Response – request-response mode. This mode of operation is the most common. In this mode, the operation description contains an input and output message and an optional error message.
· Request-response type operation. In this mode, an endpoint is a client of another endpoint. The operation format is similar to request-response mode, but the output data is listed before the input data.
· Operation notification. This mode is another version of the one-way transmission primitive, in which the endpoint sends the message rather than receiving it. The operation contains only an output message.
Each web service provides a WSDL document (Web Service Description Language) that describes everything that the client needs to work with this service. A WSDL document provides a simple and consistent way for a developer to specify the syntax for calling any Web method. Moreover, this document allows you to use tools for automatically generating proxy classes, such as those included in the Visual Studio .NET and .NET Framework environments. Thanks to these tools, using a web service is as easy as using a local class.
The WSDL document is based on XML format, according to which information is divided into five groups. The first three groups are abstract definitions that are independent of platform, network, or language specifics, while the remaining two groups include specific descriptions.
soap protocol
Communication between web services and their clients is carried out through messages in XML format.
SOAP (Simple Object Access Protocol) is a message protocol for selecting web services.
The main idea of the SOAP standard is that messages should be encoded in a standardized XML format.
In addition to SOAP messages, you can use GET and POST methods to exchange data with .NET services HTTP protocol.
Advantages of using the SOAP format over other formats for data transfer:
Encode to XML structures data and DataSets with using SOAP just as easily as data of simple scalar types.
When using SOAP messages, additional tools, allowing you to easily add security or tracing features, for example.
There are SOAP toolkits for various programming languages (and even previous ones). Microsoft versions C++ and Visual Basic). Otherwise, in order to provide communication with the service via GET methods and POST of the HTTP protocol, you will obviously have to construct the query string yourself, and then parse the response.
Disco standard
The DISCO standard provides the simplest way to access manifest files, allowing you to group references to web services.
DISCO file can include files from different web servers and supports "dynamic search" - automatic search directory of web services files on the server.
Manifest files are useful because they combine multiple web services into a single list, but they do not allow clients to search for a specific type of web service without specifying the name of the company that developed it.
uddi specification
The UDDI (Universal Description, Discovery, and Integration) specification avoids these problems by using a special storage (repository) where enterprises and organizations can place data about the services they provide. More than 100 companies have pioneered the creation of UDDI technology (a complete list can be found at http://www.uddi.org/community.html), including Sun and Microsoft. By joining forces, these companies developed a draft UDDI specification, which was standardized after 18 months.
The information in this repository must be updated manually. To this end, some "node operators" maintain identical copies of the UDDI repository. These companies provide storage of the specified repository and free access to it to popularize web services. Additionally, Microsoft has included a version of UDDI in the software Windows server.NET for use on corporate intranets.
The UDDI store contains information about the enterprises that provide web services, the type of each service, and the relationships to information and specifications related to those services. The UDDI interface itself is a web service. To register or search for a service, you must send a SOAP message.
The main disadvantages of web services are lower performance and larger size network traffic compared to technologies such as RMI, CORBA, DCOM due to the use of XML text messages.
Web Services Description Language (WSDL)
In the last few examples you may have seen some WSDL code snippets. Recall that WSDL is an XML-based grammar designed to describe how external clients can interact with Web methods available via to this address URL within each supported communication protocol. In many ways, a WSDL document can be thought of as a "contract" between the Web service client and the Web service itself. This is another metalanguage. Specifically, WSDL is used to describe the following characteristics any available Web method:
XML Web method name;
Number, type and order of parameters (if any);
Return type (if provided);
HTTP GET, HTTP POST and SOAP call conditions.
In most cases, WSDL documents are generated automatically by the corresponding Web server. Recall that when you add the suffix ?wsdl to URL address pointing to a *.asmx file, the Web server generates a WSDL document for the specified XML Web service.
http://localhost/SomeWS/theWS.asmx?wsdl
But if IIS automatically generates the WSDL document for a given XML Web service, why then do you need a deep understanding of the syntax of the generated WSDL data? The answer usually depends on how your service will be used external applications. For XML Web services intended for "internal" use, the WSDL generated by the Web server will usually be sufficient.
Meanwhile. It is entirely possible to start developing an XML Web service by creating a WSDL document manually (as discussed above). The main idea of starting development by creating a WSDL document is related to compatibility issues. Remember that before the WSI specification, it was common for different Web service building tools to generate incompatible WSDL descriptions. If you start development with WSDL code, you can build the document as required.
As you can imagine, starting XML Web service development by creating a WSDL document requires a lot of good knowledge WSDL grammar, which is not discussed in the context of this chapter. But we'll consider basic structure WSDL document. Once you understand the basics, you can appreciate the usefulness of the wsdl.exe command line utility.
Comment. The latest information about WSDL can be found at http://www.w3.org/tr/wsdl.
Defining a WSDL Document
Valid document The WSDL opens and ends with the root element ‹definitions›. The opening descriptor typically defines various xmlns attributes. They define XML namespaces that define various subelements. At a minimum, the ‹definitions› element must indicate the namespace where the WSDL elements themselves are defined (http://schemas.xmlsoap.org/wsdl). To be useful, the opening ‹definitions› descriptor must also specify the XML namespaces defining simple types WSDL data, XML Schema types, SOAP elements, and target namespace. For example, this is what the ‹definitions› section looks like for our calculator Web service.
‹wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns-mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:tns="http://www.IntertechTraining.com/"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:http="http://schemes.xmlsoap.org/wsdl/http/"
targetNamespace="http://www.IntertechTraining.com/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"›
‹/wsdl:definitions›
In the context root element you can find five subordinate elements. General form The WSDL document should be something like this.
‹?xml version="1.0" encoding="utf-8"?›
‹wsdl:definitions…›
‹wsdl:types›
‹!-- List of types available for this Web service --›
‹wsdl:/types›
‹wsdl:message›
‹!-- Message format --›
‹wsdl:/message›
‹wsdl:portType›
‹!-- Port information --›
‹wsdl:/portType›
‹wsdl:binding›
‹!-- Binding information --›
‹wsdl:/binding›
‹wsdl:service›
‹!-– Information about the XML Web service itself --›
‹wsdl:/service›
‹wsdl:/definitions›
As you would expect, each of these subelements will contain additional elements and attributes that further clarify the description of the capabilities available. Let's look at the most important valid nodes one by one.
Element ‹types›
We'll first look at the ‹types› element, which contains descriptions of all the data types offered by the Web service. You may be aware that XML itself defines a number of "core" data types, all of which are defined within the XML namespace http://www.w3.org/2001/XMLSchema (which must be specified in the context of the root element ‹ definitions›). Take, for example, the Subtract() method of our calculator Web service, which has two input parameters integer type. In WSDL terms, the common language runtime type System.Int32 is described in the context of the ‹complexType› element.
‹s:element name= "Subtract"›
‹s:sequence›
‹s:element minOccurs=" 1 "maxOccurs=" 1 "name=" x"type=" s:int" /›
‹s:element minOccurs="" 1 "maxOccurs=" 1 "name=" y"type=" s:int" /›
‹/s:sequence›
‹/s:complexType›
‹/s:element›
The integer returned by the Subtract() method is also described within the ‹types› element.
‹s:element name= " SubtractResponse"›
‹s:complexType›
‹s:sequence›
‹s:element minOccurs=" 1 " maxOccurs=" 1 "name=" SubtractResult"type=" s:int"/›
‹/s:sequence›
‹ /s:complexType›
‹/s:element›
If you have a Web method that returns or receives custom types data, they will also appear in the context of the ‹complexType› element. We'll look at the details of how to make custom .NET data types available using the Web method later. For the sake of this example, let's say you define a Web method that returns a structure named Point.
public struct Point(
public string pointName;
The WSDL description for this "complex structure" would look something like this.
‹s:complexType name=" Point"›
‹s:sequence›
‹s:element minOccurs=" 1 "maxOccurs=" 1 "name=" x"type=" s:int" /›
‹s:element minOccurs=" 1 "" maxOccurs=" 1 "name=" y"type=" s:int" /›
‹s:element minOccurs=" 0 "maxOccurs=" 1 "name=" pointName"type=" s:string" /›
‹/s:sequence›
‹/s:complexType›
‹message› element
The ‹message› element is used to define the format for exchanging requests and responses for a given Web method. Because a single Web service allows multiple messages to be passed between a sender and a recipient, a single WSDL document is allowed to define multiple message elements. Typically, these definitions use the types specified within the ‹types› element.
Regardless of the number of ‹message› elements defined in the WSDL document, they are usually "present" in pairs. The first definition represents the input format of a message, and the second definition represents the output format of the same message. For example, the Subtract() method of the CalculatorWebService web service defines the following elements‹message›.
‹wsdl:message name=" SubtractSoapIn"›
‹wsdl:part name="parameters" element="tns:Subtract" /›
‹/wsdl:message›
‹wsdl: message name=" SubtractSoapOut"›
‹wsdl:part name="parameters" element="tns:SubtractResponse" /›
‹/wsdl:message›
Here you only see the SOAP communication of the corresponding service. As discussed at the beginning of this chapter, XML Web services can be invoked using SOAP or the HTTP GET and POST methods. But if you enable HTTP POST communication (explained later), the generated WSDL should show the following ‹message› data.
‹wsdl: message name=" SubtractHttpPostIn"›
‹part name="n1" type="s:string" /›
‹part name="n2" type="s:string" /›
‹wsdl:/message›
‹wsdl:message name=" SubtractHttpPostOut"›
‹part name="Body" element="s0:int" /›
‹wsdl:/message›
‹message› elements aren't very useful on their own. However, these message definitions are referenced by other parts of the WSDL document.
Comment. Not all Web methods require both a request and a response. If the Web method is "one-way", it only requires the ‹message› element of the request. You can designate a Web method as one-way using the attribute.
‹portType› element
The ‹portType› element defines the various connections that can occur between the client and the server, and each such relationship is represented by a nested ‹operation› element. It's easy to guess that the most typical operations here should be SOAP, HTTP GET and HTTP POST. However, there are other operations. For example, a one-way operation allows a client to send a message to a given Web server but not receive a response (this is similar to calling a method without expecting a return value). A request-response operation allows the server to send a request while the client is responding (which can be considered an extension of the request-response operation).
To illustrate the format of the optional sub-element ‹operation›, consider the WSDL definition for the Subtract() method.
‹wsdl portType name= "CalculatorWebServiceSoap"›
‹wsdl:operation name=" Subtract"›
‹wsdl:input message=" tns:SubtractSoapIn" /›
‹wsdl:output message=" tns:SubtractSoapOut" /›
‹ /wsdl:operation›
‹wsdl:/portType›
Notice how the ‹input› and ‹output› elements refer to the corresponding message name defined within the ‹message› element. If the Subtract() method had HTTP POST enabled, you would see the following additional element‹operation›.
‹wsdl:portType name="CalculatorWebServiceHttpPost"›
‹wsdl:input message=" s0:SubtractHttpPostIn" /› ‹wsdl:output message= " s0:SubtractHttpPostOut" /› ‹ wsdl:/operation› ‹wsdl:/portType› Finally, note that if a given Web method is described using the Description property, the ‹operation› element will contain a nested ‹documentation› element. The ‹binding› element This element specifies the exact format of the GET, POST, and SOAP exchange. This is the most verbose of all the elements contained within the context of the root ‹definition› element. For example, here is a definition of a ‹binding› element describing how a caller can interact with the Web method MyMethod(). using SOAP. ‹wsdl:binding name="СalculatorWebServiceSoap12" type=" tns:CalculatorWebServiceSoap"› ‹soap12:binding transport=" http://schemas.xmlsoap.org/soap/http" /›
‹wsdl:operation name= " Subtract"› ‹soap12:operation soapAction=" http://www.IntertechTraining.com/Subtract" style="document" /› ‹wsdl:input› ‹soap12:body use=" literal" /› ‹/wsdl:input› ‹wsdl:output› ‹soap12:body use=" literal" /› ‹/wsdl:output› ‹/wsdl:operation› ‹/wsdl:binding› ‹service› element Finally, we have the ‹service› element, which specifies the characteristics of the Web service itself (for example, its URL). The main task of this element is to describe the set of ports open by this Web server. To achieve this, the ‹services› element can use any number of nested ‹port› elements (not to be confused with the ‹portType› element). This is what the ‹service› element looks like for CalculatorWebService. ‹wsdl:service name= "CalculatorWebService"› ‹wsdl:documentation xmlns:wsdl ="http://schemas.xmlsoap.org/wsdl/"› Wonderful web calculator service ‹/wsdl:documentation› ‹wsdl:port name= "CalculatorWebServiceSoap" binding= "tns:CalculatorWebServiceSoap"› ‹soap:address location= "http://localhost:1109/CalculatorWebService/Service.asmx"/› ‹/wsdl:port› ‹wsdl:port name="CalculatorWebServiceSoap12" binding=" tns:CalculatorWebServiceSoap12"› ‹soap12:address location= "http://localhost:1109/CalculatorWebService/Service.asmx"/› ‹/wsdl:port› ‹/wsdl:service› So, as you can see, the WSDL code that is automatically returned by the ITS server is not super complex, but since the WSDL is an XML-based grammar, the code is quite verbose. However, you should now have a better understanding of the role of WSDL, so let's look a little more closely at XML Web services communication protocols. Comment. Recall that the System.Web.Services.Description namespace contains many types that allow you to programmatically read and process raw WSDL code (check it out for yourself if you're interested). Page 2 of 3 SOAP works very well if everything is known about the Web service. However, this is not always the case. The means of describing the interface for accessing a Web service is the WSDL language (Web Services Description Language). This standard was jointly developed by IBM, Microsoft and webMethods. Each of these three companies had their own approach to developing a standard for describing Web services: IBM created NASSL, Microsoft developed SCL, and webMethods came up with WIDL. The result of their collaboration was version 1.1 of the WSDL language. Regarding the W3C, it should be noted that, as with SOAP, the W3C consortium based on version 1.1 developed WSDL 1.2, which is now a W3C recommendation. The WSDL description of a Web service contains all the information necessary to use the service, including the available methods and their parameters. This information is contained in the following five elements: All this information is stored in the root element of the WSDL description Yeah... you can’t figure it out without a glass, but this is one of the simplest(!) WSDL files. Unfortunately, one of the drawbacks of the SOAP extension for PHP 5 is that, unlike other SOAP implementations, it does not automatically generate WSDL descriptions (at least not yet). Surely this flaw will be corrected in future versions of PHP. By the way! To automatically generate the WSDL description, you can use alternative implementations of the SOAP protocol in PHP: Now that we know how to get information about a Web service and how to query it, we need to learn how to find such a service. For this purpose, there is something similar to the Yellow Pages, namely the UBR (Universal Business Registries) registries - Web service directories. There are several such registries, including those of IBM, Microsoft, NTT-Com and SAP. These registries synchronize their data, so you can use any of them. The current version of the UDDI standard is UDDI 3.0, although most implementations use version 2. The developers of this standard include giant companies such as HP, Intel, Microsoft and Sun. To interact with UBR there is two types of APIs: Inquiry API and Publish API. Interface Inquiry API (Request) is for requesting services in UBR registries, and the interface Publish API allows developers to register their services. Looks like it's only a matter of time before the contents of the registries become filled with spam :) By the way! There are test registries designed to test service registrations before placing them in the "real" registries. In the example above, you can see that the UDDI request is encapsulated in a SOAP message, so it looks quite familiar. The response to the request is also a SOAP document, shown below:
Installing the SOAP extension for PHP5 is quite easy. On Windows, this module is located in the ext subdirectory of the PHP installation directory. To use it, you need to add the following line to the php.ini file: extension=php_soap.dll To work, this module requires that it is included in PHP 5 by default, at least in the Windows version. Web services are application integration technologies that can be used on the Internet. As an example of the possible use of web services, consider travel planning. Typically, this situation requires: booking plane tickets, hotel reservations, renting a car and, possibly, using the services of local companies that organize excursions. Traditionally using the Internet, you will have to visit the server of the airline, the server of the hotel or hotel chain, the server of the car rental company, and the server of the company that specializes in organizing excursions in the place of your choice. All these actions can take quite a long time before you achieve your goal. And at the same time, none of the companies you use will know what your plans are, and therefore will not be able to optimize your time. The problem is that companies specializing in certain areas - airlines, hotels, car rentals, etc., in most cases are closed to themselves and use their own means of storing and presenting data. It would be more convenient to launch an application that would receive the necessary information from you and perform all routine actions - booking tickets, booking a hotel, etc. - automatically, without your participation. To make this possible, you must use web services. Let's look at what will change in this case. Let's say an airline provides a web service that allows applications to retrieve a list of flights between two cities for a given date. In this case, you no longer need to go to the airline's website and enter various search criteria - all the necessary information is available in a single XML document. Now suppose that an airline, hotel, and car rental agency provide web services that allow you to programmatically purchase tickets, book rooms, and rent cars. In this case, you can combine calls to all these services into a single application that can perform all the routine work without user intervention. However, the functionality of the new class of web applications does not end there. Our application can, for example, periodically contact the airline’s web service to determine the status of the flight and, in case of delay, notify hotel services, rental services, etc. to extend your reservation. Besides the obvious improvement in customer experience, using web services has many other benefits. For example, if a car rental agency knows that your flight is delayed, they can be more flexible with their cars. As the number of web services increases, we will see more complex examples of their use. However, it should be noted that the introduction of the concept of web services requires not only a revision of many business rules and interaction patterns between industries and sectors of a particular industry, but also increased security of data exchange. Having considered the practical application of web services, let's turn to the standards underlying these services. standards As we already know, web services are based on Internet standards. These standards define protocols, not how they are implemented. This statement is the key to the success of the Internet - no company can influence Internet standards and set its own rules of the game. For example, web services standards are developed jointly by companies such as IBM, Microsoft, Ariba and several others, and are discussed by the World Wide Web Consortium (W3C) committee. Web services are based on three main web standards: SOAP (Simple Object Access Protocol) - a protocol for sending messages via HTTP and other Internet protocols; WSDL (Web Services Description Language) - a language for describing software interfaces of web services; UDDI (Universal Description, Discovery and Integration) is a standard for indexing web services. Application servers store web services and make them available via HTTP GET, HTTP POST and HTTP SOAP protocols. Existing web services are described in WSDL documents, which are located either on the application server or in special XML stores. A WSDL document can reference other WSDL documents and XSD (XML Schema) documents that describe the data types used by web services. XML stores are used to manage WSDL documents. Inside the WSDL document is the address (URL) of the web service. Web services are described and indexed in a business registry containing addresses (URLs) of WSDL documents. In the following sections, we'll look at the three main web standards on which web services are based - SOAP, WSDL and UDDI - in more detail. SOAP - Simple Object Access Protocol SOAP is a standard for sending and receiving messages over the Internet. This protocol was originally proposed by Microsoft as a means for remote procedure call (RPC, Remote Procedure Call) over HTTP, and the SOAP 1.0 specification (Userland, Microsoft, Developmentor) was closely related to the Component Object Model. IBM and a number of other companies, including Lotus, made some contributions to the development of this protocol, and its specification was sent to the W3C committee for consideration. The SOAP specification defines an XML "envelope" for message transmission, a method for encoding programmatic data structures in XML format, and a means of communicating over the HTTP protocol. SOAP messages come in two types: Request and Response. The request calls a method of a remote object, the response returns the result of executing this method. Here is an example of a request in SOAP format: And here is the answer: The SOAP specification defines an encoding format, which in turn defines how data is represented in XML format. WSDL - Web Services Description Language In order for applications to use web services, their programming interfaces must be described in detail - from this point of view, WSDL plays the same role as Interface Definition Language (IDL) in distributed computing. The description may include information such as protocol, server address, port number used, list of available operations, request and response format, etc. Several languages have been proposed to describe this information. One of them was the Service Description Language (SDL), developed by Microsoft and included in the first version of the Microsoft SOAP Toolkit. IBM reworked the specification and, using the Network Accessible Service Specification Language (NASSL) specification, released the NASSL Toolkit as part of SOAP4J. The ideas implemented in NASSL influenced the SOAP Contract Language (SCL) specification proposed by Microsoft. Currently, both specifications (NASSL and SDL/SCL), as well as proposals from other companies, are taken into account in the WSDL language specification. To describe business logic, IBM and Microsoft are working on the Web Services Flow Language (WSFL) specification. Here is an example of a service description skeleton in WSDL: As we can see, the description of services is an XML document consisting of several elements, including a description of the namespace, descriptions of types and elements, messages, port, as well as possible operations - requests and responses. UDDI - Universal Description, Discovery and Integration The purpose of UDDI is to provide a mechanism for discovering web services. UDDI defines a business registry in which web service providers can register services and developers can search for the services they need. IBM, Microsoft, and Ariba have created their own UDDI registries (soon to be merged into a web registry), in which developers can register their web services, after which the data will be automatically replicated to other registries. UDDI is based on four types of elements: Business Entity, Business Service, Binding Template and Technology Model. The Business Entity element describes the industry that provides this web service. This element may include category descriptions for a given industry, facilitating a more detailed search for services. Business Service is a class of services within a specific industry or service. Each industry belongs to a specific Business Entity. Together, the Binding Template and Technology Model define the web service. The Technology Model contains an abstract description, and the Binding Template contains a concrete specification of the service. Each Binding Template element belongs to a specific Business Service element, but multiple Binding Template elements can reference a single Technology Model element. The UDDI business registry is itself a SOAP web service. It supports the operations of creating, modifying, deleting, and searching for elements of all four types discussed above. ICSI student's abstract, scientific supervisor – Sergey KuneginDescription using WSDL
WSDL description of the Web service
Directory Search Using UDDI
This is what a Web service request looks like:
Installation
xmlns:SOAP-ENV="http:///envelope"
SOAP-ENV:encodingStyle="http:///encoding//"
xmlns="http://(soaporg)/wsdl/">
...
