John Reynolds's Blog

Community: Java Enterprise Archives

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.

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

The Era of Process-Centric Design

If you follow my postings, then you won't be surprised to learn that I think we are at the dawn of a new era in programming. As with all previous eras... nothing is really new, it's just a point in time where existing good ideas rapidly ascend to a pervasive level of acceptance.

During the Object-Oriented Era, encapsulation, polymorphism, inheritance and reuse were king.... all excellent ideas... But not enough to insure the creation of agile applications... applications that can easily be adapted to meet changing requirements.

Quite frankly, adapting to changing requirements is tough and unless you set some limits and constraints it's never going to get easier... and that's where Process-Centric design comes in.

On our desktops, most of the applications that we know and love are not process-centric. Our word processors, spreadsheets, paint programs and games are marvels of ad-hoc creation where our own whims and preferences guide composition rather than any pre-ordained process. The Object-Oriented paradigm was perfect for creating these sorts of applications, because the OO paradigm sets very few constraints on the developer. Imagination and creativity are the OO developers only limitations.

Imagination and creativity are wonderful things... but a huge percentage of the applications that the world needs are not concerned with creativity and imagination... they are concerned with implementing mundane processes.

Implementing processes within the guidelines OO paradigm is not by itself particularly difficult to do... but the flexibility of OO does not force the developer to implement the process in a manner that will make it relatively easy to modify the process in the future.

Processes constantly change. As businesses grow, as business conditions change, as the whims of the population at large ebb and flow... processes need to change, and the applications that implement the processes are often the limiting factor in how quickly the processes can change.

Get a group of Java EE architects in a room, not the R&D infrastructure and product guys, but the ones who build applications for business groups, and listen to their war stories. We all seem to have the same story about the project from hell which required each developer to know half a dozen diverse technologies to simply modify a screen... JSP or JSF (with embedded AJAX) on top of Struts (but we're migrating to Spring) on top of EJBs on top of a Relational DB (except for the part that uses Hibernate) and the use of JMS at one point and Web Services at another... And by all means don't forget the custom rules-engine and half-a-dozen XML-to-Java-to-SQL libraries.

We've all implemented scores of business processes, but we've implemented them as a loose confederation of somewhat related "point" applications that each implement some aspect of the process (with ad-hoc mechanisms for passing information and process flow), or we have implemented them as uber-monolithic behemoths that are a mess to maintain.

That's where the Process-Centric paradigm "comes to the rescue". It's not a general purpose paradigm, like OO, but it's just as significant. The Process-Centric paradigm imposes order. It is a domain-specific paradigm that first and foremost establishes the Process as the leader. A project may still incorporate diverse technologies, but those technologies have to comply to the dictates of a Process-Centric architecture. If you won't play by the rules, then you can't play.

In the Process-Centric paradigm the Process Definition is decoupled from the Activities that are brought together to implement the Process. Communication between the Process and the Activities, and between the Activities themselves, is through well defined message-oriented interfaces. In essence, the activities are implemented as Services (as in SOA)... but some of the Services are automated, and others are human-powered. Once in the realm of Service implementation, programmer imagination and creativity can once again assert themselves to perform the task in the optimum manner... as long as this creativity doesn't try to short-circuit the process framework.

The end-result should be truly process-centric implementations that are primed for the inevitable process level changes. The programmers do give up significant freedoms, but they end up with fewer hassles down the road, and probably a much improved relationship with their business colleagues.

Both Business and IT folks are tired of the status quo where each side feels besieged by the other... By our very natures there will always be a disconnect between the two sides (we're very different types of people) , but hopefully by introducing an intermediary that we both understand (the process definition) life in the Process-Centric era will be better for all of us.

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.

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

Is the End of Tiered-Based Computing in Sight?

This morning I came across a whitepaper from GigaSpaces entitled: Space-Based Architecture and The End of Tier-based Computing

Perhaps the most widely adopted style of software architecture is the N-Tier architecture... the separation of concerns based on stacked tiers of functionality. The "Three-Tier" architecture is perhaps the best known N-Tier approach, with functionality separated into Presentation Logic, Business Logic, and Data Access Logic.

The premise put forward by GigaSpaces is that N-Tier solutions are hitting a wall in terms of scalablity, or more specifically that the increasingly complicated schemes necessary to scale an N-Tier solution are hitting a roadblock.

The basic approach to scaling an N-Tier solution is to deploy multiple instances of any Tier that is having trouble meeting the necessary performance goals. For example, if the EJBs in your Business tier can't keep up with the requests from your Presentation tier, then deploy copies of the EJBs on additional servers.

This approach to scaling an N-Tier application works pretty well unless you need to deploy many copies of your Business tier... the middleware necessary to deploy the EJBs and to load balance requests becomes increasingly complicated, not to mention the overhead incurred when sending messages to remote tiers.

GigaSpace suggests a different approach to scaling, which they have christened Space-Based Architecture:

"Space-Based Architecture (SBA) represents a new model that combines distributed caching ("Data Grid"), content-based messaging ("Messaging Grid") and parallel processing ("Processing Grid") for transforming existing tier-based applications into linear, dynamically scalable services. These new middleware components are implemented on top of a distributed shared memory space that provides common clustering, high availability, location transparency and consistency services across all tiers."

Radically simplifying SBA (you really ought to read the whitepaper), the gist seems to be that tiers are not deployed separately. The tiers required to process the application logic are grouped into a single logical processing unit, and scaling is achieved by running multiple instances of those units on multiple machines. To contrast this with the typical approach to scaling an N-Tier application, instead of creating multiple instances of the tiers, the approach is to create multiple instances of the application:

"The power of spaces comes from not having to separate various parts of an application into discrete physical runtimes — and then wiring those together in complex, hard-to-scale, and performance-consuming tangles of middleware. A space doesn’t care if an application has been “tiered.” Whether it has or not, the same program code will instantiate multiple times on the same machine or on multiple machines automatically — and even dynamically - in response to runtime parameters like CPU utilization." - Nati Shalom - CTO, GigaSpaces Technologies

So what do you think? Is Space Based Architecture and the emergence of Grids and Service-Oriented Architecture going to change the way most software architects approach their designs... or is this just a niche that won't make much of an impact?

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

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

Is an Enterprise Service Bus (ESB) appropriate for volume-performance critical consumer applications?

"In researching esb direction, I'm trying to assess if a "service bus" is a just another service 'on the side' of the primary services, to be used when needed, like UDDI, or if it will become a physical mediator of all service consumer-provider conversations. I ask because I'm trying to visualise what to do when we have high volume-performance critical consumer applications (such as in a financial institution) who have well defined providers and don't need externalized orchestration, transformation or even routing and do not want to to incur the overhead or support of additional mediation tiers. So will the ESB concept become mediation-integration fabric, like DNS, or will it become an application tier that must be managed and accounted for in a queuing/performance analysis? Any thoughts in this space are appreciated "

I believe the value proposition for an ESB drops considerably unless it is the mediator for all service consumer-provider conversations. The advantage of an ESB over point-to-point service invocations is mostly about managing services across the enterprise. If "rogue applications" bypass the service bus, you will lose much of its value.

At the heart of cparziale's question is the gnawing concern:

"We do not want to incur the overhead or support of additional mediation tiers."

What additional overhead (latency) is incurred by invoking a service via an ESB versus invoking it directly?

There are many factors to consider beyond this concern to determine whether or not an ESB is appropriate for your company, but we must still answer this question as best we can.

The answer will depend on the architecture of the specific ESB, but I believe that it is quite possible that the additional overhead could be quite low.

An ESB allows you to abstract the address of the service endpoint that you wish to invoke. To make this work, the ESB has to map the logical address of the service to a “physical” address. Presumably, a service registry (akin to UDDI) will be used to look up the “physical” address. Looking up the address each time a specific consumer accesses a service could be costly, but if the consumer’s ESB "agent" caches "physical" addresses the overhead could be quite low… it all depends on the implementation of the ESB itself (Check out the links to various ESB implementations at the end of this blog entry).

Tha value of an ESB comes into play when you consider the burden that would be placed on individual service consumers if the ESB was not there... so we have to look at the benefits that the ESB provides and decide whether or not we need them.

One benefit of an ESB is the aforementioned abstraction of the "physical" address. If the location of a service moves, or if a new version of a service becomes available, the consumers of the service will not have to be modified. You could of course build this logic into the service consumer itself, but imagine where that leads.

An ESB could also be a mechanism for providing scalability and load balancing. Assume that overall performance could be enhanced by instantiating multiple copies of a specific service: The ESB could function as a load balancer, hiding from service consumers any knowledge that multiple service instances exist. Of course you could accomplish the same thing by hosting a service on a clustered server, but the ESB offers the promise of creating service instances "on demand" if coupled with the appropriate provisioning software.

Some ESB implementation provide these capabilities, but others certainly do not, and it is very important for us to ask these questions before commiting ourselves. If "high volume-performance critical consumer applications" are a part of our enterprise, then we'd better be very sure that the ESB that we adopt is up to the task... Ask the right questions early, or we could end up very disappointed.

Continue Reading...

Service Oriented Mashups

I came across this quote recently:

"What programmers in a hundred years will be looking for, most of all, is a language where you can throw together an unbelievably inefficient version 1 of a program with the least possible effort." Paul Graham

"We know we don't have a corner on creativity. There are creative people all around the world, hundreds of millions of them, and they are going to think of things to do with our basic platform that we didn't think of." Vint Cerf

Perhaps that is true for the moment, but the climate for "business oriented" mashups is about to get a lot more interesting...

AJAX does a fair job of cobbling services together on a web page, but what about cobbling together services into long running processes? Tools for orchestrating services have been around for a few years, but just as it took Google Maps to propel XmlHttpRequest into the limelight, we haven't really seen Service Orchestration take off yet.

Free orchestration tools like NeBeans 5.5 may just change that.

NetBeans 5.5 "out of the box" integrates the PXE BPEL engine and a Visual Orchestration Designer, dramatically lowering the "barrier to entry" for anyone who wants to experiment with composite service oriented applications.

I have been a proponent of Process Driven Design for quite some time, but until now it has always been quite a challenge for anyone to get started; too many parts to download and install. With NetBeans 5.5, getting started will almost be child's play... In a single (free) IDE you will be able to create Service Endpoints and Orchestrate them into long running processes (Oracle's BPEL Designer for Eclipse is similar, but has a few strings).

What this means to my fellow Service Oriented Architects is that your services are about to get a whole lot more accessible. "Power Users" within your own company are about to discover the bounty that you have provided, and just as Google never dreamed what the public would do with their maps, you are about to discover that your own services can be "mashed up" in ways that you never imagined.

Let the games begin ;-)

