John Reynolds's Blog

Community Archives

The Next Generation In Workflow?

Object Only Programming (and Modelling) Considered Silly

Every so often I come across a blog entry that makes my own attempts to put my thoughts in writing seem pathetically inadequate. Stevey's Blog Rant: Execution in the Kingdom of Nouns is one such entry.

Stevey's position is that Object Only Languages are silly... at least that's how I sum up his blog.

I couldn't agree more, and I couldn't have said it better... I've tried several times:

My first attempt to express my concerns about "Objects Only" was back in in November of 2003: UML and Process Definition for Java - JSR 207. Looking back, I realize that I should have just said "Object Only Modelling is a dumb idea".

For the record... "Process Only Modelling" is also a dumb idea. To borrow Stevey's metaphor, a Kingdom of Verbs is just as silly as a Kingdom of Nouns. Let's all move to the Kingdom of Sentences :-)

Getting Tasks to the Right Users in a Managed Business Process

Perhaps this blog on Task Routing in a Managed Process will help you to understand the issues that Business Process Developers have to deal with.

Drive the Path (process and data flow)

1. What are the steps?
2. What are the possible paths through the the steps?
3. What data controls the path through the process?
4. What data flows through the process.

When you know these answers, then start your development efforts with the process diagram and use that to drive your development path in this order:

1. Model the process flow.
2. Define the data that controls the process flow.
3. Build "just enough" user interface to allow you manipulate the data necessary to step through all the process paths.

It's absolutely critical that you do these steps in this order at the outset of your project... and once you are done you've got to do the following:

Drive through ALL of the process paths with your Business Sponsors.

If you follow these steps, then you will expose the flaws in the process flow long before you've wasted any time coding up a fancy UI that is WRONG.

The process should drive the UI, but often our haste to show a sexy screen to our Business Sponsors the UI ends up locking us into a bad process model. We've all made this mistake, and we know from experience that it screws things up for the rest of the project's life.

Everyone focuses on UI. It's the most visible aspect of a project and the easiest to have an opionion about... But in truth the best UI in the world won't make the wrong process right.

Yes indeed... the UI development tools in some BPM suites often require super-human efforts to build the sexy AJAX powered screens that are all the rage, and often you'll end up developing your fanciest UIs with supplemental tools. But that's not why some BPM projects fail...

BPM project's fail when the project team doesn't follow the steps of Process Driven Design that I've laid out in this blog entry. If you've had problems with BPM... try it my way next time. I think you'll be pleasantly surprised if you do.

Give One, Get One

It's not too late to Give One and Get One...

The One Laptop Per Child initiative may not be perfect, but why not support them anyway?

I ordered mine today:

Confirmation
Thank you for participating in Give One Get One. Your donation will bring education and enlightenment to children of the developing world, and, in recognition of your gift, you will be receiving an XO laptop for the child in your life as well. If you have any questions or problems, please contact One Laptop Per Child at service@laptopgiving.org. Should your employer wish to match your donation, we are a 501(c)(3) organization and our EIN# is 20-5471780. Thanks again, and welcome to the One Laptop Per Child community!

Merci de votre participation au programme Offrez-en un, recevez-en un ! Votre don servira à l'instruction d'un enfant d'un pays en voie de développement ainsi qu’à son enrichissement personnel. En remerciement, vous recevrez un portable XO pour votre enfant. Pour toute question ou problème, veuillez contacter Un portable par enfant (OLPC) à service@laptopgiving.org. Si votre employeur souhaite compenser votre don, sachez que nous sommes une organisation 501(c)(3) et que notre numéro d’identification d’employeur (EIN) est le 20-5471780. Merci encore et bienvenue dans la communauté OLPC !

Gracias por participar en Dé uno, reciba uno. Su donación ofrecerá un acceso a la educación y al conocimiento a niños del mundo en desarrollo, y, en reconocimiento a su regalo, Ud. recibirá otro portátil XO a cambio para el niño en su vida. Para cualquier pregunta o inquietud, favor de comunicarse con Un portátil para cada niño (One Laptop Per Child) a service@laptopgiving.org. En el caso de que su empleador deseara igualar su donación, somos una organización 501(c)(3) y nuestro número de EIN es 20-5471780. Gracias nuevamente, y ¡bienvenido a la comunidad Un portátil para cada niño!

The BPM Elevator Speech

A few years ago I posted a short blog entry "The SOA Elevator Speech" to try to distill SOA into talking points that you might be able to cover on one elevator ride. With that posting in mind, here's my attempt at explaining BPM as concisely as I can...

• BPM stands for "Business Process Management". You will find some folks who say that the "M" stands for Modelling, and a few others who say that the "M" stands for Monitoring. In my opinion it really stands for all three so we might as well call it BPM³.
• BPM systems deal with processes that include both tasks that Humans perform and Automated tasks.
• BPM systems execute Process Definitions. Process Definitions are usually derived from Process Diagrams... for example a BPEL (for people) Process Definition can be derived from a BPMN Process Diagram. There are many different graphical process notations and process definition languages, but the goals are generally the same.
• BPM systems provide a Process Centric view of the code base. Rather than focusing on object hierarchies, the focus is on the relationship of the components in the context of a specific business process. This feature comes in particularly useful when debugging a process as well as when the need arises to modify a process.
• BPM tools generally have a Business Relevant focus rather than a Programmer Relevant focus. For example, a typical programming suite might include a profiler for analysing the execution efficiency of code... a BPM suite is more likely to include a profiler for analysing the efficiency of a process (based on historical or simulated metrics).
• The goal of a BPM system is to enable Continuous Process Improvement. Analysis of existing process behavior combined with simulation of potential process enhancements can be used to identify and improve the business process.
• BPM benefits from SOA, but Process Tasks are not necessarilly reusable services. Many tasks in a Business Process are not reusable in other processes, and many SOA services do not correspond to Process Tasks.

That's already too much material to cover on one elevator ride... I'd better give it a rest for now or you're likely to take the stairs the next time you see me on an elevator :-)

Monolingual web toolkits: Phobos vs. GWT

The JVM is well on its way to becoming a multi-lingual environment with support for Java, Javascript, JRuby, Groovy, etc. but I have to admit harboring concerns about polyglot programming within a single project. If at all possible, I prefer to use one language per project, but with browser-based applications that's been very tough to do. I've usually ended up with Java on the server side and Javascript on the client.

Fortunately, I can now dump either one language or the other... If I want to ditch Java I can pledge my allegiance to the GlassFish Project Phobos. If I want to ditch Javascript I can pledge my allegiance to the Google Web Toolkit (GWT).

Phobos looks really, really neat... you should really check out their screencast... but I have not had the bandwidth to even play with it. GWT also looks really neat... some of my colleagues at work have published their favorable experiences with GWT versus Dojo, and it certainly looks compelling... but once again I haven't even played with it yet.

Is it really worthwhile to use a monolingual tool? I think it is, particularly when you are trying to learn how to program. Once you've mastered one programming language it's fairly easy to pick up another, but mastering two (or more) at once seems to me like a bad idea.

As I might have mentioned before, I'm interested in teaching "normal" people how to program. Back in the good old days before that darn-old Internet things were pretty simple... I remember teaching a neighbor "enough" Visual Basic to "get by" in a few evenings. Learning "enough" to build a browser based application is dreadful by comparison...

I am thinking that Phobos might change that... Javascript seems simple enough for anyone to grok... but maybe I am kidding myself. Even Javascript has a lot of cruft.

On the other hand, GWT does liberate Java programmers from all of those nasty browser inconsistencies. For those who've mastered Java it seems like a natural... but Java seems like a poor choice for a first language to teach someone.

What do you think? Teach them Java or teach them Javascript?

"We don't see the need for BPM"

Several folks said "We don't see the need for BPM tools"... and I would like to address that in this blog entry.

I'm really not surprised that the average Java developer doesn't see a need for BPM... In fact I'm not surprised that the average worker in any industry doesn't see the need for BPM.

All of us who work for a living participate in business processes. All of us who interact with businesses participate in business processes.

Almost of us participate in business processes. We don't think about it much because we generally don't care what the full process is... We generally only care about the tasks that we have to perform within any process.

