John Reynolds's Blog

December 2005 Archives

Big dreams on the longest night of the year...

The past year has seen a lot of progress in enterprise computing. At the beginning of this year I was writing an "elevator speech" on Service Oriented Architecture to introduce the concepts to my IT colleagues:

"This talk will be far more evangelical than technical, and I hope that it will de-mystify SOA for some. I'm sure many of you will say "Duh!" when you read some of the points, but you'd be surprised how many folks just don't get it (yet). "

The other big story of 2005 has to be AJAX (Adaptive Javascript and XML). I first blogged about AJAX in March after witnessing an amazing demo by Dion and Ben. I was wowed by the possibilities, but haunted by:

"memories of pre-custom tag JSP pages... a little puddle of HTML markup embedded in an ocean of Java code (only this time it's JavaScript)"

AJAX and Service Oriented Architectures are fond remembrances of the recent past... What about dreams for the future?

David Gelernter said the following during an interview for the Sun Developer Network:

"Huge numbers of "non-technical" people rely on computers not because they want to but because they have to. The great author and culture-critic George Orwell noted 60-odd years ago (and I noted in Mirror Worlds) that some people like playing with machines; some people don't. People who don't are just barely hanging on today. They need something far simpler, far more powerful than they've got today"

I think that SOA and AJAX are catalysts for the "far simpler future" that most people need. At first glance, you may not see the linkage, but take another look.

Web Services are what makes AJAX sexy. AJAX is what makes Web Services accessible to the masses.

As the SOA mindset takes hold, we should see an explosion of web services. As the AJAX toolsets mature, it should become incredibly simple for "power users" to craft tailored solutions from the new bounty of web services. Throw in improvements in service orchestration and choreography (BPEL for People anyone?), and I think we'll see a new generation of Renaissance Artist/Programmers.

In a recent interview, Bill Buxton offered the following scenario:

"The interesting thing is if you can throw a cell phone on a passenger seat, the phone rings, and the phone says to the stereo, "There's a call coming in. Can you turn the music down and can I borrow the speakers? And by the way, can I use the microphone embedded in the steering column?" Now you can just talk hands-free."

In Bill's example, the stereo provides an "audio output" service, the the microphone provide a "voice input" service, and the phone provides several communication and choreography services. The key is to help the "Renaissance power user" discover these services and then to help wire the services together on-the-fly. The pieces of the puzzle exist, the challenge is to make it easier to put them together.

The languages, tools, and devices that deliver this kind of power to the new Renaissance men and women are what I plan to dream of tonight...

Pleasant dreams indeed ;-)

Ja-va-saurus and the Asteroid

Let's grant Peter the benefit of the doubt and assume that he's right. Let's assume that Java is in fact a dinosaur and have some fun...

Fortunately for us we can make a pretty good case that software-wise we are still living in the Mesozoic era, commonly known as "The Age of the Dinosaurs".

Large herds of the stately Ja-va-saurus and it's close relative the See-sharp-a-saurus pretty much dominate the landscape, but increasingly smaller packs of the sulking Pee-aych-pee-a-saurus and of the graceful Ru-bee-a-saurus have begun to appear.

Dinosaurs are all around us. Dinosaurs are the dominant life form, and dinosaurs are going to be the dominant life form for a long, long time... unless an asteroid hits.

I think "the asteroid" is on it's way... and perhaps it has already entered the atmoshpere. Look around, and you'll already see the signs of an imminent impact.

Watch a pre-teen juggle a dozen simultaneous threads on their video mobile phone and then tell me with a straight face that this generation is going to put up with any of the "dinosaur-age" programming languages and development models that we cling to. Do you really see these multi-media savvy kids writing applications with glorified text editors?

The future is about creative connectivity. The future is about using duct tape and baling wire to cobble together innovative solutions from disparate components that were never meant to work together.

The mammals that inherited the earth from the dinosaurs shared a lot of DNA with their predecessors, and my bet is that whatever comes next is going to share a lot of "DNA" with our good old Ja-va-saurus.

Bring on the asteroid ;-)

Form Validation in an SOA context