Continue Reading...

Service Oriented Architects

In his XML Annoynaces blog, Micah Dubinko offers his perspective on software architecture and architects:

"It goes without saying that a major development project should have a solid architect at the core. A good architect needs to be able to separate personal preferences and prejudices from legitimate good design points--in other words, get the focus right. A concrete measure of an architect is whether outside groups--even ones that wouldn't normally be directly involved--are able to understand and accept the architecture. There will be times where it's just not possible to please everyone to the level of consensus, but still it provides a measuring rod against which to evaluate a design (or a designer)."

If you work with an IT group, you (like me) are probably involved in some sort of Service Oriented Architecture discovery or implementation project; Gartner predicts that SOA will provide the basis for 80 percent of development projects by 2008.

Given this huge trend towards SOA, we really need Service Oriented Architects who can "get the focus right".

Reuse is an often mentioned benefit of SOA, but I believe that SOA's key benefit is the closer mapping between business processes and the implementation. SOA meshes perfectly with Process Driven Design.

Many Object Oriented (Jave and C++) projects have great technical architectures, but the business process implementation ends up scattered across many modules and hidden in the code. When a business process changes (and they often do) it is quite often difficult (or at least tedious) to implement and deploy the process oriented changes: Not exactly what business wants.

I don't know why this happens, but I suspect a subtle impedance mis-match between form (architectural style) and function (what the program is meant to do). Perhaps Object Oriented architects tend to focus on UML Class Diagrams more than on UML Activity Diagrams?