For example: When you apply for a loan you are a participant in a "Loan Origination Process". In general you really don't care about all of the steps of the process. You don't care about all of the tasks that the lender has to perform. You only care about the process step where you fill out the loan application and the process step where you respond to the lender's decision.

When you develop software you are a participant in a "Software Development Process". Speaking for myself, when I am working in "programmer mode" I usually don't care about all of the steps of the process. I only care about understanding the requirements, writing the code, and fixing any bugs that QA finds.

My Project Manger (PM) cares about many more steps of the software development process than I do. Project Managers have to coordinate the programmer tasks and those of everyone else on the project. Most of the PMs that I've met don't think of their projects as instances of the software development process... They tend to view their projects as schedules, which explains why those lovely Gant charts in Microsoft Project are pretty much all that they need in terms of tool support.

It's only when you get to a much higher level in your organization, perhaps to the VP of Development, that you find someone who might really worry about the whole Software Development Process. If your organization is large enough, the VP might be responsible for several projects that are running at the same time, with each project at a different point in the process.

As long as all of your company's projects are completed on time and under budget, your VP is probably going to leave your Software Development Process (SDP) alone. For some strange reason, all of the VPs that I have worked for kept tweaking their SDPs.

Development VPs mess with their SDPs to try to lower costs, to have more predictable schedules, and to just generally drive their employees crazy. They want to make more money. Meddlesome Development VPs like to find problems in the process, "improve" the process, and then do it all over again.

Your company has lots and lots of business processes besides your Software Development Process. Some are really mundane, some our critical to your company's bottom line.

All of your Corporate Officers are really interested in managing all of those business processes. Inefficient processes cost more, both in terms of expense and in terms of lost revenue, than efficient processes.

Managing a process...

The first step in managing a process is to know what the process actually is. This includes the steps that are done by people and the steps that are done by machines. I once found it necessary to gather a dozen people in a room to find out what everyone thought the process was, and then later discovered the process wasn't at all what they thought it was. Big companies like to spend lots of money to diagram their processes... which they then file away for five years until they do it again.

The second step in managing a process is to gather metrics... How long (on average) does it take for each step of the process to take? How often are steps repeated (presumably due to errors)?

The third step and fourth steps in managing a process are to analyze and actively manage the process. Use the metrics that you've gathered to analyze process performance, develop a better process, try it out and start all over again. That's Continuous Process Improvement.

All good BPM suites provide infrastructure support for all the steps needed to manage processes...

First: Know the process

At the heart of all BPM suites is a process engine that executes process definitions. These definitions are usually represented graphically using BPMN notation. Process diagrams are usually generated in conjunction with the business people who own the process... Please note that it's much more important that the business folks understand how to "read" the process diagram than it is for them to be able to draw the diagram... The process engine is going to execute the diagram, so if it's wrong the process will be wrong.

I like to say that processes are composed of Human Powered Services and Autonomous Services... Most BPM suites provide tools that help you build the Human Powered Services. These tools are basically form designers, and they're good for doing many business-task-oriented user interfaces, but they aren't meant to be used for designing "filthy rich" client interfaces... All of the good BPM suites provide interfaces that allow you to hook in virtually any client that you wish to construct. If you want a Swing application to perform a task, then you can write a Swing application and hook it in. If you want to use Netbeans or Eclipse to perform a task, you can do that too.

BPM is not about replacing all of the applications that you use. It's about coordinating the use of those applications to perform a process.

But back to knowing what the process is.... You know what the process is because you can always see it. The process definition is not scattered across multiple applications and background tasks. It's contained in one precise definition.

Second: Gather metrics

Since the process engine is managing the process, the process engine knows when each task is started and ended. The process engine knows who performs each task. This makes it incredibly easy to instrument a process.

Third: Analyze the process

All good BPM suites provide tools for analyzing all of those nifty metrics that you've gathered. The really good suites even let you use your historical data to simulate how a proposed process change would have performed in the past.

Fourth: Modify the process

With that analysis in hand, you can now go back and modify your process... This is really easy because, as you may remember, the process definition is in a single place.

I cannot emphasize how useful it is to have that process definition driving everything else. In essence, you have a process-centric view of your code base. In my pre-BPM days I would join a project and have to spend weeks to track down the code that was responsible for some specific process behavior. With a BPM tool, you can always start at the process diagram and "drill down" to the code you need to change.

But can't I just put all these features together myself?

Of course you could. What do you think all the BPM vendors did?

Wrong question... Will a client pay you to put all of these features together AND pay you to develop a process on top of that?

The optimist in me says: "Why of course they will!"

The realist in me says: "Why would they?"

Sounds boring... Why shouldn't I just ignore BPM?

There's no reason to pay any attention to BPM as long as you don't make your living building process-centric applications.

If the applications that you write only involve one participant, you'll never need BPM... but I encourage you take a good hard look at those applications because they may actually function better if they are process-aware.

For example... Every issue-tracking system implements multi-participant processes. Sadly the processes are usually hard-coded in these tools, but more and more you'll find that issue tracking tools (like Jira ) are providing web-service interfaces to interact better with the other tools that are used in a wider process.

Another example... Your favorite IDE. More and more we are seeing process oriented functionality creeping into these tools. Why not leverage an existing process engine (like Apache ODE ) and make those processes more flexible?

Parting thought...

From the very beginning, the core of most programming has been Process Definitions and Data Structures. BPM is our latest reminder of that.

Why do Java developers hate BPM?

Java developers hate BPM.

The preceding sentence is (of course) intentionally tailored to be controversial. People tend to read controversial blogs, and I'd like you to read this one. Now that I have hopefully grabbed your attention I'll tone it down a bit...

A lot of Java developers hate having to use BPM tools instead of the object oriented tools that they are comfortable with.
I work on a lot of BPM projects, and I work with a lot of other folks who work on a lot of BPM projects, and we have all encountered resistance from traditional Java developers. Java developers (in general) would rather use frameworks like Struts and Spring than be saddled with the constraints of a BPM suite.

Java frameworks like Struts and Spring are in the background... they provide just enough support to "set your creativity free" so that you can be a real programmer. You can build almost anything with Spring or Struts (if you've already mastered the intricacies of Java). They are light-weight, they're agile, and they look sexy on your resume.

BPM suites are in-your-face. They rob you of your creativity. They dictate to you how you will develop your application.

BPM suites make programming boring. They force you to use point-and-click and drag-and-drop tools to design your process diagrams, data models and forms. What's worse, they actually encourage Business People to model processes and design forms on their own... Fortunately most Business People are too intimidated to use these tools, but it does open the door for them to look over our shoulders and meddle in our affairs.

That certainly doesn't sound like something that real programmers would like, does it?

I'm not being subtle, am I?

BPM suites are a threat to traditional Java programmers. These suites are far from perfect, but even in their current state we can see where things are heading. The days of the Java Guru as indispensable are fading... We've used Java to build tools that make knowing Java itself less important, and that's opened up competition for us from folks who didn't spend years learning Java.

We're victims of our own success... and that's going to cost us.

That's why Java developers hate BPM.

Making life simpler: the Java EE Operating System

One of the biggest challenge for companies with Java EE based products is dealing with installation issues...


Granted, Enterprise Class applications are much more involved than the "shrink wrapped" applications that we install on our PCs... but it should be possible for a company to package up a Java EE application so that it can be reliably installed on any Java app-server without a lot of headaches. Sadly, that does not seem to be the case... each app-server is a little different, and all those little differences result in a lot of support costs.


One popular solution to the installation problem is to embed a Java app-server in the product itself... Instead of installing an application on a pre-existing app-server, the product installer includes an app-server. This avoids all the hassles of dealing with an "unknown" app server... but you must admit that this solution is kind of bizarre in some respects: Installing an app-server per application has got to be in some way an immorally over-engineered solution... it's almost like shipping an application with its own Operating System.


I suppose that a scaled-down embeddable app-server might be a good idea, but a better idea might be to abandon the current app-server-installed-on-your-OS model and go all the way to a Java Enterprise Operating System.


Earlier this year I suggested that the multitude of Java EE implementations is a bad thing... but now I think I didn't go far enough... Why not just build an OS that is a Java EE app-server?

Recyling old rants... Getter and Setter Methods

In search of a new acronym: SOW (Sevice Oriented Workflow)

My proposal is SOW, for Service Oriented Workflow... but unfortunately, as you can read at my other blog, there are problems when trying to coin a new acronym ;-)

