A is for Asynchronous
Asynchronous communication is the key to agility.
Asynchronous will be the cornerstone for any future distributed application architecture if your objective is to deliver robust, flexible, and reliable systems. The challenge is in getting software developers to shift away from the traditional, synchronous, request-reply paradigm that has long dominated programming ever since the introduction of client/server.
AJAX -- Asynchronous JavaScript And XML -- is based on an architectural model where a typical HTTP request to a server is replaced by a JavaScript call to an AJAX engine. The AJAX engine handles a call to a server by generating an asynchronous request via XML. The user's interaction with an AJAX application never stalls waiting synchronously for a request to complete.
AJAX is an example of MVC -- Model-View-Controller. MVC separates an application's data model, user interface and control logic into three distinct components. The Controller mediates between the Model and the View.
AJAX significantly improves how web pages interact with data, rivaling programs that run natively on desktops. Look, for example, at how draggable maps work inside Google Maps. Users click and drag to view adjacent sections of maps, without having to wait for new areas to download.
AJAX overcomes a severe limitation in traditional web interfaces which must reload anytime they try to call up new data. By contrast, AJAX lets users manipulate data without clicking through to a new page or performing page refreshes.
While Microsoft wants to be part of the AJAX revolution, its major focus for developers is on helping them build desktop applications for Windows Vista (formerly code-named Longhorn), its next generation .NET platform for delivering enterprise services that support complex distributed transactions, including support for compensating actions (instead of simple rollback operations). Microsoft includes a user interface development tool called Windows Presentation Foundation (formerly code-named Avalon). Its ultimate goal is to replace browser-based user interfaces with rich clients.
Meanwhile, recognizing the need in certain scenarios for a standardized, browser-based user interface, Microsoft also announced it is developing its own AJAX toolbox called Atlas for web developers who use Microsoft's ASP.NET technologies to build websites.
Regardless of who wins the battle between rich clients and browser-based AJAX clients, the future is all about asynchronous processing. Think of asynchronous as the lynchpin that will unlock the true power of SOA and web services.
Of course, in some sense you could say that the software industry is moving back to the future. After all, years ago when IBM introduced its CICS TP monitor, its most salient feature was delivering online computing via asynchronous computing.
posted by ITscout at 2:51 PM
Site Feed
3 Comments:
Asynchrony has tremendous benefits, but the true promise of asynchronous operation will have to await programming languages which support the asynchrony as a built-in concept.
Without support at the programming language level (as well as the runtime, OS, and hardware levels), all you're going to get is a bigger mess then we already have. Of course, that also means more work for consultants to clean up the resulting messes.
Great, super-star programmers can in fact architect, design, implement, deploy, and support asynchronous software today, but if you start with anything less than A-list talent, you might as well pre-budget those consultants to come in and clean up the mess.
The fortunate thing is that so many of the so-called asynchronous systems are not truly 100% asynchronous, so a great deal of the mess can be avoided. Of course that's bad news for consultants.
Asynchronous operation is quite valuable and needed, but without a lot more deep computer science research and concept development, it will turn out to be yet another detour or cul-de-sac on the path to effective computing solutions.
-- Jack Krupansky
Don't discount publish & subscribe. It doesn't require super-star programmers, but it does demand a paradigm shift -- and that's never easy. Instead of request-reply, you achieve asynchrony by focusing on producers and consumers. The key is to become event-oriented.
I would agree if you're talking about a simple broadcast application where you're just pumping content out to subscribers (like this blog), and maybe even permitting limited *optional* feedback, but the mess comes when the operation of the publisher *depends* on the specific content that might come back from the subscriber. In other words, if you really want to implement multi-step business transactions, especially where the two or more parties are operating on disparate time scales ("I need it now", "I'll get back to you next week").
For true "open" asynchronous systems, timeouts and unexpected responses are a very difficult and messy problem.
-- Jack Krupansky
Post a Comment
<< Home