The SOA Supermarket

Dojo does a lot of things, but it can't pull data from just anywhere. The browser won't let it. That's the first heartbreaking lesson you learn in Ajax-land, your bar.com page can't send XHR requests directly to foo.com.

There are ways around it. The hacky-but-in-vogue method is JSONP, which says "run me this little JavaScript script at foo.com, and come back when you're done with the data." Yahoo and Google web services offer JSONP counterparts to their search services, and Dojo has really nice plumbing for calling them. We go over this in Mastering Dojo chapters 3 and 8. The bad news: a very small number of web services support JSONP.

A more universal solution is a proxy server. Your bar.com page will call the server, "Go fetch me this request at foo.com, will you?" bar.com, not subject to the cross-domain restrictions of a browser, will do that and serve back the results. And it's easy. One line of PHP nets you a proxy server. That's fine for starting out, but as you start taking advantage of more services, all the little details start becoming a PITA: security, routing, data conversion, etc.

And that's where Service Oriented Architecture (SOA) comes in. Here I don't mean just SOAP-based web services, but rather services as a way-of-life: loosely-coupled components from the Internet cloud, connected with orchestration glue in the middle. Your Dojo application shouldn't have to know about foo.com. Instead, it should know "answer this question and give me the answer in JSON format." The SOA server knows to ask foo.com, and convert the answer to JSON. And if foo.com is unreachable, it could contact anotherfoo.com for the same question. And so forth.

The point is SOA saves you coding on the middle tier. And let's face it - you really need to write less code there. Back in 1998, you could spend 20 hours a week on ASP, 20 hours a week on the database, let's say. Then Ajax comes along, and you need to do 15 hours of JavaScript (Dojo helps you here - it could be worse!) How do you squeeze 55 hours into a 40 hour work week? Eliminate your social life?

What I advocate is cutting ASP out altogether - adding 5 hours a week to moving logic back to the database tier, and 5 hours a week of SOA configuration. As you create more reusable Dojo components, you can cut 5 hours from your client-programming time. Voila! You're back to 40 hours, and you're building better apps.