Java EE should be an implementation

There, I've put it in writing... Enough of this madness. Java EE should be an implementation, not a spec.

Joseph Ottinger has posted an interesting editorial over on TheServerSide entitled: "Where Java EE goes horribly wrong." In the blog, Joseph relates what a pain in the butt it is to port an application from one Java EE implementation to another.

Joseph's experiences seem all too familiar... and all too unnecessary.

Do we really want Java EE to be a spec?

Do most of us really benefit from a slew of Java EE implementations?

Wouldn't most of us really rather forgo the pain and have one official Java EE implementation?

In my thinking, Java EE has become an integral part of the Operating System. My products require it's presence, and the line between features provided by the OS and those provided by the Java EE app server is very blurry to my clients.

Back in the 80's there were a multitude of Unix implementations (most of which were tied to a vendor's hardware platform)... and all of them had quirks. Things got so bad that a truce was declared and the Unix vendors tried to collaborate on a common specification called System V. These unification efforts never really overcame the perception that Unix was fractured, and the door was left wide open for Windows NT and Linux to dominate the Server OS landscape.

Today, a multitude of Java EE implementations (with all the unavoidable porting quirks that go along with multiple implementations) is leaving the door open for implementations (products), such as Ruby, to perhaps take the lion's share of the market.

As with Unix and System V, it may be too late for Java EE to formally consolidate on a single implementation... but I sure would like to see a single Java EE implementation dominate in the same way that Linux dominates the Unix world.

Traveling Guy

I left my house at 6 am on Monday to catch a flight from Austin Bergstrom to Chicago Midway. During my 2 hour layover waiting for a connecting flight to Providence RI, I participated in a conference call with 3 folks in New London CT, one in Groton CT, one in Boston MA and one in Peapack NJ. I arrived in Providence at 3:30 pm, picked up my rental car and drove the 50 miles to New London in record time, landing at my desk away from home by 4:30 pm.

I spent Tuesday catching up with my colleagues. One of them drives in from Boston and the other takes the train up from just south of New York City. During the day I conferred with colleagues in Peapack NJ and back in Austin.

On Wednesday we had a big meeting... a presentation and walk-through for our stakeholders. A winter storm had dumped a bunch of snow and sleet on the area, and since my rental car had no ice scraper I had more than the normal amount of fun getting in to work.

The meeting went of well, but of course most of the participants were elsewhere (having dialed in via WebEx).

Thursday (Today) was very surreal... the roads were icy in the morning, so many of the locals worked from home, leaving only the out-of-towners like me in the office. I left early, expecting a longer commute up to Providence due to the snow, but the roads were fine. As I write this I am on a plane, somewhere between Connecticut and Maryland, and with luck I should walk through my front door by 11 pm.

This has pretty much been my ritual each week since the first week of October last year. I decided to make a huge career shift, and took an 80 per cent travel job as a Professional Services guy for a BPM company.

I love the work, and I am totally jazzed up about the promise of Process Driven Design... But business traveling is not for the faint of heart.

My second week out, a freak snowstorm in Chicago shut down O'Haire just long enough to throw off flight schedules across the Eastern seaboard. My flight was delayed for 4 hours (plus two hours on the tarmac in Providence waiting for Air Force one to get off the runway in Chicago), so I missed my connection. End result? I got to sleep in Concourse B of O'Haire, lost my cellphone, and did not get home until 18 hours later than originally scheduled.

That episode was my worst journey so far... but you just have to get used to it. Delays happen, and you can't do a thing about them except to be prepared and keep smiling.

I replaced my cell phone with a Blackberry, and it has become truly indispensable. With it I can check my email and flight schedules, make and change reservations, etc. and the screen is even bright enough to use as a flashlight in a pinch. I never check luggage unless I have to. I never schedule a flight through O'Haire unless I have to. I am learning the tricks that business travelers use to stay sane.

Back to my most recent trip.... the irony of that journey was that to a large extent I traveled far and wide to participate in virtual meetings. I enjoyed the quality face time with my team mates, but the important issues were resolved remotely. Virtual presence was "good enough" to get the job done... being there "in the flesh" was only to provide an added measure of trust and confidence that there were no misunderstandings.

As virtual meetings get better, as our ability to project our presence remotely improves, will there come a time when "in the flesh" meetings aren't necessary?

Today's technology has already made "being away from home" a lot less of a big deal than it once was. I call, chat, email and share photos with my wife (Teri) constantly. I can pay bills, schedule Dr. appointments, and even watch "local" TV shows wherever I can get a WiFi signal. I am never "out of touch" with the home front... and I don't have to spend time catching up when I do get to be at home with my wife.

Can't the same technology keep us from getting "out of touch" with what our client's and colleagues need from us, and what we need from them? To a large extent I think that it can... but not quite yet. Remote meetings just aren't the same... They are fine for keeping things on track, but they don't work well for establishing relationships and kicking off new projects.

So for the present, I'm a business gypsy. If you are in the same boat, I'd love to hear the tips that you have learned to keep yourself sane... Happy Traveling!

The Twin Paradox

My friend King sent me a link to this wonderfully perverse anecdote about how an insurance company was unable to handle twins: Disjoint Twins - The Daily WTF

To make a short story shorter:

"It turns out that a new version of their software was installed that tracked each person's budget based on their last name, plan number, and month/year of birth. Hence, having two people born in the same month and year on one plan would cause all claims to be booked against one of the two's budget, risking a premature budget exhaustion. "

Programmers don't dictate requirements... and in many shops they are even discouraged from questioning any requirements... but this anecdote points out something pervasively wrong.

My guess is that the technical aspects of the problem overwhelmed the practical aspects of the problem. Dealing with large numbers of users and high transaction rates consumed the intellectual bandwidth of the development and testing team.

Fear of the Unseen...

Many problems that businesses have with software seem to involve visibility. The role that specific software components play within an organization are often hidden, obscured, or just plain forgotten.

I have been in shops where software has been reliably clunking along for 20 years... faithfully executing night after night, 7 days a week, 52 weeks a year... for decades. Undoubtably, this software "keeps on ticking" because it is doing something useful for the business... but I also suspect that some of the things that the software is doing may no longer be necessary. In many IT shops there is a distinct "If it ain't broke don't fix it" mentality, and if you aren't sure you just leave things as they are.

