Invoking Web Services from Within Your Workflows in C#

Drawing UPC Symbol in C# Invoking Web Services from Within Your Workflows

18

Once you add the InvokeWebService activity, which in many respects is similar to adding a Web reference to a typical Visual Studio project, you need to configure the proxy. There are two ways this can be accomplished: static and dynamic configuration.

Static proxy configuration is performed by setting the properties of the InvokeWebService activity using Visual Studio s Properties pane. When you add a new InvokeWebService activity and bind to a Web service (using the Add Web Reference dialog box we ve been discussing), nearly everything is complete and ready to use. The URL is known and saved in the workflow project s Settings property bag, and the proxy type is assigned. (The ProxyClass property will have a value.) The exception is the MethodName property. Visual Studio knows what methods are available to you when it interprets the WSDL and creates the proxy. Specifying a method to invoke is then as simple as dropping a list of available methods and selecting one. Unless that method has bindable parameters, your configuration is complete. If there are parameters, either into or from the method, you need to bind a local field or dependency property to those parameter values. With the MethodName established and the method properties bound, you truly are ready to access the XML Web service using InvokeWebService.

However, as soon as anything is statically set, it always seems like we need to dynamically reconfigure it. Perhaps you want to algorithmically assign a URL rather than use one baked into Settings. Or maybe you need to assign credentials to the invocation to gain access to a secured Web service. None of these things is available through statically configured parameters in Visual Studio. The solution lies in handling the Invoking event. If you provide an event handler for the InvokeWebService activity s Invoking event, you are given access to the proxy class itself via the event s InvokeWebServiceEventArgs. InvokeWebServiceEventArgs has a property named WebServiceProxy that is the instance of the proxy the InvokeWebService activity is using to invoke the XML Web service. By simply casting this object to the proxy type you re using, you can change any dynamic value you require, including the URL and credentials. Note

For information regarding how you gain access to the Internet when it is protected by a proxy server, see http://msdn2.microsoft.com/en-us/library/system.net.configuration. proxyelement(VS.80).aspx. For information describing accessing secured XML Web services, see http://msdn.microsoft.com/library/default.asp url=/library/en-us/dnnetsec/html/SecNetch10.asp (especially the Passing Credentials for Authentication to Web services section).

Sessions, in Web parlance, are sets of connected request-response pairs. That is, if you make a request of a Web resource in one invocation, you expect the next invocation to keep track of the previous invocation. This is definitely not how the HyperText Transfer Protocol (HTTP) works under the covers. HTTP was developed to support a single request-response pair. Any knowledge of prior dealings with the server are completely forgotten. However, as Web users, we demand that Web request-response pairs be remembered. The most obvious example is the Web-based shopping cart. When you place orders for goods over the Internet and those goods are collected into a virtual shopping cart, you expect the things you selected will be available for checkout at a later time. How do we reconcile the disparity between what HTTP expects to support and what we, as users, demand The answer is Web applications maintain session state. When you begin using a Web application, you initiate a session. That session is tracked until you cease using the Web application, either by logging out of the application (if it s secured) or by simply closing your browser. A common way to track session state is through the use of a cookie. Cookies are auxiliary data containers that ride along with your HTTP request-response in the HTTP packet, along with the actual payload (SOAP-based XML, HTML, or whatever). On the server, they re typically extracted into memory and are accessible by your Web application for whatever reason you re tracking session information. On the client, they re commonly stored as files. When you access the given Web resource, any cookies destined for that resource are retrieved from the cookie folder and shipped back to the server. Although this process is not the only way to maintain session information, it is a common scenario. XML Web services are a little different, however. For one thing, they re not invoked using a browser, at least not when using WF. (Other technologies most certainly do invoke XML Web services from a browser.) Because of this, the cookies associated with an XML Web service are not file-based but merely exist in memory or on the wire when transferred back and forth to the server. They re not stored in files on the client. Another way they differ is that they might not always be present, so you can t depend on their existence. If the XML Web service isn t configured to send session-based cookies, session continuance isn t possible. Tip If you re writing your XML Web service using the .NET Framework and you want sessions to be in effect, be sure to enable session management using the EnableSession key in the WebMethod attribute identifying your Web-based methods. By default, the session management subsystem is deactivated in .NET XML Web service operations.