Unlike Object-Oriented design, SOA is tailored to solve problems in a specific domain. As Miko Matsumura puts it:

"there are nearly an infinite number of software programming problems—game programming, graphics, engineering, mathematics, statistical modeling, you name it. The SOA that is getting people all hot and bothered isn't particularly interesting as a solution for all of these other problems. SOA is for business."

If this begins to sound a lot more like a Business Architect than a Technical Architect... I've made my point.

Continue Reading...

SOA/ESB Level Set

	This figure shows the basis of an application developed using SOA principles and an ESB. Specific services are plugged into the bus, making them available to any application.
The service bus is responsible for routing messages to and from each service, eliminating the problems associated with "point-to-point" programming. Many ESBs are built on top of reliable messaging technologies. Messages are often XML based, but some ESBs allow for multiple protocols and formats. Applications are composed by developing driver programs that orchestrate the available services. Languages such as BPEL are tailored for writing these "driver" programs. Any number of "driver" programs can be written to utilize the services on the bus.
	If the application requires a user interface it is generally bolted on to the driver program.
Any user interface technology can be used; Rich Interfaces using Swing, Browser Interfaces using JSF and/or AJAX.
	If the application requires an external interface to the world beyond the service bus, those interfaces are also generally bolted on to the driver program.
Although it is certainly possible to expose all of the services to the outside world, that is usually not desirable. Generally only "composite services" that represent a service offered to a business partner will be exposed. Before exposing any service to the outside world, security issues must be addressed.
	Legacy programs are added to the mix by creating custom “service adaptors” between the legacy code and the service bus.
The success of integrating any legacy asset into the mix is related to the difficulty of crafting an adaptor (a.k.a. connector) for that asset. If the adaptor is fairly straight-forward, successful integration is more likely. If the adaptor is convoluted, only minimal success is likely. Although reuse of legacy assets is touted as a major SOA selling point, in reality many legacy assets will require refactoring to be of much use. The real payoff is adopting a style of programming that will make new services much easier to reuse later.
	The services that are plugged into the bus should be loosely coupled. Invoking one service should ideally have no side effect on other services. Care must be taken if the services directly access a shared database.
If services share records in a common database, they are coupled in a manor that may not be obvious to the author of the driver program. "Hidden" coupling in an underlying database can be a real problem. When possible, services should be stateless and operate only on the documents that are passed to them.
	To avoid hidden database coupling, some vendors recommend plugging a data service into the service bus.
The primary concern with the data access service approach is the performance issue associated with accessing all data through the bus. The use of data access services has let to several related ideas, such as using Service Data Objects to pass working data between services.

Please let me know what else you think I should add...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pleasant dreams indeed ;-)

Form Validation in an SOA context

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

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

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

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

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

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

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

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

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

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

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

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

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

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

How Beans side-tracked Enterprise Java

My enthusiasm for Java took a distinct nose dive the first time I encountered the implementation details for the dreaded Enterprise Java Bean. It was quite a shock, and I did everything that I could to avoid using them. Now that EJB3 has significantly lessened the learning curve, many of my initial complaints have been addressed, but there's still something not-quite-right.

Beans?

Java Bean was a cute pun. What better name for a nice little package of Java functionality; but when you look at the Sun's definition for Java Bean, it becomes pretty clear that the original analogy didn't anticipate Enterprise Java.

From Greg Voss's Java Bean tutorial:

"A Java Bean is a reusable software component that can be visually manipulated in builder tools."

If the word "Service" had been used instead of the word "Bean", J2EE would have made more sense.

Think about it; the original EJBs only had Remote Interfaces. In the original EJB model, Entity Beans only appeared as an afterthought. When you use the word "Bean" this makes no sense. When you use the word "Service" it makes perfect sense.

