Deploy web services using WSDL: Part 1 Introduction to Web Services and WSDL

From

Http://www-128.ibm.com/developerworks/cn/webservices/ws-intwsdl/part1/index.html

Use WSDL to deploy Web Services: Part 1

Introduction to Web Services and WSDL

Level: elementary

Bilal Siddiqui, CEO, WAP monster

November 01, 2001

In the "deploy Web Services with WSDL" series, Bilal will study all major technical aspects of creating, deploying, and publishing Web services-from Web Service Description Language (WSDL ), to Simple Object Access Protocol (SOAP) and Universal Description, discovery and Integration (UDDI) registration center. Part 1 describes how to create a WSDL: you will learn how to manually create a wsdl interface, and then compare your results with the output of the WSDL Writing Tool.

The concept of interoperable web-based distributed applications is not a new concept. For example, the market demand for electronic data exchange (EDI) exists before any meaningful implementation of B2B online e-commerce-and with the popularization of B2B e-commerce, interoperability has become the most urgent EDI demand.

Take any online electronic market as an example. There are many enterprises that provide their own "services (services) (Let us call it "Web Service (Web services)"). In today's e-commerce, there is no such mechanism, so that a business can automatically discover the services provided by its expected partners. The so-calledNext Generation. comThis automatic discovery mechanism is also provided.

What is WSDL?

This new. com requires a solution to describe the services it provides (Web Services ). Specifically, this means that you need a format or a type of syntax so that you can use them to describe the answers to the following questions:

• What services does your online business provide?
• How do you call business services?
• What information does a user need to provide when calling your business service?
• How do Users provide the required information?
• In what format will the service send the information returned to the user?

Fortunately, WSDL provides a mechanism to complete all these jobs.

 

 

WSDL and soap

To better understand how WSDL works, I will first describe how soap and HTTP work with WSDL. The purpose of WSDL is to "describe" your web service. Businesses will understand each other's services by exchanging the WSDL file. Once you know the services of your partners and want to call them, soap will come in handy. Services can be viewed as objects accessed through soap.

Most likely, you will communicate with potential partners through the Internet or email. Of course, the Internet uses HTTP and email works in SMTP mode, which makes HTTP and SMTP a favorable candidate for soap as the "transport service provider.

 

 

Write WSDL

Now, I will describe the process of compiling WSDL for Web Services. The purpose is to publish existing Web Services. Your situation may be one of the following:

• You have an existing service (such as a website) and want to express its functionality.
• You Have a wsdl and want to implement the logic of the Web server based on the defined functions. (Some may think this is an impossible solution, but the concept of UDDI fingerprint makes it extremely possible; I will discuss UDDI in the fourth part of this series ).
• You are starting from scratch and have no website or WSDL interface.

The information covered in this article applies to either or all of these possibilities.

 

 

Four steps for writing WSDL

I will divide the WSDL writing into four simple steps. Following each step, your web service is ready for deployment.

Step 1: Service Interface

You will build a service interface of a mobile phone sales company as a sample project (I call this serviceMobilePhoneService). The company sells mobile phones of different models, so the company's web service back-end data repository will contain (model numberAndprice. (To keep the focus on the WSDL itself, I keep the table simple ). There are two methods for the Service to be expressed using WSDL:

• Getlistofmodels ()
• Getprice (modelnumber)

GetListOfModelsMethod provides a string array, where each string represents a mobile phone model.GetPriceGet the model and return its price. WSDL calls these methods as operations. Now we will start to build the "WSDL interface file (WSDL interface file)".

The root element of each WSDL file is<definitions>And must provide a complete description of the service. First, you must<definitions>Element to provide declarations of various namespaces. The three mandatory external namespace declarations are WSDL, soap, and XSD (XML schema definition ). There is also a namespace-TNS, which refers to your mobilephoneservice (which represents the abbreviation of TNS (targetnamespace ).MobilePhoneServiceName of all elements and attributes defined ). However, WSDL is the main namespace that you will use most in WSDL writing. When using other namespaces in this series of articles, I will mention their utility.

Note that the concept of namespace is widely used in WSDL. I encourage you to go to the W3C official website to learn more about namespaces (see references ). WSDL is an implementation of this idea, because namespace provides unlimited flexibility, and this is exactly what is needed for the portable format of electronic data exchange.

<definitions>The element contains one or more<portType>Element. In fact, each element is a seriesoperation. Alternatively, you can think of a single porttype element as a logical grouping of various methods into classes. For example, if your supply chain management solution needs to interact between customers and suppliers, what you are most likely to do is to define the functionality of interaction with them separately; that is, you will define a porttype for each user and supplier. Each porttype should be calledServiceTherefore, the entire WSDL file becomes a service set.

