Topic: Application Architecture

Your SDLC or Your Product – You Decide

Michael Walkden, Wednesday, December 9, 2009 @ 10:33 pm

…or the telephone game

Crane Gears
Creative Commons License photo credit: tallkev

Last weekend I was watching a movie with my kids. In the movie there was a chain of monkeys that needed to pass on the message from one character to one on the other side of the chain. The message went something like, “Don’t throw us over the wall. There must be another way. We will all be killed.” As it went through the chain and the receiver heard, “Throw us over the wall. It’s the only way. Banana.” The scenario seems ridiculous, but its roughly equivalent to how many companies approach software product design. Often times companies don’t realize they are creating a product at all. They think they are just running a project and focus only on delivery of that project as if it is the only artifact of their work.

The problem stems from the fact that when organizations reach a sufficiently large size they must focus on consistency of delivery and efficiently using people’s time. For large organizations this is part of the mix that makes up their competitive advantage. However, the sheer size and number of moving parts required to enable clocklike consistent delivery leads to the most knowledgeable people about the customer never directly speak to the people responsible for building the product. Or translated into a traditional SDLC, the definition/high level design team isn’t communicating with the build team. In my experience they are usually two different groups of people. I’ll give you an example:

A while back, I was leading a software development team creating a product to be used by all 170,000 of my customer’s employees on a daily basis. They happened to have a team of user experience designers and wanted to take on the “big picture” part of the design themselves. This company could afford the best and the brightest talent - and was able to attract them. Individually the folks on this team were talented and knew their craft well. I actually learned a lot just from my brief time with them. However, once we got the design in hand it was obvious that the usability team’s artifacts weren’t going to work for the project. They didn’t meet the end user’s needs nor were they implementable within the time we had available for the project. The client’s design team literately spent months of time showing users lo-fi prototypes, running focus groups, and understanding usage statistics from similar applications. But, the simplicity the end users craved didn’t match the complexity of the business rules required. Upon further investigation the customer’s design team never was given a business level view of the problem to be solved. We tried to merge the business requirements with good usability, but ultimately the franken-design didn’t work. We had to throw out the big picture design and use them as ”guidelines” instead. Clearly it was a waste of talent and a haphazard way to build a product.

In hindsight the design team should have been presented the complex business rules so that their design could incorporate them from the beginning. However, the customer’s SDLC only allowed the design team to be engaged in the definition/high design phase of the project. Once we got to the design phase they were hard to find. By the time we got into the build phase the development team was simply a distraction from other work for these designers. A better model would have kept the designers on the project as each piece is built. I’m not suggesting full dedication to the team – 40 hours a week. That would be nice, but that’s not likely possible in most organizations. I’m suggesting a small time commitment over a long period of time.

Most of the time projects are actually building products. If you are building a product, but focusing SDLC metrics and efficiency, keep in mind that your phases are likely making walls around teams and causing ineffective communication between them. As Matt from 37Signals points out, “Inefficiencies are what make you special.”

Topics: , , , , , , ,

Software Development Software Development

Wireframing with incomplete requirements

Sholom Sandalow, Thursday, September 10, 2009 @ 3:43 pm

The value of wireframing even with incomplete information

The task of wireframing in application development, as I've come to know it, should begin after user research has been performed, and a complete set of requirements gathered.  But what happens when, for whatever reason, you just don't have access to user research, or a full set of requirements?  What if all you have are some rather unspecific, vague notions of what the user should and should not be able to do?  Is wireframing at this juncture useful?  I say yes.  With incomplete or even almost non existent information about target users and or requirements, wireframes can still be a valuable tool in the interface designers toolkit.

The key to a wireframe's usefulness is that it is a visual document.  Presumably it will be presented to one or more product stakeholders, and they will have the opportunity to review it and comment.  Having something visual to respond to is one of the easiest ways to generate ideas, and identify incomplete specifications.  A good assumption is that if a product's requirements are incomplete, someone at the wireframe review will notice the gap by responding in the context of the visual presentation.  "Where is the Cancel button?  Oh...not in the requirements?  Well it's obvious that on this screen the user will need to be able to cancel, so we have to add that as a requirement."

In this way, a wireframe can be an ever evolving document, which begins by starting the requirements conversation.  Of course ultimately, just prior to feature development, the wireframe should have all of the necessary specifics so that the developers can use it as a guide (along with the relevant user stories).


Topics: , , , , , , , , ,

Software Development Software Development

