mult.ifario.us

Over on InfoWorld, David Linthicum has some misdirected and FUD-filled comments (original and follow-up) on the impending release of the WS-BPEL 2.0 standard by OASIS. Bruce Silver, Steve Hoffman, and Fred Holahan are quicker on the draw in responding on the topic, but I'll come out of semi-retirement as a BPEL wonk to comment. (I could never quite get off my kiester to go after David Chappelle when he blogs about BPEL, partially because he has the clever defensive tactic of a broken blog that makes it impossible to link directly to entries...)

First off, if there are any genuine issues with the consistency of the specification, behavioral, semantic, or otherwise, then those should get presented to the OASIS BPEL TC promptly for consideration. I doubt it. The TC discussed literally thousands of issues — at length and sometimes ad nauseum. Of the 308 of those that were worthy of issue status, all have been resolved with the input of several dozen smart folks (and a few dumb ones).

As far as BPEL4WS 1.1 goes, finding a reasonable profile for the language isn't that onerous. (In fact, it's easier to figure out a behavior profile than to decipher the combined licensing terms from the specification's "owners".) Make a choice about variable declarations and fault-handlers, think hard about event-handlers, etc., and you can work it out. Someone else might make different choices, but c'est la vie. Row-level locking works differently in every SQL database, and no one's crying about it. The PXE engine offered side-by-side execution of a working profile for BPEL4WS 1.1 and a spec-tracking version of WS-BPEL 2.0 starting back in 2003 (and was the first engine to do so), with the ability to apply management, deployment, and debugging functionality equally to both 1.1 and 2.0 processes within the same runtime container. (PXE is now part of the ODE project under incubation at Apache and part of Intalio's open-source BPMS.) This was purposeful, up-front future-proof design; there was no planned or inadvertent obsolescence, no subterfuge. Side-by-side support should be the baseline customer expectation.

Before banging on a drum about portability, what would portability mean for an orchestrated process? No one should expect that vendor-specific goodies are portable. I can't run PL/SQL in DB2, and I'm cool with that. Does portability mean demonstrable behavior equivalence, up to non-determinism? A reasonable definition would be that a process written in vanilla WS-BPEL 2.0 should run in any engine that claims to be compliant, up to fussing with deployment descriptors. (Neither the 1.1 nor 2.0 versions of the specification address the way that BPEL ports are bound to concrete ports, so this is different across the various vendors.) For what it's worth, we had reasonable luck taking BPEL4WS 1.1 processes created with other tools and running them, with a modicum of fiddling.

I said it in 2004, Assaf said it recently in a long guest post over on IT|Redux, and it's still true: BPEL is an orchestration execution language, in a role analogous to assembly language. To quote myself:

And that's all you should expect it to be. Diagramming tools? Not in there — I'd recommend taking a look at BPMN. Workflow add-ons? Not in there — check out BPEL4People or just (gasp) model your workflow components as services.

The kid is really starting to develop some personality, and her growing capabilities make it more fun to be a father. (Don't get me wrong, babies are wonderful blah blah, but toddlers are even better.) She can take multi-step commands, and she understands that Mom and Dad can help with things like hurting teeth or itches. She taught herself to do a somersault, spontaneously stacks objects, colors randomly on place mats at restaurants (whether or not they're intended for that purpose), and skipped right past shape-sorting toys to putting pry-out pieces back into a multi-page book.

So far, so good. The weird thing is that she's also developing quirks. I was giving her a bath tonight and turned my back for a split second to put something away, and she let out a blood curdling scream. She was standing in the tub with a serious expression on her face, arm stuck straight out, pointing to a small fleck of dirt floating in the tub. I fished it out, and she went back to pouring water from one cup into another like nothing had happened. It's very difficult to be a neat freak as a baby, where the difference between food, finger paint, and hair gel is situational, but she's showing a definite trend now. This is just one instance; for example, she behaved similarly after dropping a piece of food on the mat that sits under her highchair. A month ago, the mat was there to protect the floor, but today, she feels that it's important to keep it clean.

Who knows whether the kid will carry this into adulthood or even into next week, but the nascent idiosyncrasies are one of the things that makes her more fun.

Without running it, what does the following chunk of code print?

Long a = new Long(4);
Long b = new Long(4);
System.out.println(a == b);
System.out.println(a.longValue() == b);
System.out.println(a.longValue() == b.longValue());

