« Predictions for 2005 | Main | Two sites that need RSS feeds »

Ant, workflow, orchestration

I've been looking at some of the new features coming through for Ant 1.7; they look very useful and seem to have a common conceptual theme - better control for conditional reasoning about dependencies. The fact that the Ant 1.7 feature set is conceptually clear is a good sign in itself.

It occurs to me that if tools like Ant and make tend to break down as projects grow larger and more conditions arise, expectations need to be managed for the family of XML based business process languages and tools. Building software is a specialized problem domain, narrower that the gamut of business process orchestration or even the basic workflows you can expect from something such as a write/review/edit cycle for document publishing. Powerful underlying formalisms like pi-calculus and Petri-nets notwithstanding, the risk is that users are left disappointed and cynical with business process tools due to hype.

I suspect for the general problem of capturing a business process as an orchestration, our reach exceeds our grasp*. This is not an argument against the declarative approach. There's no question that too much business logic is locked up in middleware and systems programming languages. But we need to avoid the industry standard hype cycle on these technologies and be clear on what they can and cannot do, which is why online voices of clarity such as Stefan Tilkov's and Paul Brown's are much appreciated.

* I'll avoid going down an Artificial Intelligence history rathole here, but AI researchers hit on this declarative/procedural impasse as far back as the 1970s - Drew McDermott in particular has written some thoughtful essays on the subject.

January 2, 2005 03:09 PM


Steve Loughran
(January 2, 2005 05:36 PM #)

Which features do you mean? The import task is a 1.6 feature, and I dont see much else that does dependencies. The libraries stuff deals with dependent JARs and the like, but is still stabilising as we use it more.

Ant sometimes gets (ab)used in places it shouldn't; like GridAnt...too many people think ant is a generic workflow engine, even though the language and runtime doesnt cover failure handling or persistance. By focusing on development only, we have avoided these, and also made design tradeoffs to support build processes first and foremost.

Kurt Cagle
(January 2, 2005 09:52 PM #)


Very good comment on XML for orchestration, especially the historical annotation about the declarative/imperative impasse. I think we are moving toward a world which is mainly XML based in terms of both orchestration and framework architectures, but that also provides enough of an excape hatch for imperative logic to handle those exceptions that cannot be easily encoded within XML. The challenge that emerged within the AI community in the 1970s came about because of the belief that a purely declarative solution was both achievable and desireable.

In my experience, however, an XML framework (or any framework for that matter) cannot reasonably specify all edge conditions that occur in the real world, and any attempt to do so makes the framework huge and unwieldy. This doesn't obviate the advantages of using the framework for most cases, but the escape hatch must be there.

Happy New Year!

-- Kurt Cagle

Bill de hra
(January 8, 2005 03:50 PM #)


Post a comment

(you may use HTML tags for style)

Remember Me?

Trackback Pings

TrackBack URL for this entry: