John Reynolds's Blog

Community: Java Tools Archives

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.

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...

Ken Orr's advice to Java programmers (and the secrets of writing good software)

In the 1970's, Ken Orr expanded on Jean-Dominique Warnier's methodology to develop Data Structured System Design (DSSD).

DSSD is primarilly a data driven methodology for designing systems with (gasp!) direct user involvement. Through the use logic and data charts that are easily explained to the users, the requirements of a project are collaboratively captured in a format from which much of the code and data schemas can be generated... This may sound like "no big deal" today, but Ken published these techniques in his book Structured Systems Development in 1977.

Ever the opportunist, I cornered Ken during lunch one day to pump him for insights (as fodder for this blog)...

John: "Ken... What advice would you give Java programmers?"

Ken Orr: "Don't define yourself as Java programmers."

Being a good programmer really has very little to do with the languages that you know... Being a good programmer is mostly dependent on the methodologies that you know and on how you employ those methodologies.

Good process design skills and good data modelling skills are the foundations for being a good programmer.

Process design and data modelling are best done in collaboration with your users (Don't confuse this with letting the users design the process or model the data, both require considerable skills that aren't easily mastered). Ken offered this advice when developing a new design with a client:

It is better to be clearly wrong than to be obscurely right.

If you have something wrong in your design, and it is clearly wrong, then your client will point it out and you can correct it. If the design is obscure, the client may never know if it is right or if it is wrong.

Tools are the key for communicating with your clients... processes (and data) are expressed well through pictures (flow charts, etc.), and you are missing the boat if you don't adopt tools that map these pictures to code.

I got the feeling that Ken's biggest regret is that Computer Aided Software Engineering (CASE) seems to have been on hiatus for most of the 90's and the first years of this century. Model Driven Architecture is surely a form of CASE, but Ken feels that the focus isn't quite right.

UML was developed to meet the design needs of programmers. We need tools focussed on meeting the design needs of users.

This led us into a discussion of SOA and BPEL. Ken is very "hype-sensitive", and cautions that SOA must be understood before you take the plunge.

One of the most promising aspects of SOA is that it brings the art of process design back into focus. In many cases, each service can serve as a step in a process, and BPEL can be used to describe the process itself.

Ken's parting advice was perhaps the most important thing to remember...

Master more than one design/programming paradigm.

Ken gave the example of AOP vs. OOP. Objects are very good at solving "vertical" problems... Hierarchies of relationships being the most common. Aspects are very good at solving "horizontal" problems... Cross-cutting concerns require thinking beyond object boundaries.

I suspect this is why Ken has never become too old to program. By mastering the basics of data modeling and process design, and by mastering newer paradigms as they are developed, Ken has remained a vibrant force in the programming world.

I don't want to make Ken blush, but in my book he's a darn good role model.

Continue Reading...

Software for Business People (like my dad)

From a "40,000 foot view" of the business perspective, very little has changed in the world of credit unions. Computers have enabled process automation, and that has made it much easier for folks like my dad to process transactions. Computing interest accruals is no longer a scary proposition. Everything happens much faster, and fewer staff members are needed, but the basics of the business are still about the same.

Every business involves a collection of processes that result in services or products that are delivered to customers and business partners. As conditions change, the processes need to change or the business suffers (or fails). Computers and software have enabled the automation of these processes… but they generally have not significantly altered these processes (unless automation by itself enabled a better process).

Processes are composed of events, tasks and decision points. Execution of one or more tasks leads to a decision point, the outcome of which leads to the execution of more tasks (or the completion of the process). As with my father’s process, we’d like to be able to “hire more workers” to perform these tasks if our business grows (and we’d like to be able to “lay off workers” if the business slows). Said another way, we want processes that scale well… as the business grows we should be able to add hardware to keep pace without having to change our software.

We also want processes that can be easily changed. If a new task is required, or an existing task is no longer needed, or the criteria for making a flow decision changes, we want to be able to easily implement the changes.

Java and the JVM clearly play a huge role in crafting the infrastructure underlying "Business Process Environments". With the combination of Java-based application servers, messaging systems, user interface components, database support, rules engines, identity and security solutions, enterprise service busses, etc. the Java ecosystem is by far the best choice as the basis for solutions.

To capitalize on Java's strengths, we need to step back into the shoes of those pre-computer business folks (like my dad) and consider what we need to provide to make all of this "stuff" really work for them.

Back before computers, you could sit in an office and observe the business processes. The process flow and process steps could be easily monitored and analyzed. The need to modify the flow, or to improve the efficiency of a specific task was something the business owner could easily discern.

From this perspective, you can probably understand why I am interested in languages like BPEL, and in the SOA design paradigm. The tasks and decision points that make up processes can be mapped very closely onto Services and BPEL orchestration logic.

BPEL is far from perfect, and the use of Services (particularly those with XML/HTTP interfaces) adds overhead, but the paradigm is the right one for many businesses. I’m comfortable to predict that better “process oriented” languages will be written, the performance overhead associated with using Services will be lessened, and the ESBs will become a whole lot more capable.

The NetBeans 5.5 Orchestration Designer is very cool, but it is only the tip of the iceberg. We should soon see tools that let someone who really understands a business (like my dad) make (appropriate) process changes without having to involve a programmer (To use a car analogy: “real” programmers will build and maintain cars, but business people will be able to tune the engines.)

If my dad were still with us, he'd probably still be hesitant to give up his paper records... but in the near future I'll bet that we could win him over ;-)

Continue Reading...

Longing for an Integrated Maintenance Environment

We are blessed with many great IDE choices for developing our code... and now we're beginning to see glimpses environments that will help us maintain deployed applications

When the dot.com boom went bust, I was fortunate enough to land a job as an enterprise architect in the development and production support group of a mid-sized corporation. After a career in R&D, I found myself in a more typical IT environment where keeping things running was way more important than implementing new features.

This change in perspective from R&D to IT was a very good thing for me. After years of delivering solutions to customers and moving on to the next challenge, I was now the producer, consumer and supporter of my own team's creations. I now had to "eat my own dog food" in a production environment (24x7x365).

When you really have to live with (and support) your own products, your perspective on what is important changes.

For the most part, business applications are conceptually simple. You present a form to a user, validate the responses, and process the request. It's hard to conceive what could go wrong after deploying such Simple Business Applications^TM, but inevitably Murphy's Law kicks in at 2 a.m. during peak processing season.

Another common factor of Simple Business Applications^TM is perpetual change. SBA's are living and breathing entities that evolve over time: Fields get added, fields get deleted, validation rules change. Edicts from governing agencies impose new constraints. Changing business partnerships impact workflow. Nothing is truly static.

Add to the nature of SBA's the inevitability of staff rollover (developer's tend to change jobs frequently), and you start to place a premium on code that is robust, easy to fix and easy to learn.

Continue Reading...

This work is licensed under a Creative Commons License.