Use Macromedia Flex to develop Web service clients

Introduction

Open standards are used by enterprises to reduce high integration and maintenance costs. In reality, various heterogeneous software systems make it necessary for us to use policies that involve open standards, and Web Services soon become an important part of the solution to this challenge. Until now, it is still tedious to construct an interface-friendly GUI client to interact with these systems. One part of this problem is that the Web Service Description Language (WSDL) tends to become the unique description language of the service endpoint, which sometimes makes it very difficult to comply, especially for designers and user interface developers in the Organization. Flex is a rich Internet application platform developed by Macromedia. It builds a bridge between user interface designers and more traditional server developers. Traditional background programmers can use a large number of attractive visual control, performance, layout, and existing flash components, coupled with their deep knowledge of service endpoints, to assemble an attractive client application. No matter what types of resources are available in your project at any time, the final result is that you can easily create a highly interactive and attractive application, it integrates your investment in Web Services.

Understanding WSDL

In order to exchange messages between different soap service endpoints (In Flex, soap messages are restricted to being transmitted over HTTP only ), flex uses existing WSDL definitions by referencing the URL of the WSDL document. The following table lists elements that often appear in the WSDL document:

Table 1. Common WSDL Elements

Element name	Description
Types	Defines the data types that can be used by web service messages.
Message	Defines the data format to be transmitted in Web service operations.
Porttype	Defines one or more operations to be provided by a Web service.
Operation	Defines a combination of input, output, and error messages.
Input	Indicates the message that the Web service client (such as the flex application) needs to send to the web service.
Output	Indicates the message that the Web Service sends to a client (such as a flex application.
Fault	Indicates the error value returned when a message error is processed.
Binding	The network protocol used to communicate with Web Services. Existing soap bindings include http get, http post, and mime protocols. Flex now only specifies the soap binding.
Service	Define a port set. Each service element corresponds to a porttype element, which specifies different methods for accessing the operation defined in the porttype element.
Port	Web service endpoint, indicating the association between the binding and network address.

These help us to have a unified understanding of how these elements define different Web Services in the WSDL document. However, flex tries to hide the complexity of developers' Web Service definitions, and for most people, it is enough to probably know what functions the service will provide.

It is also very important that WSDL provides two completely different methods to describe service operations: Remote Procedure Call (RPC) and document-oriented (document-oriented. For a flex call of an RPC service operation, it sends a SOAP message to indicate the parameters required for the operation and operation to be called. For a document-oriented flex call, it will send a SOAP message encapsulated into an XML document. Flex provides both methods, but because they use special tags, this implies a slight difference between the two methods. Later in the article, the author will explain in detail the use of these two methods through various examples.

Use Web Services in flex

In your flex application, the most basic principle for declaring Web Services is to use<mx:WebService>MxmlMXThe XML tag with a prefix is part of the mxml namespace and used to form an mxml file ). A typical usage is to useWSDLAttribute to indicate the URL of the WSDL document to be referenced. Flex provides a specialized service concept to move some of these declarations to a specialized block in the flex-config.xml documentation. The flex document contains a more detailed introduction to this specialized service. To point to it in the entire mxml application, you can<mx:WebService>Use in tagIDAttribute to indicate the service ID.

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

Corresponding ActionScriptserviceID.send()Now this web service function is called. However, it is very important to use it without parameters.send()All Parameter Bindings should be defined in the actual web service definition. In other words, parameter binding should use<mx:request>An XML data model in the tag is implicitly associated.

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

Another way to bind parameters to this service call is to explicitly transfer these parameters. A call that explicitly binds these parameters should look likeserviceID.send(input1.text, input2.text)With this method, we do not need to use the XML data model in the mxml declaration as described above.

You have seen the Web service calling mechanism from the flex application, but how do you handle these call results? Let's take a closer look at the previous statement.<mx:operation>MarkedResultAndFaultAttribute. These reference The ActionScript method to handle possible errors in call results and service calls. It should be emphasized that the call to your web service described above is an asynchronous call. This is a different point of attention, because you may be used to this situation-after a method is called and returned, it means that the method has been correctly executed. However, in your flex applicationsend()The statement after the method is executed immediately without waiting for the Web service to return. WhenResult)When the processor (referenced in the Operation attribute) is notified that the Web service has been executed, the application can process the service call results. If an error occurs in a service call, the associatedFaultThe processor will be notified.

If it goes well, you are figuring out how to integrate your web services using the flex environment without being so monotonous. We will look at some examples later. They describe the WSDL-specific mxml in the Web service declaration, which is not mentioned in this section.

WSDL to flex ing instance

About this instance

The following examples cover different methods for defining soap-based Web services using WSDL and how the WSDL definition maps to the mxml web service structure. We mentioned in the previous section that web services can be declared using parameter binding in mxml. This means that the operation parameters can be included as part of the web service declaration (in an XML Data Model), as follows:

<mx:WebService><mx:operation><mx:request><!--parameters here--></mx:request></mx:operation></mx:WebService>

In<mx:operation>Element<mx:request>Elements contain a mixture of XML and flex bindings, which are necessary to construct the soap body content of a message.

The WSDL file used in this instance is automatically generated through the IBM WebSphere Application Developer v5.1 Web Service wizard (both this wizard and WebSphere Application Server Web service support are based on JSR 109 specifications. This wizard produces the configuration entries required for the WSDL file, type ing, serialization, and deployment of web services to WebSphere Application Server v5.x (we use v5.1 here. Although there are multiple methods to declare web services when using WSDL, the following examples focus on the WSDL definition Set Produced by WebSphere tools.

First, we describe the WSDL ing between the WSDL definition and the mxml web service declaration (which is common to any WSDL file. These include mxml elements and corresponding attributes. The values of these attributes do not depend on the specific soap binding settings. Then, we explain the more complex mappings that depend on the operation method (document or RPC), the encoding mechanism used (text or encoding), and the parameter type (simple or complex) and the number of parameters.

Public ing

The first step to describe Web services using mxml is to select the Web Service's WSDL definition file. You can set<mx:WebService>ElementWSDLThe property is the URL of the WSDL file (in the updated flex version, you can use the service name to query the URL of the WSDL ). Then you set<mx:WebService>ElementServiceAndPortTo select the target service and port. Figure 1 shows you where the values of these attributes are found in the WSDL definition.

Figure 1: Service and Endpoint ing. Top: WSDL file, bottom: mxml File

These attributes are optional. ForServiceAttribute. Its value is the first one by default.<wsdl:service>Element (prefix:WSDLAnd is used to form a WSDL file.NameAttribute Value. ForPortAttribute. Its default value is the first one included in the selected<wsdl:service>Element<wsdl:port>ElementNameAttribute Value. To avoid confusion, if the WSDL definition includes multiple<wsdl:service>And<wsdl:port>It is best to explicitly set these attribute values.

After selecting the service and port to be used from the WSDL definition, add<mx:operation>Element<mx:WebService>Element. Every<mx:operation>ElementNameAll attributes correspond<wsdl:operation>Element (which defines Web service calls)NameAttribute. Selected<wsdl:operation>Required<wsdl:service>And<wsdl:port>Part of the target. Figure 2 shows you where to locate the WSDL DefinitionNameAttribute Value.

Figure 2: Operation ing top: WSDL file, bottom: mxml File

<mx:operation>Elements have other attributes. Their values do not depend on the WSDL definition, but they are worth noting. WhereResultAndFaultThe attribute is the event processor of the event. They contain the ActionScript code to be executed when the soap response and the soap error arrive.

Request ing

After you select a web service operation, the flex parameter binding mechanism is used to declare the parameters of these operations. As shown in the following code<mx:operation>Each element contains<mx:request>Element, which uses '{}' to include a mixture of XML and flex binding.

<mx:WebService><mx:operation><mx:request><node1>{var1}</node1><node2>{var2}</node2></mx:request></mx:operation></mx:WebService>

Generally, XML elements mapped to the WSDL or Schema are referenced by mxml binding.<mx:WebService>Variable in the element range.

Decision<mx:request>The content of elements is difficult, because it requires knowledge of the soap binding rules of WSDL. In particular, based on different operations (document or RPC) and encoding mechanisms (literal or encoded ),<mx:request>The content of the elements is mapped to different WSDL elements.

Public ing

Document-oriented text

The soap binding part defined in the WSDL determines the structure of the SOAP message body. It then sets the operation used.MethodAnd encoding mechanism. The operation method is through<soap:operation>Element (SoapThe XML tag as the prefix indicates that it belongs to the soap-bound namespace and is used in the WSDL definition .)StyleAttribute. Its value can beDocumentIndicates document-oriented operations, orRPCIndicates the RPC operation. In a document-oriented operation, XML documents exchanged in the soap body do not have any other encapsulation elements. In addition, in an RPC operation, the soap body is structured to represent a process call. It contains an element named by operation, and this element contains a group of elements and data named by Operation Parameters in sequence. Table 2 illustrates the differences between the two methods.

Table 2. semantic differences between documents and RPC Methods

Document Method	RPC
<soap:Body> <node1> <node2> <node3>data</node3> <node4>data</node4> </node2> <node5>data</node5> </node1>...</soap:Body>	<soap:Body> <operation_name> <parameter1>data</parameter1> <parameter2> <complex_element> <value1>data</value1> </complex_element> </parameter2>... </operation_name></soap:Body>

The encoding mechanism is bound<soap:body>ElementUseAttribute. Its value can beLiteralIs a literal/non-encoded message, orEncodedIndicates that the message is produced by a set of predefined encoding rules.

The following group of instances use a web service with three operations in document-text mode. The difference between these operations is that the number and complexity of their parameters are different. Figure 3, 4, and 5 illustrate<mx:request>The content of the element is mapped to the elements defined in the WSDL definition of the web service.

Figure 3: An operation parameter ing for a document-text service call

Figure 4: Multiple operation parameter ing for a text service call

Figure 5: a document-a complex operation parameter ing for text-style service calls

Operation Request<wsdl:message>The element contains<wsdl:part>And useElementAttribute points to the elements defined by the mode. In a document-text Operation Request, the elements pointed to by the part directly appear in the soap body without any other encapsulation. Therefore,<mx:request>The XML content of the element maps to the schema definition element that the message part points.

RPC-Text

The following example uses a web service with three operations, and the parameters of these three operations are the same as those in the previous example, but are defined as RPC-text operations in WSDL. For these reasons,<wsdl:message>The element contains one or more<wsdl:part>Child element. Every<wsdl:part>Element Through itsTypeAttribute Value to point to a schema-defined type. Figure 6, 7, and 8 indicate that in this case<mx:request>How is the content of an element mapped to an element in the WSDL definition.

Figure 6: single parameter ing operation called by RPC-Text Service.

Figure 7: multi-parameter ing operation called by RPC-Text Service.

Figure 8: complex parameter ing operations for RPC-text service calls.

Tested Flex (beta 3) versions are defined according to the WSDL<wsdl:message>Each part is arranged sequentially in the element. It ignores the port type definition.>wsdl:operation>ElementParameterorderThe order of parameters set in the property.

In an RPC-oriented request, the SOAP message body contains a group of elements in order<wsdl:part>All these elements are named according to each target.<wsdl:part>Elements. Each<wsdl:part>All named elements belongTypeThe type specified by the property. Result:<mx:request>The top-level XML elements in the element are mapped<wsdl:part>Element name. The content of each of these XML elements depends on the relevant<wsdl:part>Element type. For complex mode types, as shown in figure 8, these elements can be XML elements mapped to schema definition elements.

RPC-Encoding

In the RPC-encoding operation call,<mx:request>The method for ing element content to the WSDL structure is the same as that of the previous RPC-text instance. The only difference is that the content of the SOAP message body contains some additional type information, which is generated by the encoding mechanism. Note that the encoding mechanism is not included in the recommendation of the WS-I basic profile 1.0 specification. Literal (non-sequential) XML is more required.

Other cases

The WSDL definitions used in these instances are automatically produced by the WebSphere Studio Application Developer v5.1 Web Service wizard. Therefore, the structure of the generated WSDL-defined document follows the agreement expressed based on the Operation Style value. In particular, for document-style operations, each<wsdl:message>Element contains<wsdl:part>Element to point to a schema element. For RPC operations<wsdl:message>The element contains a group in sequence.<wsdl:part>Element to point to the mode type. In a literal message, the content of the soap body depends on<wsdl:part>Whether to point to an element or a type. Table 3 lists possible combinations and explains the corresponding message bodies (shadow elements represent the situations of the above instances ).

Table 3. Possible message PART definitions and corresponding message bodies when using text XML

Operation Method	Point	Soap body
Document	Element	The elements pointed to by the part appear in the message body.
	Type	The Type pointed to by the part is used as the mode type of the message body (multiple parts cannot be processed)
RPC	Element	The elements pointed to by the part appear in the encapsulated element named by the part.
	Type	The Type pointed to by a part is used as the mode type of the encapsulated element named by the part.

Result ing

Until now, we have concentrated on defining the mxml elements required to call a web service operation. Now we will discuss how to handle the results received after the Web Service is called. As mentioned above, flex treats all web service calls as Asynchronous processing, which means that the client will not block the response of the web service, but will continue to execute, in addition, once a result message is received, an event is triggered.<mx:operation>MarkedResultProperty refers to the ActionScript code to be executed once the result message is accepted. Flex deserializes the soap response to a graph of the ActionScript object.OperationObjectResultA member is a reference to the graph. The full name of the result object is as follows:

<value of WebService id>.<value of operation name>.result

InPeriod (.)It is used to browse the result object in a deeper level, but you need to know that in the response XMLResultWhat the object represents. Rules for ing web service requests to the WSDL file, which are uniformly applied to the WSDL ingResultObject To WSDL.

Conclusion

Quick transfer of policies, including Web Services, is advantageous for organizations to fully master the development environment and create applications using these environments. In addition, since WSDL is generally the only web service description language, it may be tedious and time-consuming to develop applications that integrate existing services. Macromedia Flex is a rich Internet application platform, which is fully positioned to solve these needs. By leveraging the huge investment of most systems in Web Services, designers and server developers can easily develop interactive visualization applications. We have demonstrated a little knowledge of the definition structure of WSDL and how they work with Flex.<mx:WebService>By associating declarations, you can quickly develop powerful and attractive applications that use web services, so that rapid development and use of web services can become a real requirement.