Those startups have it easy. Okay, startups don't have it easy where products, funding, customers, or revenue are concerned. But when it comes to building slick AJAX applications, if you're an enterprise developer, you have a lot more to worry about than they do. This article discusses the challenges to developing AJAX applications in the enterprise environment, how to adapt to handle those challenges, as well as ways you can avoid some challenges altogether through your choice of technologies.
Key Differences Between Startup Development and Enterprise Development
Let's begin by asking, "Why do startup AJAX developers have a leg up on enterprise developers?"
There are two reasons:
1. Startup applications are, by definition, new, or "green-field," projects: there are no old internal databases, code, infrastructure, business rules, or data center rules to deal with. In this regard, building a new app is playing tennis without a net, compared to the challenging game of enterprise development.
2. The life cycle of startup code is measured in weeks or months, rather than years. Large parts of the application are rebuilt on a regular basis to add new features. If the company does so well that the code is running five years hence and starts getting crufty or unmaintainable, that means the early developers are doing pretty well. So the early developers don't worry so much about the long term.
In enterprise scenarios, few projects are fully "green-field." If a new project is valuable enough to execute, it's gaining some of that value from existing business data and systems. Examples include projects to provide new access to existing customer records, or a better way to process an existing transaction.
In addition, enterprise code will be around for a long time - typically 2-5 years and occasionally as long as decades. Over that time, maintainability is critical, as is resilience in the face of restructuring and staff turnover, compliance with changing regulations, and adherence to business continuity planning rules.
If you spend a good part of your career at a large company, you may be the one paying the price in the future for a poor technology design today. Think about those utility scripts you write day-to-day: the idea of building and maintaining a mission-critical business application with those kinds of scripting languages should make you nervous.
Remember how easy Visual Basic was for those first apps in the early '90s...and how difficult it became to modify and maintain those apps in production years later? And those data-access samples in the magazines look so easy...but the authors don't know that your company's "Customers" table is split across two legacy databases and a mainframe.
As an enterprise developer, you have different and longer-term concerns.
Issues Facing Enterprise Development with AJAX Technologies
A number of characteristics of AJAX technologies create tricky - or at least thought-provoking questions - when we bring them into the enterprise.
Some of the popular languages and runtime options are young and still evolving quickly. There are hundreds of AJAX toolkits in use today. Only a few of these will still be in wide use in several years. Even the most popular libraries are adding features and fixing problems at a prodigious pace. While this is a great sign of their vitality, it means there's a new version every few months.
There is also reason for concern over running interpreted scripts as production software, whether in the browser or on the server. While scripting environments are used successfully - and power some of the most successful applications on the Web today - transitioning from a traditional code-compile-link-deploy-test methodology may be challenging for your software organization.
Because there is no compile/link step, you'll only find problems when your code hits them; you'll find missing dependencies when they break the app at runtime. We'll look at approaches to mitigating these issues. It also doesn't help that software teams using scripts extensively as "duct tape and baling wire" may have developed scripting habits that are not suitable for production code.
Next, we see that the languages are fundamentally different from what enterprise developers typically use. JavaScript, for example, is at its core a functional programming language, where functions, with their closures, are the fundamental construct in the language and serve to control scope boundaries. JavaScript, and other scripting languages such as Ruby, are also dynamic. This means that significant parts of the program code may be generated at runtime based on external data or the branch path an application takes. Metaprogramming - programs writing themselves or other programs - is fairly common in these languages and, even if you don't use these techniques, you are likely to encounter libraries that do so.
As we've said, enterprise applications are also less likely to be green-field projects. What does that mean for AJAX development?
For one thing, test-driven-development techniques, a cornerstone of building solid code with dynamic platforms, become trickier. Since enterprise apps often span many systems, it is harder to assemble a full test system that can be manipulated by automated testing. The data in the test systems may not be complete, or may be encumbered by privacy issues. The test systems may be formally controlled or resource constrained so that continuous testing may not be allowed. Proper testing of gateways from partner companies may be hard or impossible. And, since real-world legacy data is not all clean and up to date, you need test data sets that cover these dirty or incomplete-record scenarios as well.
If your application needs to access existing non-HTTP-based network resources, you will need to do some special planning. Pure AJAX is restricted to HTTP; if you need another TCP protocol, or UDP, you'll have to plan on deploying to a plug-in environment in the browser or using a proxy on the server side.
The overhead of deploying additional server applications just to serve as proxies to other systems (a common AJAX technique) could be considerable in the enterprise. And, finally, your data access layer needs to be both compatible with your legacy schemas (something not handled equally well by all of the popular frameworks) and compatible with the rules and leanings of your DBAs.
Adapting to the Challenge Wrangling Platform Versions
There are two basic approaches to dealing with version changes: controlling the version in use where possible, and leveraging abstraction layers to hide version differences. I recommend using both techniques as much as possible.
On the server, you have control of all of your library versions (including JavaScript that is served to run in the client), and many of your interpreter versions (e.g., Ruby or Python on the server, but not the JavaScript or Flash runtime in the browser). Think of the interpreter as a runtime library and consider deploying it together with your server app.
On the client, a key evaluation criterion for a JavaScript library should be its cross-browser, cross-platform abstraction capabilities. Your AJAX toolkit should handle the differences between Safari and Firefox, Mac OS and Windows, leaving you to focus on core UI and business logic. Because of the rapid evolution of AJAX toolkits, you may even want to consider a minimal abstraction layer of your own to mediate between your code and the underlying toolkit, to ease potential toolkit changes.
Working with Dynamic Interpreted Languages
A number of techniques make it easier to enjoy success with your dynamic-language projects.
Testing at all levels, and "Test-Driven Development," are probably
familiar. But adding some extra juice to a testing model will really
pay off:
1. Code coverage analysis - knowing exactly how much of your program
and which parts of it are being exercised by your test suite - is
critical. Testing without coverage analysis can give you a false sense
of security, or cause you to eat up time fixing the wrong bugs.
2. Expand your test coverage using aggressive testing mechanisms that
take advantage of dynamic runtime features. For example, Kevin Clark's
Heckle library1 for Ruby will automatically mutate your Ruby code in
critical ways, in order to make sure that if the code is altered, your
tests take notice and fail. If the code changes (e.g., a branch
condition is reversed, with > becoming <=) and your tests still
pass, then something's wrong.
Although it may sound like an exercise in red tape, write a style guide for your team's code. Discuss things like variable and method names, and rules for language features to embrace or to avoid. Without a compiler to help catch mistakes, it's really easy to assign a value to one variable and try to read it from another - maybe in a different module of code - and automatic type conversions only make this trickier. The style guide can help you prevent similar names. Then use a configurable lint-type tool (such as Douglas Crockford's JSLint2 for JavaScript) to check your code against your style guide. Make this step part of your testing scheme.
For some rules, consider writing your own testing tools. Suppose you want to find all symbol pairs in your code that differ by only one or two characters, suspecting you might find some bugs this way. If your team is ramping up on a new language, building a script to produce this report is a fun and practical exercise in language reflection.
In conjunction with testing, leverage your SCM (software configuration management, or source control) system to help keep dependencies together. Bring all of your scripts inside the SCM system, even if that was not common practice before. Tag or annotate versions of files that have been tested to work together. If your enterprise SCM system is unwieldy, consider bringing in a lighter-weight source control system, like Subversion3, for your day-to-day builds, while still committing code to the company's official repository regularly.
Another addition to your toolset is the axiom that just because a language supports a particular construct doesn't mean it's a good idea to use that construct. A modest number of programming constructs can be the source of serious problems, and the easiest way to rein in the trouble is to resist the temptation to use those constructs in the first place. At the top of the list is the eval statement4, which takes string data and passes it to the interpreter to run as code. At the least, it's worth auditing your code and making sure you know each and every place eval is called and why (remember, each eval call can potentially hide arbitrarily many other eval calls, depending on what is passed to it).
Some valuable dynamic programming patterns can be used, but separated out from the core runtime app by design so that they're easier to analyze and test before the application is run. Examples include scripts to generate a set of types, such as proxies for accessing remote resources (databases or Web services). Sacrificing full dynamism by running a "generate" script ahead of time, which builds a concrete proxy5 that can later be used at runtime, is a reasonable compromise.
Working with Legacy Infrastructure and Databases
In a pure AJAX scenario, a dedicated server-side proxy is a practical
solution to both network issues (access to various network resources,
unusual protocols, etc.) and data access. Although, as mentioned
earlier, running an additional proxy app can itself involve some
enterprise red tape, it opens up a world of solutions as an extra tier
in the architecture.
One of the advantages of a proxy app is that it can leverage existing code and platform knowledge in your company. If, for example, the "old" Website used Java to access a particular data store, then it is straightforward to create a Java Web service that accomplishes the same access and offers those records as XML or JSON for the new AJAX application.
Alternate Approaches: Side-Stepping AJAX Challenges
In addition to writing JavaScript to build AJAX clients, there are a
variety of other approaches to producing AJAX and AJAX-like rich
Internet applications (RIAs). Some of these alternatives are noteworthy
for enterprise developers because they can obviate the need to write
script applications directly. In some cases they can make it easy to
take advantage of a company's existing codebase and comfort using a
particular platform (not to mention those critical support contracts).
The alternate approaches break down into two groups:
1. Building browser-native JavaScript applications without actually writing the JavaScript
2. Building applications that run in browser plug-ins (Flash, Java, etc.) rather than the browser's JavaScript engine
Compiled or Generated JavaScript: Building AJAX Clients Without Coding JavaScript
Outside of writing your own script or using JavaScript libraries, there
are a variety of other ways to end up with JavaScript apps. These other
approaches fall into two groups of their own:
1. Systems that let you code in another imperative language and then transform that to JavaScript
2. Systems that let you declaratively mark up the AJAX effects you'd like, and then generate script to do it
The Google Web Toolkit (GWT) is the most influential library in the former group6. GWT allows you to leverage your company's existing investment in Java development by building both your browser client and your Web services using standard Java. When you need to pass data between tiers, you do so using plain old Java objects (POJOs). At build time, GWT compiles the client-side Java application into optimized JavaScript, and handles marshaling data between the server and the client.
A .NET-based alternative to GWT is Nikhil Kothari's Script#7. Similar to GWT, Script# translates C# code to JavaScript. Unlike GWT, though, Script# attempts to create human-readable, human-editable JavaScript, rather than code optimized for speed and size. If your firm has a large investment in C# and .NET technology, Script# may be an effective way to leverage that investment to create browser applications. It's also worth noting that while Mr. Kothari is an architect at Microsoft, Script# is thus far a personal project and not part of a Microsoft offering.
Another approach is to employ tools that use declarative markup (in the form of tags) to generate JavaScript. Enterprise developers, who are often starting from a Java-based or .NET-based Web application stack, may already have ready-to-run tag libraries available to AJAX-enable their pages. ASP.Net AJAX8 as well as JSF (JavaServer Faces) Dynamic Faces9 are just two examples of libraries that allow declarative markup to generate AJAX capabilities in a Web page.
This approach is not as flexible as some other ways to create JavaScript; however, it is a quick, easy way to add some AJAX functionality within a technology stack that is already adopted at your firm.
Targeting Browser Plug-Ins: Bring Your Own Language
While browser plug-in applications can have their own issues (vendor
control, slow startup time, less-than-100% install base), they
represent the most direct route for enterprise RIA deployment without
building a JavaScript application.
Nearly all of the widely used Web app development languages are present in plug-ins today, and more are coming: the Java plug-in can, of course, run Java applications, but it can also run JavaFX scripts, Python (via Jython), and even Ruby (via JRuby)10. Silverlight 1.0 requires JavaScript, but the upcoming 1.1 release of this Microsoft plug-in adds support for .NET languages such as C#, Python (IronPython), Ruby (IronRuby), Visual Basic, and others11.
Flash Player versions 9 and up support ActionScript 3. ActionScript 3, while less familiar to enterprise coders than C# or Java, is an implementation of ECMAScript 412. As such, it brings classes, static typing, packages, namespaces, and other familiar elements that make an easy on-ramp for C# or Java developers. Adobe's Flex development tool adds another layer of familiarity, since it is built on the Eclipse IDE used by many enterprise developers already13.
Though plug-in based RIAs are not strictly AJAX, in many cases they meet or exceed enterprise and customer requirements, while bringing traditional languages and powerful development capabilities such as complete control over graphics and networking operations.
Conclusion
Enterprise development faces challenges
that make the transition to AJAX trickier than it is for a startup.
Nonetheless, there are a variety of ways to address these challenges.
Solutions range from improvements in development and testing processes, which make it easier to deploy rock-solid apps via script, to mechanisms for avoiding script altogether and using the company's existing technical know-how instead.
As long as we think carefully about the issues - especially how they work at our company - rather than grabbing onto the latest trend for its own sake, we can not only be successful, but also contribute to enterprise best practices for AJAX, which are just beginning to be invented.
Resources/Notes
1. Kevin Clark's Heckle library: http://glu.ttono.us/articles/2006/12/19/tormenting-your-tests-with-heckle
2. Douglas Crockford's JSLint: www.jslint.com/lint.html
3. Subversion version control system: http://subversion.tigris.org/
4. Eval in Mozilla-based browsers:
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Predefined_Functions:eval_Function
• In Internet Explorer: http://msdn2.microsoft.com/en-us/library/12k71sw7.aspx
• In PHP: http://us2.php.net/eval
• In Ruby: www.ruby-doc.org/core/classes/Kernel.html#M005947
• In Python: http://docs.python.org/lib/built-in-funcs.html
5.
By concrete proxy, we mean objects with concrete methods or properties,
rather than dynamically dispatched calls. Examples of the latter
include dynamic proxies built on Ruby's method_missing, ActionScript's
flash.utils.Proxy, etc.)
6. Google Web Toolkit: http://code.google.com/webtoolkit/
7. Nikhil Kothari's Script#: www.nikhilk.net/ScriptSharpIntro.aspx
8. ASP.Net AJAX: www.asp.net/ajax/
9. JSF Dynamic Faces: https://jsf-extensions.dev.java.net/nonav/mvn/gettingstarted-ajax.html
10. Jython applets: www.jython.org/applets/index.html
• JRuby applets are not mainstream-practical today, but will be soon:
http://headius.blogspot.com/2006/11/ruby-for-web-check.html
• JavaFX applications are typically deployed as Java Web Start apps
(running outside of the browser), but can run in an applet as well:
www.reportmill.com/jfx/gallery/
11. Microsoft GM Scott Guthrie on Silverlight 1.0 and 1.1 language support: Click Here !
12. ActionScript 3: www.adobe.com/devnet/actionscript/articles/actionscript3_overview.html
13. Adobe Flex: www.adobe.com/products/flex/