-
Subscribe -
Community
-
Top Commenters
-
Popular Threads
-
Recent Comments
- Thanks for your comment. I've encountered people who talk about non-distributed SOA. I think that is an idea that is totally boring, as it says nothing that hasn't been said for twenty...
- In the text you, like most I think, define services to be distributed. I do not understand why everybody i
- Hi, Eve Thanks for the offer. Let me know if there's any way I can make it easier. Do you think I should consolidate all the articles into one, for example?
- I'd be more than happy to read drafts, run through example code, and whatnot. I've done a little bit of Rails work, but I'm enough of a noob that I'll be able to give good feedback...
- I've never had much luck with the precreated keys. But then again, I use the convention of a null-key to indicate unsaved objects, so I'd run into other problems. FWIW, it sounds like your...
Jump to original thread »
Before Web Services, there was CORBA. Before CORBA, there was DCOM. Before DCOM, there was RPC. Before RPC, there was BSD sockets. Before sockets, there were databases. And as it was in the beginning, so shall it too be in the end.
The only systematically successful strategy in the his ... Continue reading »
The only systematically successful strategy in the his ... Continue reading »
2 years ago
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!
2 years ago
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.
2 years ago
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...
2 years ago
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.
2 years ago