<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.3" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Common Sense</title>
	<link>http://www.dancres.org/blitzblog/2007/11/25/common-sense/</link>
	<description></description>
	<pubDate>Fri, 16 May 2008 07:42:19 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.3</generator>
		<item>
		<title>By: Dan Creswell</title>
		<link>http://www.dancres.org/blitzblog/2007/11/25/common-sense/#comment-791</link>
		<dc:creator>Dan Creswell</dc:creator>
		<pubDate>Mon, 26 Nov 2007 13:22:52 +0000</pubDate>
		<guid>http://www.dancres.org/blitzblog/2007/11/25/common-sense/#comment-791</guid>
		<description>Hi Patrick,

Belated Thanksgiving wishes - wondering a little why you're reading a techblog on the holiday ;)

Custom service invocation layer - I'm aware of a couple of examples some of which at least have properties of JERI but aren't typically focused on Java.  However this is just a distraction.  The important point is that most of the invocation infrastructures one might choose are locked in some part to a particular architectural approach.  Or at least they represent a particular set of compromises chosen by the vendor/developer that may not fit with all cases one finds in implementing these large systems.  Ideally one would like a single invocation infrastructure that can cope with all eventualities which is leading some to build their own that take the best bits of a selection of infrastructures and combine them to get exactly what is required.

As to the rest of the posting, you're pretty close to what I was trying to say which amounts to:

Systems of a certain scale and diversity do not easily fit within a particular style.  When this happens, one must fall back on what I'm (perhaps wrongly) calling common sense - focusing on partitioning, various patterns that might pop up in one or more styles, past experience and so on.

Bruce Lee wrote something that I feel fits with what I'm getting at:

"Jeet Kune Do favors formlessness so that it can assume all forms and since Jeet Kune Do has no style, it can fit in with all styles. As a result, Jeet Kune Do utilizes all way and is bound by none and, likewise, uses any techniques which serve it's end."

My (architectural) style is no (architectural) style, all I have are my wits and experience.....</description>
		<content:encoded><![CDATA[<p>Hi Patrick,</p>
<p>Belated Thanksgiving wishes - wondering a little why you&#8217;re reading a techblog on the holiday <img src='http://www.dancres.org/wordpress/wp-includes/images/smilies/icon_wink.gif' alt=';)' class='wp-smiley' /> </p>
<p>Custom service invocation layer - I&#8217;m aware of a couple of examples some of which at least have properties of JERI but aren&#8217;t typically focused on Java.  However this is just a distraction.  The important point is that most of the invocation infrastructures one might choose are locked in some part to a particular architectural approach.  Or at least they represent a particular set of compromises chosen by the vendor/developer that may not fit with all cases one finds in implementing these large systems.  Ideally one would like a single invocation infrastructure that can cope with all eventualities which is leading some to build their own that take the best bits of a selection of infrastructures and combine them to get exactly what is required.</p>
<p>As to the rest of the posting, you&#8217;re pretty close to what I was trying to say which amounts to:</p>
<p>Systems of a certain scale and diversity do not easily fit within a particular style.  When this happens, one must fall back on what I&#8217;m (perhaps wrongly) calling common sense - focusing on partitioning, various patterns that might pop up in one or more styles, past experience and so on.</p>
<p>Bruce Lee wrote something that I feel fits with what I&#8217;m getting at:</p>
<p>&#8220;Jeet Kune Do favors formlessness so that it can assume all forms and since Jeet Kune Do has no style, it can fit in with all styles. As a result, Jeet Kune Do utilizes all way and is bound by none and, likewise, uses any techniques which serve it&#8217;s end.&#8221;</p>
<p>My (architectural) style is no (architectural) style, all I have are my wits and experience&#8230;..</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Patrick Logan</title>
		<link>http://www.dancres.org/blitzblog/2007/11/25/common-sense/#comment-789</link>
		<dc:creator>Patrick Logan</dc:creator>
		<pubDate>Mon, 26 Nov 2007 03:43:58 +0000</pubDate>
		<guid>http://www.dancres.org/blitzblog/2007/11/25/common-sense/#comment-789</guid>
		<description>Dan -- first two posts in this series clicked for me. This one has not clicked yet.

I think the middle part of the post is the key message: for sufficiently large systems there may be more than one style of distributed architecture. And for some systems there may be a single style, say ROA, but although logically, or conceptually, it is a "single" system, the parts may conflict with each other if they were forced to co-exist to closely in a single implementation.

And so the lessons are, I think I am reading:

1) Don't lock into a single style just to have a single style.
2) Don't lock into a single implementation just to have a "single implementation".

Or something?

I became lost in the last couple of paragraphs about "custom service invocation layer" -- do you mean like Jini's?

And finally with the CSA -- "Common Sense Architecture" -- what's that architecture? What's the common sense that does not exist in ROA or EDA (I'll leave SOA out of it -- that one leaves me feeling queasy in and of itself.)</description>
		<content:encoded><![CDATA[<p>Dan &#8212; first two posts in this series clicked for me. This one has not clicked yet.</p>
<p>I think the middle part of the post is the key message: for sufficiently large systems there may be more than one style of distributed architecture. And for some systems there may be a single style, say ROA, but although logically, or conceptually, it is a &#8220;single&#8221; system, the parts may conflict with each other if they were forced to co-exist to closely in a single implementation.</p>
<p>And so the lessons are, I think I am reading:</p>
<p>1) Don&#8217;t lock into a single style just to have a single style.<br />
2) Don&#8217;t lock into a single implementation just to have a &#8220;single implementation&#8221;.</p>
<p>Or something?</p>
<p>I became lost in the last couple of paragraphs about &#8220;custom service invocation layer&#8221; &#8212; do you mean like Jini&#8217;s?</p>
<p>And finally with the CSA &#8212; &#8220;Common Sense Architecture&#8221; &#8212; what&#8217;s that architecture? What&#8217;s the common sense that does not exist in ROA or EDA (I&#8217;ll leave SOA out of it &#8212; that one leaves me feeling queasy in and of itself.)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