Cognitive Load, Portability and the Superiority of Client-Side Frameworks

Brian Dillard, Tuesday, September 4, 2007 @ 4:59 am

The recent introduction of TrimPath Junction got me to thinking about Dietrich's widely read post on Cognitive Load and the Superiority of Server-Side Ajax GUI Frameworks. GWT's big advantage is that it mobilizes armies of Java programmers to write browser-based applications without having to learn JavaScript. This is clearly of enormous benefit to organizations with lots of Java programmers, few client-side resources, and a burning desire to build powerful webapps. Yet for the similarly huge army of client-side programmers out there, GWT is pretty useless. Why learn a foreign language just to have it translated back into your native tongue?

I haven't yet had a chance to play with TrimPath Junction, but it sounds pretty cool. Using the open-source Helma framework, it offers Rails-style MVC scaffolding in a JavaScript syntax that executes the same code on the client and server. Basically, it's RoR meets Adobe AIR for JavaScript programmers. I hope to give it a test drive soon.

Server-side JavaScript has been around for ages, but it's never really become a common development model. I remember writing ASP Classic apps in server-side JScript back at the turn of the millennium and having people wig out on me. "Why not write in VBScript like everyone else," they'd ask. My answer: "Because I can save time by running the same validation libraries on the client and the server ... and because I can write the entire app in one language." I obviously have no argument with Dietrich's thesis on cognitive load. It's just that my brain features a JavaScript compiler, not a Java one.

GWT is a great piece of engineering that keeps getting better; just check out the new non-beta 1.4 release. But I think there are a lot of advantages to frameworks that mobilize the JavaScript masses to write front-to-back webapps. The same cognitive efficiencies can be achieved, plus client-side programmers already know all the pieces of the UI puzzle. Ask a room of Java developers how to build accessibility and usability into standards-compliant XHTML and CSS. Nine out of 10 wouldn't have a clue.

The other big advantage to developing UI code in its native language is that you can port it to any server platform. With GWT and similar frameworks, you've got to rebuild much of your UI from scratch if you want to change course in mid-stream. With purely client-side frameworks such as Prototype, jQuery, YUI or MooTools, switching libraries may entail rewiring some of your code to a new API. But switching server platforms, from J2EE to .Net to PHP to RoR, can be done without much work at the UI layer. "The right tool for the right job" is a truism for a reason. Pure client-side development of UI code allows for the development of reusable components whose only dependency is on the standards bodies and browser vendors who control JS, CSS and HTML. GWT and its peers are useful for some teams and some projects, but they're not the only answer to webapp development.

Topics: , , , , , , , , , , , ,

Software Development Software Development

Intellectual Frameworks for Classifying Ajax Frameworks

Dietrich Kappe, Friday, August 18, 2006 @ 9:00 am

Who knew that a simple architectural principle like AJAX (Asynchronous Javascript and XML) would cause so much trouble? The trouble I'm having at the moment is classifying different Ajax frameworks in ways that make sense to developers, designers and business people all at once.

There are a number of people who have pondered the Ajax framework classification question and are very much worth reading:

  • Dion Hinchcliffe has wrestled some with building an intellectual framework for classifying Ajax frameworks and approaches. He divides them roughly into the full lifecycle Atlas, the declarative Laszlo and Backbase, and the client-side Dojo.
  • Michael Mahemoff on his excellent Ajax Patterns Wiki, has taken it upon himself to produce a good collection of Ajax frameworks, somewhat categorized, and the beginnings of a framework comparison martix. His take seems to be client, server and hybrid frameworks.
  • Daniel Zeiss has a comparison matrix just for .NET Ajax frameworks. One way he classifies the frameworks is by those that have a multi-page versus a single-page interface.
  • The Midnight Coders have a feature matrix comparing their product WebORB with DWR, Ajax.NET and Sajax. It's the usual feature matrix with check boxes in all of WebORB's rows.
  • I, myself, have emphasized the benefits of abstraction provided by the server-side frameworks like Echo2, versus the frameworks that expose too much of the browser details.

All of these different takes on comparing Ajax frameworks reminds me of a professor I had at the University of Chicago, McKim Marriot. He was a Social Anthropologist and taught us about South Asian culture. He emphasized to us that the answer to any question about ancient India depended on your viewpoint or context. My memory is failing me a little bit, but as I recall, there were three basic principles -- Dharma, Karma and Artha -- through which everything was filtered. He had a grad student make him a big plexiglass box with each of the three pairs of facing sides tinted a different primary color -- red, green and blue, as I recall. Depending on which way you looked through the box, you got different color combinations. By the time I took his class, the colors had faded and the box was scuffed and suffering from some sort of inner condensation problem.