A name must be provided for each service. In this example, there is only one service (so there is only one<portType>). ThenameThe property is the name specified by the mobile phone sales service.

There can be several methods in each service, oroperation, WSDL passed<operation>Element to reference them. The sample application has two methods to represent:getListOfModelsAndgetPrice. Therefore, you must provide two<operation>Element, each element hasname. I have used<operation>ElementnameEach operation is named for the attribute.

In this case, the WSDL file looks like Listing 1.

Listing 1: defining operations

<?xml version="1.0" encoding="UTF-8" ?> <definitions  name="MobilePhoneService"      targetNamespace="www.mobilephoneservice.com/MobilePhoneService-interface"      xmlns="http://schemas.xmlsoap.org/wsdl/"      xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"      xmlns:tns="http://www.mobilephoneservice.com/MobilePhoneService"      xmlns:xsd="http://www.w3.org/1999/XMLSchema">      <portType name="MobilePhoneService_port">              <operation name="getListOfModels ">                      .......                      .......              </operation>              <operation name="getPrice">                      .......                          .......              </operation>      </portType> </definitions>

Step 2: Specify parameters

After an operation (or method) is defined, You need to specify the parameters that will be sent to and returned from them. In WSDL terminology, all parameters are called "messages ". It is useful to think that you are delivering a message and the returned message is returned. A method call is an operation that prepares to return a "message" to respond to the incoming message.

Recall that there are two operations to represent in step 1. First operationgetListOfModelsNo parameters are required and an array of strings is returned. Each string represents the mobile phone model. Therefore, you must define<message>Element.

Let's take a look at the various<message>Element. The first element is equalListOfPhoneModels(Logical name of the message), and a single<part>Element, which meansListOfPhoneModelsIs a message containing only one part. The only part is named "models ". A message can have any number of parts. A message is uniquely identified by different names.

I already include<part>Another attribute of the element, which istype. Use this "type" attribute as the data type in C ++ or Java. I have alreadymodelsThe data type of is specified as TNS: vector. (Recall that I am<definitions>Some namespaces are specified in the root element, one of which istns.) This type refersMobilePhoneServiceNamespace. This means that you can create your own namespace when writing the WSDL. Now you may ask two logical questions: Why? And how to do it?

To answerWhy?, Let's usegetListOfModelsThe string array returned by the operation is used as an example. WSDL uses the XML schema definition (XSD) to define some original data types (such as int, float, long, short, byte, String, Boolean, etc.) and allows you to use them directly, alternatively, you can use these primitive data types in messages after building complex data types. This is why you need to define your own namespace When referencing complex data types. In this examplearray of stringsConstruct a complex data type.

Now let's seeHow to doQuestion: You will use XSD to create your own namespace. For this purpose<types>The XSD: complextype element is used to defineVector.VectorTwo Original data types are used: string (element data) and INTEGER (element count ). Therefore,VectorBecome a part of the namespace and use aliasestns.

In Listing 2, I defined the other two messages in a similar way.PhoneModelAndPhoneModelPrice. These two messages only use the original data type string in the XSD namespace, so you do not have to define any more complex data types to use them.

You may have noticed that when you create<message>When the element is specified, whether the message enters the parameter or the return value is not specified. This is<portType>Element<operation>Elements. Therefore, as you can see in Listing 2<input>And<output>The elements are added to these two operations. Each input element uses a message name to reference it and uses it as a parameter to be provided when you call this operation. Similarly, each<output>The element references a message, which is treated as the return value of an operation call.

So far, listing 2 accurately limits the scope of the current discussion.

Listing 2: defining parameters

<?xml version="1.0" encoding="UTF-8" ?> <definitions  name="MobilePhoneService"    targetNamespace="http://www.mobilephoneservice.com/MobilePhoneService-interface"    xmlns="http://schemas.xmlsoap.org/wsdl/"    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"    xmlns:tns="http://www.mobilephoneservice.com/MobilePhoneService"    xmlns:xsd="http://www.w3.org/1999/XMLSchema">    <types>       <xsd:schema targetNamespace="http://www.mobilephoneservice.com/MobilePhoneService"       xmlns="http://www.w3.org/1999/XMLSchema/">          <xsd:complexType name="Vector">             <xsd:element name="elementData" type="xsd:String" />             <xsd:element name="elementCount" type="xsd:int" />          </xsd:complexType>       </xsd:schema>    </types>    <message name="ListOfPhoneModels">       <part name="models" type="tns:Vector">    </message>    <message name="PhoneModel">       <part name="model" type="xsd:String">    </message>    <message name="PhoneModelPrice">       <part name="price" type="xsd:String">    </message>    <portType name="MobilePhoneService_port">       <operation name="getListOfModels ">          <output message="ListOfPhoneModels"/>       </operation>       <operation name="getPrice">          <Input message="PhoneModel"/>          <output message="PhoneModelPrice"/>       </operation>    </portType> </definitions>