The result of this poor word choice may have been five years of arguing about POJOs and misusing EJBs (both Entity and Session).

EJB3 goes a long way towards erasing the differences between EJBs and POJOs, and that is definitely a good thing in terms of simplifying our programming model, but are we still impeding ourselves with our own terminology?

Most EJBs, POJO based or not, are not really Enterprise in scope. Most EJBs are tightly coupled to specific applications and live within the same JVM. The term is still causing confusion.

The term "Enterprise" is a natural companion for the term "Remote". If something is useful across the Enterprise, then it probably has a remote interface. Think Jini. Think Web Services. Those are the real Enterprise aspects of Java

SOA: Real Meat, and Potatoes too

The answer probably requires a change of perspective. Jame's falls into the same trap that I fell in... SOA isn't really about a programming paradigm, it's about a product paradigm.

Let me rush to explain....

To programmers SOA looks a lot like OOP (especially a lot like OOP as promoted by the SmallTalk language). Clearly defined interfaces, message oriented invocation, etc. What's the difference?

To product managers SOA looks only vaguely like OOP. SOA is about composing solutions from mostly pre-existing business services (Pay attention to the business services part).

SOA is about Meat and Potatoes programming (programming to pay the bills). It's not really sexy, and it's not really about anything new.

Most companies already have a lot of legacy assets. They are not very interested in developing a wonderful new object hierarchy. They are very interested in squeezing every last bit of value out of a system that they've already paid for. To a product manager, SOA is the lure that a magic "connector" between a legacy asset and a new-fangled ESB (Enterprise Service Bus) will let the company squeeze five more years out of that old COBOL application.

It's the connectors that make the immediate business case for SOA.

Nobody (well, almost nobody) is creating SOA solutions from scratch. Instead, we're figuring our how to duct tape a snazzy JBI connector onto our 20th century legacy code.

I can't blame you if you're still confused. The sometimes mundane reality isn't much like the hype.

Not wishing to end on a down note, I've got to say that once the messy SOA-enabling slogging of today is behind us, SOA should actually be fun to work with. I just hope that I live that long ;-)

Continue Reading...

Java EE app servers: Why pay for support?

With Sun's decision to "Open Source" their Java EE app server, it's likely that all Java EE app servers will soon be free. JBoss, JOnAS, Geronimo and Sun's GlassFish are going to exert huge pressure on the holdouts IBM, BEA and Oracle. IBM and BEA are already formulating responses, as is witnessed by the announcements of IBM support and BEA support for Geronimo, but it's hard to believe that anything short of total capitulation to FOSS is going to keep their app servers viable.

When all Java EE app servers are free, many companies will turn to selling support and maintenance contracts, but will anyone pay for ongoing support?

Continue Reading...

Java EE app servers: Why pay for support?

With Sun's decision to "Open Source" their Java EE app server, it's likely that all Java EE app servers will soon be free. JBoss, JOnAS, Geronimo and Sun's GlassFish are going to exert huge pressure on the holdouts IBM, BEA and Oracle. IBM and BEA are already formulating responses, as is witnessed by the announcements of IBM support and BEA support for Geronimo, but it's hard to believe that anything short of total capitulation to FOSS is going to keep their app servers viable.

When all Java EE app servers are free, many companies will turn to selling support and maintenance contracts, but will anyone pay for ongoing support?

Continue Reading...

Java Business Integration, JSR 208, passes final ballot

For me, JBI's advent will probably be a really good thing. SOA (Service Oriented Architecture) is a paradigm, not a product. I've bought into the SOA paradigm hook-line-and-sinker, but getting from vision to reality has proved difficult.

Web Services, by themselves, just aren't enough to base an Enterprise-wide SOA solution on:

• We need means to manage a large number of services.
• We need means to deal with multiple versions of services.
• We need reliable messaging.
• We need publish/subscribe in addition to request/response.
• We need management and monitoring tools.
• We need provisioning systems.

