Introduction Open standards are being embraced by enterprises as a means to drive down high integration and maintenance costs. The reality of today's heterogeneous software systems is that it is imperative to employ some strategy involving open standards, and Web services are quickly becoming an important piece to this puzzle. Up until now it has been quite tedious and cumbersome to build rich GUI clients to interact with these systems. Part of the problem is that Web Services Description Language (WSDL) tends to be the only description of the service endpoints, and it can sometimes be difficult to follow (even more so for the designers and user interface developers within the organization). Flex is a Rich Internet Application platform by Macromedia that bridges this distinct gap between user interface designers and the more traditional server-side developers. Traditional back-end programmers can leverage an extensive set of visually appealing controls, effects, layouts, and existing Flash components, together with their in-depth knowledge of the service endpoints, to put together an attractive client application. A designer can use these same facilities and leverage their creative skill set to build a comparable client, while shielded from complex service definitions. The end result, no matter what type of resources are available to your project at any given time, is the ability to easily create a highly interactive and engaging application that integrates your investment in Web services.
 |
Understand WSDL Flex uses existing WSDL definitions by referencing a URL where the document is located, in order to exchange messages between SOAP service endpoints (SOAP messaging in Flex is constrained to only use HTTP as the transport mechanism). The following elements are commonly found within a WSDL document: Table 1. Common WSDL Elements | Element | Description | | types | Defines data types that a Web service's messages can use. | | message | Defines the data that a Web services operation transfers. | | portType | Defines one or more operations that a Web service provides. | | operation | Defines a combination of input, output, and fault messages. | | input | Specifies a message that a client such as a Flex application sends to a Web service. | | output | Specifies a message that a Web service sends to a client such as a Flex application. | | fault | Specifies an error value returned as a result of a problem processing a message. | | binding | Specifies the protocol used to communicate with a Web service. Bindings exist for SOAP, HTTP GET, HTTP POST, and MIME. Flex supports the SOAP binding only. | | service | Defines a collection of ports. Each service maps to one portType and specifies different ways to access the operations in that portType. | | port | A Web services endpoint that specifies an association between a binding and a network address. |
It helps to have a general idea of how these elements come together in a WSDL document to define various Web services and what they mean. Flex however tries to hide the complexity of the service definition from the developer, and for the most part it is sufficient to have a basic understanding of what functionality the service is to provide. It is also important to point out that WSDL provides two very distinct styles of describing service operations: Remote Procedure Call (RPC) and document-oriented styles. A Flex call to a RPC service operation sends a SOAP message specifying the operation and wrapping its respective arguments. A Flex call to a document-oriented operation sends a SOAP message that encapsulates an XML document. Flex provides support for both, but the subtle differences between the two have implications as to the specific mark-up tags used. This paper walks you through various examples of these two styles in more detail in the examples below.
Use Web services in Flex The basis for declaring a Web service within your Flex application is to use the <mx:WebService> MXML tag (XML tags prefixed by mx are part of the MXML namespace and are used to construct an MXML file). Typically you associate a wsdl attribute with this tag, and this points to the referencing WSDL URL. Flex provides a named service construct that moves some of this declaration to a specific block in the flex-config.xml document. The Flex documentation covers the use of named services in more detail. It also helps to use an id attribute with the Web Service in order to refer to it throughout the MXML application.
| <mx:WebService id="serviceID" wsdl="http://somehost/someService/service.wsdl; <mx:operation name="someOP" result="someResultHandler()"fault= "someFaultHandler()"> <mx:request> <!-- parameters --> </mx:request> </mx:operation> </mx:WebService> |
A corresponding ActionScript serviceID.send() call now invokes this Web services functionality. It is important to point out that when using the send() method with no parameters, all parameter binding should be defined within the actual Web services definition. In other words, parameter binding is implicitly associated using an XML data model within the <mx:request> tags.
| <mx:WebService id="serviceID" wsdl="http://somehost/someService/service.wsdl; <mx:operation name="someOP" result="someResultHandler()"fault= "someFaultHandler()"> <mx:request> <param1>{input1.text}</param1> <param2>{input2.text}</param2> </mx:request> </mx:operation> </mx:WebService> |
The other way of binding parameters to this service call is to explicitly pass them. A corresponding call that explicitly binds parameters looks like serviceID.send(input1.text, input2.text) , where it is no longer necessary to use the XML data model within the MXML declaration as previously described. You have now seen the mechanism for invoking a Web service from a Flex application, but how do you process the results? Taking a closer look at the declaration above, you will notice a result and fault attribute on the <mx:operation> tag. These reference ActionScript methods to process the results and handle any faults your service call may have. The point to make here is that the invocation of your service as described above is an asynchronous call. This is an important difference to note since you are probably used to the case where a return from a method call implies that its work has finished completely. In your Flex application, statements that are defined after send() immediately executes without waiting for a return from the Web service. The application is able to process the results of the service call when the result handler (referenced in the operation attribute) is notified that the Web service has finished execution. In the case that there were some error, the associated fault handler is notified instead. Hopefully you are getting a clearer picture of how integrating your Web services can be less tedious using the Flex environment. We now walk you through some examples describing the WSDL-specific MXML tags contained in the Web services declaration that we did not discuss in this section.
WSDL to Flex mapping by example About the examples The following examples cover different ways of defining SOAP-based Web services operations using WSDL, as well as how the WSDL definition maps to MXML's Web services constructs. We mentioned in the previous section that Web services can be declared in MXML using a parameter binding mechanism. This means that the parameters of the operation are included as part of the Web services declaration (within an XML data model) as follows:
| <mx:WebService> <mx:operation> <mx:request> <!--parameters here--> </mx:request> </mx:operation> </mx:WebService> |
The <mx:request> element inside the <mx:operation> element contains a mixture of XML and Flex Bindings necessary to construct the content of the message's SOAP Body. The WSDL files used in the examples were automatically generated using IBM® WebSphere® Application Developer V5.1 Web Services Wizard (This Wizard and WebSphere Application Server WebService support are based on JSR 109). The Wizard generates the WSDL file, type mappings, serializers, and configuration entries required to host the Web Service in WebSphere Application Server V5.X (We used V5.1). Although there are multiple ways of declaring Web Services using WSDL, the following examples emphasize the set of WSDL definitions that are generated by this tool. We begin by describing the mappings between the WSDL definition and the MXML Web services declaration that are common to any WSDL file. These include MXML elements and attributes which values are independent of the specific SOAP binding settings. Then, more complex mappings are explained, which depend on the operation style (Document or RPC), encoding mechanism used (literal or encoded), type (simple or complex) of parameter, and number of parameters. Common mappings The first step in declaring a Web service using MXML is to select the Web services WSDL definition. You can do this by setting the wsdl attribute of the <mx:WebService> element to the URL of the WSDL file (Newer versions of Flex allow you to lookup the WSDL URL by using the name of the service). Then you select the target service and port by setting the service and port attributes of the <mx:WebService> element. shows you where to find the values of these attributes in the WSDL definition. mor info: http://www.ibm.com/developerworks/webservices/library/ws-macroflex/ | 