Step 3: message transmission and transmission

I define operations and messages in an abstract way without considering implementation details. In fact, the WSDL task is to define or describe Web Services, and then provide a reference to the external framework to define how the WSDL user will implement these services. This framework can be used as the "binding (binding)".

Currently, the most popular binding (bindingThe technology is to use Simple Object Access Protocol (SOAP ). WSDL specifies the SOAP server that can access the actual implementation of the web service. Since then, the whole task of soap is to bring the user from the WSDL file to its implementation. Soap is the topic of the next part of this series of articles, so I will continue to focus on WSDL writing without discussing soap details.

The third step in WSDL writing is to describe the process of binding soap to the WSDL file. You will<binding>Elements include<definitions>Element. This binding element should havenameAndtypeAttribute.nameBind the identifiertypeThe porttype (a group of Operations) that you want to associate with this binding will be identified ). In listing 3, you will find<portType>ElementnameAnd<binding>The Type attribute value of the element matches.

The WSDL binding element contains the declaration of external technologies that you will use for binding purposes. Because soap is being used, the namespace of soap will be used here. In WSDL terminology, the use of external namespaces is calledextensibilityElement.

In listing 3, you will see an empty<soap:binding/>Element. The purpose of this element is to declare that soap will be used as the binding and transmission service.

<soap:binding>The element has two attributes: style and transport. Style is an optional attribute that describes the nature of the operation in the binding. The transport attribute specifies HTTP as the lower-level transmission service that will be used for this binding.

The soap client reads the soap structure from the WSDL file and coordinates it with the SOAP server at the other end.interoperability. I plan to detail this issue in the third part of this series.

In the empty<soap:binding/>The element is followed by two WSDL<operation>The operation in step 1. Each<operation>Elements provide binding details for their respective operations. Therefore, I provide anotherextensibilityElement, that is<soap:operation/>(It is still an empty element, which is related to the operation that occurs ). The<soap:operation/>The element has a soapaction attribute, which is used by the soap client to create a SOAP request.

Recall step 2,getListOfModelsThe operation only has output, but does not have any input. Therefore, you must provide<output>Element. The output contains<soap:body/>Element (it is still an empty element, which is related to the operation it takes ). The soap client needs this information to create a SOAP request.<soap:body/>The namespace attribute value of must be consistent with the one you deploy on the SOAP serverserviceThe SOAP server is described in the next section of this series.

You have almost finished step 3. As long as you copy the next operation to the end of this operation, you will complete listing 3.

Listing 3: adding soap support

<?xml version="1.0" encoding="UTF-8" ?> <definitions  name="MobilePhoneService"    targetNamespace="http://www.mobilephoneservice.com/MobilePhoneService-interface"    xmlns="http://schemas.xmlsoap.org/wsdl/"    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"    xmlns:tns="http://www.mobilephoneservice.com/MobilePhoneService"    xmlns:xsd="http://www.w3.org/1999/XMLSchema">    <types>       <xsd:schema             targetNamespace="http://www.mobilephoneservice.com/MobilePhoneService"       xmlns="http://www.w3.org/1999/XMLSchema/">          <xsd:complexType name="Vector">             <xsd:element name="elementData" type="xsd:String" />             <xsd:element name="elementCount" type="xsd:int" />          </xsd:complexType>       </xsd:schema>    </types>    <message name="ListOfPhoneModels">       <part name="models" type="tns:Vector">    </message>    <message name="PhoneModel">       <part name="model" type="xsd:String">    </message>    <message name="PhoneModelPrice">       <part name="price" type="xsd:String">    </message>    <portType name="MobilePhoneService_port">       <operation name="getListOfModels ">          <output message="ListOfPhoneModels"/>       </operation>       <operation name="getPrice">          <Input message="PhoneModel"/>          <output message="PhoneModelPrice"/>       </operation>    </portType>    <binding name="MobilePhoneService_Binding" type="MobilePhoneService_port">      <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" />       <operation name="getListOfModels ">          <soap:operation soapAction="urn:MobilePhoneService" />          <input>             <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:MobilePhoneService" use="encoded" />          </input>          <output>             <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:MobilePhoneService" use="encoded" />          </output>       </operation>          <operation name="getPrice">          <soap:operation soapAction="urn:MobilePhoneService" />             <input>             <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:MobilePhoneService" use="encoded" />          </input>          <output>             <soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:MobilePhoneService" use="encoded" />          </output>       </operation>    </binding> </definitions>

