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 sanity such as Stefan Tilkov'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....
Previous Topic
