Tool-based approaches for data-centric RIA development

The need for data-centric development tools has increased with the growing popularity of rich Internet applications (RIAs) and Service-Oriented Architecture (SOA). RIAs offer a rich, engaging experience that improves user satisfaction and increases productivity. SOA, being the natural architectural choice for web application development, is increasingly being used to expose data via services. These two trends have led to a stronger focus on consuming software as a service in the development of RIAs.

One challenge in building data-centric RIAs is the need to consume different kinds of services (RESTful services, web services, and so on) with heterogeneous data formats (including XML, JSON, and AMF) in a uniform way. To manage this challenge, developers need tools capable of creating a technology-agnostic data model, and they need a way to bind this model to the application user interface.

This article outlines a service-centric approach that applies a service-based model definition methodology to work with disparate services as well as a model-centric approach to define a common application data model across clients and servers. It also covers a model-driven user interface authoring approach for building powerful data-centric RIAs using the industry leading Adobe Flash Platform. Challenges related to data synchronization, conflicts, and on-demand data access are also addressed.

In the early days of Internet computing, application interfaces were mostly text based and the main development challenges centered on handling the volume of data traffic and diversity of services. Advances in SOA helped pave the way for new software delivery models over the web. The need for providing better user experiences became amplified with software as a service (SaaS) becoming a mainstream, proven methodology for delivering complex software products. RIAs provide that improved user experience by combining the reach of the web with rich, interactive user interfaces. Rich refers to the ability to incorporate client side interactivity and intuitive user interfaces resulting in engaging experiences, whereas reach is the ability to make an application available to almost anyone, anywhere. Technology advancements along with concepts such as social networks are fueling many of the so called “Web 2.0” applications in which data, exposed through services, is considered to be the central element. In RIAs, local computing power is used for rendering user interfaces, integrating video and animations, or even offline data analysis.

RIA platform expectations

An RIA platform is an integrated set of technologies meant for designers, developers, and consumers that provides everything needed to create and deliver compelling applications (see Figure 1). The following are the key expectations of an RIA platform:

• Ubiquitous client runtimes—Runtimes reside on PCs, mobile devices, and (increasingly) consumer electronics to fulfill the goal of universal reach.
• Write once run everywhere consistency—Given that browser and device fragmentation is expected to deepen, the client runtime should work across platforms, and browsers, and it should provide consistent experiences across devices.
• Designer-developer workflows—Design is a key element for creating engaging experiences and designers need to collaborate with developers.
• Heterogeneous data access—RIAs typically access data in disparate formats such as JavaScript Object Notation (JSON) and XML from a variety of services such as RESTful services and web services. The RIA platform should enable this.
• Developer productivity—Shortening time to market is a big competitive advantage. Developers can help an organization seize this advantage with productivity enhancing tools and easy to learn and easy to maintain languages.
• Data synchronization, data management, and on-demand data access—For RIAs that must operate when disconnected, these capabilities are essential.

Challenges in building data-centric RIAs

Because organizations have already invested in building service-oriented architectures, one of the key challenges that RIA developers face is the need to integrate with existing server-side technologies such as J2EE, ColdFusion, PHP, or web services. To this end, they need to be able to work in a seamless way with both client and server code within an Integrated Development Environment (IDE). Further, the IDE should provide design time facilities that abstract diverse services and data formats by using technology-agnostic representation of the service operations and data.

XML and JSON are less efficient for exchanging large volumes of data. As a result developers often use binary formats such as Action Message Format (AMF) for such situations. Services that are exposed over AMF can be developed in different languages, including object-oriented (Java) and script-oriented (PHP) languages. RIA developers need a uniform way of working with these AMF services, similar to how Web Service Definition Language (WSDL) has provided a uniform way of working with various web services. There is also a need for the IDE to help the RIA developer author user interfaces by leveraging technology-agnostic data representations to help boost developer productivity.

The Adobe Flash Platform (see Figure 2) includes the following products and technologies:

• Adobe Flash Player is available on 99% of PCs and forms the core client-side runtime of the Adobe Flash Platform.
• The open-source Flex framework provides abstractions to connect to disparate data services via HTTP, SOAP, or AMF. The Flex framework uses an easy to learn declarative language called MXML for developing user interfaces.
• Adobe Flash Builder is an Eclipse-based IDE. It provides robust code editing, navigation, interactive debugging, and a WYSIWYG design surface to accelerate application development.
• Adobe Creative Suite tools, such as Flash Catalyst, enables designers to collaborate with developers to create engaging user experiences.
• Adobe LiveCycle Data Services simplifies data management tasks such as tracking changes, synchronization, paging, and conflict resolution.

Designer tools, client-side RIA development tools, and server-side development tools form the foundation for creating rich web applications (see Figure 3). When creating expressive, data-centric RIAs, there is a sweet spot for tooling in which the tools integrate well with each other and enable necessary workflows for the designer, client-side developer, and server-side developer to work seamlessly.