Step 4: Summary

You have generated a complete description Serviceinterface. Now, the WSDL requires an additional step to create the summary of the WSDL file. WSDL calls this fileimplementationFile, which is used when you publish a web service in the UDDI registry in the fourth part of this series. See Listing 4-the WSDL implementation file. Its main features are as follows:

• Besides
  Listing 4 references differenttargetNamespaceIn addition to referencing implementation files,<definitions>The root element is exactly the same as that in listing 3 (the WSDL interface file.
• There is
  <import>Element that references the interface file (file name MobilePhoneService-interface.wsdl) and its namespace in listing 3.
• There is
  <service>Tag. One of them indicates the logical name of the service.name. There is a port element in the service element that references the soap binding created in listing 3.

Listing 4: WSDL implementation file

<?xml version="1.0" encoding="UTF-8" ?> <definitions name="MobilePhoneService"       targetNamespace="http://www.mobilephoneservice.com/MobilePhoneService"    xmlns="http://schemas.xmlsoap.org/wsdl/"    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"    xmlns:tns="http://www.mobilephoneservice.com/MobilePhoneService"    xmlns:xsd="http://www.w3.org/1999/XMLSchema">    <import location="http://localhost:8080/wsdl/MobilePhoneService-interface.wsdl"       namespace="http://www.mobilephoneserviceservice.com/MobilePhoneService-interface" />       <service name="MobilePhoneService">       <documentation> Mobile Phone Information Service </documentation>       <port binding="MobilePhoneService_Binding" name="MobilePhoneService_ServicePort">          <soap:address location="http://localhost:8080/soap/servlet/rpcrouter" />       </port>    </service> </definitions>

 

Use IBM Web Services Toolkit (wstk) for WSDL writing

Now, the Web service is fully ready for deployment. I have demonstrated how to manually create these files (using a simple text editor like Emacs ). You can use Web Service writing tools such as IBM's wstk (see references for this toolkit and links to other references mentioned in this article) to generate the same files.

Wstk can use the wizard help process to generate these files. You can generate a WSDL file that is the same as the two methods I demonstrated in the above tutorial, and compare the wstk file with the WSDL file in listing 3 and 4.

Note the following differences:

• Wstk
  All name attributes are created according to logical rules. In this example, I use a name that is convenient.
• Wstk generates at least one input for each operation
  Mark, even if this operation does not have to get any input.listAllPhoneModelsThe operation does not have any input element, but if you use wstk to generate the same file, it will contain an empty input element of this method.
• Wstk generates a third file except the two generated files. The third file is
  The soap deployment descriptor used by the SOAP engine for service deployment. I will discuss service deployment in this series.

In this section, I demonstrated how to manually write WSDL to create interfaces and implementation files, and compared it with the files generated by IBM Web Services toolkit. In the next part of this series, I will discuss how to deploy the WSDL service on the SOAP server.

 

 

References

• For more information, see the original article on the developerworks global site.

• Visit the W3C official website to find the Web Service Description Language (WSDL) 1.1 specification and all other XML-related official specifications, including the XSD and namespace technical documents.
• Visit the IBM alphaWorks website to download the Web Services Toolkit (wstk) used in this article ).
• Download the Apache SOAP toolkit from apache.org.
  Building Web Services: Making Sense of XML, SOAP, WSDL, and UDDI is a new book, the authors are Steve Graham, Simeon simeonov, Toufic boubez, Glen Daniels, Doug Davis, Yuichi Nakamura, and Ryo neyama-a group of people from all over the Web Service technology field. (SAMS publication, 2001 ).
• Read this article on developerworks, which describes how to map WSDL elements to the UDDI registry.
• Please visit webservicesarchitect.com to get a good article about Web Services.

 

 

About the author

Bilal Siddiqui is an XML consultant. After graduating from the university of engineering and technology, Lahore, in 1995, he began designing various software solutions for industrial control systems. Later, he worked on XML and used his experience in C ++ programming to build XML processing tools, server-side parsing solutions, and service applications based on Web and WAP. You can obtain a working copy of the code file contained in this article from Bilal via email (wap_monster@yahoo.com.