Validation of user input has always been an important aspect of user interface programming. You have to make sure that the values a user provides to your program are of the right type, in the right range, etc. and you should provide meaningful feedback to help users correct any errors.

I have often blogged my opinion that validation rules are business logic, and that they should not reside in the presentation layer. The presentation layer may apply validation rules, but developers should not have to modify presentation layer code (including JSPs) when validation rules change.

Please note that when I use the terms “validation rules” or “validation logic”, I am incorporate all of the following:

• Field level validation: rules applied to a field based solely on the contents of that field
• Form level validation: rules applied to fields of a form based on the contents of other fields on the form
• Application level validation: rules applied to fields of a form based on data that is external to the form

Assume that you craft a business service called ProcessLoanApplication. This is a coarse-grained service that provides a few service methods to achieve a specific business goal, and the service involves the exchange of large document-oriented parameters.

ProcessLoanApplication is designed for B2B integration with an external partner. Our assumption is that a “LoanApplication” document is generated by the partner’s systems, and transmitted to ProcessLoanApplication when complete. Obviously, we’re going to have to apply our validation rules to the incoming documents, and we will have to provide document-oriented feedback if any rules are violated.

So far so good, but now assume that that our own company wants to provide a browser-based application that allows users to create “LoanApplications” and submit them for processing (via the ProcessLoanApplication service).

Using an IDE such as Java Studio Creator, it is fairly straight-forward to create a browser-based application to front-end a web service. We can easily configure JSF controls to gather the necessary input data, prepare an appropriate document, and invoke the ProcessLoanApplication service. If ProcessLoanApplication detects any errors, they will be returned in a document to the JSF application. The response can then be parsed and we can display appropriate error messages to the user.

If you are not already shaking your head at this description, then you probably have not done much user-interface development. It is generally considered as “bad form” to defer all input validation until after a form is submitted. The consensus view is that you should detect invalid input data as soon as possible and prompt the user to correct the mistake.

Assuming that we want to provide timely feedback to the user, and that we don’t want to duplicate input validation logic in our JSF application, we will need a service interface to apply (or obtain a copy of) the validation rules that are used by the ProcessLoanApplication service.

The need to obtain a copy of our validation rules becomes more apparent if we also encounter an external partner that wants to apply our rules to their documents prior to invoking the ProcessLoanApplication service. Within our own enterprise, invoking a validation service as the user inputs data works fairly well (sort of an AJAX approach), but constraining 3rd parties to operate in that manner may not be acceptable (for example, they may want to minimizes transmissions through their own firewall).

This is one of those cases where I really do not want to roll-our-own solution. I want proven tools and templates to insure that the business oriented tasks (writing business logic, writing validation rules, defining workflow, etc.) do not get intertwined with infrastructure development and configuration. I know that all of the pieces of the puzzle exist, but I am still looking for a holistic solution that addresses the client, the web application, and the web service.

Are there widely-used blueprints, best-practices, frameworks or products that address the scenarios that I have outlined in this blog? Are there de-facto standards for creating validation services that are intended for use both by coarse-grained web services, and by JSF-centric web applications? Are there de-facto standards for exchanging validation rules with external partners (particularly application level validation rules)?

If you have any suggestions (besides changing careers) I would love to hear them.

Paving cow paths - Service Component Architecture plans to smooth out the bumps

Unfortunately, "No part of the document may be reproduced or transmitted in any form without written permission..." so I can't quote the document, but I can hopefully paraphrase its goals without getting into trouble:

• Simplify business component development
• Simplfy the assembly and deployment of business solutions built as networks of services
• Shield business logic from middleware details and low-level changes
• Improve the testability of business services

These goals are particularly attractive to those who have had some misgivings about Java's suitability for business programming.

SCA builds on and embraces Spring, BPEL, Web Services, EJB3, REST, etc. in an attempt to create de-facto standards for assembling diverse components into composite applications using little or no bridging code. In that sense, SCA is paving cow paths rather than breaking any new ground. I find that refreshing.

It is way too early to judge SCA's success, but it could turn out to be a very good thing if they can pull it off.

This work is licensed under a Creative Commons License.