Thinking inside a bigger box - Latest Comments in On Integration: The vision of a single database

Re: On Integration: The vision of a single database

chwlund — Thu, 19 Oct 2006 15:51:20 -0000

I am really looking forward to experience a project with a BPM-tool myself, but I am quite new in the business so I havent got a chance yet, but I have tried a few in my spare-time and some of them seems very promising. Biztalk is very powerful and flexible, and is great for both integration processes, messaging, and more complex human-driven business processes. a great powerful java open source bpm tool is http://www.intalio.com/. I will post more comments on my experiences with these and others on my blog, so you are welcome to subscribe! in general the bpm market in norway is starting to grow, more companies want to have control over their processes, so I think the process oriented way of thinking about certain applications is coming more and more! later!

Re: On Integration: The vision of a single database

Johannes Brodwall — Thu, 19 Oct 2006 09:25:30 -0000

I have actually never seen a system implemented with a BPM-tool, my knowledge of such tools is limited to articles on how it might work, so I can't really compare the techniques well.

A BPM using database-integration would indeed be a strange monster. Since you can't drive the control flow from the database (without going insane, at least), So the control would have be be decentralized. I don't know how current tools deal with this.

Anyway, it would be really interesting to hear about your experiences with BPM in a real project (I subscribe to your blog now). I suspect that hard parts aren't what I'd intuitively think they'd be.

Re: On Integration: The vision of a single database

chwlund — Thu, 19 Oct 2006 08:55:52 -0000

after thinking it through I agree that those issues are the same independent of technology. sorry about that!
but I am one of those sick bastards that likes the idea of implementing long-running business processes in a separate process layer, using some kind of BPM-tool or sometimes an integration tool and then I would rather like to integrate closer to that layer than doing this all the way down in the database layer...

Re: On Integration: The vision of a single database

Johannes Brodwall — Sun, 08 Oct 2006 15:31:50 -0000

Thank you for the comment.

I am not sure I understand you concern about long-running transactions. These issues are the same no matter what technology you use to integrate, I think? Compensating transactions are not tied to web services or remoting in any particular way.

Anyway, yes, in may ways, this is a "back to the 80s" vision. I do think that many of the ideas that came out of computing in the 90s were indeed steps in the wrong direction, and we have to rethink them. The monolithic system design of the 80s do present significant challenges of scale, like you point out. These challenges are indeed what I intent to address.

A2A integration with a (remote) service layer has in my experience proved to cause much more harm than good in terms of productivity, performance, reliability and complexity. This is what I intent to explore in my next post.

Re: On Integration: The vision of a single database

chwlund — Sun, 08 Oct 2006 07:01:17 -0000

I guess this is maybe coming in the next articles, but can you explain a bit more on how this should work? the way I understand your strategy is that you want to have all your web servers / applications servers running different kinds applications and hosting all sorts of domain objects to use the same database to communicate?
then what about long-running transaction? processes that involves humans?

and isnt this like taking application design back to the 80s? is it possible to come up with a unified database design that can meet the requirements of the different applications? I get this utopian ERP-like feeling here? isnt it just so that a large/medium organization always will have some number of different applications running on different technologies with ownership from the different departments?

in my opinion I think integration higher up in the application stack is a better idea, for instance in an integration layer or service layer!