Introduction to Web Services and WSDL

In the Use WSDL Deployment Web Service series, Bilal will look at all the major technical aspects of creating, deploying, and publishing Web services-from Web Services Description Language (WSDL) to Simple Object Access Protocol (SOAP) and Universal Description, Discovery, and Integration (UDDI) registries. Part 1th focuses on WSDL creation: You will learn how to create a WSDL interface manually, and then compare your results with the output of the WSDL authoring tool. The idea of interoperable web-based distributed applications is not a recent occurrence. In just one example, the demand for Electronic data interchange (EDI) market is long before any meaningful implementation of Business-to-business online E-commerce has been achieved-and interoperability has become the most pressing EDI requirement as business-to-business electronic markets get more popular.

Take any online electronic market as an example. There are many businesses that provide unique "services" (Let's call it "Web Services"). In today's e-commerce, there is no mechanism to enable a business to automatically discover the services that its intended partners provide. The so-called next generation. com still provides this automatic discovery mechanism.

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 some type of syntax that allows you to use them to describe the answers to the following questions:

What services are available in your online business. How you invoke the business service. When a user invokes your business service, the business service requires what information he or she provides. How the user will provide these required information. What format the service will send the information returned to the user.

Luckily, WSDL provides the mechanism to complete all of these jobs.

WSDL and SOAP for a better understanding of how WSDL works, I'll first describe how SOAP and HTTP work with WSDL. The purpose of WSDL is to "describe" your Web service. Business will understand each other's services by exchanging WSDL files. Once you know your partner's services and want to invoke them, SOAP comes in handy. A service can be viewed as an object that is accessed through SOAP.

Most likely, you will be communicating with potential partners over the Internet or through e-mail. Of course, the Internet uses HTTP and e-mail works in SMTP, which makes HTTP and SMTP a good candidate for the "Transport service provider" of SOAP.

WSDL Authoring Now, I'll talk about the process of writing WSDL for a Web service. The purpose is to expose existing WEB services. Your situation may be one of the following:

You have an existing service (for example, a Web site) and want to indicate its functionality. You have a WSDL and want to implement the logic on the WEB server side according to the functionality that has been determined. (Some people might think this is an impossible scenario, but UDDI's fingerprint concept makes it extremely possible; I'll discuss UDDI in part Fourth of this series). You are starting from scratch, and there is neither a Web site nor a WSDL interface.

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

the four steps of WSDL writing I'll split the WSDL into four simple steps. Following each step, your Web service will be ready for deployment.

Step 1: Service interface you will build a mobile phone sales company's service interface as a sample project (I call this service mobilephoneservice). The company sells different models of mobile phones, so the back-end data repository for corporate WEB services will contain a table with two columns (model number and price). (to keep the focus in the WSDL itself, I keep the table simple). There are two ways to use the services represented by WSDL:

Getlistofmodels () GetPrice (ModelNumber)

The Getlistofmodels method provides an array of strings in which each string represents the model number of a mobile phone. GetPrice Gets the model number, then returns its price. The WSDL calls these methods as actions. You will now begin building the WSDL interface file (WSDL interface files).

The root element of each WSDL file is the complete description of the service that must be provided. First, you must provide a declaration of various namespaces in the element. The three external namespace declarations that must be made are WSDL, SOAP, and XSD (XML schema definition). There is also a namespace-tns, which refers to your mobilephoneservice (this means that TNS (targetnamespace abbreviation) contains the names of all the elements and attributes that are specifically defined for mobilephoneservice). But WSDL is the primary namespace that you will use most in WSDL authoring. When using other namespaces in this series of articles, I'll mention their usefulness.

About namespaces just note that WSDL uses the concept of namespaces extensively. I encourage you to go to the official website of the consortium to learn more about namespaces (see Resources). WSDL is an implementation of this idea, because namespaces provide unlimited flexibility, exactly what is needed for portable formats for electronic data interchange.

element contains one or more elements, in fact, each element is a series of operation that you want to represent. Alternatively, you can consider a single portType element as a logical grouping of the various methods that make up the class. For example, if your supply chain management solution requires interaction between customers and vendors, the most likely thing you can do is to define the functionality that interacts with them separately, that is, you will define a portType for users and vendors. Each portType should be called a service, so the entire WSDL file becomes a collection of services.

You must provide a name for each service. In this case, there is only one service (so there is only one). You need to specify a name for the mobile phone sales service using the PortType element's Name property.

Within each service, there are several methods, or operation,wsdl, that can be referenced by elements. The sample application has two methods to represent: Getlistofmodels and GetPrice. Therefore, you need to provide two elements, each with a name. I have named each operation using the element's Name property.

At this point, the WSDL file looks like Listing 1.

Listing 1: Defining Actions

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 ">

....... .......

....... .......

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

Recall that there are two actions to represent in the first step. The first operation, Getlistofmodels, does not have to obtain any arguments and returns an array of strings, each of which represents the model number of the mobile phone. Therefore, you must define an element that contains an array of strings.

Look at the various elements in Listing 2. The first element has a name attribute equal to Listofphonemodels (the logical name of the message), and a single element with the name models, which means that the listofphonemodels is a "only one part" message, where the only The name of part is "models". Messages can have as many part-as you want only to have a different name for them to uniquely identify them.

I have included another attribute of the element, which is type. Use this "type" attribute as a data type in C + + or Java. I have specified the models data type as Tns:vector. (Remember, I've specified some namespaces in the root element, one of which is TNS.) This type refers to the Mobilephoneservice namespace. This means that when you write WSDL, you can create your own namespace. Now you may ask two logical questions: why. And how to do it.

To answer why, let's take an example of an array of strings returned by the getlistofmodels operation. WSDL uses some of the original data types (such as int, float, long, short, Byte, String, Boolean, and so on) that are defined by the XML schema definition (XSD) and allows you to use them directly, or after building complex data types with these raw data types, Use them in the message. This is why you need to define your own namespace when referencing complex data types. In this case, you need to build a complex data type for the array of strings.

Now to see how to do the problem, you will use XSD to create your own namespace. To do this, I used the xsd:complextype element in the element to define a data type called a Vector. Vector uses two original data types: string (element Data) and Integer (element count). Therefore, Vector becomes part of the namespace and can be referenced by the alias TNS.

In Listing 2, I defined another two messages Phonemodel and Phonemodelprice in a similar way. These two messages use only 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 an element, you do not specify whether these messages enter parameters or return values. This is the work that you will accomplish in the elements within the element. So, as you can see in Listing 2, I've added and elements to both operations. Each input element refers to it by its name and treats it as a parameter to be supplied when the action is invoked by the user. Similarly, each element references a message, which treats the message as the return value of the action call.

To date, listing 2 has accurately defined the scope of the current discussion.

Step 3: Message delivery and transport I defined operations and messages in an abstract manner, regardless of the details of the implementation. In fact, the task of WSDL is to define or describe a WEB service, and then provide a reference to the external framework to define how the WSDL user will implement those services. You can use this framework as a "binding (binding)" between WSDL abstraction definitions and their implementations.

Currently, the most popular binding (binding) technology is the use of Simple Object Access Protocol (SOAP). The WSDL will specify a SOAP server that can access the actual implementation of the WEB service, and since then soap's entire task is to bring the user from the WSDL file to its implementation. Soap is the topic of the next part of this series, so I'll continue to focus on WSDL writing for the time being by avoiding the discussion of soap details.

The third step in WSDL writing is to describe the process of binding SOAP to a WSDL file. You will include the elements within the element. This binding element should have the name and type attribute. Name identifies this binding and the type identifies the PortType (a set of actions) that you want to associate with this binding. In Listing 3, you will find that the element's name matches the element's type attribute value.

The WSDL binding element contains a declaration of the external technology that you will use for binding purposes. Because soap is being used, the SOAP namespace is used here. In WSDL terminology, the use of an external namespace is called a extensibility element.

In Listing 3, you will see an empty element. The purpose of this element is to declare that SOAP will be used as a binding and transport service.

Element has two properties: style and transport. Style is an optional property that describes the nature of the operation within that binding. The transport property specifies the lower-level transport service that HTTP will use as the binding.

The SOAP client will read the SOAP structure from the WSDL file and coordinate with the SOAP server on the other end, so special attention must be paid to interoperability. I intend to cover this issue in detail in the third part of this series of articles.

After an empty element, there are two WSDL elements, representing the actions of step 1, respectively. Each element provides the binding details of the respective operation. So I provide another extensibility element, which is (still an empty element, related to the operation it takes). The element has a SOAPAction property that the SOAP client will use to create the SOAP request.

Recall that in step 2, the getlistofmodels operation has no input but output. Therefore, you must provide an element for the operation. The output contains an element (still an empty element that is related to the operation that occurred). The SOAP client needs this information to create a SOAP request. The namespace attribute value should correspond to the name of the service that you will deploy to the SOAP server, as described in the next section of this series of articles.

You are almost done with step 3. You will complete listing 3 as long as you copy the next operation to the back of this action.

Step 4: Summarize that you have generated a WSDL file that fully describes the service interface. Now, the WSDL requires an additional step to create a summary of the WSDL file. WSDL makes this file known as the implementation file, and in part Fourth of this series, it is used when you publish a Web service in a UDDI registry. Take a look at listing 4-this WSDL implementation file. Its main characteristics are as follows:

The root element is exactly the same as in Listing 3 (the WSDL interface file), except that listing 4 (the implementation file) refers to different targetnamespace to refer to the implementation file. There is an element that references the interface file (filename mobilephoneservice-interface.wsdl) and its namespace in Listing 3. Has a tag that has a logical name name that represents the service. Within the service element, there is a port element that references the SOAP binding created in Listing 3.

Using IBM's Web Services ToolKit (WSTK) for WSDL authoring Now, the Web service is fully ready for deployment. I've shown how to create these files manually (using a simple text editor like Emacs). You can generate the same files using Web service authoring tools such as IBM's WSTK (see Resources for a link to this toolbox and the other references mentioned in this article).

WSTK can use the wizard Help process to generate these files. The user can generate a WSDL file with the same two methods that I demonstrated in the previous tutorial, and compare the WSTK file with the WSDL file in listings 3 and 4.

You will notice the following differences:

WSTK creates all the name attributes according to the logical rules; In this example, I use a name that I consider convenient. WSTK generates at least one input token for each operation, even if the operation does not have to obtain any input. The listallphonemodels operation does not have any input elements, but if you use WSTK to generate the same file, it will be because of an empty INPUT element that contains this method. WSTK produces a third file other than the two files that have been generated. This third file is the SOAP deployment descriptor used by the SOAP engine for service deployment. I will discuss service deployment in this series of articles.

In this section, I demonstrate manual WSDL authoring to create interfaces and implementation files, and compare files generated with IBM's Web Services ToolKit. In the next installment of this series, I'll discuss deploying this WSDL service on a SOAP server.