2005-05-01

Integration products - loosing your OO-design?

I've been working on automating a manual process by using BEA WebLogic Integration. My initial feelings about how these products works is that the design has a tendency to be functional oriented instead of object oriented. I think that these products are important and very valuable for companies where the J2EE connectors - like CICS, SAP etc. - maps to the companies legacy systems. Using such components are also crucial in a object oriented design. But these products also focus on the business logic part - often represented as business processes using a visual representation - like this one below:



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:

Glenn Bech said...

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.

Paul Beckford said...

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.

Anonymous said...

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.

Paul Beckford said...

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.

Anonymous said...

Great site, I am bookmarking it!Keep it up!
With the best regards!
David

Anonymous said...

Hello!I enjoyed looking around Your website, colors,
layouts are great, keep up a good work!With the best regards!
Jimmy

Anonymous said...

Great article! Thanks.

Anonymous said...

Thanks for interesting article.

Anonymous said...

Excellent website. Good work. Very useful. I will bookmark!