Welcome!

Java IoT Authors: Pat Romanski, Yeshim Deniz, Elizabeth White, Liz McMillan, Paul Simmons

Related Topics: Machine Learning , Adobe Flex, Agile Computing

Machine Learning : Article

RIA Debugging: How to Improve the Life of RIA Developers

It's time to improve the debugging of backend services RIAs depend on

This is a call to action to everyone building clients, servers and frameworks for rich Internet applications (RIAs) to improve the life of RIA developers by improving the debugging of backend services RIAs depend on. I’d like to thank the people who’ve offered valuable feedback and additional information that I’ve integrated here.

Motivation

The relationship of an RIA to its backend is quite different than that of a traditional Web application. In a traditional, dynamic HTML generation Web app, the output stream is under the control of the developer and the application server. Developers can freely mix application output with diagnostic information. By contrast, RIAs have a narrow communication channel with the server, typically using a service-oriented architecture (SOA). Because the output format is typically XML or JSON (and because there are no established standards for augmenting message payloads) there is no opportunity to include any additional information. This is particularly problematic during debugging.

Consider the following with Adobe Flex as the example frontend and ColdFusion (CF) as the example backend although the discussion applies to any RIA:

  • An exception on the server would cause a service request to fail without providing any useful information to the developer. In particular, there is no way to see the exception information or the server-side stack trace, despite the fact that CF would generate ample information useful for debugging.
  • Turning on debug information output on the server would break the service by adding HTML at the end of the XML output. Developers have no good way of consuming that debugging information other than test-driving the service in an HTML test harness.
  • CFDump is a one of the most beloved tags in CFML. Almost every developer uses it in every application because it provides great debugging efficiency. There is no way to use CFDump in RIA development.
  • There is no way to generate any auxiliary, Flash trace()-like output in service responses, something any HTML developer is used to doing. Again, when using services with RIA front-ends, developers are flying blind.
  • Conversely, RIA developers have no good mechanism of creating any persistent application output. For example, while writing a message to a log takes one line with CFLog, an RIA developer would have to implement a logging service in order to achieve this capability and store some information for future analysis.

Debuggers are not the answer

Every backend environment has its own debugging capabilities. Also, there many ways to debug AJAX and Flex applications:

However, debuggers do not address the problem of efficiently debugging backend services for RIAs. Most Web developers don’t use or don’t know how to use debuggers effectively. Debuggers are good for step execution and occasional variable inspection. They are poor at displaying a lot of specific information efficiently. Also, using both a client-sde and a server-side debugger often slows down the develop-test-fix cycle. In short, using debuggers are no substitute for having flexible and powerful diagnostic output from backend services.

As an example, consider the actions a developer must take in a CF debugger to get the information equivalent to seeing the output generated by a CFQuery exception with stack trace enabled or a CFDump of a query with 200 rows. There is simply no comparison in terms of productivity.

The closest approaches I’ve found to what I’m proposing here are FirePHP and the ability of ColdFusion to return page debug data to the Flash player through FlashRemoting using ActionScript Message Format (AMF, a binary protocol) server debug response headers. (Mike Nimer pointed me to the CF-AMF capability and to a FlexDebugPanel that he built to better display the information.) Both approaches use response headers, which limits their ability to deal with large amounts of data. I also think the industry needs a broader and more standardized solution.

A personal tangent

A recent experience underscored these problems and was the personal motivation for me to write this. The latest RIA I built had a Flex 3 frontend with a CF8 backend. Despite its simplicity-one component (CFC) on the backend and only a couple of thousand lines of MXML-I constantly had to work around the lack of visibility when I was invoking services from the client. Before long, I found myself installing Fiddler to see the HTTP traffic and logging WDDX packets and CFDump output which I then crudely displayed in a browser window using a quick’n'dirty Web page. When using the client-side and server-side debuggers I was frustrated by the number of clicks it took to get to data I cared about and the amount of irrelevant information presented, e.g., tons of underscore-prefixed internal variables for unnamed controls I had to scroll through to get to variables I cared about.

When I pinged a few people building AJAX and Flex apps I heard the very same feelings about their debugging experience and the difference between building RIAs vs. traditional Web applications.

