Flex has gotten popular lately because of its rich GUI capabilities. It also comes in handy with HTTPService and Web Service components connecting to back-end servers to fetch and update data. But using this mechanism to talk to the back-end server requires formulating a unique service object from the Flex side, making a request, and getting back data from the back-end either in XML or plain text format. The response data then has to be parsed and fed to the Flex objects to update the UI. For small to medium-size Flex projects it's a viable solution, but for enterprise projects with thousands of external service calls it will get quite repetitive and could result in a lot of unmanageable, buggy code.

The approach discussed here provides a more intuitive solution to generate ActionScript classes on the Flex side that are direct counterparts of the enterprise object classes in the back-end server. This way the Flex environment just becomes an extension of the back-end server and the Flex UI gets access to back-end objects. The infrastructure to make remote calls to the back-end server is taken care of by the framework that marshals objects to the back-end to make service calls and un-marshals the results to ActionScript objects transparently so the developer can concentrate just on the UI logic.

Adobe provides Flex Data Services (FDS) that also provides a robust data services solution but costs a huge license fee and ties to proprietary Adobe technology. The new approach discussed here provides a clean, efficient way for back-end integration based on open source technologies like e4x and XML. This approach is suitable for any project implementing Flex for UI with J2EE/Web Services at the back-end. Moreover, this approach doesn't need to be deployed on the server side, which makes it a better solution than FDS while programming the UI for already-deployed production applications. If you're implementing a Flex project and need an easy, efficient way to connect to your back-end data and hate to pay huge license fees, read on...

Why a New Framework?

mx.rpc.http.HTTPService and mx.rpc.soap.WebService
provides the basic infrastructure to call a back-end service to fetch data into the Flex environment. These services rely on formulating a unique request object on the Flex side manually and sending it to the server and getting a response back from the server when invocation is successful.

The response then needs to be parsed and the UI updated on the parsed data from server. For small projects this approach holds good but for enterprise projects just formulating the individual HTTP/Web Service objects to talk to the back-end server and parsing the data from the server to update the UI will result in repetitive and unmanageable code.

Figure 1 shows a simple way to call the back-end server from any Flex application using an HTTPService or Web Service call. In a simple use case, the Flex UI components have to do a remote service call to update the data from the back-end server; the ActionScript (AS) objects on which the UI components are built are used to populate the parameters/XML needed for the HTTP/Web Service call. When service invocation is successful the response is also intercepted by the service object or by any function assigned the responsibility to parse the back-end data and update the AS objects in the Flex UI layer. Moreover, it's very difficult to maintain the Flex code when the server-side service changes its invocation parameters or response. Since the Flex code is dynamically typed during parameter/XML population and response parsing; it will be very difficult for the Flex compiler to spot coding errors due to incorrect parameter-type mappings.

So the basic requirement for the new approach is to have a clean framework that will take care of service object creation right from the passed-in AS object references and parse back-end server data back to the AS objects to update the Flex UI. Communication to the back-end server using HTTP/SOAP and getting a response back to parse into the AS layer is taken care of by the framework. See Figure 2 for details on the new approach.

The new approach relies on generating AS classes that are direct counterparts of the server-side business object classes. These classes are generated from the server-side schema/WSDL definition and available during compile time in the Flex environment as an extension of the remote server objects. The AS object counterparts generated can be directly called and referred to in the Flex environment providing easy-to-use back-end server objects. Moreover, as the AS classes are generated from the server-side schema/WSDL any changes in the server-side service parameters or response is readily propagated to the Flex environment while generating the code. Since the parameter/XML population in the new approach is based on direct AS object references and statically typed, the compiler will also pick up coding errors with type conversion for any changes done in the remote service definitions.

Why XML for Data Transfer?
The approach discussed is based on XML data transfer. XML is suited to the interchange of data as XML documents are tagged, easily parsed, and can represent complex data structure so it's been widely adopted for data transfer in many enterprise applications. XML is used to call Web Service in the back-end server using SOAP. The REST API (Representational State Transfer), which provides a simple HTTP request and XML response, is becoming more popular day-by-day providing more avenues to get well-formed XML data back as a service response. So a UI client that works on the XML backbone based on the infrastructure provided by this new approach can easily integrate with REST/Web Service-based servers.