The scary thing about needing an ESB is in the commitment. ESBs have not been around that long, and what if you pick the wrong one?

JBI is welcome because it should increase commonality among ESBs. The more ESBs have in common, the less likely it is that we'll have to radically change our services and development/deployment processes if we have to migrate from one ESB to another.

IBM and BEA both abstained from the JBI vote, expressing the sentiment that JBI didn't really add all that much to the Java stack. I have to disagree... JBI may not include any groundbreaking concepts, but it greatly adds to value of the Jave stack by increasing this developers peace-of-mind.

Uncertainty may not be what you think it is

Tom Koulopoulos was the keynote speaker at a conference that I attended last week. He's a really bright guy and a very entertaining speaker (or at least I think so).

Tom covered a wide range of topics, one of which was in dealing with uncertainty. He began with a question to the audience:

"What are some games that involve uncertainty?"

Audience members tossed out three examples:

1. Dice
2. Cards
3. Chess

Sure enough, Tom's next slide showed the same three games (He swore he didn't plant shills in the audience, but you never know).

We fell right into his trap. None of these games really involves uncertainty. For example, with dice you will never roll a 13 (Assuming that you are using two "standard" dice).

Uncertainty is not what you least expect, it's what you don't expect at all.

So how do you plan for uncertainty? I can tell you from my own experience that the answer is not "plan for every eventuality". In the first place, you can't know "every eventuality". In the second place, if you try to add in hooks to deal with anything that might happen your product will be bloated and over-engineered. In the third place, the hooks that you build will seldom be the ones you need.

Agile methods evolved from the recognition that you can't predict the future:

• Build only what you need today
• Build it lean
• Build it well
• Get really good at building things fast

If you can build things quickly, you can respond quickly when the thing that you never expected happens.

I have great respect for Bruce Tate and his Better, Faster, Lighter mantra, but in my world of application integration I have to focus at a different level. The Spring/Hibernate stack is great for implementing point solutions, but it's not enough for implementing connect the dots scenarios. Put another way, Spring/Hibernate is great for creating individual services, but it's not the answer for implementing solutions that require orchestrating dozens of services.

Einstein is quoted as saying:

"Make things as simple as possible, but no simpler"

I think that Spring/Hibernate solutions by themselves are too simple for most enterprise-wide problems.

Spring/Hibernate articles generally discuss solutions that are created from scratch. Enterprise-wide solutions evolve over time, and they're never pure. Just as our DNA contains garbage sequences, enterprise-wide solutions always contain legacy junk that will never quite die.

There is no "homogenous future". There will never be a single language, operating system, database management system, or presentation technology.

We need a better, faster, lighter approach towards integrating heterogeneous services.

This is where SOA comes in. SOA mandates loose coupling between services. Loose coupling leads to less efficient solutions, but the agility of the solutions to respond to changing requirements is preserved.

If you tailor a suit too well, it will only fit one man. The suit will look great, but as the man gets older (and middle-age spread sets in) the suit will probably end up at a thrift store.

SOA is a paradigm that allows for growth. OpenEAI is a Java-based open-source framework for implementing solutions that can grow.

Stephen Wheat and Tod Jackson presented a session on OpenEAI at the conference that I attended last week. The framework and methodology were developed by the University of Illinois and then released publicly under GNU licenses.

From their web site:

In the face of this complexity, it is very helpful for an enterprise to have an integration methodology that can be uniformly applied to any new integration project, regardless of the technology involved. Even more helpful is a flexible technology foundation that has already been applied to many types of projects and can be readily extended and applied to new situations. The OpenEAI Project strives to provide this methodology and technology and, most importantly, to provide it in a way that allows all the individuals and enterprises that practice the methodology and use the technology to share their experience and benefit from each other's work. The goal of the OpenEAI project is to explore and codify the science of enterprise application integration in a practical, public, and methodical way.

I don't know if OpenEAI will be to SOA what Spring/Hibernate is to Agile methods, but it looks like a good start.

This work is licensed under a Creative Commons License.