Many of the ideas proposed in this document are not new. Back in the spring of 2001, I built what may have been the first prototype of Flash communicating to servers using SOA. For the backend I used CF with a dynamic dispatch layer to custom tags (CFCs weren’t there yet). In testing the prototype I hit the same debugging problems. I implemented a feature that took diagnostic output from the server and displayed it as trace() output in the player. It made my life easier but it wasn’t a generic solution because it relied on a particular response format. The FlashRemoting team later on generalized the concept via the amf_server_debug response header, which is not an HTTP response header but a payload response header (think SOAP).

Some years ago I would have jumped to code the solution I propose here and open-source it, like I did a decade ago with WDDX. For better or worse, I don’t code that much these days. Instead, I’m focusing on helping entrepreneurs start companies. I hope this post inspires someone to tackle this problem and share their work with the RIA developer community.

Proposed solution

Improving the debugging of RIA service backends requires a multi-faceted approach that spans clients, servers and tools. In order of importance, there are four inter-related pieces:

  1. Establishing a diagnostic output channel from the server to the client. The goal here is to give Web developers familiar capabilities such as the ability to see exception diagnostics, to display diagnostic output and dump complex variables.
  2. Providing a persistent output channel from the client to the server. The goal here is to enable structured logging from the client to the server so that important diagnostic output can be preserved for future analysis.
  3. Implementing structured logging on the server. The goal here is to improve the power of logging by building the kind of logging system that makes developers more productive during the debugging cycle.
  4. Improving debuggers. There is no such thing as a true RIA debugger out there. Since this part of the solution has much broader scope, it is not covered here.

Architecture

There are multiple ways to implement the proposed solution. The approach outlined here is probably one of the simplest. It involves a single diagnostic output specification, three new services on the backend for server-side diagnostic output, client-to-server logging and log viewing, and a reusable viewer of diagnostic output. These capabilities are exposed in an appropriate manner through the frontend and backend programming models and frameworks.

Figure 1. RIA diagnostic output architecture

Diagnostic output specification

The diagnostic output specification has three parts:

  • A schema for identifying the output format
  • A mechanism for identifying specific output stored remotely
  • A mechanism for passing diagnostic output identifiers from the server to the client

Diagnostic information is provided in “documents” (chunks, payloads, etc.) according to the schema. Each such document must be URI-addressable during its lifetime. The exact format of the URI is specific to a particular server environment. For example, in a ColdFusion deployment it can be a URL to the diagnostic output service. The URL will be parameterized such that the right diagnostic information is returned to the client. Let’s call this a DebugURI (dURI).

For performance reasons, the URI must be able to address sub-parts of any single pile of diagnostic information. For example, if the diagnostic information includes a reference to a 10,000 record query it wouldn’t make sense to either arbitrarily restrict how many rows the client can have access to or to ship all 10,000 lines with the diagnostic information request. However, to simplify implementation, the URI format need not be exposed to the client. For example, the client shouldn’t necessarily be able to request rows 9,212 - 9,532 of the query. Instead, the server can simply put a placeholder in a document saying “there is more data here and if you want it, request this URI and I’ll get it to you”. Let’s call this particular type of dURI a ContinuationURI (cURI).

The specific mechanism for passing diagnostic output identifiers from the server to the client is protocol and environment specific. An HTTP response header carrying the dURI is a simple choice that works well across languages and platforms and does not modify the response payload.

The diagnostic output schema is a format (not necessarily a formal XML Schema) for describing the information typically encountered while debugging applications, including but not limited to:

  • Exception information
  • Call stack information
  • Data structure dumps
  • Application state information
  • Service requests & responses
  • External service interactions, e.g., database queries and responses
  • Performance-related information
  • Developer-created diagnostics messages

There are trade-offs in the amount of detail in the schema. With more detail, providing support across environments will take a little more time but, on the other hand, the output viewer can be more capable, e.g., allowing dynamic expansion of data structures, etc. With minimal detail, developers will only be able to look at volumes of text in the viewer.

The schema should have built-in extensibility features.

Last but not least, the schema must specify the format of the cURI placeholder discussed above.

Backend support

Backend support includes a persistent and a transient store for diagnostic information and three new services.

Data stores

The backend must implement two data stores, one for run-time diagnostic information and one for persistent diagnostic information.

The runtime information store can leverage the traditional app server state management capabilities, in particular, session management. The information model is simple. Diagnostic information generated during the processing of a request can be maintained as an aggregate object indexed by dURIs. There needs to be a purging policy for efficient resource management.

