Service Development Tools…

Jeff Schneider, of MomentumSI, posted his predictions for 2006. One of them was this:

The Business Process Platform becomes the accepted standard as the foundation for enterprise software.

This was very interesting. One thing I’ve commented on in the past is the tooling support for contract first development, and how the BPM tools work better when taking a contract first approach. One thing that I don’t think too many people will argue with is that with advances in frameworks and code generation, the opportunity for more visual development environments on the server side is increasing. You can look at BEA Workshop, M7 (now also owned by BEA), or Microsoft’s Whitehorse as examples of this. Therefore, there is a convergence that is happening between these two environments for developing services. While this convergence continues, what do we do in the short term? What things are best suited for development on a business process platform, using schema-driven tools, and what things are still best suited for development in a traditional OO programming language? Certainly, problem number one is that each tool has its own custom development “language.” While most of the tools either have or plan to have BPEL support, the development language is usually a graphical model from which BPEL can be generated/exported. What about the model for reuse? Do we need OO concepts like inheritance in these visual models? What other programming concepts are being rendered unnecessary for typical corporate IT development because all of the source code is generated behind the scenes, if at all (do these tools generate code or are they tightly coupled with an execution container that interprets the models on the fly… I suspect the latter)? I’m very interested in hearing what other practitioners are doing- where are they getting big wins from the graphical model-based business process platforms and where are they continuing to utilize programming languages.

Leave a Reply

Ads

Disclaimer
This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.