<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>先有法而后有信，信而后有礼，礼后义，义后仁，德道皆不失也 &#187; 架构艺术</title>
	<atom:link href="http://blog.ywxyn.com/index.php/archives/category/dao/architectureart/feed" rel="self" type="application/rss+xml" />
	<link>http://blog.ywxyn.com</link>
	<description></description>
	<lastBuildDate>Thu, 29 Dec 2011 05:23:25 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.2</generator>
		<item>
		<title>一些鲜为人知的编程事实[转]</title>
		<link>http://blog.ywxyn.com/index.php/archives/735</link>
		<comments>http://blog.ywxyn.com/index.php/archives/735#comments</comments>
		<pubDate>Sat, 04 Sep 2010 13:23:23 +0000</pubDate>
		<dc:creator>寻道者</dc:creator>
				<category><![CDATA[架构艺术]]></category>

		<guid isPermaLink="false">http://blog.ywxyn.com/?p=735</guid>
		<description><![CDATA[我的程序员经历让我明白了一些关于软件开发的事情。下面是一些在编程中可能会让人感到诧异的事情： 一个程序员用了大约只用了10%-20%的时间来编码，而且大多数程序员，无论他的水平如何，其平均每天只有10-12行的代码最终会进入最终的软件产品中。这是因为，优秀的程序员会花费90%的时间来思考、调查、研究最佳的设计。而糟糕的程序员则会花费90%的时间来调试代码，并随意地改动代码并尝试让代码工作起来。 “A great lathe operator commands several times the wage of an average lathe operator, but a great writer of software code is worth 10,000 times the price of an average software writer.” –Bill Gates “一个优秀的车工其工资是一个普通车工的好几倍，但是一个优秀程序员写出来的代码比一个普通程序员要值钱一万倍。——比尔盖茨” 一个好的程序员比一个普通的程序员多十倍的生产率。而一个优秀的程序员的生产率则比普通程序员多20-100倍。这并不是夸张（自从上世纪60年代的研究一直表明这是一个事实）。一个糟糕的程序员并不只是没有产出的——他们并不仅是完成不不工作，而且还会制造出大量的让别人头痛并要去解决的麻烦。 优秀的程序员花少量的时间写代码——那些代码都会出现在最终的产品中。那些花大量的时间写代码的程序员其实是很懒惰、很无知，或是很自大的，以至于不能使用已经存在了的解决方案来解决已有的问题。优秀的程序员精通于对通用的模式的识别和重用。好的程序员并不害怕持续地重构/重写自己的代码，直到达到最理想的方案。糟糕的程序员的代码基本上都缺少概念一致性，代码冗长，缺少层次和模式，所以，也就很难被重构。所以，重写他们的代码要比重构他们的代码要容易得多。 软件和其它一切事物一样，都遵循着一致性规则。持续得更改只会让软件变成一潭烂泥，其破坏了原始设计的概念一致性。软件产品变成泥沼是不可避免的事情，但是因为程序员不考虑软件概念一致性而导致软件产品更为快速地成为泥沼，这种速度快得可能 会在软件产品还没有完成时，软件产品已经变得没有价值。设计概念一致性的失败通常都会导致软件项目的失败（而第二大导致软件项目失败的原因则是发布的软件并不是用户想要的）。软件变成烂泥的速度正在呈指数级下降，太多的项目在被完结前都面临着激增的时间和成本。 一个 2004 研究报告 指出，大多数的软件项目 (51%) 都会在关键环节出问题。而15%的项目则是完全失败，当然，这比1994年有了很大的进步，当时完全失败的项目是是31%。 虽然，几乎所有的软件产品都有些开发团队，但其并不是民主的。通常，只有一个人负责设计，而剩下的人去实现细节。 编程是一个辛苦的工作。其是一个巨烈的脑力劳动。好的程序员24×7地在思考他们的工作，他们一般都在在洗澡和梦中编写软件中最重要的代码。因为最重要的工作只能在键盘之外完成，软件项目不可能因为加班或是加人来加快进度。]]></description>
		<wfw:commentRss>http://blog.ywxyn.com/index.php/archives/735/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>关于分布式系统和Web服务扩展相关链接</title>
		<link>http://blog.ywxyn.com/index.php/archives/610</link>
		<comments>http://blog.ywxyn.com/index.php/archives/610#comments</comments>
		<pubDate>Sun, 27 Jun 2010 06:24:52 +0000</pubDate>
		<dc:creator>寻道者</dc:creator>
				<category><![CDATA[架构艺术]]></category>

		<guid isPermaLink="false">http://blog.ywxyn.com/?p=610</guid>
		<description><![CDATA[引自feelwheel王迪的《互联网应用服务扩展的一点经验》的ppt Blogs •Nati Shalom&#8217;s Blog: Discussions about middleware and distributed technologies http://natishalom.typepad.com/nati_shaloms_blog/ •All Things Distributed: Werner Vogels&#8217; weblog on building scalable and robust distributed systems. http://www.allthingsdistributed.com/ •High Scalability: Building bigger, faster, more reliable websites http://highscalability.com/ •ProductionScale: Information Technology, Scalability, Technology Operations, and Cloud Computing http://www.productionscale.com/ •iamcal.com http://www.iamcal.com/ (the &#8220;talks&#8221; section is particularly interesting) •Kitchen Soap: [...]]]></description>
		<wfw:commentRss>http://blog.ywxyn.com/index.php/archives/610/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>说说大型高并发高负载网站的系统架构（转）</title>
		<link>http://blog.ywxyn.com/index.php/archives/380</link>
		<comments>http://blog.ywxyn.com/index.php/archives/380#comments</comments>
		<pubDate>Fri, 18 Dec 2009 10:31:17 +0000</pubDate>
		<dc:creator>寻道者</dc:creator>
				<category><![CDATA[架构艺术]]></category>
		<category><![CDATA[架构]]></category>

		<guid isPermaLink="false">http://blog.ywxyn.com/?p=380</guid>
		<description><![CDATA[说说大型高并发高负载网站的系统架构]]></description>
		<wfw:commentRss>http://blog.ywxyn.com/index.php/archives/380/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>观InfoQ视频《提高架构质量的10个观点》有感</title>
		<link>http://blog.ywxyn.com/index.php/archives/375</link>
		<comments>http://blog.ywxyn.com/index.php/archives/375#comments</comments>
		<pubDate>Thu, 17 Dec 2009 15:50:20 +0000</pubDate>
		<dc:creator>寻道者</dc:creator>
				<category><![CDATA[架构艺术]]></category>
		<category><![CDATA[架构]]></category>

		<guid isPermaLink="false">http://blog.ywxyn.com/?p=375</guid>
		<description><![CDATA[演讲人 高焕堂 ，地址为提高架构质量的10个观点 用了五十多分钟看完，体会颇多，感触良深，一方面是高老师的讲解角度很独特，另一方面是自己的阅历和思考力想象力不够。以下几点是我看完视频之后的深刻体会。 1、我们的程序员或者我们的民族缺乏想象力，因为早在孩子时代有着天马行空的想象力的时候，就被扼杀了 2、软件产业已经走向末路，而信息产业却在不断的蓬勃发展。像数据库、操作系统、应用服务器等等软件，都是国外的，而我们只会使用，并在其上架构信息系统 3、没有人真正的在做架构。高老师借喻张良和韩信两个历史人物，分析了作为架构师的张良如何运筹帷幄和决胜千里的。而我们现在的团队模式都是架构师、项目经理、程序员在一起，没有运筹帷幄的，也没有在外面打仗的 4、我们国内一直在做着开发量大却收益少的工作。高老师讲的强龙和地头蛇的案例。微软开发了.net framework，google 开发了android framework，而我们呢，就基于这些framework进行二次或多次开发，最主要的效益都让别人拿走了； 5、我们平常写代码，很少写base class（interface），都是直接写类 6、我们不经常使用逆向思维，从结果推导基础。程序员是从基础做起，而架构师是从结果逆向进行设计 第一次看高老师的视频，在这里也要感谢InfoQ，我一直关注InfoQ的。高老师虽然讲的时候言语中总带些英文单词，但大部分还是能听懂的。我对他所讲的用中国的文化去包容外国不断更新的技术这个观点，我是赞同的，但如何去包容，我一直没有想到方法，希望在这点上进行扩展，因为外国的技术变化实在是太快了，我又真的非常喜欢技术，但又是一个中国文化迷，超级的那种。真的能将两者结合，以前我一直没往这方面想过，自己的思维还是有局限啊。在结合点上，我还要多学习，多思考。因为我相信，和我这种情况类似的不是我一个人，而是大批大批的。]]></description>
		<wfw:commentRss>http://blog.ywxyn.com/index.php/archives/375/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>转企业级SOA之路——在Web Service中使用HTTP和JMS</title>
		<link>http://blog.ywxyn.com/index.php/archives/364</link>
		<comments>http://blog.ywxyn.com/index.php/archives/364#comments</comments>
		<pubDate>Wed, 09 Dec 2009 09:39:52 +0000</pubDate>
		<dc:creator>寻道者</dc:creator>
				<category><![CDATA[架构艺术]]></category>
		<category><![CDATA[SOA]]></category>

		<guid isPermaLink="false">http://blog.ywxyn.com/?p=364</guid>
		<description><![CDATA[转自：http://blog.csdn.net/steelren/archive/2007/08/23/1756683.aspx 概述 IT业界在早期有一种误解，认为Web Service等同于面向服务架构(SOA)。实际上，SOA远不止这些。虽然SOAP是一种愈加通用的消息格式，但SOA通常还会需要其他的底层transport。当构建SOA的时候，如何选择这些底层transport是最重要的决定之一。为了支持关键业务应用系统的需要，使用的transport必须要灵活、可靠而且可扩展；必须能够支持不同类型的同步或者异步的服务通讯。HTTP和Java消息服务(JMS)是两种最常用的标准SOAP消息transport。 本文分析了HTTP和JMS各自的优点和协议，重点讲述每一种transport在SOA中的什么地方是最适用的并且演示如何使用它们。 企业SOA通讯需求 灵活性，可靠性，可扩展性。要想最大限度的利用所有的连接服务，这是企业SOA中使用的transport都要具有的三个属性。 在SOA架构中，transport需要能实时(同步)地进行消息传输，以对用户或者系统进行响应。通常企业也要求拥有灵活性，以实现异步通讯服务。一个原因可能是服务并不总是处于可用状态。另一个原因可能是不可靠的或者非持续的网络连接，比如无线网络。 在这些情况下，同步传输会产生失败结果，除非服务本身可以进行“重新请求”操作和错误处理。此外，SOA中流程间的通讯并不总是点对点或者一对一的。通常，服务需要同时对多个流程或者系统发送消息，是一对多的关系。当服务也可以被多个“消费者”请求时，就增加了服务本身的复杂度并且使服务和终点紧密关联。 在很多情况下，服务要求有可靠的transport。如果transport没有提供可靠的消息发布，在应用系统中就必须要增加额外的验证。 最后，transport必须是可扩展的。Transport本身不能对发布消息数量，消息发送方和消息接受方数量的增长进行限制。 HTTP的优缺点 HTTP是SOAP消息中最常用的transport。毕竟，它是原始Web服务标准中的第一个官方的SOAP transport。因此HTTP作为标准的与Web服务连接和通讯的方法，被应用系统和系统提供商广泛地采用。 然而，HTTP本身所具有的点对点、同步的特性成为了它作为服务transport的局限。了解HTTP的功能和局限可以帮助我们找到最合适的地方使用它，并且根据情况考虑使用其他的协议替代它。 HTTP只支持点对点和同步方式 HTTP支持的通讯方式有两方面的局限。首先，因为HTTP是点对点协议，它不提供对多个接收方的并发请求能力。在企业SOA中，一个服务提供者可能需要在流程中的某一步完成后通知其他服务提供者。当使用HTTP时，服务必须明确的识别每一个接收者并向其发送消息。 这种限制可以得到某种程度的缓解。解决方案包括开发一个应用系统来进行这些消息的连续传输或者根据OASIS制定的Web服务通知规范进行编码，SOAP扩展程序对通知进行寻址。Web服务通知规范目前正处于标准设置进程的公共评审阶段。 另一个局限是HTTP只支持同步通讯。很明显，在SOA中既需要同步通讯也需要异步通讯。流程经常会等待人工干预或者其他的流程结束。在这种情况下，HTTP的同步特性就不满足SOAP对transport的要求了。HTTP等待请求的响应，要占用宝贵的通讯资源直到它接收到响应信息。在异步的情况下，在接收到响应消息前可能会有很长时间的等待。 一个并不算完善的使用HTTP的SOAP提供异步消息的解决方案是采用Web服务寻址标准。通过使用Web服务寻址，SOAP消息的整个路径(包括它的返回路径)可以在SOAP消息封装中直接描述。Web服务寻址支持单向消息，双向消息(比如请求/响应和点对点通讯)和长连接对话。但是，这个标准增加了复杂度，需要另外编写程序和购买产品。 除去这些解决方案，情况依然如此：为了使消息能够被成功的发送，HTTP需要发送方和接收方同时被连接。如果网络或者接收程序没有连接，HTTP就不能发送消息。 简单的说，HTTP本身并不具备企业SOA所要求的通讯(通知和异步操作)的灵活性。不论是在应用程序级还是在SOAP级，开发人员都必须要额外编程来实现通知和异步操作。 HTTP提供有限的可靠性 因为HTTP只能提供很有限的错误码，只能根据这些错误码区分很小一部分可能的错误情况，所以这个协议本身是不能保证发送方的消息确实被发送了。然而确保信息被发送是任何企业SOA的一项基本功能。为了保证全部流程的每一步都能持续地进行，发送者的发送的信息必须保证能被指定的接收者接收到。 一个提升企业架构可靠性的方法就是提升网络和应用系统的可靠性，防止网络和应用系统过载。另一个方法是为应用系统额外创建错误处理和修复功能。第三种方法是在SOAP层编写程序，使他符合Web服务可靠消息标准(可靠的Web服务消息)。但是，每一种方法都会增加成本和复杂度，而且他们也无法完全的避免失败。 HTTP缺乏有效的可扩展性 通过HTTP进行通讯的基础架构无法有效的进行扩展。HTTP服务器的架构限制了在任何时候同时连接的端口的个数。理论上端口的数量可以达到65536个，但是为了避免服务器过载，可用的端口的最大数量要小很多。这些连接占用了宝贵的机器资源，限制了可扩展性。一旦达到了限制的数量，就需要增加额外的硬件(比如其他的Web服务器)以增加容量，并且要设置负载均衡。这些额外的手段增加了系统架构的成本和复杂度。 尽管Web服务器可能有很多端口连接在使用，但可能同时只有一小部分在发送消息。在这种情况下，服务器即使还没有满负荷运行，也不能接受更多的连接。服务器的资源并没有被高效的利用。 基于HTTP的SOAP复杂度高 综上所述，简单的HTTP通讯方式可以被扩展成灵活的、可靠的和可扩展的通讯方式，来充当基于的Web服务的SOA的通讯基础。进行这些改进是通过扩大SOAP层进行的。这些改进，处于不同的批准和采用阶段，充分证明了SOAP的扩展性。然而，他们同样带来了额外的复杂性，并且需要额外的开发资源和/或额外的软件来执行，因此增加了成本。 JMS降低复杂度 JMS是由Java通讯程序制定的规范。它提供了标准的编程接口用来发送和接收消息，支持同步消息、异步(发布/订阅)消息和请求/响应(点对点)消息。JMS提供商的每个JMS产品，都对如何进行消息发布进行了规范，这些规范涵盖了消息转换、安全、错误处理和服务器与客户端之间的底层通讯协议。这样，为服务传送消息就变得简单易行，不需要在应用系统中额外的编程去实现错误处理和恢复。要获得更多的JMS方面的资料，可以访问java.sun.com/products/jms/index.jsp。 正因为有这些功能，JMS作为消息transport在应用集成和SOA中被广泛的采用。包括使用JMS作为基于SOAP的服务的transport 。 JMS支持更多的通讯方式 JMS相比HTTP能进行更灵活的消息发布。JMS支持“发射后不管”通讯，消息在发送后不必等待应答，并且可以存放在持久存储或者Queue中。基于Queue的方式可以进行异步通讯，消息发送时，消息的最终消费者不需要连接到服务器上。当消息的消费者连接到JMS服务器上时，消息就可以被发送到消息的消费者。HTTP就明显不能支持这种异步的通讯方式。当使用HTTP时，开发人员必须编程使应用系统支持异步方式，并且要有效的重新创建消息传送。 除了在消息生产者和消费者之间进行点对点的消息通讯，基于JMS Topic的架构可以支持发布/订阅方式，使用这种方式一个消息生产者可以与多个消息消费者同时进行通讯。生产者向给定的Topic上发送任何消息都可以被订阅了这个Topic的每一个消费者接收到。HTTP不能提供这样的功能，除非增加SOAP消息的复杂度或者编程使应用系统实现一对多的消息发送。OASIS的Web服务通知(WSN)技术委员会定义了一套规范，用来对Web服务使用“通知”和“事件”的交互进行标准化。它们构成了使用Web服务架构事件驱动的基础。 Modes of Transport for HTTP and JMS &#160; Point-to-Point Publish/Subscribe Synchronous HTTP, JMS JMS Asynchronous JMS JMS [...]]]></description>
		<wfw:commentRss>http://blog.ywxyn.com/index.php/archives/364/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