Still, he would twirl it around in class, mumbling about perspective, context and viewpoint. His way of thinking is very similar to the ideas in UML and the various OOAD approaches, where each diagram or artifact gives a different view or perspective into a system -- domain, design, behavioral, deployment, physical, etc.

Looking at the above different comparisons, we can extract a few perspectives and add our own.

  • Architectural - n-Tier webapp, desktop GUI-style abstraction on the server, SOA-style client orchestrator of services, browser extension cross-site apps, etc.
  • UI Style - enhanced page based versus single page.
  • Language - Java, C#, Javascript, PHP, Ruby, etc., both on the server side and for generating Javascript.
  • Component - Client engines, Server engines, Client Plugin, Widgets, Transport Protocols, etc.
  • Feature - is it themeable, does it integrate with db, does it degrade gracefully, what kind of effects does it have, etc.
  • SDLC - do we develop webapps the same way as before, or do we change?
  • Tools & Methods - IDE support, debugging support, etc.
  • Platform - pure browser, hybrid Flash/Javascript, etc.
  • Application Framework - does it provide all of the things, in an Ajax way, that we've come to expect from other web frameworks: authentication, database persistence, workflow, etc.?

Seen through this prism, some packages we've previously thought of as frameworks are not really frameworks at all. For example, seen through the SOA (service oriented architecture) perspective of Javascript apps running in the browser as orchestrators of web services, Tibco GI is a framework. Seen through a client/server or n-tier webapp architecture perspective, Tibco GI isn't a framework but only a part of a larger solution.

What I've realized over the last few months is that this simple architectural idea of Ajax has opened up a whole new world of possibilities when it comes to writing web applications, with the simple n-tier app giving way to a number of new approaches. Anyhow, this is all still percolating in my brain and is not in a ready state by any means.


Technorati : , , ,

Topics: ,

Software Development Software Development

Echo2 vs GWT

Dietrich Kappe, Tuesday, July 4, 2006 @ 9:00 am

Back on June 6th I made a note of this post by Echo2 creator Tod Liebeck at The Server Side, entitled Comparing the Google Web Toolkit to Echo2, but never got around to blogging about it. Tod gives a fairly succinct description of both GWT and Echo2:

GWT's defining attribute is the Java-to-JavaScript compiler. This compiler allows you to develop the web interface to your application in Java, then compile it to JavaScript. GWT limits the developer to a subset of the Java 1.4 libraries. GWT applications can be served by any web server, such as Apache, without the need for server-side processing.

Echo2 applications are compiled to Java byte code and run on a Java server. Their Java code is executed by Echo2's "Web Application Container" layer, which sits atop a Java Servlet. On the web browser, the Echo2 "Client Engine" communicates user input to the Web Application Container via AJAX requests, with the server responding with directives to perform incremental updates to the state of the client web browser.

He goes on to analyze other points of comparison, including architectural, performance and legal issues. A good comparison by one of the AJAX worlds leading developers.

One thought here is that many folks have held out a GWT as a tool for writing widgets for other frameworks such as ZK and Echo2. I've been going through the Javascript infrastructure of GWT and it seems there's a whole lot of plumbing that stands in the way of making this a reality. More on this later.

Topics: , , , , , ,

Software Development Software Development

CMS and AJAX

Dietrich Kappe, Wednesday, June 21, 2006 @ 9:00 am

Back in April, CMS Watch published an article entitled Ajax and Your CMS. The article looks at the impact of AJAX on CMS systems from both the content author's and the site visitors perspective. From the author's perspective, the news is all good and pretty conventional as far as AJAX articles go: fewer click, drag-and-drop, faster, more powerful UI. There are a few noteworthy points to the article, however. For one, content management with AJAX enabled, single-page sites puts a premium on managing assets:

If you are going to use a heavily-Ajax-driven interface on your websites, then it is worth considering a CMS to manage intra-page snippets and interaction as discrete elements. In practice it could be difficult to manage a rich, interactive site that uses single page interfaces without a CMS, since at this point you are managing content components rather than entire "pages." The whole notion of "pages" tends to dissipate, which would call for a more component-oriented -- rather than page-oriented -- CMS for those looking to manage Ajax-driven websites.