The diverse ways of authoring services and disparate data formats have resulted in the so called service hell phenomenon, which presents unique challenges for the client developers working with them. This section presents three approaches for working with these services: service-centric development, model-driven development, and contract-centric development. It also covers how these approaches leverage the data communication infrastructure to solve challenges related to data synchronization and management. All three approaches enable developers to invoke services in a uniform way, access service responses in an object oriented way, author user interfaces, and manage data communication. This is achieved through a format- and technology-agnostic model called the Adobe Data Model.

Adobe Data Model

The Adobe Data Model enables developers to define data entities, the relationships between those entities, and abstract services responsible for delivering the entities to data clients in an XML-based language (see Figure 4). In addition to entities and services, definitions found in a model include styles, (which bundle user interface related information with data types) and annotations, (which enable specific consumers to add domain specific information to a model).

Service-centric development

A service represents a set of operations providing a certain functionality. For example, a WSDL document represents a service exposed over the SOAP protocol. Service-centric development is an approach in which the client-side developer works with already defined services to build data-centric RIAs. This approach has three main building blocks (see Figure 5):

• Service definition
• Service analysis
• Model-based user interface authoring

Service definition

There are three main components to service definition:

• Importing the service—Provides a wizard-based approach to connect to various server technologies, such as PHP, ColdFusion, web services, and RESTful services.
• Service introspection—Introspects the available methods in the service and their related input and output parameters. This enables the developer to use the methods in an object-oriented way.
• Service model—Represents the service operations and entity models graphically for the developer.

Service analysis

In service analysis sample data is introspected after it is obtained from one or more providers that will be queried by the application under development at runtime. The sampling results can be used to provide hints or suggestions at development time so that a developer has the proper context to reference the data. When the sampling results comprise many parameters, the developer can indicate custom type declarations for the returned parameters or identify a subset of the parameters returned by a query as being of interest, which can then be used to facilitate more meaningful hinting or suggestion by the tool.

This process starts with querying the data source using the data source interface (see Figure 6). The data introspection process comprises receiving a data sample returned by the data source in response to the service operation, characterizing the returned data, and storing one or more characterizations of the data in a object-oriented way for later use by the code authoring, hinting, and user interface authoring modules of the tool. Characterizing the data can be done by identifying the underlying data types and structures directly from the protocol or through the sample data. For instance, the returned data may be "strongly typed" when using the AMF protocol. In other cases, the data may be "weakly typed," (such as when using XML or JSON data) but then "strongly typed by the developer" using the tool. The tool can support characterizing data without the use of strong types, however, independent of whether the data is strongly typed at the source.

Characterizing the returned data also includes inferring a data structure definition for the returned data. For example, the data returned by the query may have an underlying tree structure. A data structure definition for the returned data may be inferred by using heuristics based on the format of the returned data. Thus, characterizing returned data can include determining a data parameter's relative location in a data structure. As an example, nested objects may be recognized through analyzing the structure of a returned XML document. In some service responses, characterizing the returned data requires identifying a subset of the returned data structure as being of interest based on user input. Continuing with the example of data parameters organized into a tree, a developer may indicate that only a certain subset (or subsets) of the tree is of interest, analogous to using XPath to address specific XML data elements. This preference is stored by the tool and can be used to provide hints to the developer.

Data introspection forms the basis of the service's entities and operations and generates the model.

As an example, consider a call to a service that provides the temperature at a particular location from a weather service. In the sample code, the HTTPService tag has a URL and an operation to get the weather data. Below there is a text box with a data binding (indicated by curly brackets) to a particular data item from the query.

From the data introspection module, the developer can actually invoke the GetWeather operation, identify the response as a Weather custom type, and reference the result as that type during development. The developer can reference the currentTemp data item as a property of the Weather custom type using code hinting and can bind that to a component in the user interface authoring module as described in the next section. This process eliminates many of the difficulties that crop up when working with weak data.

Model-based user interface authoring

The process of model-based user interface authoring involves two elements:

• A design surface for laying out graphical elements and intuitive gestures to bind data, such as dragging and dropping a service operation on to the graphical element.
• A mechanism to make use of the data model, which the tool stored during data introspection, to bind the model to the graphical element.

Code generators form an important building block in user interface authoring. With the growing diversity in services and the disparate data formats, code generators in the developer tool help the developer by:

• Abstracting the service invocation mechanism—The developer need not worry about using a HTTP connection, a SOAP request, or an AMF request, but instead just makes a function call. The generated code has all the necessary plumbing required to make the request.
• Abstracting the data returned from the service as objects—Instead of handling data formats like XML, JSON, or AMF responses, the developer can access the data in an object-oriented way.

Model-driven development

