The Importance of XML Schema & Interface-based Programming
When speaking of XML integration it becomes crucial to know the exact representation of the XML data structure and hierarchy. There are various ways to describe the same data in XML and so it becomes impossible to come up with a generic integration solution on raw XML data. An XML schema is needed to describe the XML data structure and hierarchy and provide the generic interface on which both the client and server implementation can be based, If needed it can also be used to validate the data while sending and receiving.

With the advent of SOA and the adaptation of XML as a data exchange mechanism, several servers provide XML-based access to their services namely RSS feeds, the REST API, traditional HTTP/HTTPS implementations, and Web Services implementations. These server implementations often define XML schema to describe their internal data structure. For Web Services-compatible systems the WSDL file describes all the operations and internal XML complex types needed for a particular operation in the WSDL file or referenced schema file.

The new framework considered here is XML Schema-based and so loosely coupled with the server-side implementation. The concept is based on generating AS classes from the schema definition that are direct counterparts of the server-side business classes. (See Figure-3 for details.) The objects generated on the AS side have the same data structure as their server side counterparts since they're based on the same schema representation. But to talk effectively with the server side a framework is still needed on the Flex side to convert these objects to XML and back to AS objects, as described below.

XML Schema binding to the AS classes to compile server-side classes to their AS counterparts have certain advantages such as:

• Client-side implementation can be done independent of the server side. Schema-based implementation ensures seamless integration to the server side.
• To come up with a Flex-based user interface there's no need to shut down a production server.
• For the Flex client working on AS objects, schema-based architecture also provides the resources to generate client-side AS classes to mimic strongly typed AS counterparts of server objects, which may be referred directly while programming the client UI. So this approach provides complete segregation between the client and server but provides a solid bridge to bind them together with XML Schema.
• Basing on XML Schema makes this approach equally good for J2EE and .NET implementations since the underlying infrastructure is hidden behind the XML Schema interfaces.
• Strongly typed AS objects.
• The new approach also provides an efficient mechanism to build a functional application based on several Web Services since the states and logical flow of execution when using one Web Service to invoke another may be captured in the Flex layer itself. Thus the framework can be used to implement a fully functional BPEL engine in the client layer using Flex.
• Over the last years the enterprise has embraced SOA and Web Services technologies and a plethora of implementations are now found everywhere on the World Wide Web. Integrated application development has already started consuming these Web Services in a workflow on the server side using BPEL (Business Process Execution language) and similar technologies in the server side. But with Flex and this new framework plugged in all the intricate Web Service implementations can be implemented on the client tier where internal objects pertaining to those Web Services are exposed as AS objects. Statically typed business object classes with a rich Flex API will definitely open up new ways of integrating Web Services on the client tier. And with the Flex 3 release, versatile GUI-rich Web Service-enabled applications will fill user with delight just like the standalone applications on their desktop.
• With default Web Services support Flex clients can connect to Web Services, but data from Web Services is dynamically typed so making a workflow implementation with default Web Services support in Flex will be daunting without this framework support.
• Our new framework is all interface-based and loosely coupled with the server-side implementation. This lets an application using this framework implement the Flex UI layer regardless of the server-side implementation. The only data contact with the server is the XML Schema interface, which the server publishes. Based on the schema and a list of functions described either in a WSDL or any native schema form, both the client and server can be implemented on their own as completely disintegrated systems. This feature provides the framework to easily implement a Flex-based user interface for any live Service and deploy it on the server at any time to enable a Flex-based UI without stopping a production server and fully functional Flex 3 client programs can be put together without deploying on the production server. So, this framework provides a rich platform for system integrators consuming Web Services and XML data to create applications rich with the Flex UI.
• This framework also opens up an avenue to integrate REST based services with classical Web Services and build robust client applications using Flex.

A Comparison with FDS and AMF
Adobe provides a Flex Data Service (FDS) based on the ActionScript Messaging Format (AMF). It's a very robust solution but need server-side deployment to work. AMF is a binary format so it's ideally faster than XML, (but there are ways to make the XML footprint small on the wire with compression).

It supports server push to update the Flex client in server data state changes. It can readily integrate with any J2EE/Web Service/.NET implementation but needs server-side deployment.

On the flip side it's based on the proprietary AMF format from Adobe that exacts a huge per-seat license fee. It can't work on any server without deploying the server-side FDS, whereas our framework can readily connect to any production server.

For the huge enterprise community using XML as a data interchange, leaning towards AMF (a proprietary format) may be difficult. For production servers implementing Web Services or the REST-based API, the new approach plugs in seamlessly while FDS needs server-side deployment to work.

For servers that understand XML the new approach provides a more robust solution than FDS and keeps all the ease of use and flexibility provided by FDS.

XML & Flex, E4X
Flex comes with a new concept of easy XML parsing with ECMAScript for XML (E4X) implementation, where the XML hierarchy can be navigated with easy "." syntax. It supports all XML semantics including namespaces. So robust XML serialization/de-serialization can be very easily implemented in Flex using a new XML object with e4x in action. The new framework uses e4x to parse XML data and HTTPService and Web Service components to send and receive from the back-end server. This approach is based on the infrastructure provided by Flex 2 and may be distributed as a Flex library that can be plugged into any Flex project needing an elegant data service solution using XML.

The New Framework Explained
Our framework can be ideally termed a layer between the Flex ActionScript UI object layer and the HTTP/Web Service layer. See Figure 4 for details.