My friend Si told me a story about an accounting package that was written many years ago (in the early 1960's) for a machine that has long since become extinct. Rather than rewrite the package when the company upgraded their hardware to the next generation, an emulator for the original hardware was obtained . Years later, when the company upgraded their hardware once again, they continued to run the package, on an emulator for the 2nd generation hardware that ran an emulator for the original hardware.

Si swears that this is a true story... and given the conservatism of a lot of organizations I have no reason to doubt him.

This anecdote relates an extreme case, but I doubt that it is unique. We keep doing things not just because we've always done them, but because we can't always "see" what's really going on. In general, we know what a package does, but we can't see its side effects and interactions with other software package. "Something else" may rely on our package, and there is no real way to know what will happen except to shut down our package and wait to see what happens. That's a scary proposition in a production environment.

Going back to Si's anecdote, continuing to use the legacy accounting package could be held up as a poster-child for software reuse. Did it really matter that the implementation details of the package were unknown as long as the package continued to perform as advertised?

Sound object-oriented engineering principles encourage "hiding things". Hiding implementation details behind published interfaces is essential when building any non-trivial system... When building the system, you really don't need to know how a function is implemented, you just want it to work as advertised... and apparently Si's accounting package did just that.

But my gut tells me that something's not quite right. We don't decouple implementation from interface solely for the benefit of those who consume our software... Interfaces are meant to benefit both parties. Our consumers don't have to worry if the implementation changes, and we don't have to worry about changing the implementation.

In Si's anecdote, the accounting package survived due to fear. Nobody understood the original code, so everybody was afraid to touch it. In a real sense the implementation was hidden (since it was written in an extinct assembly language).

I think we've got a visibility paradox. We need to hide implementation details behind interfaces, but at other times we need to know those very same implementation details.

Our challenge is to have it both ways. An application should never rely on the implementation details of its components... but we must be able to delve into those implementation details when necessary. When we need to upgrade hardware or operating systems, or when we need to diagnose and resolve performance issues, we need to know the details... or we may be forced into bizarre solutions like the one Si relates.

Kitchens and Fast Food Factories

Recently I've begun thinking that a Kitchen vs. Fast Food Factory analogy might teach us a bit about writing better software...

I'm always looking for good analogies: A good analogy is worth 1000 pictures (and since a picture is worth 1000 words, analogies must be worth a million words).

Kitchens and Fast Food Factories (like MacDonald's) are places where meals are prepared. Both contain all of the tools and ingredients needed to prepare meals, and both provide the space necessary to prepare meals. They share a lot in common, but they are also fundamentally different.

Kitchens support the ad-hoc creation of meals. A well stocked Kitchen enables a chef to prepare almost any meal. The only limits are the skills of the chef and the available ingredients. The quality of the meal is very dependent on the skill of the chef.

Fast Food Factories support the structured creation of meals. Each Fast Food Factory is optimized to produce specific meals, quickly, and in great quantities. The quality of the meal prepared in a Fast Food Factory has little to do with the skill of the operators. Meal quality is controlled by the quality of the ingredients and the process by which they are assembled.

I haven't done any surveys, but I suspect that people who really like to cook would rather do so in a Kitchen than in a Fast Food Factory.

Software comes in all sizes, shapes and flavors (so to speak)... Some software is "Kitchen-ish" and some is "Fast Food Factory-ish". Think Microsoft Office vs. Turbo Tax. Ad-Hoc creation vs. guidance through a Structured Process.

When gathering requirements from potential users, be very wary of the "dream kitchen scenario". People will often describe "dream kitchens" rather than the "fast food factory" that their business really needs. They will describe software with powerful features that can be used in any combination. They will describe software that is flexible enough to be used for all of the scenarios that they have experienced. Metaphorically speaking, they will describe the kind of stove, refrigerator and sink that they want, and they'll probably be very explicit about what these appliances should look like (brushed stainless steel, of course). Lost in all of these details may be the fact that they only cook burgers, and if they don't cook burgers faster than the competition they will go out of business.

I'd suggest that, regardless of requirements, most of us can get a good idea of what role the software will play in the business. If the software is destined to play a major role in an important business process (as most software is), then architect your software (as much as possible) to function as components within a larger process (that is likely to change). Back to the Fast Food Factory... there are many specialized components, but the interfaces are designed for movement. Each component accepts output from a previous component, and passes results on to a later component. Components themselves may be black boxes, but the connections between the components are highly visible. Traffic between components can be monitored, and if necessary rerouted should a change in process be necessary.

Why are we going?

Fabrizio is worried about where Java 7 is going and about the topics that the community perceives as the most important.

I share many of his concerns about where the language is going, but I am also wondering why the Java language is changing at all?

Are problems with Java itself prompting change?

Are external factors prompting changes to Java?

Is Java changing just to change?

I sincerly hope that the last possibility is not a big factor.

CDW's "Fred" vs. Microsoft's "Bill"

Read more at my other blog...

Human-Powered Web Services

As SOA has become a more mainstream IT concept... you might even say a more mundane IT concept... there has been a lot of thought put forth on the creation of Composite Applications.... collections of distinct Services that are orchestrated and choreographed together (using BPM technologies) to implement some "higher-level" business functionality.

Many of these Composite Applications need user-interfaces, just like "normal" applications, but fortunately the transition from building a UI on top of objects (often EJBs) to building a UI on top of Services (often Web Services) is generally not that hard for programmers to make. Perhaps the biggest adjustment is in moving from a world where pass-by-reference was possible to a message-oriented world where everything is pass-by-value... but that's not really much of an obstacle for good programmers.

A more subtle aspect of user-interfaces and Composite Applications becomes apparent when you start to consider the Services that make up the applications. Most of the folks that I talk with tend to think of Services as automatons... fully automated tasks carried out by machines. This is especially true when I use the term Web Services... Everybody knows that a Web Service has nothing to do with people, it's just a machine at the "other" end of the line.

I'm going to suggest that conceptually limiting Web Services to automatons is a mistake that has hampered our ability to benefit from all that SOA has to offer. Our shared belief that Web Services are "always" automatons has impacted our conception of Composite Applications and has even impacted the design of most of our development environments (IDEs).

That's a pretty strong statement, so I'd better try to explain myself. Perhaps an example is in order....

Let's say that you are building a Composite Application to process an Order of some sort. Also assume that your customers speak many languages, and that it's necessary to translate each order to a common language before it is processed. To make this process pretty darn simple, let's also assume that Services are available to translate the orders from one language to another. Piece of cake... just funnel the order through the Language Translation Service and you're done.

Any good Service-Oriented IDE (such as NetBeans with the Enterprise Pack ) can handle the above process with ease. The IDE's tools make it relatively simple to orchestrate the process using BPEL, and relatively simple to build a UI on top of the BPEL (it's a Web Service after all). In short-order, you've created your Composite Application and all is well in the world.

So where's the beef? What's wrong with this picture?

Nothing really... until you start to consider the creation of the Language Translation Service with your IDE. Our conception of Web Services as automatons causes few problems when consuming the Services, the problem becomes evident when creating them.

I picked Language Translation on purpose... It's hard. Go out to any of the free translation services, translate this page to another language and back again, and you will see what I mean. Language Translation (at this point in time) is better performed by a person than by a machine.

Here's the previous paragraph translated to Spanish and back to English:

Try building a Human-Powered Web Service with your IDE. You can do it, but it's tough. You're going to have to cobble together something that links together a human-oriented application with a Web Service, and it's probably not going to be pretty. This "ugliness" really shouldn't be a big surprise, because we've never thought of doing such a thing (maybe "never" is a bit strong... but not very often).

Now that I am spending much more time as a Business Process Guy, I'm finding the need for Human-Powered (Web) Services isn't rare at all. All of the good BPM suites (like Lombardi and Fuego) erase most of the distinctions between creating Human-Powered Services and creating Autonomous Services because most business processes are a mix of both types of Services.

Unfortunately, at this time there aren't widely-adopted standards for Human-Powered Services (HPS)... the BPM suites are proprietary and the concept of a "stand-alone" HPS seems alien. There's a good reason for that... when an HPS is invoked, the Human has to "know" that there is work to be done and that implies a notification mechanism like a task list or email.

I don't want to imply that it will be "easy" to come up with standards for Human-Powered Services... just look at all of the turmoil surrounding "BPEL for People"... but it is time for us to start addressing this class of Service in our IDEs. In this blog entry I have focused mostly on the creation of the HPS... but there are also some issues of consumption (people tend to be much slower than machines).

What it all really boils down to is wider awareness of Process-Oriented concerns... business processes are made up of automated and human-performed tasks, and we need to be able to implement both types of tasks in a manner that allows them to be consumed by a multitude of applications. That's what SOA was really all about in the first place.

Business Process Musings

For the past few months I've been working with a very polished Business Process Management (BPM) suite from Lombardi Software , and I have to say that I am as happy as a clam. I feel like I have discovered a tool that I've been missing for at least 20 years, maybe longer, and I'm delighted.

It's hard to explain BPM to those who haven't experienced it, and to complicate matters it seems that each BPM vendor defines the space a bit differently, but I think that the dawning availability of high quality BPM suites is going to have an impact on business programming that will be just as significant as Object-Oriented programming was to programming at large. Quality BPM suites will usher in an era of Process Driven Design, and the wide-spread adoption of that paradigm is going to lead to a renaissance in business process engineering.

Okay, so you are now thinking that I've found another shiny penny, and that I'm vaulting back into hyper-enthusiast mode... Well... Not really. This is pretty much the same song that I've been singing for the past few years, but a different verse.

Remember SOA (Service Oriented Architecture)? Remember how folks couldn't really grok the difference between Services and CORBA and EJBs?

The answer is surprisingly simple... There really isn't much difference between Services and CORBA and EJBs in terms of functionality. The difference is in terms of "composability", and that's where BPM tools are making the difference. BPM tools give you the ability to compose (in a very agile fashion) multi-party process-oriented applications that can incorporate Services.

At this point you may be thinking that I'm describing BPEL (the Business Process Execution Language), but BPEL's only a small subset of what BPM offers (BPEL doesn't even handle human interactions yet).

BPM suites allow you to create multi-party process-oriented applications from scratch, deploy them to production, and maintain them over the long haul. You begin by diagramming the business process using a graphical notation such as the Business Process Modeling Notation (BPMN). The resultant Business Process Diagram (BPD) captures the highest level requirements in an executable process definition... This is one of the great things about BPM, the mapping between the requirement and the implementation couldn't be more straight-forward. The BPD can be stepped through with the business folks ad-infinitum to make sure that it's really correct, and together you can add in all of the (business) exception flows and caveats until everyone is happy.

Meanwhile, the activities that make up the process have to be fleshed out in detail. Some activities will require human interaction, others will be fully automated. Some activities will leverage pre-existing services, others will require new services... Good BPM suites contain tools for creating UI's, constructing light-weight services, and connecting to existing services (Web Services, Java objects, databases, packaged applications like SAP, etc.)... Most of the BPM suites that I'm familiar with are Java EE based, so what you're getting is a process-oriented veneer on top of all the Java functionality that you know and love.

Once the activities have been fleshed out and tested, the resultant application can be deployed to a Process Execution Engine (PXE) and made available to the masses... just like a Java EE application. But unlike a generic Java EE application, the PXE's generally provide a great deal of support for process-level instrumentation, and this is where Business Process Engineering comes into play.

Software Engineers generally care about infrastructure metrics. How fast is a query? What's the latency of response time for an incoming message? How much space is left on the hard drive?

Business Process Engineers deal at a different level. How long does it take to process an order? Where is the bottleneck in the process?

A good BPM suite (which includes a good PXE) allows the Business engineer to ask these questions directly. Each process can be instrumented in a natural fashion to obtain the answers that the Business engineer needs. If you've ever worked in an IT department you've probably had to scour through log files to answer a Business question that you thought they'd never ask. You've probably also had to develop some sort of ad-hoc instrumentation in your applications to capture metrics that might be useful someday, but will most likely never be evaluated.

BPM suites go a long way towards curing those headaches for you by coupling straightforward process instrumentation with focused reporting tools. Drag a few instrumentation points onto your BPD, create a simple report, and now your Business Process Engineers have the data that they need to really tune their processes.

None of what I am describing is really new, but the combination of these features into a truly usable environment is something that I hadn't experienced before, and you are probably going to have to experience it for yourself to truly grok the value. Unfortunately the Lombardi tool that I am using has no community edition, but there are some pretty good alternatives out there to sink your teeth in. I haven't had a chance to use them yet, but Intalio's Open Source BPM and JBoss's jBPM both look promising (and you can try them for free).

If you are a nuts and bolts infrastructure guy, or a game designer/simulation god, then BPM probably won't be your cup of tea... but if you're a business programmer, BPM is probably going to make your job a lot more fun.

Open software pragmatism - Free (as in beer) isn't the point

Back in the mid-90's I was working on the user interface for a Windows desktop application that included a fairly sophisticated cross between a table and a tree component. We wanted to display a multi-column table of assets where each row was actually a summary of information; for example one column was the total value of the asset. Each row of the table could be "expanded" to list the details of all the transactions that were "rolled up" into the summary. You see similar components all over the place today.

Fortunately, even in the 90's we did not have to write this component from scratch. A commercial table/tree component was available (for a reasonable price), and we were able to purchase a source-code version that allowed us to modify the code to our hearts content. One huge advantage to having the source code of the table/tree component was our abilitiy to debug problems, and if the problem turned out to be in the table/tree component itself, we could actually fix the bug instead of having to work-around it.

The downside to having the source code came whenever an updated version of the table/tree was released. If there was a feature in the new version that we wanted to use, we'd have to reapply all of the enhancements that we'd made to the previouse version, and more annoyingly we would have to figure out if the bugs that we'd found in the older versions had been fixed (if not, we'd have to hope that our old fixes could be applied to the newer code base).

As I mentioned before, this was in the mid-90's. The Free Software Foundation was alive and well, but very focused on Gnu's Not Unix. I was working in the Wonderful World of Windows, where Open Source was yet to gain a foothold, and everything cost money: You paid for development tools, you paid for libraries and components, and you certainly paid for source code. Perhaps because of my youth and enthusiasm, paying for stuff didn't bother me very much. I remember that I would often buy a development tool*** that I wanted to use ... usually from Borland because they had great tools for a reasonable price... and then talk my boss into letting me use these tools at work. If I was lucky, I would get reimbursed, but that didn't very happen often, and I usually didn't mind. (*** Note that free development tools such as the Gnu C++ compiler and Emacs were available on Window at the time, but they just didn't have the polish of the tools that you paid for)

