WF from Getting started to mastering (18th Chapter): Invoking Web Services in your workflow

After completing this chapter, you will learn:

1. Invoke Web Services in your workflow

2. Adding and configuring Web service proxies

3. session (sessions) management in your workflow

For me, some of the data sent and received based on the network is very attractive to me, and for many years I have enjoyed writing code based on communication. When I see WF's ability to connect to Web services and serve as a Web service, I've looked at it more deeply.

WF integrates several activities based on XML Web services, which we will investigate on the client side of the activity in this chapter. (In the last chapter, "Workflow as a Web service," we'll discuss the activities on the server side). Before I actually use the invokewebservice activity, I think I should describe how Web services work, because we need to understand the term in this chapter and in the last chapter.

Web Service Architecture

One idea is that any internet-based server that performs tasks based on your request is a Web service. However, in this chapter and in the next chapter I will use this term to compare with a more precise explanation. Here, I'll mention the XML Web service, which is a service based on the SOAP protocol.

Note: "Soap" comes from the acronym for Simple Object Access Protocol, an xml-based communication framework. However, in the current release of SOAP, the Protocol is simply referred to as the SOAP protocol. You can find the latest SOAP specification in http://www.w3.org/tr/soap/.

The basic idea behind the creation of the SOAP protocol is the intention to convert the original data type or even the complex data structure from the original binary format into XML, which can then be sent over the internet, just as it would send a Web page by using HTML. The original SOAP specification clearly outlines the serialization format (serialization format) to describe integers, strings, enumerations to arrays, and complex structures. The later specification relaxes the serialization format with the advent of the serialization Description Language (serialization Descripton languages). Currently, the serialized description language selected is the Web Services Description Language (Web Service Description Language), or WSDL.

WSDL allows you to format your SOAP messages in what you think is appropriate. In the WSDL format you can simply and easily describe the content and provide your WSDL to the user, so use your services, from which they can interpret the structure and methods of your Web service output. Although the original SOAP specification wanted to use SOAP in the context of remote method invocation, the latest specification, with WSDL, was allowed to be used in more message-based architectures, which could be anything you could serialize into XML.

Therefore, when you reference a remote Web service, you will download and interpret the WSDL provided by the service. When you use. NET, the tools built into the. NET Framework will do this for you and create a C # class that you can use to invoke the method of the remote service. This C # class is called a proxy because its behavior is to replace the real service. Ultimately, your software will not even know that it is actually communicating with a internent service in addition to communication delays. The proxy makes it look as if the service is on your local computer.

To recap, you can refer to a Web service that will send its WSDL to you. NET creates an agent for you that you can use to communicate with the remote server based on the specification of the remote server (according to its WSDL). When you communicate, the data you send is converted to XML and sent using the SOAP protocol on the (communication) line. The remote server interprets your request and response. When you receive a response from the server, the response XML is converted back to the binary data that your code will use.

Note: It will be very easy for you to continue discussing Web services and how they are executed, but what we really need is to go deep and migrate it into the workflow. But if you want to learn more, many books and online references to this knowledge are available. A very good starting point is: http://msdn.microsoft.com/webservices/.

Using Invokewebservice Activities

WF's built-in client-facing XML Web service support is derived from invokewebservice activities. In many ways, invokewebservice activity is just one of your proxies, but it adds the ability to use a single session cookie to control multiple invocations.

Some key properties are needed when using invokewebservice activities, as shown in table 18-1.

Table 18-1 Some key properties of invodewebservice activity

Property	Function
MethodName	Gets or sets the method to invoke when the activity is executed. This attribute represents the method name of the remote method you want to invoke.
Proxyclass	Gets or sets the type name of the proxy class. You can either provide it yourself or you can drag the activity into your workflow by creating a proxy class to let WF help you with.
SessionID	Gets or sets the session to be used. You can use this mechanism to bundle all the different XML Web service calls together. I'll discuss this property further in the section "Work with Session".
Url	Gets or sets the URL to use to communicate with the XML Web service. Although you can easily use the property panel to modify it for your invokewebservice activity, the URL itself is actually saved in the Settings Property bundle (bag) of your workflow project.