Model-driven development is a mature development process and has been part of software engineering for quite some time. Model-driven development for creating data-centric RIAs is becoming a key trend as it addresses the challenges related to diverse services and formats by providing a layer of abstraction via the model. Model-driven development differs from service-centric development in that the developer starts with a model rather than with a service. Therefore the developer is in control of the data properties and service operations. The following are the key elements of the model driven development life cycle:

• A model designer to design the model of the application, which includes a tool to design entities and their properties, computed properties, validations, and constraints.
• A developer tool that understands the model and provides code generators from the model to generate the user interface elements of the RIA.
• A server component that understands the model and provides the complete set of data services to the RIA for data access, as well as a mechanism to deploy the model on the server.

Adobe Flash Builder and Adobe LiveCycle Data Services provide a comprehensive set of tools for developing RIAs based on model-driven development.

Contract-centric development

The process of contract-centric development addresses challenges such as frequently changing interfaces and data formats from one or more service providers. It also accelerates the development of data-centric RIAs when there are different teams working on the client side and the server side independently and in parallel. The following contracts are required for RIA development:

• Service contract—Provides the details of the service on how it can be invoked; in some cases the service contract is defined late in the development life cycle.
• Data contract—Provides the details of the data returned by the service as part of the invocation; typical examples include WSDL, XSD, XML, and JSON data formats.

Classical approaches require contracts to be finalized before development starts among client and server developers. However, there are alternate approaches in which client-side developers start with initial contracts and add their own definitions to the contract that are exchanged with the server-side developers during development. Examples include adding new operations or entities on the client, which can be implemented later by the server-side developer.

Adobe Flash Builder supports contract-centric development. Developers can generate models from XML and JSON contracts and work with frequently changing contracts. Further, such contracts can be easily replaced with actual services once they are available.

Data-centric RIAs invariably need to process data, cache data, execute business logic on the client side, and update data on the server. The messaging and data synchronization libraries form the backbone of communication in an RIA (see Figure 7).

Data synchronization and management

For occasionally connected RIAs data synchronization is paramount. Such RIAs need mechanisms to automatically store data in a local cache when the user is offline and synchronize the data with the server when online. The RIA development platform, as part of this process, should provide tools to enable this data synchronization and provide developers with mechanisms to handle data conflicts during synchronization.

Data management is another key requirement and includes paging, automatic data persistence, and keeping track of the creation, update, and deletion of objects on the client side.

Many RIAs also require exceptionally reliable communication with the server. Such applications include:

• Online banking and trading applications
• Web applications that provide real-time updates
• Customer support applications

Client-side data management libraries (see Figure 8) help the RIA developer by providing:

• A uniform mechanism for data management and synchronization for diverse services
• A data manager to handle data updates from the client side as well as the server side and provide the right interfaces to access the data
• A data store for offline workflows and batch updates
• An Adobe Data Model to abstract the responses and work with a uniform types
• A way to automatically call create, read, update, and delete methods (CRUD) based on changes done on the client side
• A mechanism for working with a single copy of an entity to avoid erroneous updates and display of data, also known as the highlander principle
• Automatic calls to the server when a particular data property or entity is unavailable. This on-demand data access also known as lazy loading. This could also be used when working with associated objects, where only the related object's id property is loaded and the associated object will be fetched by the RIA only when needed.

• Events on the client side when the server pushes data or data conflicts occur
• Support for paging of data, by automatically making server calls whenever subsequent pages of data need to be fetched

Network monitoring tools

The increased complexity of data communication as highlighted in the previous section coupled with disparate data formats fuels a need for deeper analysis of data communication during the development life cycle of an RIA.

In RIA development, developers encounter the following problems:

• The application sends the correct data, but the server component does not get it
• The service operation is not returning the correct result on the client side, but server logs indicate otherwise
• The application is performing slowly, and the developer must identify which code is causing the issue
• The server is getting overloaded, and the application's data traffic to the server must be optimized

The solution to all of these is a network monitor, provided by the RIA development tool, that the developer can use during development for deeper analysis of the RIA application. The network monitor intercepts communication from the application and reports the results. Traditional network sniffing tools provide information on the data traffic, but fall behind in identifying the code that is causing issues. The Flash Builder Network Monitor provides the mapping of source code to data traffic captured, which helps developers easily identify the root cause of problems.

Where to go from here

Data-centric RIA development comes with a unique set of challenges. This article has presented several approaches and technologies that take advantage of a format-agnostic data model. The approaches presented use innovative ways to construct the application, including model-based user interface authoring, code generators that accelerate application development, and client-side data management, which makes it easy for RIA developers to handle data synchronization, automatic data persistence, paging, and on-demand data access. RIA application development has spurred tool innovation in all the three axes of development: design, client-side development, and server-side development.

In the future, these tools are expected to converge further towards the sweet spot of data-centric RIA development tools by providing features like seamless client-server data debugging and round trip engineering of designer-developer artifacts between tools. The Adobe Flash Platform provides mechanisms and state-of-the-art tools that take RIA application development to the next level.