The persistent information store can leverage the existing logging architecture of a server. However, a more efficient implementation may want to use an embedded database. See the following discussion on the log viewer.

Services

The debug output service is invoked via dURIs passed with a server response or generated by the log viewing service (see below) or with cURIs. It generates a diagnostic information document. It can use a default or user-configured policy governing the size and detail in these documents, adding cURIs where appropriate. The debug output service can pull information from both the transient and persistent stores.

The remote logging service takes a diagnostic information document and some additional meta-data describing where, when and how the diagnostic information was created and persists that information.

The log viewing service has two functions. It monitors the log for changes to know when new data is available. It also allows the log viewer to list and query (and potentially search inside) the available diagnostic information documents. Every available document is identified by a dURI that the client can pass to the debug output service to retrieve the document.

Client-side support

Client-side support comes via a pre-packaged viewer application. The viewer is an RIA that provides rich functionality for working with diagnostic output documents such as:

  • Communicating with the application running on the client, allowing it to deliver diagnostic output that can be displayed richly. For example, this would be substantial improvement compared to basic trace() output in Flash or Log4Ajax.
  • Listing of available information. Some information can be provided by the client. Transient information from multiple server interactions may be available. In addition, all the persisted information is available. The viewer should also be able to open a file in the diagnostic output format.
  • Allowing some information to be persisted for future analysis. This becomes particularly interesting if there is support for annotations and sharing of the information with team members (via a URL to the debug output service or as an email attachment).
  • Supporting flexible data structure navigation and basic search across the data structures and messages.
  • Providing appropriate formatting for exceptions, call stack information, performance information, etc.

An ideal implementation of the viewer would be as an AJAX or Flex application component that can communicate with both Flash/Flex and other AJAX applications independent of the server environment. Client-side debuggers can add the viewer capability also. Perhaps the FireBug Working Group can take this on?

From a user-experience standpoint, the viewer should be able to run next-to an application as a docked component as well as a pop-up in a separate window, which would be particularly useful for developers with multiple monitors.

Specific environment support

These capabilities should be supported as appropriate by specific RIA environments. Ideally, support should be implemented at the application server level for maximum performance, efficiency, etc. As a second option, it can be provided as native or side-along extensions to common frameworks.

Specifying invocation intent

In some such environments it may be helpful to know whether a server request is made by a browser for the purposes of HTML display or as a service call. In the case of service calls, certain display-oriented capabilities such as debug output or the output of the CFDump tag in ColdFusion can be automatically redirected to contribute data to the transient diagnostic output store. In some cases the context of request can be determined directly from the HTTP-level information, e.g., a POST with Content-Type application/XML. In other cases, such as a simple HTTP GET to a RESTful service, it is difficult to do this without knowing a priori that the URL is a service. Some server components such as ColdFusion CFCs can be addressed in a number of different ways. It therefore may be helpful to consider having RIA clients optionally send a custom HTTP request header to identify the intent of the request.

Additional considerations

Managing diagnostic information in this way adds substantial overhead to application processing. It should only be enabled in debugging scenarios.

Exposing detailed server state information to remote clients poses a security risk. The backend services should require authentication and they should be able to run over a secure connection to prevent data snooping and man-in-the-middle attacks.

Manipulating diagnostic information with such ease can benefit traditional HTML application development also. Therefore, it is worth thinking about ways to integrate the view application with traditional HTML applications.

Conclusion

This document outlines a simple approach to improving the debugging backend RIA services across languages and platforms. The approach is amenable to standardization as it includes a common format for diagnostic output and a common viewer application.

These could be developed with open extensibility in mind and remotely-hosted viewer extensions allowing, for example, Ruby-on-Rails (RoR) to provide some special RoR-specific structured output that can be natively viewed via an extension (implemented as a JavaScript or Flex component) hosted on rubyforge.org.

Postscript

The discussion here points out some of the fundamental differences between RIAs and traditional HTML applications. Beyond improving the debugging of RIA services, there are many more opportunities to provide better support for RIA applications. After all, the first Web application server shipped a dozen years ago. Too much of what app servers do assumes dynamic HTML generation as opposed to Flex/AJAX clients. I’m surprised I haven’t seen more innovation in this area from large platform vendors. Smaller players such as Aptana (with Jaxer) and JackBe are pushing the boundary but their lack of distribution on the backend limits the effects of their innovation.

 

