Cross Column

Showing posts with label WebService Class. Show all posts
Showing posts with label WebService Class. Show all posts

Friday, January 23, 2009

Setting Web Services to A Different URL in ActionScript

Some Web Services don't provide a correct port address in its WSDL. To get around this issue, it requires developers to set new endpointURI in MXML/ActionScript files.

There are two ways of calling web service operations in Adobe Flex:
  1. Use Flex built-in WebService class

  2. Use web service proxy classes (automatically generated by WSDL Instrospection Wizard)

Using Flex Built-In WebService Class


Using the first approach, you can set endpointURI on the WebService instance. The creationComplete event is thrown when the application is initialized. In this case, you can attach a listener (i.e., initApp()) to intercept the event and set the correct endpointURI on the WebService instance. Note that the new endpointURI set on the WebService instance applies to all operations defined in it.

<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication
xmlns:mx=http://www.adobe.com/2006/mxml
layout="vertical"creationComplete="initApp()"
xmlns:search="search.*">

<mx:WebService
id="myWebService"
wsdl="http://www.example.com:7753/search/query/Search?WSDL"
showBusyCursor="true">

<mx:operation name="doSimpleSearch" resultFormat="XML"
fault="onFault(event)"
result="showResult(event)"/>

<mx:operation name="login" resultFormat="XML"
fault="onFault(event)"
result="showResult(event)"/>

</mx:WebService>

<mx:Script>


private function initApp():void
{
myWebService.endpointURI =
"http://www.example.com:7753/search/query/Search";
myWebService.login("yyy", "yyy");
}
]]>

</mx:WindowedApplication>

Using Web Service Proxy Classes

You can also 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.

Generated web service proxy files
The Import Web Service feature introspects a provided WSDL file and generates the following ActionScript class files:
  • BaseServiceName.as

  • IServicename.as

  • etc.

To see the full list of generated files and their descriptions, see Adobe Help.

For example, our service is named SearchService which is retrieved from the WSDL file. Using Import Web Service feature in FlexBuilder, it generates the following files:
  • BaseSearchService.as

  • ISearchService.as

  • etc.

To fix the URL issue, you locate endpointURI in the BaseServiceName.as file. Then set it to be the correct URL as shown below:
BaseSearchServicePort.endpointURI = "http://myserver:7777/search/query/Search"

This should work when you use the generated code to call web service operations directly. Without this fix, you will get the notorious stream error #2032.

I also noticed that there is a generated WSDL file in the project under .wsdl folder. It may be a good idea to change the URL in that WSDL file to be correct.

Thursday, January 22, 2009

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
  1. myWebService.login(userName, password);
  2. myWebService.login(preEncodedXml);
Response myWebService.login.lastResult
Parameters

  1. Marshaled and validated by SchemaManager (i.e., provide multiple parameters mapped to message parts in the WSDL definition) [see Note #1]

  2. 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)

  1. Even "Import from WSDL" Introspection Wizard fails, you can still call web service operations.


Disadvantage(s)

  1. Need to know the mappings between the WSDL definition and the MXML Web services declaration [see Note #2].

  2. If the marshaling and validation is done at runtime, it incurs overhead.

  3. 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)

  1. Parameters are strongly typed.

  2. 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)

  1. Sometimes "Import from WSDL" Introspection Wizard fails to convert.

  2. Sometimes generated SOAP message based on wizard's interpretation of schema is invalid (i.e., invalid to a specific implementation of web server).

  3. 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).

© Travel for Life Guide. All Rights Reserved.

Analytical Insights on Health, Culture, and Security.