It might be my naive usage of WebLogic Integration, but I do see a tendency to focus on handling the complexity by using "function points" instead of objects. The reason? Well - one of the strong points with these business process products are that they communicate what's going on within the business process. This involves classical constructs like for and while loops, if and case statements and of course more high level constructs to create parallel processing. The result of these processes is that you run a function - made by yourself or other components - alter the data - and then the next function works on the same data. The connections points between the functions are the data, but as you probably see the object oriented principle of keeping data together with the logic doesn't apply in these processes.
I haven't used any other integration products, but have gotten Microsoft BizTalk presented and I saw similarity with BEA WebLogic Integration.
Whether or not this is a good or bad thing - I'm not sure, but my guess is that on a large project this approach might be a bit difficult. I also suspect that these business processes get very complex and the reuse perspective might be more difficult. It surely will be interesting to get more experience with such a solution. My current assignment isn't big enough to pinpoint possible problem areas.
Any thoughts on this issue?
9 comments:
I kind of agree. I see the same result of overusing the command Pattern, especially in a "chain of command" setting.
Data gets pushed around in very complex chains of processors in often losely typed "Context" objects. It can be very hard to actuallt trace what's going on with your data in a deug setting.
I work with a colleague who was forced to use this stuff. He bitches about the experience almost everyday.
I'll e-mail him a link to your post. I'm sure he'll comment.
Interesting to see your post. In an age where all seem to be caught up in the latest tools and products that software vendors offer, it is sometimes hard to cut through all the hype and confusion and get back to basics. Not that I would class myself a luddite - I am interested in new ideas and innovation in the software development community - it's just that rational thought occaisonally eludes us.
I also used Weblogic Integration and Workshop and had a tough time trying to reconcile my object oriented background with ‘flow chart programming’ which so clearly discourages object thinking. You have hit the nail on the head when you describe the approach as function oriented. Delegation and polymorphism are powerful tools introduced by object oriented languages and these concepts are not available to the developer who chooses an integration/BPM product for development.
On the face of it, BPM and code generation sound like a great idea and the major tools vendors can effortlessly sell their products these days – everyone wants a silver bullet after all – we want to believe that these products really can aid in the product of software in a timely and cost effective manner. It can be advantageous to produce a model of the key processes in an organisation to foster the communication and comprehension of the key issues in the business domain. However, object oriented analysis and design techniques to not sit comfortably with process models alone – they are another impedance mismatch. Looking at process to the detriment of static structure and state for example can prove costly mistakes.
It would be interesting to know if there businesses out there who have successfully built medium to large scale application using integration/BPM technology where those systems could not have been built more efficiently using more traditional methods.
Integration tools are expensive, complex (contrary to the sales pitch), inefficient and will lead to the same problems we had with function oriented languages. Perhaps we have reached the optimum level of abstraction – object technology – for now.
As I said, I thought Andy may have a few words to say. I think his final sentence makes the point well:
"Perhaps we have reached the optimum level of abstraction – object technology – for now."
In managing complexity, abstraction is the most powerful tool in our toolbox. "Dumming down" to flow charts in an attempt to make development easier (cheaper) is a fallacy.
The cheapest, most productive approach is to hire the best developers you can afford and let them use what ever tools they see fit.
Great site, I am bookmarking it!Keep it up!
With the best regards!
David
Hello!I enjoyed looking around Your website, colors,
layouts are great, keep up a good work!With the best regards!
Jimmy
Great article! Thanks.
Thanks for interesting article.
Excellent website. Good work. Very useful. I will bookmark!
Post a Comment