So now your middle tier is a combined POWS (plain ol' web server) and SOA server. What do SOA servers look like? What do they do for you? And how do you choose from the veritable swamp of alternatives? I have some thoughts, which I'll share in the next post.

Dojo and The Incredible Shrinking Server

When you start using Dojo, your focus naturally shifts to the browser. The complexity you once shoved into server-side scripts begins to dissipate. JSP, ASP, Rails and PHP tasks like:

- Generating HTML based on dynamic data
- Validating and massaging user input
- Directing the navigation path

In a Dojo Rich Internet Application, some of this responsibility shifts to Dojo and JavaScript. For example, you now do validation and input massaging with dijit.Form elements. You generate HTML directly from the Dijit components themselves and from Dijit templates.

Some of the responsibility disappears altogether. Navigation from page to page, for example, doesn't matter if you only have one page. So the answer to the question "Where is the Dojo equivalent of Struts or CakePHP?" is "Nowhere."

It's fairly common for Dojo applications to slim down to pure HTML and JavaScript. Suddenly a circa 1995 web server is the right size for serving up your site. What's more, the web applications look like client-server apps from 1995, albeit more connected. Everything old is new again!

So what is the middle tier doing for you? Why not just connect your browser straight to your database and cut out the middleman, as it were? Well, you could. But don't go unplugging servers yet! There turns out to be lots of work you can do on the middle tier. And the nice part is a lot of this work can be done without programming. This is where Service Oriented Architecture comes in. I'll tell you what I mean in tomorrow's post...

Instant Book Gratification

What's that? You promised this great new Ajax application in 2 weeks? You could probably use a good JavaScript toolkit and a good book on how to use it. May I suggest Dojo (http://www.dojotoolkit.org) and Mastering Dojo as the book? It's now available for electronic purchase at Pragmatic - http://www.pragprog.com. Printed copies purchased there will start shipping the week of June 23rd. Or you can buy them at Amazon the week after, or at your favorite bookstore the week after that.

Pragmatic Press books have their own style. If you've read one of their books (like the bestselling Agile Development with Rails), you know what I mean. They read like novels where the first chapters really grab you, then the subsequent ones unfold the topics evenly and gracefully. People have different learning styles, but I particularly like this format because it helps you learn the Way of Dojo - in other words, what concepts hold it all together. The more you learn the concepts, the less you need to memorize. Sounds good, eh?

Mastering Dojo Podcast

If you like your information spoken rather than written, here 'tis: http://pragprog.com/podcasts
... in which my coauthors and I talk about the origin and uses of Dojo.

The book is nearing the end of the writing cycle, but we left some topics on the floor. At some reviewers' requests, we're going to put a chapter in on future directions and other interesting modules.

"You mean you can't describe a JavaScript toolkit in 500 pages?" you might ask. Dojo is really more of an ecosystem than a toolkit. DojoX, the extension module, is like a greenhouse where interesting, small plants grow. It's like getting your Perl with CPAN in the same download.

Mixed Languages and Debugging

JavaScript and server-side languages can work well together ... if you don't set them on the same task.

The programmer's mind is like a kid with a dinner plate - they don't like foods to touch each other. (Ugggh. Terrible metaphor, but what the hey.) Kids have problems debugging food. If they get gravy mixed into the applesauce and it doesn't taste good, there's no way to get them unmixed. Adults probably don't mind it because (1) they know through experience which foods mix well (2) they have given up trying to keep food apart (the "quiet desperation" theory).

I'm not opposed to using more than one language. In fact, that often makes the problem much more decomposable and succinct. What makes me leery of technologies like Google Web Toolkit and Java Server Faces. They try to cover up the language blending, as if a parent can solve the touching-food problem by dousing the whole plate in melted cheese or something. GWT tries to cover up the underlying JavaScript by generating it out of Java. And that's great until you have a problem on the browser side. Is it your code? Is it the translation process? Is it the supporting code provided by GWT? Who knows? You are left with a "this.myProperty is not defined" error, and it's up to you to fix it.

The Dojo Way (tm) is to cleanly separate the tasks of a web application. Styling in CSS. Layout in HTML. Client side logic in JavaScript. Data-providing web services on the server. Now that is like a compartmentalized dinner plate. A little bit of a lot of variety, and nothing touching. You can generally debug these elements as black boxes. Someone works on the web services, writes the unit tests against them without the client. Design gurus do the CSS. The application logic is in JavaScript, and in Dojo you can package them in nice little bite-sized widgets. The app talks back to the server to execute bits of business logic. Very clean. Very nice.

Debugging JavaScript is not a perfect science, unfortunately. And I'll talk about that in my next post.

Dojo and Code Separation

I remember my first foray into Dynamic HTML and heavy duty JavaScript. It wasn't making a ball roll across the browser or drag-and-drop tic-tac-toe. We had a real problem.

The company I was working for had a huge catalog. The items were grouped into over 1,000 categories, which rolled up into about 100 mid-level categories, and 10 top-level. We wanted a catalog search where people could ask for parts at any level. Modeling the top and mid-level groups as combo boxes - no problem. The bottom-level ones were a problem -nobody wanted to scroll through 1,000 categories.

Our idea was to make the combo boxes hierarchical. I'm gonna change the items here to protect the innocent, but let's say someone wanted to search Lemon Lime Soft Drinks. They would choose Beverages from the first combo box. The second combo box would narrow down to Beverage choices: Water, Juice, Soft Drinks. Choosing Soft Drinks would constrain the third combo box to Cola, Root Beer, Lemon-Lime, etc. So rather than searching through all 1,000 categories of food, they'd have only about 10 choices. Fair enough. That means we have to remove choices from the other two boxes.

To dynamically add and remove choices, the page needed to load all the top, middle and bottom categories into the page (there was no Ajax back then!) I ended up having to mix JSP and JavaScript like this:


<script>
var c=[];
<% for (c in categories) { %>
c[i++] = <%= c %>;
<% } %>
</script>


Ugggg .... leee. Mixing two languages caused us no end of trouble - for example, what is the relationship between the JavaScript c and the Java c above? (Answer: none). We were forever mixing up syntax. This bilingualism is as annoying in code as it is in "artsy" novels.

This problem is endemic to all server language/client language mixtures, be it JSP+JavaScript or PHP+Silverlight or whatever. The more rich we wanted to get on the browser side (which our customers were pushing), the more problematic the mixture becomes. And Ajax? That made the problem worse.

Then there's the Dojo Way. And by "Way", I mean a paradigm shift - so get ready for some out-of-the-box thinking. To rid ourselves of the mixture, we must rid ourselves of the server-side language. Do it all in JavaScript. In MVC parlance, keep the model on the server and put the view and controller on the client. This looks a lot like Visual Basic, right?

But isn't JavaScript a kiddie language? How can it possibly compete with PHP, ASP and Java? Turns out, it can. Very adeptly. And hence Dojo, a JavaScript-based toolkit, makes it an easy process. So stay tuned!

Dojo, Dojo, We Adore Thee

I program computers for a living. And as you know well, one of the occupational hazards is getting all gushy over programming tools. It's like woodworkers raving over a particular brand of buzz saw (or whatever they rave about. I dunno.)

Dojo (http://www.dojotoolkit.org) well earns my gush. Superficially Dojo is a JavaScript library in the same vein as jQuery or Prototype. A library, to me, provides stuff I know that I need. I have a great affection for libraries .... Apache Commons comes to mind as a masterpiece of librarydom. But they don't mess with your head, they don't help you dream or architect anything.

Dojo messes with your head. All of a sudden, you begin seeing a world where the browser does the heavy lifting. Server languages like PHP, ASP and JSP ... even nice ones like Ruby on Rails ... are not as important in this world. They might provide data and proxy services to the browser, but not much else. The important reusable components are built in JavaScript.

In the next few columns, I'll show how Dojo short-circuited my Java-based server-centered world.