M. David Peterson just turned me onto a very interesting blogging tool - w.blogger (at http://www.wbloggar.com. It's essentially a reasonably complete word processing tool that's specifically designed for use with a whole host of blogs. I'm still getting a feel for it, but thus far I'm pretty impressed with the product - a standalone blog editor that doesn't need to be online to work, that contains a full set of formatting tools, works with a fairly wide number of blogging servers and is open source to boot. We'll see how well it works over the long term, but out of the gate I could see it being an invaluable addition to my set of tools.
Paradigm Shift, Redux
Every so often I find that, without quite realizing it, I end up in an area that has suddenly become hot. One of the odd facets of working with cutting edge technology is that you reach a stage where you tend to take the technology for granted because of familiarity with it, long before most people have even heard of it. Then, periodically, this little paradigm shift occurs and you realize that everyone else has just caught up with what you've been doing for several years.
AJAX is a lot like that for me at the moment. The implications of AJAX are huge, but they've been huge for a while ... its just that in most cases, the use cases for things like XMLHttpRequest haven't been obvious to most people because of the tacit assumption that because only one platform supported it that it wasn't worth building large applications for (there's something very interesting in that assumption, and that is that even when Microsoft Internet Explorer was the only real player to speak of in the browser space, there was an innate resistance to deviating too far from the existing W3C standards from an application development perspective. My suspicion is that had FIrefox not come along, something else (Opera?) would have come stealing IE's thunder in the same time frame anyway. This isn't diminishing the power of Firefox, but could be highlighting the possibility that developers may not have been as comfortable dealing with Internet Explorer (or Microsoft) as may have been evident at the time.
Regardless of whether that is in fact true, what AJAX has done in the space of the last few years has been to set into motion what looks to be a major, perhaps even tectonic, shift in the way that we build applications, providing the necessary critical link to turn Services Oriented Architectures (SOAs) from being a convenient marketing term into being something far more significant.
One of the critical problems that I felt with the direction of Web Services initially (and through to its now politically more correct SOA incarnation) has been that they have not in fact been very friendly to the one area where they would seem most logical - the web. The original notion of web services seemed so much at odds with the way that the web was set up: build stand-alone, traditional applications that used largely synchronous bindings to external APIs using XML-based SOAP messages, disguising these calls as ordinary object method invocations and performing behind the scenes marshalling between strongly typed C++ or Java variables and XML abstractions of type. It was as if the entire notion of web services in the first place was to get people off of this curious, profit-sucking Internet thing and back to "standard" applications where they belonged, hiding all of the XML and marshalling and the like in the background so that people would use the one true "object-oriented-programming" way that the masters of traditional programming protocols deemed blessed.
I'm going to talk about Java here, but you could readily replace the term Java with C# and have the same conversation. Both are strongly typed languages that generally require large frameworks in order to be able to support all of the potential that the language is supposed to be able to deliver. They are both oriented around the notion that you should build complex class structures to model data, both are "generally" statically typed. They both employed a binary marshalling format for communicating with remote systems, in time replacing (at least partially) these formats with SOAP/WSDL protocols generally applied synchronously. Indeed, I've found with most web services implementations, while the vendors may in fact talk about asynchronous messaging in promoting their products, what actually gets written, at least until people's servers start to melt down, are classical remote procedure calls.
I've worked with C++, C# and Java, and am reasonably proficient with all of them, and there are still a large number of applications where these applications make sense. I'd rather not use a photoshop-esque program over the web, for instance, because while you could do a pretty fair job writing one in AJAX, the things that make Photoshop powerful - its wide array of filters, masks, actions and so forth would prove to be both hideously difficult to accomplish in a pure web interface and very inefficient if using something like Javascript. This also covers many games and certain other editors.
Yet on the flipside, think about most enterprise level applications. Web page design and content is becoming increasingly easy to do within a web browser context, and it is a surprisingly small step from there to building a fully functional document editor (with an open XML standard underlying it of course). Spreadsheets are declarative, and could readily be handled by utilizing some of the capabilities of XForms (indeed, I think that the true killer XForms editor app is going to look a lot more like Excel than it will Visual Basic). Flash already produces far better "slideshows" than Powerpoint and I think that the CMS aspects of XML driven slideshows utilizing SVG will likely be the final nail in the slideshow coffin. Ditto for graphical symbol manipulation programs such as Visio being replaced by browser based SVG that is generally much more lightweight, doesn't require a specialized runtime beyond that necessary to display the SVG, and that creates truly powerful, metadata rich graphics.
Beyond the office suite camp, most enterprise-oriented applications are already moving to the web, but typically the story being sold is that while there are advantages to having the presentation layer be dynamically generated HTML or XHTML or even SVG, for middle-tier applications, Java or ASP.NET are far superior to poor old Javascript on the client. Curiously enough, though, even this conventional wisdom is beginning to be challenged. Part of the reason for this has to do with a significant shift in where business logic resides. In the Enterprise Java space (through much of J2EE) one of the central concepts has been that the business logic should be handled via binary components because of the inherent efficiency of compiled components.
However, one of the more significant changes in recent years in the enterprise space has been the realization that one can readily encode business logic state tables as XML and perform most, if not all of the actual decision making process and business decision making through the use of such XML rule-sets. The advantages here are not small - by utilizing XML here you canmake changes to the business logic of system without necessitating rebuilding or restarting the environment, the business rules can themselves be developed from more distributed state logic in a dynamic fashion, testing and debugging can be accomplished through validation methods on the XML itself independently of the running syste,and the XML can be just as readily cached as binary code can. The additional effect of this is that such a distributed architecture can significantly reduce the processing overhead; and can remove the synchronous bindings that tend to lead to both fragile and insecure code.
In these systems, the Java or C# doesn't go away, but it does become more generic, and in some (perhaps many) cases the shift can be significant enough that languages such as Python or Ruby begin to reach a cost effective parity with (or even exceed) the more traditional "heavy frameworks" languages. In essence, server applications become less "aware" of what it is that they are serving - with XSLT or some other XML process languages and XML streams coming from XML-fronted databases or external messaging queues essentially abstracting the specific server nodes such that from the standpoint of the system-level application there is comparatively little distinction between a database, a black-box functional processing node, or, intriguingly, a web client.
AJAX, in turn, represents this same philosophy applied to the web client. The business logic COULD be processed on the client (what's an XForm, after all, but one manifestation of such business logic) or the client could simply take the results of a non-visible server's applied business logic on some internal model and style that through bound XML-based components. Taking this to its logical next step, the number of points where enterprise-oriented Java needs to be in the system continue to drop. Java does not necessarily completely disappear, but its role is increasingly relegated to running the XSLT transformers, filter engines, and socket level communications. This isn't because of the inherent flaws of Java as a computer language - its because XML essentially pushes the level of abstraction up at least a notch, and in such an abstract world you can far more effectively separate model, processing and presentation than you could a generation earlier.
I know that there are a number of people who can (and likely will) argue that the utility factor (the ease of use) of such enterprise level frameworks in simplifying the processing of some piece of the overall business pipeline is where the real benefits come - that it is easier by far to work with invoice objects and invoice item objects and specific methods and events on each of them, for instance, than it is working with relatively large and generic DOMs. To be honest, I'm not so sure that's all that true. An object class, once created, is very constrained in how it can perform operations, and to change those constraints I have to, in general, create a new class from the base class ... in essence adding to the localized framework for that particular domain. With XML, on the other hand, the same XML can be styled in many different ways based upon the transformations applied to, can be validated based upon both typecast and business-logic oriented schematic systems (XSD or RelaXNG for the former, Schematron or XQuery for the latter) and can have the business logic change without needing to even touch the underlying data object in any way.
In a framework oriented system, you and I must perforce agree to the interfaces for not just data but data logic, but in an XML pipeline architecture, all we need agree to is the underlying structure of the data itself -- what you do with the data is immaterial to me. AJAX is part of this latter viewpoint, and in the larger picture will likely represent a major incursion not just into the presentation space (where its already becoming critical) but in the larger distributed application space that's rapidly becoming the norm in dealing with just about any real problem domain.
http://www.understandingxml.com/archives/2006/01/will_ajax_repla.html
No comments:
Post a Comment