More Stories By Simeon Simeonov

Simeon Simeonov is CEO of FastIgnite, where he invests in and advises startups. He was chief architect or CTO at companies such as Allaire, Macromedia, Better Advertising and Thing Labs. He blogs at blog.simeonov.com, tweets as @simeons and lives in the Greater Boston area with his wife, son and an adopted dog named Tye.

Comments (2) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Richard Walter 09/22/08 01:06:27 PM EDT

The discussion here points out some of the fundamental differences between RIAs and traditional HTML applications

ckendrick99 09/17/08 07:59:34 AM EDT

This has existed in SmartClient (Ajax RIA platform) since 1.0 in 2001, in increasingly refined form. It's called the Developer Console.

It's a SmartClient RIA that can be launched from any page that loads SmartClient, and appears as a separate browser window connected to the page that launched it.

The Developer Console has a view of client-side logging where you can enable or disable client-side log categories on the fly, similar to Log4j. You can also see all service calls, similar to Fiddler/Firebug but more purpose-specific.

If you are using the SmartClient Java Server, the Developer Console also contains a tab that allows you to view the most recent server-side logs as output via Log4j.

Your article seemed to me to imply some kind of special diagnostic support on the server specifically for the RIA - I don't think you'd want to build diagnostic information that is *separate from* the logging and diagnostics you already do on the server. In a true RIA (or SOA) architecture the services you are calling should be generic enough to be called by other technologies, including possibly clients that aren't web-based - if the logs aren't good enough of debugging service calls made by RIAs, improve them until they are, then all possible client systems benefit.

More about the Developer Console:

http://www.smartclient.com/index.jsp#_Welcome_Developer.Console

