Two Ways of Calling Web Service in Flex

There are two ways of calling web service operations in Flex:

1. Use Flex built-in WebService class
2. Use web service proxy classes (automatically generated by WSDL Instrospection Wizard)

Flex Built-in WebService Class

The <mx:WebService> tag gives you access to the operations of SOAP-compliant web services deployed on a web server.

See a working example here.

Web Service Proxy Classes

You can use the Flex Builder "Import Web Service" feature to automatically generate connection code for invoking SOAP-based web service operations. The generated code includes client-side (ActionScript) web service proxy classes that return strongly typed objects. You can use the generated code to call web service operations directly and to pass strongly typed objects as operation parameters. See the details on Adobe Flex 3 Help.

The following two tables compare these two approaches:

	Flex WebService Class
Example	<mx:WebService  id="myWebService"  wsdl="http://.../OracleSearch?WSDL"  showBusyCursor="true"> <mx:operation name="login" resultFormat="XML"  fault="onFault(event)"  result="onLoginComplete(event)"/> </mx:WebService>
Request	myWebService.login(userName, password); myWebService.login(preEncodedXml);
Response	myWebService.login.lastResult
Parameters	Marshaled and validated by SchemaManager (i.e., provide multiple parameters mapped to message parts in the WSDL definition) [see Note #1] Bypassing the marshaling and validation of SchemaManager (i.e., use a pre-encoded node such as a single XML object, XMLList object, etc.)
Advantage(s)	Even "Import from WSDL" Introspection Wizard fails, you can still call web service operations.
Disadvantage(s)	Need to know the mappings between the WSDL definition and the MXML Web services declaration [see Note #2]. If the marshaling and validation is done at runtime, it incurs overhead. If the marshaling and validation is bypassed, the SOAP payload may be invalid.

	Generated Web Service Proxy Class
Example	<search:OracleSearchService id="myWebService">  <search:login_request_var>   <search:Login_request>    <search:username>{tiNameInput.text}</search:username>    <search:password>{tiPassInput.text}</search:password>   </search:Login_request>  </search:login_request_var> </search:OracleSearchService>
Request	myWebService.login_send()
Response	myWebService.login_lastResult
Parameters	Strongly typed objects (i.e., Login_request class instance).
Advantage(s)	Parameters are strongly typed. No need to know the mappings between the WSDL definition and the MXML Web services declaration [see Note #1] because the Web Service Introspection Wizard generates proxy classes that take care of web service data mapping and event plumbing.
Disadvantage(s)	Sometimes "Import from WSDL" Introspection Wizard fails to convert. Sometimes generated SOAP message based on wizard's interpretation of schema is invalid (i.e., invalid to a specific implementation of web server). Whenever WSDL is updated, you need to regenerate proxy classes.

Notes

1. Based on WSDL's schema definition, WSDL introspection wizard generates a set of web service proxy classes in advance. At runtime, operation's parameters are provided as strongly-typed objects (i.e., content objects) and marshaled/validated to SOAP message body.
   
2. The mappings between the WSDL definition and the MXML Web services declaration depend on the operation style (Document or RPC), encoding mechanism used (literal or encoded), type (simple or complex) of parameter, and number of parameters. (You can read "Develop Web services clients with Macromedia Flex" article to understand the mapping issues although it is a little bit out-of-date).