Paying For Stuff wasn't annoying; Persistently Unfixed Bugs were annoying. I remember being really pissed with the vendor of the commercial table/tree component because there was not an effective process for submitting bug fixes to the vendor (It was understandable that a reported bug might not make it into the next release... but not when you had sent them the fix). My colleagues and I became very intimate with the internal details of this component, because we were stressing its functionality a bit farther than it could go... and we often found (and fixed) bugs in the component long before the vendor knew they existed. Applying these patches over and over again to subsequent releases of the code base really "chapped my hide".

Life here in the 21st Century has certainly changed with respect to Paying For Stuff, especially with respect to source code. I've done no real survey, but I would be willing to bet that the source code for most of the frameworks, libraries and components that developers rely on today are readily available. We simply don't tolerate hidden code anymore: If I can't see your code, I'll use somebody else's code that I can see (whether or not I have any intention at all of actually looking at the code).

As the last bastions of "closed code" fall, such as Sun ovecoming its earlier reluctance to "Open Source" Java, I want to shout out a reminder:

Free (as in beer) isn't the point

Go back with me to the mid-90's and revisit the issues that we had with that table/tree code that we'd purchased: We were pissed that bugs that we had fixed ourselves never made it back into the official code base, and that we'd sometimes have to significantly mangle the code to add in our own enhancements. If there had been an effective process for getting bug fixes back into the code base, and if there had been an effective process for refactoring the code base to enable end-user enhancements, we'd have been tickled pink.

The same is true today. Allow us to get our fixes back into the code base, and pay attention to our requests for refactoring and API changes, or it's not going to make much difference that the code is now "Open Source".

Thoughts on "The Modular JRE" and Open Sourcing Java

David Herron posted a clarification of "what it means to be Java" on his blog, and the examples that he used got me thinking...

David made it clear that anyone can add whatever they like to their version of the JRE (Java Runtime Environment) and still call it Java... but if they leave anything out then it is most certainly not Java. The example he sited was the hypothetical incusion of SWT (the windowing toolkit used by Eclipse) in a version of the JRE. This version could still label itself as Java as long as AWT and Swing (the windowing toolkits in the Java specifications) are not excluded.

This makes sense to me... but I'm hoping that the folks who are opening Java also take another look at the basic definition of what must be in the JRE. Let me explain my concern...

Many Java applications (maybe even most) have no desktop-based user interface at all (they are browser-based web applications)... and if the adoption of Web Services and SOA continue we'll see more and more "headless" Java-implemented Services (Services that have no user interface at all). In a world where it is quite legitimate to have a large percentage of Java applications with zero need for any windowing toolkit, why carry around those toolkits in the JRE?

I know that code that isn't used doesn't really "cost" much, but let's assume that you are really into Grid computing, and you have thousands of nodes in your cluster... and each node has a JRE with unused windowing toolkits on it. Seems wasteful.