Why?

The kid developed a pretty nasty rash of unknown origin after dinner today, so we called the on-call advice nurse. After a few not-so-fruitful rounds of questions about what the rash looked like, I grabbed a couple of digital pictures, posted them to Flickr, and gave the nurse the URL over the phone. (I took the pictures down after the call was over.) A cool bath followed by some hydrocortisone, and peace returned to our household. No Bendryl for the kid if we can avoid it, as it seems to function as a strong stimulant in her case; the one time we gave it to her at 10PM, she literally ran laps around her room for four hours...

This brings to mind an idea for a software business — branded, private, secure photosharing portals for physician's offices and hospitals that provide advice over the phone. The portal would provide secure, permanent storage for the images and integration with the medical record system.

WS-BPEL is finally in public review. John Evdemon has links and additional information on his blog.

Every time I talked with Maciej about what was happening and created a mental estimate of when the WS-BPEL spec would finally be out, I added a twelve-month buffer, just in case. Even then, my guesses were always early. Nonetheless, as an educated observer, I think that the process took about the right amount of time.

Engineers have a variety of perspectives on ready-for-production, from "It works on my desktop" to "The functional and integration suites all pass" to "The theorem prover and state space traversal heuristics assert that it's perfect". Ultimately, "Are we ready to go to production?" is the wrong question. The right questions are more business-oriented:

• How would it impact the customer and what would it cost us to flip the switch right now?
• How can we respond to issues and get the system back on its feet?

The first question is for the business owner to answer outside of the context of what the development team has to say about the state of the system. Failure is a fact, and managing the probability of a failure requires time and investment. It's the business owner's prerogative to choose the points on the curves of magnitude of customer impact and ongoing investment in development — independent of asserted outcome of the development effort. It's a bit like cooking a steak à point in that you want the software to be just barely done.

The second question is for development leads and architects to answer, both at design time and during implementation. Recovery options need to be matched to failure modes and possible inconsistencies, and failures need to be detectable other than via confused or angry customers. The design-time imperative is to pick the right design patterns — stateless when possible, idempotent always, and minimal horizontal co-footprint per unit of traffic come to mind. (I'm saying "co-footprint" because "footprint" isn't quite the right term. A customer spread across a couple of tables is no big deal, but needing to have all of the customers in a single database is constraining.) The development solution is to engineer-in instrumentation and plug-points where data or operations can be cleanly injected into the system, ideally to the point that an operator can use the system in the same ways that the system uses itself. (The body of thought on recovery-oriented computing is a good read on the subject of designing systems so that failures are just bumps in the road.)

In all practical terms, the developers are the only capable and knowledgeable operators for the system, and refining and documenting the system to the point that first-tier and second-tier support can exist is an organic process that needs to happen in response to observed issues, not a phase on a project plan. To extend the steak analogy, this would be bien cuit, which is only suitable as a chew toy for a dog or for the manufacture of footwear. In my mind, intimacy with the system is the bond that links development to operations, but just handing out pagers to software engineers without the proper groundwork is both illegitimate and destructive.

In a maxim, system failures are to be expected, but business failures are unacceptable.

When the Sprial Frog relationship with Universal was announced, I was tentatively intrigued and waited for the catch to come out. This is in spite of the fact that I can't think of any artists on major labels that I give a hoot about. Once the first sketchy details were out about having to watch ads, it sounded like a job for Mechanical Turk — I can have a remote human watch the ads on my behalf for a nominal fee. The idea had a certain impish appeal in that I'm certain that the advertisers wouldn't want their demographic to be people somewhere in the world who'd sit through an ad for a nickel, but it was all mooted when it the details of Spiral Frog's plans for regressive DRM came out. I'm going to have to think about other opportunities where MechTurk could provide an acceptable-cost route around other on-line annoyances.

Now, as for the obsession with DRM,...

Consumer: (in raspy falsetto) I'd like to download some music, but I don't like DRM.

Waiter: (earnestly) Well, we've got some Same-Old-Same-Old; that's got DRM, ads, music, and DRM. That's not much DRM.

Consumer: (angrily) I don't like DRM!

Chorus of Record Labels: DRM DRM DRM, D-R-M D-R-M...

Bloody Vikings.