@ThingsExpo Stories
DXWorldEXPO LLC announced today that All in Mobile, a mobile app development company from Poland, will exhibit at the 22nd International CloudEXPO | DXWorldEXPO. All In Mobile is a mobile app development company from Poland. Since 2014, they maintain passion for developing mobile applications for enterprises and startups worldwide.
@DevOpsSummit at Cloud Expo, taking place November 12-13 in New York City, NY, is co-located with 22nd international CloudEXPO | first international DXWorldEXPO and will feature technical sessions from a rock star conference faculty and the leading industry players in the world.
"Akvelon is a software development company and we also provide consultancy services to folks who are looking to scale or accelerate their engineering roadmaps," explained Jeremiah Mothersell, Marketing Manager at Akvelon, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
As data explodes in quantity, importance and from new sources, the need for managing and protecting data residing across physical, virtual, and cloud environments grow with it. Managing data includes protecting it, indexing and classifying it for true, long-term management, compliance and E-Discovery. Commvault can ensure this with a single pane of glass solution – whether in a private cloud, a Service Provider delivered public cloud or a hybrid cloud environment – across the heterogeneous enter...
DXWorldEXPO LLC announced today that ICC-USA, a computer systems integrator and server manufacturing company focused on developing products and product appliances, will exhibit at the 22nd International CloudEXPO | DXWorldEXPO. DXWordEXPO New York 2018, colocated with CloudEXPO New York 2018 will be held November 11-13, 2018, in New York City. ICC is a computer systems integrator and server manufacturing company focused on developing products and product appliances to meet a wide range of ...
More and more brands have jumped on the IoT bandwagon. We have an excess of wearables – activity trackers, smartwatches, smart glasses and sneakers, and more that track seemingly endless datapoints. However, most consumers have no idea what “IoT” means. Creating more wearables that track data shouldn't be the aim of brands; delivering meaningful, tangible relevance to their users should be. We're in a period in which the IoT pendulum is still swinging. Initially, it swung toward "smart for smart...
Headquartered in Plainsboro, NJ, Synametrics Technologies has provided IT professionals and computer systems developers since 1997. Based on the success of their initial product offerings (WinSQL and DeltaCopy), the company continues to create and hone innovative products that help its customers get more from their computer applications, databases and infrastructure. To date, over one million users around the world have chosen Synametrics solutions to help power their accelerated business or per...
Dion Hinchcliffe is an internationally recognized digital expert, bestselling book author, frequent keynote speaker, analyst, futurist, and transformation expert based in Washington, DC. He is currently Chief Strategy Officer at the industry-leading digital strategy and online community solutions firm, 7Summits.
In an era of historic innovation fueled by unprecedented access to data and technology, the low cost and risk of entering new markets has leveled the playing field for business. Today, any ambitious innovator can easily introduce a new application or product that can reinvent business models and transform the client experience. In their Day 2 Keynote at 19th Cloud Expo, Mercer Rowe, IBM Vice President of Strategic Alliances, and Raejeanne Skillern, Intel Vice President of Data Center Group and ...
Founded in 2000, Chetu Inc. is a global provider of customized software development solutions and IT staff augmentation services for software technology providers. By providing clients with unparalleled niche technology expertise and industry experience, Chetu has become the premiere long-term, back-end software development partner for start-ups, SMBs, and Fortune 500 companies. Chetu is headquartered in Plantation, Florida, with thirteen offices throughout the U.S. and abroad.
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...
"We are a well-established player in the application life cycle management market and we also have a very strong version control product," stated Flint Brenton, CEO of CollabNet,, in this SYS-CON.tv interview at 18th Cloud Expo at the Javits Center in New York City, NY.
It is of utmost importance for the future success of WebRTC to ensure that interoperability is operational between web browsers and any WebRTC-compliant client. To be guaranteed as operational and effective, interoperability must be tested extensively by establishing WebRTC data and media connections between different web browsers running on different devices and operating systems. In his session at WebRTC Summit at @ThingsExpo, Dr. Alex Gouaillard, CEO and Founder of CoSMo Software, presented ...
Most people haven’t heard the word, “gamification,” even though they probably, and perhaps unwittingly, participate in it every day. Gamification is “the process of adding games or game-like elements to something (as a task) so as to encourage participation.” Further, gamification is about bringing game mechanics – rules, constructs, processes, and methods – into the real world in an effort to engage people. In his session at @ThingsExpo, Robert Endo, owner and engagement manager of Intrepid D...
Recently, WebRTC has a lot of eyes from market. The use cases of WebRTC are expanding - video chat, online education, online health care etc. Not only for human-to-human communication, but also IoT use cases such as machine to human use cases can be seen recently. One of the typical use-case is remote camera monitoring. With WebRTC, people can have interoperability and flexibility for deploying monitoring service. However, the benefit of WebRTC for IoT is not only its convenience and interopera...
Michael Maximilien, better known as max or Dr. Max, is a computer scientist with IBM. At IBM Research Triangle Park, he was a principal engineer for the worldwide industry point-of-sale standard: JavaPOS. At IBM Research, some highlights include pioneering research on semantic Web services, mashups, and cloud computing, and platform-as-a-service. He joined the IBM Cloud Labs in 2014 and works closely with Pivotal Inc., to help make the Cloud Found the best PaaS.
Everything run by electricity will eventually be connected to the Internet. Get ahead of the Internet of Things revolution. In his session at @ThingsExpo, Akvelon expert and IoT industry leader Sergey Grebnov provided an educational dive into the world of managing your home, workplace and all the devices they contain with the power of machine-based AI and intelligent Bot services for a completely streamlined experience.
Cloud-enabled transformation has evolved from cost saving measure to business innovation strategy -- one that combines the cloud with cognitive capabilities to drive market disruption. Learn how you can achieve the insight and agility you need to gain a competitive advantage. Industry-acclaimed CTO and cloud expert, Shankar Kalyana presents. Only the most exceptional IBMers are appointed with the rare distinction of IBM Fellow, the highest technical honor in the company. Shankar has also receive...
Business professionals no longer wonder if they'll migrate to the cloud; it's now a matter of when. The cloud environment has proved to be a major force in transitioning to an agile business model that enables quick decisions and fast implementation that solidify customer relationships. And when the cloud is combined with the power of cognitive computing, it drives innovation and transformation that achieves astounding competitive advantage.
Personalization has long been the holy grail of marketing. Simply stated, communicate the most relevant offer to the right person and you will increase sales. To achieve this, you must understand the individual. Consequently, digital marketers developed many ways to gather and leverage customer information to deliver targeted experiences. In his session at @ThingsExpo, Lou Casal, Founder and Principal Consultant at Practicala, discussed how the Internet of Things (IoT) has accelerated our abilit...