Windowing toolkits in the base JRE are fairly easy to throw stones at, but there are many other components that really should be optional. For an example, just take a look at the recent "discussions" on whether or not JavaDB should be included in the Java Developer Kit (I shudder to think of the threads that would be spawned if JavaDB is ever packed into the JRE).

My impression is that there is a large consensus that the JRE should be more modular, broken into logical chunks that are installed based on need. A modular JRE does pose some rather interesting technical challenges (to get the code that you need when you need it), but I had overlooked the challenge posed by the current definition of Java itself.

If I'm reading David right... a modular JRE wouldn't quite meet the current definition for "Java"... it's all or none. If I never install the "windowing-toolkit" chunk on my application servers, then they aren't really "Java" application servers.

Just something to think about...

Disconnected Browser-Centric Clients

There is a huge paradigm gap between writing a desktop application with something like Swing, and writing a browser-based application with something like Java Server Faces. Frameworks like NextApp's Echo2 go a long way towards narrowing the gap, but there are still underlying disconnects that just won't go away...

Just from the practical standpoint of learning how to program, this is a big deal.

I know that some folks wish that browser-based applications would disappear... but I think that adopting that credo would be a mistake. The "old school" desktop applications aren't truly suited to a mobile lifestyle where an individual may connect to the Web from a variety of devices. In a single day I might use my home computer, PDA, mobile phone, work computer, and public kiosk to access my applications and data.

That said, I must admit that most of the current crop of browser-based applications don't quite cut the mustard: If you can't connect to the Web, then you can't use your applications.

We need a blend... We need applications that can be accessed from any device connected to the Web, but with persistent components that reside on the devices that we actually own.

I'll use Google's Calendar to illustrate what I have in mind: I love having a calendar that I can access from any web connection (actually, it doesn't work from my PDA yet, but hopefully they are working on that). I also love the ability to share my calendar with others (particularly with my wife).

What I don't love is losing access to my appointments when I am not online.

I want a persistent component of my calendar on all of the devices that I own. I want my devices to "synchronize with the mother ship" when connected to the Web, updating themselves from a central data store, and passing along any appointments that I might have recorded while offline.

Fortunately, Google has thoughtfully provided a Web Service Interface to their Calendar, so it is quite possible to create a client application to satisfy my wants and needs... I can have a desktop application in addition to my browser-based application if I so choose.

The down side to dual applications is that there's something clunky about this approach...
Accessing a desktop application when not online, and a browser-based application when I am online seems rather like a kludge.

Call me crazy, but what I'd like would be to always start from my browser, type in or select a URL, and have the appropriate version of the application run... If I am online, give me access to the full blown web application. If I am offline, give me access to the persistent components on my local machine. Adam Bosworth has written extensively on the subject of disconnected web applications... but his solutions always seem to end up relying on making changes to the browsers themselves, and I just don't think that's likely given the vested interests of browser manufacturers.

Roshan Shrestha's article "Take Your Tomcat On The Road" gave me an idea for supporting disconnected web applications that does not require the support of browser manufacturers: Create a locally hosted web application to do your bidding.

In my Calendar example, write a locally hosted web application that interacts with the Google Calendar web service. To access this application, simply enter the proper URL in the browser. If the device is offline, the local web application displays the "disconnected client" interface... If the device is online, the local web application redirects the user to the "online client" interface provided by Google.

I might be the only person on the planet who finds this approach attractive... but then again maybe there are a lot of other odd people out there who want something similar.

The biggest obstacle that I see to this approach is the installation of the "disconnected client" on the local machine. Roshan has demonstrated that it's a breeze to bundle a fully functional web application in a neat little package... but how to get that package onto a user's devices?

Would it be possible to use Java Web Start to install something like Roshan's "Tomcat On The Road" package on a user's machine? I'm really not sure... but hopefully somebody out there can help me find out.

Continue Reading...

Why Use A Database Instead Of ____?

A recent blog entry by Simon Morris questions the usefulness of including a relational database (JavaDB) with the Standard Edition of the Java Development Kit (SE JDK). The JDK is primarily intended for the development of Desktop applications, and in Simon's words:

"most real desktop applications (browsers, players, word processors, video editors) are not database heavy, why is Java DB being included in the SE JDK?"

Let's take look at word processors: A very common business function for a word processor is to create a "form letter" and populate fields of the letter with data that comes from another source (sometimes a database, sometimes a flat file of some sort). Of course the word processor's author could come up with a custom mechanism for extracting data fields from a file... But if an RDBMS (Relational Database Management System) is used, much less custom code is required, and (much more importantly) the data will be stored in a format that makes it available to other applications.

Okay... So maybe you agree with me that storing data in a format that is accessible to many applications is a good idea, but why not use XML (eXtensible Markup Language) files instead of an RDBMS. XML files are very easy to parse, and they are very easy to extend over time.

True... But what if multiple applications need to be creating, updating and deleting data simultaneously?

All "real" Database Management Systems are designed from the ground up to handle simultaneous inserts, updates, and deletions. Options abound for managing simultaneous access to tables and records, and for handling collisions and potential deadlocks. Many people have worked for many years to fine tune these systems, and they work very, very well.

Okay... So maybe you are beginning to agree that an RDBMS is a good idea for inclusion in any development kit... but why JavaDB? It's not a "real" RDBMS. It's just a toy, and there are many, many alternatives.

Now we have reached an agreement of sorts. I don't really understand the merits of JavaDB over HSQLDB or any other contender... but I also have to admit that I really don't care all that much.

What is important to me is that an RDBMS is included (by default) in the development kit. Inclusion of something like JavaDB means that every single Java tutorial can assume the presence of an RDBMS. Every new programmer learning Java can painlessly learn to program using JDBC (Java Database Connectivity) and learn enough about SQL to keep them from being dangerous.

But wait... Isn't Java Object Oriented? Shouldn't Java developers be focused on using persistent objects rather than fields from a database?

I know that it's contrary to promote tables and fields over persistent objects, but in defense of this position I'd like to share with you some insights that Ken Orr (of Warnier-Orr diagram fame) shared with me (highly paraphrased below)...

"An object is just a single hierarchical view of the underlying data. With an RDBMS, you can support many views of the data... each of which is appropriate for the application that needs it. Constraining data to a single view (as an object) is robbing the data of some of its worth"

Data is often a company's true "treasure"... They slice it, they dice it, they analyze it right, left, up, and down. Reports are written against this data. Presentations are built from this data. Businesses literally live or die on their ability to leverage this data.

This is true whether you are writing a Browser-based application for a business, or whether you are writing a Desktop application for a business. Data is really important, and an RDBMS is a really good tool for handling data.

Continue Reading...

Off topic blog on Distracted Drivers...

If you have any thoughts on how Java might be used to help solve the "distracted driver" problem, please leave your comments here.

Thanks,

-JohnR

Why JMatter matters - a wake-up call for programmers

I am always interested in Eitan's activities, but jMatter really struck a chord when I read a bit about its background on the jMatter mailing list:

A small Austin software firm was "approached maybe a year ago by someone who wanted to develop a custom software application to aid him in his work."

"The customer was initially turned down."

"The problem was that the estimated amount of work to design and implement and deliver the solution approximated three man-months of software development. The customer's budget was nowhere near that."

"This customer recently contacted them again, coincidentally at a time where they became aware of the jMatter framework. I ended up contracting to do the job using jMatter. I built the entire application myself in approximately eight days. There were 2-3 follow-up incidents where small change requests or bug fixes were implemented (maybe 2-3 hrs each)."

"Today, this customer is using this custom solution to aid him in his work and apparently it has already saved him a considerable amount of time and effort"

What's not familiar is the outcome of Eitan's tale: The small budget customer gets a solution that he needs at a cost that he can afford. This outcome is what intrigues me about jMatter... Eitan was able to take a project that should have taken three man-months to complete, and he successfully implemented in 8 days (more or less).

This is a big deal if you are an independent software consultant... the number of potential clients on limited budgets far exceeds those with fat bank accounts, and the competition for the "well healed" clients is brutal. If you can find tools that make it profitable for you to service small accounts, you might do quite well for yourself...

But even if you aren't an independent or working for a small firm, tales like Eitan's ought to be a wakeup call: The "Custom Software" business is changing... Some clients have been paying far too much for the custom software that we've been writing for them, and they're probably about to figure that out.

Let's take a look at Eitan's numbers...

This example is hardly a scientific survey, but using these figures one could make the case that over 85% of the "custom" development effort that this client would have paid for (without jMatter) would have been used to implement infrastructure and functionality that really wasn't "custom" at all.

Of course jMatter is not appropriate for all custom software... nobody would suggest that... but many, many custom business applications have a great deal in common, and it is not unreasonable to suggest that a manageable set of tailored frameworks could be used to eliminate 80% of the effort necessary to write 80% of the "custom" applications that we are writing today (Yes, I made up the 80% figure... but it's probably in the ball-park).

This is why jMatter and frameworks like it should matter to all professional programmers... If custom software can be now be built for 20% of the effort that it once took, the entire cost structure of our industry is about to go bonkers.

Programmers in the US had to adjust when companies started offshoring software development to programmers who work for lower wages... Imagine the adjustment that we'll all have to make if projects that once paid our salaries for 3 months now only pay our salaries for a couple of weeks?

Please don't take this "wake-up call" the wrong way... these new developments in programmer productivity are just the latest in a long chain of improvements. Back in the 80s, I wrote business applications in assembly language... Nobody would pay me to do such a thing today.

As the tools evolved, I evolved. I think that the tools just evolved again ;-)

Objects are Nouns... Services are Verbs... SOA hinges on designing the right Verbs

I still find postings that express confusion about the relationship between object-oriented architectures and service-oriented architectures... so I would again like to offer my own $0.02 worth of insight...

Objects are Nouns; Services are Verbs

An Object is primarily a Thing that is manipulated (and is generally stateful), a Service is primarily an Action that is performed (and is generally stateless).

In an object-oriented architecture, the software components are primarily organized as entities (things) that are to be manipulated. These entities generally have relationships to other entities, and that leads to the emphasis on design artifacts such as UML class diagrams.

In a service-oriented architecture, the software components are primarily organized as tasks (actions) that are to be performed. These tasks are generally designed to function as steps in more complex processes, and that leads to the emphasis on design artifacts such as BPMN diagrams.

Businesses use software to automate business processes. Business processes do involve Nouns (Objects), but they are generally more concerned with Verbs (Services).

Let me explain: Most businesses process forms of one sort or another. In general, manipulation of the form (an object) is not the primary concern of the business; the primary concern of the business is to perform a set of tasks (services) based on the contents of the form.

If the software components are packaged as distinct services, the mapping between the business requirement to "process the form" and the software implementation of the process is relatively straight forward. This clean mapping between requirements and implementation results in solutions that can better respond to changing requirements over time (Trust me, all business requirements change over time).

Sun's Tim Bray has recently expressed his opinion that the term "SOA" is meaningless, and that he prefers the term "Web-style". With respect to Tim, I disagree with his opinion.

I do not agree with Tim that "Web-style" is a better term than "SOA".

I agree with Tim that the term SOA has:"become damaged, weakened by over hype, over use, over promise (and) under deliver", but unlike Tim, I think that I can "explain what the difference is between SOA and Web services". Web services are a protocol specific form of service. To implement an SOA you must eventually pick a protocol, but it needed be a Web oriented protocol.

Tim asks for "an explanation that's meaningful in terms a programmer can understand, so a programmer can go and build one of these things". Perhaps it is my own arrogance or naivete, but I think my explanation is a darn good start.

In my experiences with many developers, I have found that explaining how to design and build SOA solutions is not any more difficult or "verbose" than it was to explain how to design and build Object-Oriented solutions. I confess that I do resort to "paragraphs and paragraphs (of) prose", but everyone who knows me understands that I always resort to paragraphs and paragraphs of prose ;-)