So, if you're publishing content rather than constructing an application, then composing a bunch of widgets together using a CMS sounds plausible. However,

Web CMS tools are notoriously poor at managing stylesheet elements and client-side scripting in particular. The rise of Ajax should prompt some improvements here.

Improve or die, I guess.

The few bad patches for the content author are things that people are already working on: back button, refresh/reload an state, etc. Previewing content from a single page interface is a problem not just restricted to CMS's. You can identify the "states" within the single page interface and preview those, i.e. "show me the state after a restaurant has been picked."

That's It?

The fact that CMS Watch really struggled to find much more to say about AJAX than "will make it easier to use, may make content harder to manage," I think points out that nobody really has a clue about how to effectively use AJAX for content sites. All of the major AJAX enabled sites these days seem to be collaborative filtering excercises like digg and dzone. There must be better ways than this to apply this nifty technology.

I think we can come up with a few ideas. What are some of the content display issues we can tackle with AJAX? Let me give three off the top of my head:

  • Screen real estate - we can summarize an article and expand the full test into a new reading context when the user navigates to it. I have a primitive little example here. Just click on one of the text boxes to read the full article in place.
  • Breadcrumbs on steroids - this is more about providing a better reading metaphor. We can make the sections of the paper fold and unfold, allow the reader to rapidly navigate through tabs or trees. No more slow postback means we can try more stuff.
  • Contextual control - the WSJ already has the capability to right click on a selected word and perform a search. But contextual search, navigation, and other operations are the next step. Imagine an online newspaper where a reader can right click in an article about their neighborhood and get restaurant review listings for nearby establishments. You no longer have to cram every single relevant thing into the sidebars!

The day is still young on CMS and AJAX. Think outside the box and share your own thoughts on what AJAX can do for CMS.

 

Topics: , , , , , ,

Software Development Software Development

Grizzly – Infrastructure for COMET and AJAX

Dietrich Kappe, Monday, June 19, 2006 @ 9:00 am

Other than being the black hole into which the JavaMail API has disappeared, the Open Source Glassfish project -- a J2EE app server building on the Toplink and J2EE code donated by Oracle and Sun respectively -- has some interesting stuff under the hood. They have a new NIO-based HTTP Connector named Grizzly. See their Webtier page; down a little on the page, you'll see a heading entitled "HTTP Connector." Along with a nice high level diagram, the section describes Grizzly as

Grizzly is an HTTP Listener using Java's NIO technology and implemented entirely in Java. A re-usable NIO based framework that can be used for any HTTP related operations (HTTP Listener/Connector) as well as non-HTTP operations, thus allowing the creation of any type of scalable multi-threaded server.

With NIO, as anyone who has ever used the Unix select system call, you can have a single thread operating on a bunch of connections instead of one thread per connection. This can save tremendous overhead and can achieve a surprisingly high degree of performance. See the old single-threaded HTTP servers Boa and Tiny httpd for evidence that this is not a new concept.

To understand why Grizzly helps in one piece of the COMET puzzle, we look at Jean-Francois Arcand's blog entry, Can a Grizzly run faster than a Coyote. He ran ApacheBench against Tomcat and Glassfish and came up with the following result: Tomcat needs 500 threads where Grizzly needs only 10 to handle a large benchmark test.

The results are a little controversial -- nobody likes their app server trashed -- and I don't want to get into a discussion about the relative performance of Tomcat vs Glassfish, but the ability to handle the IO of an application server with a small number of threads bodes well for COMET. COMET, remember, keeps a connection open to the browser while the Servlet is performing some long running calculation or waiting on a message, and that means we'll have more connections open at one time. If we needed one thread per connections, we'd be hosed.

What NIO doesn't solve, however, is the that the waiting Servlet still chews up a thread. As we've mentioned previously, Jetty 6 has a continuation mechanism for Servlets that allows waiting Servlets to give up their threads. That's the other part of the puzzle for COMET. Jetty 6, BTW, also has an NIO HTTP Connector to go with its Servlet Continuations, so this may be the way to go for COMET early adopters.

 

Topics: , , ,

Software Development Software Development

AJAX and Security

Dietrich Kappe, Friday, May 26, 2006 @ 9:00 am

Lots of articles like this one from eWeek broach the subject of AJAX and security but give few answers. The most insightful quote from the article is from the Dojo man:

Panelist Alex Russell, co-founder and project lead for The Dojo Toolkit, a popular AJAX framework, said, "It's worth noting that the fundamental problems with browser security and Web application security haven't changed in five years—most rely on a single root of trust, and AJAX doesn't change that. Wider spread use of cross-domain content distribution," which is not new with AJAX, is part of the issue. "The short version is still, Don't trust the client."

Right on. But beyond "nothing to see here...move along, move along," can we at least categorize security concerns and explain how they might apply to AJAX?

The security issues, as I see them, fall into two distinct categories: end-user and server. End-user issues revolve mostly around privacy. A user wants control over what information is revealed to third parties. The server issues, on the other hand, revolve around exposing services that a malicious user can exploit by subverting the client. (There are hybrid versions of these, such as third parties launching attacks on sites using cross domain content, etc.) AJAX has added a wrinkle to both of these issues.

On the client side:

  • XHR has made it difficult for the user to know whether information about their behavior is being transmitted back to the server. Solution: give users a way of seeing what is happening with XHR and other "invisible" communications.
  • It is easy for developers to overlook the need for SSL or some sort of encryption when confidential information is sent back to the server. Solution: Give the use better insight into how information is about to be transferred.
  • Larding in new functionality into the browser raises the chance that security holes might be opened up. Solution: decouple the browser from the OS (IE) and institute a sandbox approach. Don't hold your breath for this one.

Should we give the user more control over XHR, i.e. give them an option to disable certain features of the browser? With the increased complexity of these apps, even tech-savvy users might find it difficult to evaluate the security of the application.

On the server side:

  • Ad-hoc code - We've learned to protect ourselves from things like injection attacks and the like on the server side through the use of webapp frameworks. Opening up lots of little services using ad-hoc AJAX tools can lead to repeating these mistakes. Solution: consider using a server-side component GUI framework like Echo2 or ZK to avoid this issue.
  • Reliance on too much business logic in the client. No matter how much you obfuscate your code, it is still accessible to the client. This is the pitfall with client-side component GUI frameworks like Tibco GI and OpenLaszlo. Solution: you can try and fight against this by making the services they access as simple as possible and dependent on cryptographically secure session information. I just wouldn't do anything mission critical with this.
  • Application complexity - It used to be that if someone compromised your site, they would deface it, install a rootkit or grab some credit card numbers. Now, a cracker might instead modify your AJAX application to send malicious Javascript to the client. Since "view source" ain't what it used to be with DHTML and eval'd Javascript, this sort of compromise might be hard to detect. Solution: regular regression testing against the app is probably the best you can do.

The Open Web Application Security Project has some good resources on webapp security, but they're a little bit behind on AJAX. One of their suggested approaches that I can heartily recommed is using mod_security, sort of a stateful firewall for webapps.

Topics: , ,

Software Development Software Development

MVC and RIA – Learning From Desktop Apps

Dietrich Kappe, Thursday, May 25, 2006 @ 9:00 am

Whether you're writing AJAX applications using enhancements to existing webapplication frameworks or adopting the new component GUI approach, you as a developer are faced with a new granularity of events. Where before you had the monster postback, now you must respond to mouse clicks, key presses, menu selections, etc.

On top of this, with a single page interface, you may have many more controls on the page. This brings on the problem of context, i.e. that not all of these controls are appropriate for a particular context such as when a particular part of a table or list box is selected or when the focus is on a particular window.

The above just scratches the surface of the sorts of challenges that you'll discover writing RIA's with AJAX technologies. The good news is that there are already solutions in place since these are the sorts of problems that desktop GUI developers face all of the time. For example:

  • Enabling and disabling menus and other controls can be done using the State pattern. A collection of state objects would be used to enable and disable the controls as appropriate.
  • Many of the component GUI frameworks implement an Observer pattern for event management. UI events come in now in little bites instead of one huge request and can be consumed by listeners that wait on a specific component.
  • MVC needs an upgrade when you're dealing with big heirarchies of components. Combining the Composite and Chain of Responsibility design patterns, you get the Heirarchical MVC (HMVC) pattern. (If you've worked with WebWork you may have run across the "Pull HMVC" pattern. That heirarchy refers to the model, not the whole MVC.)
  • The Command pattern is often used to implement undo.

That's just a sampling of desktop GUI solutions you can make use of. What can you do to expand your solution space for RIA's? Read lots of code. Find as many good open-source desktop GUI's as you can and read their code. You'll find ways of doing things that don't resemble the typical webapp approach. Here are a few to get you started.

