<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"><channel><title>Disqus - Latest Comments for Carl</title><link>http://disqus.com/people/eb15929720fee5f3de544274c8f58fa5/</link><description></description><language>en</language><lastBuildDate>Thu, 19 Oct 2006 15:51:20 -0000</lastBuildDate><item><title>Re: Anti-spam measures</title><link>http://thinkinginsideabiggerbox.disqus.com/anti_spam_measures/#comment-1796601</link><description>Simple math question (&lt;a href="http://www.herod.net/dypm/" rel="nofollow"&gt;http://www.herod.net/dypm/&lt;/a&gt;) works fine for me too! I really like the simplictity of it!</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Carl</dc:creator><pubDate>Mon, 18 Sep 2006 17:15:39 -0000</pubDate></item><item><title>Re: On Integration: The vision of a single database</title><link>http://thinkinginsideabiggerbox.disqus.com/on_integration_the_vision_of_a_single_database/#comment-1796831</link><description>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?&lt;br&gt;then what about long-running transaction? processes that involves humans?&lt;br&gt;&lt;br&gt;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? &lt;br&gt;&lt;br&gt;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!</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Carl</dc:creator><pubDate>Sun, 08 Oct 2006 07:01:17 -0000</pubDate></item><item><title>Re: On Integration: The vision of a single database</title><link>http://thinkinginsideabiggerbox.disqus.com/on_integration_the_vision_of_a_single_database/#comment-1796834</link><description>after thinking it through I agree that those issues are the same independent of technology. sorry about that!&lt;br&gt;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...</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Carl</dc:creator><pubDate>Thu, 19 Oct 2006 08:55:52 -0000</pubDate></item><item><title>Re: On Integration: Why I enjoy working with databases</title><link>http://thinkinginsideabiggerbox.disqus.com/on_integration_why_i_enjoy_working_with_databases/#comment-1797023</link><description>puh! I had written a long comment to this post and then suddenly the math failed and I lost mye whole comment... so this will be some kind of sum up:&lt;br&gt;&lt;br&gt;first I would like to say that I really enjoy reading your blog, exiting and insightful ideas that seems to be based on many many years of experience. really worth listen to!&lt;br&gt;&lt;br&gt;but I really cant wait for the "how"-part of this serie, so here are some questions:&lt;br&gt;&lt;br&gt;-how is it possible to trigger a business function in another application using your shared database strategy? I guess that all applications have access to all the data in the database, but what if an application A want another application B to do some calculations on a specific set of data. how do application A trigger this calculcation in app B? (I presume that you want to avoid the nightmare of stored procedures)&lt;br&gt;&lt;br&gt;-how can you avoid that the applications get tight coupled? when the apps share and communicate trough a shared database then they have to know and use the inner data structures of the other applications. this will make them strongly coupled. if you change the structures of one application this might affect three others... isnt this like really entering the world of spaghetti?&lt;br&gt;&lt;br&gt;-will it not be hard to change the technology that one of these applications are based upon? when the database layer are merged together and there are no explicit system borders in the database layers, how can you manage to replace the technology... isnt the system borders in a database just to vague and implicit? isnt it much better to move the system borders for instance up in a service layer?&lt;br&gt;&lt;br&gt;my philosophy is that applications that solves different problems and that actually explicitly are separate applications should (if they have to communicate at all) know as little about each other as absolutely possible! and I dont see how you achieve this goal with the shared database strategy!</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Carl</dc:creator><pubDate>Thu, 19 Oct 2006 09:38:00 -0000</pubDate></item><item><title>Re: On Integration: The vision of a single database</title><link>http://thinkinginsideabiggerbox.disqus.com/on_integration_the_vision_of_a_single_database/#comment-1796835</link><description>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 &lt;a href="http://www.intalio.com/" rel="nofollow"&gt;http://www.intalio.com/&lt;/a&gt;. 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!</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Carl</dc:creator><pubDate>Thu, 19 Oct 2006 15:51:20 -0000</pubDate></item></channel></rss>