But if Tim is right, and the term SOA has become a dead alabatross, then I'd like to offer an alternative to "Web-style": How about Process Oriented Architecture? Kind of has a nice ring to it; Don't you think?

Regardless of the acronym or term that we use to describe it, the point remains the same: If your primary task is to automate a business process, then you should package (most of) your software components as verbs... er, I mean services.

JSF and AJAX versus Swing

Evan Summers wrote a very good blog on "Swing versus everything else" a few days ago, and it started me thinking...

Many heated battles have been fought in the war between browser-based applications and "stand-alone" applications... and when a new skirmish flares up it often brings to mind lyrics written by (Country) Joe MacDonald back in the 60's:

"And it's one, two, three,
What are we fighting for?
Don't ask me, I don't give a damn,
Next stop is Vietnam;
And it's five, six, seven,
Open up the pearly gates,
Well there ain't no time to wonder why,
Whoopee! we're all gonna die."

The roots of this User Interface war go deep to an era long before Java existed... the war is really about the best way to implement the client aspects of client-server computing: Dumb-terminal versus Smart-terminal.

I've said it before, and I will say it again, a computer that is not regularly connected to the Internet is not of much use to most people. To quote Sun's motto: "The Network is the Computer"... and that makes the device that you sit in front of a glorified terminal.

At this point in time, I believe that the substance of the battle between JSF and Swing is mostly over the amount of functionality that an application possesses when it is not connected to The Network:

• JSF applications are powerless when The Network is absent
• Swing applications can operate on local data when The Network is absent
  

My belief that The Network is at the root of the war was reinforced on Wendesday when I got a sneak peak at Oracle's ADF Rich Internet Components at the Oracle Developer Day held here in Austin. The newest components are snazzy-looking, AJAX enabled, and with Tools like JDeveloper it is very easy to create non-trivial applications with them.

From a presentation on NetBeans and Matisse presented by Greg Sporar at Austin's JUG a few months ago, I also know that it's pretty easy to create non-trivial applications using Swing components.