Resources:

  • The Spring Rich-Client Project. Based on the Spring Framework. Used for buidling desktop GUI's. Read the code and get a sense for how to build your RIA framework. Good source for ideas
  • The Scope Framework. The bad new is that this is a desktop GUI framework based on Swing that hasn't been updated since 2002. The good news is that this is a great place to read some code and learn how to develop component GUI applications.
  • The HMVC Framework from Crionics. Again, no longer maintained, but a great place to read some code.
  • Tutorial (in C#) on implementing undo with the Command pattern.
  • A discussion of the Presentation-Abstraction-Control (PAC) architectural pattern. This one is just as old as the MVC pattern, but since the MVC pattern was intended for simple interfaces it was also simpler to implement. Thus MVC won out even in cases where PAC is more appropriate, such as with more complicated UI's.

Update 1: Oliver Steele has an excellent overview of MVC as it exists in the desktop, webapp and RIA worlds. He points out why non-RIA, i.e. traditional webapp programming is so tough:

That complexity includes the real world application of what are still
research topics in academia: staged programming for multiple-target
code generation (Mac IE, Windows IE, Netscape, Mozilla, Safari, Opera),
process migration, and (usually manual) CPS conversion to maintain program state across pages.  No wonder web programming is hard!

Well worth a look.

Topics: , , , , ,

Software Development Software Development

Struts and the Tension Headache

Dietrich Kappe, Wednesday, May 17, 2006 @ 9:00 am

I'm spoiled. This past week I had to go back and revisit a Struts application I developed back in the early days, before Hibernate, before EJB's. I found myself developing an anger headache as I bounced between the struts-config.xml, the web.xml, the jsp's, the home-brew ORM layer, and the various validators, actions and pieces of business logic. Even using an IDE and with well documented code, it was a real pain to make just a handful of modifications. Each time I made a change, it seemed that I had to modify three or four files to make it work. A little XML, a little JSP, a little Java, a little SQL. Oiy!

Why did this stuff make me so angry? Hadn't I designed my code in layers to avoid all this mess? Well, it was actually pretty painless for a struts application. The problem is that struts, and most frameworks, expose too much of the plumbing and force developers to repeat themselves in several places and in different languages and formats.

Why didn't I just accept that this was the way things were? Because I'd spent the last 7 days working on an AJAX newspaper interface using Echo2, and I hadn't spent one second writing HTML, Javascript, XML plumbing or SQL. Just Java. And now here I was back in the bad old world of the web worrying about sessions and postbacks, repeating myself over and over again in different languages.

Yes, things today aren't as bad as in the early days of struts. Hibernate and Spring have made things easy on the ORM front, so I write little or no SQL. Web application frameworks like Webwork and JSF are moving toward components and a higher level of abstraction. But the problem I have with their MVC is that all three really should be realized in Java, not a mix of different languages. That's the only way to stay DRY (Don't Repeat Yourself).

So, why isn't everyone embracing this new, pure Java (or C#, or Ruby, pick your poison) way of writing apps?

Paradigm Shift
People tend to overuse the term "Paradigm Shift", which was coined by Thomas Kuhn back in 1962 in his book The Structure of Scientific Revolutions. What does it mean, Paradigm Shift? It happens when a scientific theory can no longer explain the facts, i.e. when enough anomalies have cropped up to invalidate it. When this occurs, it isn't just the theory that is discarded but the whole worldview from which is comes. From the Wikipedia:

When enough significant anomalies have accrued against a current paradigm, the scientific discipline is thrown into a state of crisis, according to Kuhn. During this crisis, new ideas, perhaps ones previously discarded, are tried. Eventually a new
paradigm is formed, which gains its own new followers, and an
intellectual "battle" takes place between the followers of the new
paradigm and the hold-outs of the old paradigm.

Yes, we're not fighting about Ptolemaic versus Copernican cosmology and if the latter meant that man was no longer the center of all creation. In our case the paradigm is not how which questions we ask and what experiments we do, but rather how we build web applications now that AJAX has come along. The worldview is not whether the planets revolve around the Earth or the Sun, but what exactly web applications can do. The battle is between those who want to build web applications with the old methods -- sort of a souped-up struts with AJAX -- or with the component GUI approach.

I for one am on the side of the component GUI's. I can't stand the tension headaches.

Topics: , , , ,

Software Development Software Development

Not There Yet: COMET with Apache and Jetty

Dietrich Kappe, Tuesday, May 16, 2006 @ 9:00 am

I had intended to marry the nice Apache2 event MPM and Jetty 6 with Continuations in order to achieve a thrifty, thread-sparing COMET capable Java app. The idea is that the Event MPM module in apache frees up a thread when an open connection to the browser is snoozing and Jetty frees up a thread when the backend servlet is snoozing. There are two problems, however.

  1. The Event MPM module seems to only snooze between requests. With COMET the need to snooze happens during a requests, i.e. we are expecting something to come back from the server.
  2. The request handler module -- in this case mod_jk or mod_proxy_ajp -- and not the Event MPM module handles the socket connections to the servlet container. From my reading of the most recent SVN branch, the modules are using blocking I/O and not polling.

It seems there's still a bit of work to be done to make Apache and Jetty do the COMET dance.

Topics: , , , ,

Software Development Software Development

RIA and AJAX: Another Perspective

Dietrich Kappe, Wednesday, May 10, 2006 @ 9:00 am

        Marc Domenig over at javalobby.org has some thoughts on selecting the best product for RIA using AJAX. He gives a decision tree approach to deciding which technology solution to settle on. Given the headlong rush to embrace AJAX for everything from stock tickers to CMS systems, I think it's wise for product managers to carefully consider A) why moving to an RIA model is good for them and B) if AJAX is in fact the best solution.

His view on AJAX is a bit outmoded, however:

JavaScript was designed for scripting rather than full-fledged rich
client development. For this reason, a JavaScript/AJAX product may not
necessarily support all RIA functions mentioned. Partial screen
updates, asynchronous communication, modal dialogs and menus will
probably be available. But other RIA goodies may be severely limited in
functionality or missing altogether. Typically, the set of rich UI
widgets that supports direct manipulation will be poor compared to
those we find in toolkits for desktop applications.

Yes to everything except the idea that AJAX means Javascript apps. While frameworks like ZK and Echo2 certainly make use of Javascript for their display manipulation, it is at such a low level that the development of new component widgets and the porting of widgets from existing desktop GUI frameworks is simplified.

He's preaching to the choir when he points out the benefits of a thin, Javascript rendering engine:

JavaScript code can be limited to an application-independent
presentation engine that comes with the product, as illustrated by the
rightmost option in Figure 4. This pure thin-client approach has
several advantages: applications can be written entirely in Java, with
a single programming environment. Moreover, there is a homogeneous
server-side programming model, and no need to distribute the
application code between client and server, nor between different
programming languages. This simplifies both development and testing
substantially. Finally, the application code will execute primarily in
the robust server-side environment.

He goes on to evaluate the Java and Flash alternatives to AJAX. Overall a well thought out and informative article. Well worth the read.

Topics: , , ,

Software Development Software Development

AJAX Component GUI Frameworks: The Reviews

Dietrich Kappe, Tuesday, May 9, 2006 @ 9:00 am

Over the next week or two, I'm going to begin reviewing several AJAX frameworks, specifically those of the Component GUI variety. The basic idea is that these frameworks allow you to develop AJAX application much like a desktop GUI, by composing reusable widgets and attaching behavior and data to them. The development techniques are well understood and mature. Also, the component GUI is a much better design model than the form-and-reports multi-page awkwardness of traditional webapp development techniques and frameworks for developing RIA's. Picking the right approach now will save you time and heartache. To quote Jesse J. Garrett:

Web sites are technologically complex, and getting
more intricate all the time. Identifying the technology strategy for
the site - platforms, standards, technologies, and how they can all
interoperate - is essential to avoiding costly mistakes.

Two Kinds
There are two kinds of Component GUI's we'll be looking at -- servers-side and client-side. Client-side frameworks essentially build an application in Javascript on the browser and communicate with a backend via web services calls. That's a bit of a generalization, but the idea is that much of the logic is in the browser and the server side takes care of the data and some select operations.

Server-side frameworks use the browser mostly as a display servers, i.e. there is a model of the UI on the servers-side that pushes updates to the client and which is periodically updated due to events on the client-side. All of the business logic sits on the server.

Each type has it's advantages -- client-side frameworks can be more responsive and function in the absence of connectivity, server-side frameworks don't leak business logic out to the client tier and can be made less susceptible to browser variations -- but they share a common advantage over their non-component GUI competitors: they reduce development time because the developer is working at a higher level of UI abstraction and is not concerned with low-level UI tasks such as drag-and-drop, asynchronous updates, etc., and the developer can work largely in one layer without having to repeat himself (DRY).

Client-Side Frameworks
The client-side frameworks we will look at are:

Server-Side Frameworks
The server-side frameworks we will look at are:

Why not X?
Why not Tapestry? Why not ICEFaces? Why not Atlas? There are a number of frameworks that one could argue belong in the above two lists. It's my list, so that means I get to decide what goes on it. I'm looking at Java or Javascript solutions that don't involve mucking about in multiple layers with HTML, CSS or whatnot, and provide a full application framework, not just a library.

First on tap is ZK, the spiffy server-side framework with XUL. Stay tuned.

Topics: , , ,

Software Development Software Development

COMET: Socket Hungry AJAX

Dietrich Kappe, Friday, May 5, 2006 @ 9:00 am

From back in late March, Alex Russel over at IrishDev writes about a new AJAX technique, calling it COMET. What is COMET? Basically the browser makes a request of the servers, but the server keeps the socket open over a long period of time.

[COMET applications] all use long-lived HTTP
connections to reduce the latency with which messages are passed to the
server. In essence, they do not poll the server occasionally. Instead the server has an open line of communication with which it can push data to the client.

Does it scale? We've talked about this stuff before when we spoke about Jetty Continuations. I wrote then that

I don't like this method because it is wasteful in terms of sockets and
threads; also, it is likely to stress stateful firewalls, load
balancers, etc., and may break in lots of client environments.

I stand by that statement. Beyond the issue of migrating these connections between nodes in a load-balanced cluster (yes, you could close the connection and have the client automatically reopen the connection), there are serious scaling issues.

One of the things that made HTTP based applications scalable was that they made use of small, stateless requests. This meant you could handle requests from an order of magnitude or more users than a comparable stateful application.

It's true that the typical AJAX polling for async updates also puts a burden on the server, firewall, load balancers, etc., but that depends partly on the frequency of the polling and the number of clients doing the polling. Even if I have 10,000 users polling the server every half second, I may still only have a few hundred sockets open at any one time if the request/response size is small and the user's network latency is low.

Modifications to server software like Apache and Jetty to conserve resources like threads and make use of IO multiplexing is a first and probably necessary step. Maybe I'm making too much of this stateful thing. We may have so much application state information floating around on the server side anyway that is will dwarf any OS and network resources that COMET and related technologies seek to spend.

Update 1: DWR's next release should have an implementation of COMET that they are calling "Reverse AJAX." More interesting, however, is the fact that they are releasing an API that allows one to write Javascript by writing Java.

Topics: , , ,

Software Development Software Development

How Cool an App in 300 Lines or Less?

Dietrich Kappe, Monday, May 1, 2006 @ 9:00 am

I've always thought that one of the big advantages of a component GUI
framework was that you are able to leverage all of those prewritten
components to produce something rather spiffy with very little original
code.

I gave a presentation on AJAX and Component GUI's this
past Wednesday in Chicago and highlighted Echo2 as a framework worth
investigating. To demonstrate it's power, I showed off an application
that clocked in at 298 lines of code. That's including the code to pull
the stock quotes from a web service via the Mule ESB (a very nice choice, IMHO if you need to do async background processing).

The app can be found here. It's on a somewhat underpowered server, so don't mention it on slashdot. :-)

Demo1

The app allows you to drag stock symbols from a left column into a
right, where they turn into market data grids. You can drag these grids
back again. The quotes are updated every 15 seconds or so. It's of
course much more interesting when the markets are open.

I've
intentionally left it a limited demo, i.e. you can't add in other stock
symbols, since I don't want people to be tempted to use this as a real
stock ticker and burry me with traffic. I do plan to include this app
as an example in my tutorial series.

I made use of Echo2,
Echo2_Contrib and EPNG for the app. It caused quite a stir, since folks
in the audience (designers and developers for the most part) had a good
sense of what it might take to bang something like it out in DWR or
some other framework.

So, the challenge: what can you do in 300
lines of code? Be honest, count Javascript, XHTML, Java, etc. Then let the best demo win.

Update 1: To determine "lines of code," I'm counting semicolons in Java and Javascript, CSS entries, and XHTML entities. Since I'm only writing Java, all the others sum to 0.

Topics: , ,

Software Development Software Development

Launch: Pathfinder Newsletter

    Get a monthly update on best practices for delivering successful software.

    Subscribe via email


    Subscribe via RSS      RSS icon

Categories

Topics

Blogroll

Search

WordPress

Comments about this site: info@pathf.com