If you will grant me the latitude of gross generalization, the biggest difference (from an architect's perspective) between a Swing application and a JSF application lies in where the bulk of the application logic is executed... on the client (Swing) or on the server (JSF).

No doubt we should quibble about the phrase "the bulk of the application logic"... It's quite possible to build a very "thin" Swing front-end on top of Web Services, and with more and more client side Javascript the AJAX components can seem to be pretty "thick". Add to this equation the use of Derby-in-a-browser to provide offline capabilities and I am not left with much of a distinction between Swing and JSF clients.

So what are we fighting for?

I think it is easier to say what we are fighting against... We are fighting against having to use wildly different programming styles in a single application. I say "We", because I think this is the goal of both the JSF and the Swing camps.

Swing advocates obviously like the ability to do everything in Java and they hate markup (except for Josh Marinacci and Ethan Nicholas).

JSF advocates are much more markup-tolerant, but they want to hide all the the markup ugliness (and Javascript) within nicely wrapped packages.

If you can get past these differences, then you will find that the client-side JSF event-handling-logic is not all that different than Swing's event handling logic.

So is either side ever going to "win"? I dearly hope that they both do... and I pray that both sides don't destroy each other or:

"Whoopee! we're all gonna die."

John Gage's Ad-Hoc Keynote - WCIT2006

Senator Kay Bailey Hutchinson (R. Texas) was not able to make it to Austin's WCIT2006 for her Friday Keynote Address (due to a late Senate vote), so John Gage (Chief Researcher and Vice President of the Science Office for Sun Microsystems) pitched in with a delightful Ad-Hoc presentation.

John had spoken at earlier sessions, and given that he has a lot to say he took full advantage of the opportunity to engage a larger audience (the hall was packed in anticipation of a speech by former US Secretary of State Colin Powell)... John easily filled his alloted time, and had to be gently ushered away from the microphone by WCIT2006 CEO Glyn Meek.

John took us on a journey to many of the countries represented at the convention by enlisting Google Earth. As he flew between continents, he pointed out and zoomed in on the homes of fellow presenters and on the future site of 2008's WCIT in Kuala Lampur... and then he demonstrated how the tool could be used to visualize important data... for example the locations of reported Avian Flu incidents.

If Avian Flu spreads as many fear, the first signs are going to be from the undeveloped nations, from the mostly remote rural areas where people live in closer proximity to animals... For our own sakes we need to build out the world's networking infrastructure - starting with the poorest countries first - to insure that we know what is going on in those locales... We need to hear the news of disease outbreaks as soon as possible to prevent the feared pandemic (a compelling argument).

John went on to demonstrate another wonderful tool from www.gapminder.org that can be used to visualize Human Development Trends from around the world over the last four decades. Words Cannot Begin To Describe This Tool --- VISIT THE SITE AND SPEND A FEW HOURS EXPLORING ON YOUR OWN!

Pardon the dramatic all caps of the previous sentence... but you really ought to check this tool out... By graphing Child Survival Rates and GDP per capita income for regions (and individual countries), you can visualize dramatic trends that have taken place over the last several years. You can see countries that were once poor with high child mortality rates blossom in both wealth and health... and you can also see countries where wealth has increased, but health has not.

John makes a compelling point that tools like this can be used to strip away deciet and expose the truth... it is painfully clear which countries have successful health/wealth policies, and which do not. Knowledge (not raw information) is power, and gapminder's tools help transform raw information into knowledge that people and governments can use to the benefit of all...

John's passion for ICT (Information and Communication Technology) as a tool for a better world is contagious, and nobody seemed to mind that he over-ran his allotted time slot... We all wish he could have spoken longer, and with respect to Senator Hutchinson... I was kind of glad that she missed her plane.

Thanks John... You've helped rekindle hope that ICT really can make a difference.

Continue Reading...

Security and Privacy - WCIT2006

One of the three focuses of Austin's WCIT2006 is Privacy & Security, and quite by coincidence I spent Thursday volunteering with the Conference Security Team.

I snapped this picture on the way into the Austin Convention Center this morning: The row of police motorcycles stretching down 4^th Street was quite impressive... and it is indicative of the heightened sense of security at events in the US since 9/11.

All of the volunteers for this year's event had to undergo background checks by the FBI... No exceptions. That's a really harsh requirement when you are so reliant on volunteers to conduct business... it was impossible to accept any of the many last minute offers to help.

Privacy and Security are inextricably linked. You cannot have true security unless you know who you are dealing with, and that makes it impossible for anyone to be truly anonymous.

My sense is that we in the US are alone in our stubborn insistence on anonymity. In Malaysia all citizens have been required to carry identification papers since the nation's independence, and as technology improves they have constantly upgraded these ID cards. I was told that the Malaysian smart-ID card has been adopted by nations across the globe.

Our US forms of ID are getting better, but we still fight the establishment of a National ID card. Instead, we complicate the task of identity documents by mandating that each State upgrade their own driver's licenses (the Real ID act). To me, this seems like a lot of smoke and mirrors to preserve a fictional concept instead of meeting our real ID needs.

Security at the conference is pretty tight (we have many dignitaries attending), but it is still dependent on a lot of people standing around and looking at badges. I believe there were plans at one time to set up RFID readers for the badges, but it was impractical for some reason... so we rely on people.

I must say that the reliance on people to check badges was a boon for me: I love to watch people, and standing at the escalator in my "official" staff T-shirt (black, of course) gave me a legitimate excuse to stare at individuals as they walked by. I did not get to hear any of the great keynote sessions, but I did get to have conversations with several interesting attendees.

Of course, this points out why people should not do the task that I was performing. I was diligent in my efforts to check badges, but I was also easily distracted by interesting people (and as my wife knows... I am guilty of looking at pretty women). Perhaps one of the biggest distractions was the incredibly cute bomb-sniffing dog that was working the floor. Wherever the dog went, a crowd gathered... all focused on the dog (including members of our police department).

Even when I was truly focused on the badges, I was relying on color coding... if the color was right I let it pass. I could not check the biometric information on the badges (the picture) to verify that the badge really belonged to the person who was wearing it, and truth be told someone could have easily used a colored piece of paper to deceive me.

Obviously for real security at our conference we would need something like the technology in the Tom Cruise movie "Minority Report" (retinal scanners are pervasive, and identify you wherever you go). We would have to sacrifice privacy for security: Is the price of real security worth the benefit?

Maybe security is worth the loss of privacy, maybe it isn't... and that is one of the topics that the World Congress of IT is discussing in Austin this week.

Continue Reading...

Exchanging Innovative Ideas - WCIT2006

My memories of Tuesday's WCIT2006 Innovation Exchange are a bit of a blur, but it sure was fun. I volunteered to help out, and was assigned to help usher speakers to and from the podium... We started at 8:00 am, and ran non-stop until 6:00 pm... 17 speakers from Texas, Malaysia, Australia, Korea, Taiwan, Cambodia, Australia, Canada, and Mexico... and that was in only one of three meeting halls.

The Innovation Exchange was coordinated by Rebecca Judis... who volunteered for WCIT2006 last year but ended up as a Vice President for the convention ( you should always be careful what you volunteer for... it can end up taking over your life).

The pattern for the Innovation Exchange was the "Venture Capital Pitch"... 25 minutes to sell yourself and your idea to potential investors or partners. My meeting hall was filled with a mix of governments and companies... come and do business in our country, and come do business with my company.

I learned a great deal... Malaysia is like Silicon Valley but with Hawaii's climate; Koreans work too many hours a week, but that's changing; Cambodia is slowly but surely recovering from the Khmer Rouge; Mexico graduates 34,000 programmers a year. I took notes, but the sessions have still blended in my little gray cells, so I appologize in advance for any mistakes.

Some of the business pitches really roped me in... these were marketing pitches, not technical pitches... so they really focused in on relevence: Why is this technology useful? What problem will this software/hardware solve?

Joel Trammell did a great job of explaining NetQOS by using an analogy of "The mayor and city traffic": When a reporter asks the mayor "How's traffic today?" the mayor needs to be able to say "Pretty good" or "Really awful", and have a short justification... Outlining all the road closures and construction delays is overkill... the mayor needs something simple like transit time: "Traffic is pretty good, the average commute today is only 20 minutes".
NetQOS does something like this for networks... it can tell you the average transit times for messages in the network, and it can tell you where the time is being spent in your infrastructure.

Mark Spiloto pitched his company iKnowWare (pronounced "I know where")... a device agnostic view of what you need to know based on business rules, privledges and personalized views. Mark had a side-splitting video for their product... hopefully he will post it on iKnowWare's web site.

José Luque of Merkatum blew me away with their facial recognition system. His small startup created a database for the state of Florida that contains all driver license photos (and other biometric information)... it is currently the largest facial recognition database in the world, and they can match faces to photos in 4 seconds. What intrigued me by the pitch was Merkatum's intent to offer biometric recognition as a web service. If they get the funding to pull this off, they will be able to offer a very low cost solution to any company or agency that has been mandated to provide biometric verification of identity.

I had helped José get his laptop ready for the presentation the day before. He is a very charming person, and we chatted a bit about identify theft... we have both been victims. Although there are privacy concerns, the ability to more reliably prove that "I am me" before executing a transaction is very appealing (I hope these guys get rich).

Wayne Karpov of YottaYotta tailored his pitch to the convention's topic of IT and Health Care. Wayne made a very compelling argument that Health Care costs can be reduced by managing many hospitals as one... and that is an IT problem. If the databases of many hospitals could appear to be one giant database, then it would be fairly easy to write applications to manage across the multiple entities. That is essentially what YottaYotta's product does: High Performance, Resilient Global Data Sharing.

Wayne also clued us in on what a Yotta is... it doesn't have anything to do with Jerry Sienfeld. A Yotta (10²⁴) is approximately the number of snowflakes that fall on Canada in a calendar year (That's a yotta snowflakes!).

James Balestra of Safefreight showed off a nify "brick" that contains a GPS receiver and a tracking transmitter that is smart enough to switch between cell and satellite signals (satellite is way more expensive to use than cell). The brick can be attached to a truck, trailer, shipping container (you name it) and transmits information back to the company's home base. Various sensors are available (temperature, motion, etc.) and Safefreight supplies easy to use software that makes it very easy to generate views, reports, and exceptions. For example, the brick can generate an alert if its temperature exceeds a range, or if the trailer goes outside a pre-determined area.

Peter Neve of Fieldworker pitched his company's device agnostic software development platform for mobile workers... He told us that Fieldworker had origi