系统架构师(高级)学习资料.doc

《系统架构师(高级)学习资料.doc》由会员上传分享，免费在线阅读，更多相关内容在应用文档-天天文库。

.Net下企业应用系统架构构建心得在开始架构设计之前，需要了解一下架构是什么，按照IEEE标准的定义是：Architecture是一个系统的基本组织，它蕴含于系统的组件中、组件之间的相互关系中、组件与环境的相互关系中、以及呈现于其设计和演进的原则中。(Theembodiedfundamentalorganizationofasysteminitscomponents,theirrelationshipstoeachother,andtotheenvironment,andtheprinciplesguidingitsdesignandevolution.[IEEEStd1471-2000])　　一句话，架构就是软件产品的骨架，这个骨架把组件、环境纳入其中，使之能有效得发挥它们的技能。　　从架构、技术和需求的关系来看。一个软件产品包含了需求和技术，而架构同样是要包括需求和技术的，只是它没有全包全括这个需求和技术，应该是一些整体性的需求，尤其是一些非功能性的需求。如果在构建架构的时候，架构设计人员根本不了解企业使用的目标软件的整体需求，企业使用目标系统的整体环境，那指望架构适用显然有点强求。　　架构的重要性是不言自明的：　　l)从需求、技术和架构的关系看，架构是软件产品的骨架　　2)从软件过程上看，架构处在需求即将完成，实现开始之前，是一个承上启下的关键点　　3)从技术上来看，架构是整体设计，包含了软件需要用到的各项技术　　4)架构决定开发过程，方法和工具，这一点都不夸张，架构决定了软件的规模，技术。很自然就觉得了资源的需求以及如何配置这些资源来进行开发　　5)架构影响软件产品的成本，包括开发成本，测试，实施和维护成本架构实际上是软件的一部分，同样都需要遵循软件设计中要考虑的设计原则。但是，架构由于是前期设计，整体设计，又具有其需要强调的地方：　　6)明确目标，切合需求（实用决定一切）　　7)可扩展性　　8)易用性和易维护性平衡艺术,易用性就要求系统不能过于负杂，而易维护性就要求可扩展性和灵活性，就要求系统不能太过简单，这就要权衡这两个性能方面的考虑。　　9)安全性,架构的安全并不是说把架构的代码放到一个地方加密，是在架构设计中考虑软件的安全性能，这个在先期考虑是相对重要的。　　l0)稳健性,架构设计时需要纳入考虑的要素有：　　l1)ApplicationInfrastructure,应用的基础架构，也可以说是架构是建立在什么平台上的，比如windows2003+.Netframework1.1，当然并不是就这么简单，下面会有具体的讲解。　　l2)Management,架构设计中要考虑用户对软件的管理方面的考虑，比如用户对性能监控的要求，用户要对软件执行各个环节的执行效率统计等等。　　l3)Security,安全性是在什么地方都要考虑的，不光是软件开发。　　l4)Storage,存储，面对一个企业级的应用而言，对存储的要求是要特别注意的。　　l5)Network,网络拓扑结构，以及企业对网络的要求层级，数据传输要求等等。　　在了解了软件架构的这些本本上的东西，那么我们来搭个应用看看。以我碰到的项目为例，当然一些技术是可通用的，但这个是一个个案，不代表适用您的项目，只求交流。 　　先交待一下，假设：　　1．系统是建立在微软的架构基础上的，MicrosoftSystemArchitecture(MSA)　　2．它是一个B/S的N-Tier架构　　3．同时它是一个企业级应用系统，信息平台　　在考虑使用N-Tier的过程中，由于系统中没有涉及到要使用跨平台的应用，在可预见的将来也不会有，所以就把WebService拿掉了。WebService从3年前就开始用，但是几个问题还是没有解决：　　1.WebService从接口继承，如果两个或者两个以上的Webservice同时从相同的接口继承，由于WebService的自描述性，每个WebService都重新生成接类，就成了两个不同的类。　　2.WebService本身不能被继承，同样由自描述性搞的。　　3.WebService要真正做到跨平台那就需要做到跨语言，从Java到C#的转化时数据类型转化是相当麻烦的，基本类型之间就有很大问题，如byte，sbyte(C#)中，当Java中根本就没有sbyte。早在一年半前曾用相异平台做了一个应用系统，为了处理这个数据类型转化，我曾想去掉WebService。　　4.WebService方法不能重载，这个很恐怖。　　5.WebService的安全问题。　　尽管WebService有其种种好处，连现在的网格都开始醉心于它，更不用说SOA了，本身就是以WebService为核心展开的。但是，WebService到底能走向哪里？　　在开始架构设计之前，需要了解一下架构是什么，按照IEEE标准的定义是：Architecture是一个系统的基本组织，它蕴含于系统的组件中、组件之间的相互关系中、组件与环境的相互关系中、以及呈现于其设计和演进的原则中。(Theembodiedfundamentalorganizationofasysteminitscomponents,theirrelationshipstoeachother,andtotheenvironment,andtheprinciplesguidingitsdesignandevolution.[IEEEStd1471-2000])　　一句话，架构就是软件产品的骨架，这个骨架把组件、环境纳入其中，使之能有效得发挥它们的技能。　　从架构、技术和需求的关系来看。一个软件产品包含了需求和技术，而架构同样是要包括需求和技术的，只是它没有全包全括这个需求和技术，应该是一些整体性的需求，尤其是一些非功能性的需求。如果在构建架构的时候，架构设计人员根本不了解企业使用的目标软件的整体需求，企业使用目标系统的整体环境，那指望架构适用显然有点强求。　　具体的了解一下这个层的关系，以及构建架构时上文提到的需要涉及到的问题。　　1．PresentationTier　　表示层分层两层，UIComponents可以直接看作是HTML，UIProcess这里不是MVC，而是code-behind类。在表示层，就我所碰到需要处理的问题有：　　l)MVC(Model-Views-Controller)　　Asp.net下是否需要使用MVC一直是一个有争议的问题。Asp.net的特点是事件驱动与Code-behind，Code-behind本身就可以理解是MVC中的Controller，但是没有体现MVC的好处来，微软缺乏双向赋值的考虑。UIP(UserInterfaceProcessApplicationBlock)是微软社区里的一个开源项目。严格说来它只是一个管页面流转，不是一个MVC的框架。Maverick.net是一个比较轻量级的框架，简单实现了MVC，但是也有其缺陷，而且比较老了。还有Castle的框架，Spring还没有完整推出。 　　2)国际化　　如果是一个多语言的企业应用，那就需要国际化支持，.Net提供了很好的国际化支持。　　3)页面元素格式统一转化与验证　　比如日期形式从“yyyy-mm-dd”需要转化成“yyyy/mm/dd”，如果没有一个统一配置的地方，那页面就要伤筋动骨了。　　4)安全，在后面的安全节有介绍，这里先按下不提　2．WebService　　这里不再说了，已经去掉了。　　3．BusinessTier　　Business层是应用系统的核心，包括体现用户的商业运算逻辑的BusinessLogic；还有保障BusinessLogic运算安全和完整性的事务，日志，安全验证，性能管理等辅助逻辑。在设计BusinessTier的时候要考虑的问题有：　　l)可扩展性　　i.将接口进行到底　　在Business实现层之上，建议抽出一个接口层，遵循一般原则提倡接口编程，BusinessComponents都从一个或者一个以上接口继承，在调用代码中调用类工厂产生实例，在代用代码中建议不要使用此类的new操作符。　　ii.设计模式的应用　　适当应用模式，可以增加程序的灵活性，可扩展性。（在设计中经常用到Factory，Adapter，Singleton，Decorate，Command，Template等模式，建议可以重点了解一下这些模式。有时间可以详读GOF的设计模式）Example:从Business结构，划分为CRUD（增查改删，称为“四架马车”）和其它具体业务实现的Components，这里用Decorate模式，简单实现一个继承的过程，如果你要继承两个基类，可以考虑使用此模式，当然，即使不继承基类，用Interface+Adapter同样可以实现多继承。　　2)区分业务逻辑　　所谓区分业务逻辑实际上在上面的描述中已有提及，大致上可以分为两类，一类是商业业务逻辑，一类则是软件功能性逻辑，起辅助保障上述逻辑用，如事务，日志，安全验证等。第二类的使用频率高，实现又是非常类同的，如果提取出来，那复用价值是很高的。这种区分早有定义，把抽出来的部分称之为CrossCut或者叫Aspect。这个就是AOP在事务，日志，安全验证方面的应用。先来看一下CrossCut（Aspect）的结构表示图：3)MS组件、服务的是应用　　这里的服务和组件主要是讲是在Applicationinfrastructure中的元素，如COM+，MSMQ，IIS，AD等等。这里常用到的两种COM+和MSMQ。　　i.COM+　　如果应用系统需要使用分布式事务，或者的确希望把组件编程一个服务，那么就可以使用COM+，当然这也造成部署的不方便。　　ii.MSMQ　　消息队列，主要使用于异步处理。比如，在业务处理过程中要发一封邮件，如果采用消息队列来做，不管当前的邮件服务忙，还是根本就不能工作，用户可以转回来处理其它业务而不必等待。 　　4．DataAccessTier　　数据访问层，是用来隔离系统访问不同的数据媒体或者系统外服务（比如，其它系统的WebService等）用的。　　l)将接口进行到底　　2)or-Mapping,ORMapping所带来的好处这里就不多说了。我们先来谈一下下面的几个概念。　i.DomainModel&TableModule　　根据MartinFlower的定义DomainModel：Anobjectmodelofthedomainthatincorporatesbothbehavioranddata.　　-RichDomainModel：是上面的这种定义　　-AnemicDomainModel：这种方式方法和Data是分别在不同的类里实现的，OR-Mapping就是建立在这种方式上的。　　ii.NHibernate　　NHibernate是OR-Mapping的一种实现，是一个比较齐整的框架，是从Java的Hibernate转过来的。当然.Net下还有其它的OR-Mapping实现，如Gentle.net　　iii.SqlMapper&IBatis.Net　　SqlMapper为DomainModel和TableModule两种方式一个折中方案，它可以以面向对象的方式直接处理自定义数据实体对象，同时可以根据与数据源与业务实体的映射关系执行手写的Sql语句，这样完全使得我们可以针对具体数据源做优化，对于复杂操作同样可以胜任。IBatis.Net是SqlMapper的实现。　　3)or-Mapping与复杂查询的问题　　OR-Mapping带来的好处是在CU，D方面还可以，毕竟大批量的删除一般不会经常出现，但是R方面就是一个实实在在的问题，面对复杂查询的执行效率也是一个问题。蹩脚的解决方案是两条线，R这方面采用TableModule这种方式来，而CUD才用对象。　　5．CommomTier　　是系统性能、检测、跟踪用的，有些可以采用AOP来解决，如计数等。　　三．企业级应用　　企业级应用一般的特点是数据量大，交互操作要求高，在线用户量比较大，用户地理分布较广。这就要求我们在设计架构是要考虑其安全性，数据存储要求，集群，与其它应用交互。　　l)安全性　　安全性是一个多角度多方位的立体式问题，应用体统的安全性，是与其它安全性一起才构建起来。一般安全分成几个层级：　　1.网络安全性　　-网络服务的安全，如http，ftp，mail　　2.操作系统安全性　　-访问控制表（ACL）安全控制，主要通过组、用户权限控制完成　　-网络访问安全控制，在域模式下　　3.数据安全性　　- 数据库系统安全　　-数据访问权限安全　　-数据加密　　-数据备份　　4.应用系统安全性　　-Asp.net的安全性　　-安全通信　　对于上面列举的一些安全层次，有些是在系统的使用过程中要注意的问题，并非在架构设计时能做到的，但是，可以做为输入项来构建一套安全的系统。下面主要来讲一下如何用Asp.net来构建安全的系统。　　1.Asp.net安全性　　-ASP.NET身份验证，包括Windows、表单、Passport和无身份验证　　-ASP.NET授权，包括URL授权、文件授权、主体权限需求和.NET角色　　-标识和主体，主要是通过编程方式来进行(标识和主体对象必须实现IIdentity和IPrincipal接口。这些接口在System.Security.Principal名称空间内定义)　　2.在采用windows验证时，Asp.net可以在IIS上配置一些安全选项。　　3.安全通信　　-Internet协议安全(IPsec)　　IPSec提供传输级安全通信解决方案，可以用于保护两台计算机之间传送的数据安全。VPN也是在这个协议基础上构建的。　　-安全套接字(SSL)　　这通常用于保护浏览器和Web服务器之间的通道安全。结合IIS和证书，就可以配置https协议使用。　　-远程调用(RPC)加密　　分布式COM(DCOM)使用的RPC协议提供了一个身份验证级别（数据包保密性），它对客户端和服务器之间传送的每个数据包都进行加密。　　2)存储　　企业级应用级的存储特点是I/O访问要求高，数据容错性要求高。所以，就有可能使用比较高端的存储设备以满足存储要求，硬件不是软件系统架构的内容，但是Raid等使用却是软件架构必需考虑的。 　　3)集群　　同存储要求一样，对于一个大型的应用来说，大访问量，分布式数据应用，就可能需要使用集群。　　对于分布式数据库的需要使用数据库集群，可采用数据库系统本身得到解决。　　对于分布式部署需要应用服务器集群，这在代码实现上就要先期考虑到Session在分布式部署环境下的同步问题。　　4)与其它应用交互　　在设计架构时，还要考虑与其它系统的交互。　　1．使用其它系统的接口　　2．与原有系统的整合　　3．开放接口，供其它系统使用2009年软件架构师必须了解的十个新领域在云计算、社会化媒体等新技术风起云涌之下，软件架构将往何处去？　　著名的Web2.0观察家DionHichcliffe认为，2009年将是软件架构的大变革之年。传统的n层架构、SOA、编译型语言、关系型数据库等等都将在2009年开始向新的替代品转换。也许，喜欢2.0这个字眼的Dion心里实际上是在想说软件架构2.0了吧。　　他的blog列出了十个软件架构师必须了解的新领域：　　云计算（比如AmazonEC2）　　非关系型数据库（比如CouchDB，AmazonSimpleDB）　　下一代分布式计算（Hadoop）　　面向Web的架构（WOA）　　Mashup（混搭）　　开放API（【按】原文是OpenSupplyChainsviaAPIs）　　动态语言（【按】还包括了Erlang？）　　社会化计算　　群众外包（Crowdsourcing）与用户制作（【按】）　　新的应用模型（【按】似指Widget、Gadget这些）　　虽然这篇文章在TheServerSide上很被实干的程序员和技术人员们嘲笑了一番，但我倒是认为，如果能多了解一些这种比较宏观的前瞻，结合自己的实际思考一下，是非常有益的。当年我的同行O'Reilly出版公司（现在已经改名媒体公司了）的老板TimO'Reilly最早创造Web2.0这个名词的时候，还不是有很多人骂他空谈？可是如今呢，从Web开始，2.0已经席卷社会各个层面，政府2.0、企业2.0甚至教育2.0都已经有人提出来了。软件架构2.0？我看很多方面变成主流，将是迟早的事情。2010年下半年系统架构设计师考试试题分析本次考试是系统架构设计师开考以来的第2次考试，从形式上来看，系统架构设计师的考试风格已趋于稳定。这表现在上午考试各科目知识点分布稳定。案例分析维持1道必答题+4选2模式，论文维持4选1模式。　　1.信息系统综合知识试题在本次考试中，值得特别注意的是：在嵌入式系统部分，开始考查到硬件基础的一些知识点，这是在考纲中没有做要求的部分，已超纲。但依据软考的传统出题风格，这属于正常现象。 2.案例分析与设计试题　　试题一　　试题一仍然为必答题。本题是一道架构设计方面的试题，考查的内容是常见架构风格的选用。　　问题1考查架构风格的基本概念与主程序-子程序、管道-过滤器的特点。这一空属于送分题，难度较低。　　问题2考查主程序-子程序和管道-过滤器优缺点对比。这两种风格的优缺点包括多个方向的很多内容，但要应对该题，并不需要我们面面俱到的把每一个细节记清楚。只要了解两者的核心思想即可。　　具体的优缺点可以看《软件体系结构原理、方法与实践》（张友生，清华大学出版社）。问题3是补充架构设计示意图。其实这个图要表现出来的，无非就是利用管道-过滤器架构，需要处理的信息的操作有哪些，按什么顺序排列。　　试题二　　试题二为一道软件系统数据架构建模的问题。实际上是考的分布式数据库。　　问题1考查数据架构的基本思想，也就是要说明集成式数据库与分布式数据库的优缺点。　　问题2考查分布式数据库的设计。其中涉及到单点故障的概念，单点故障是指系统中由于某一处的故障，导致整个系统不能正常运行（注意：并不是系统的每一处出错，都会影响到整体故障的，有时只是局部功能的丧失）。例如平时我们局域网中的交换机出现故障，就会导致整个局域网无法通信，这就是一个单点故障。在进行设计时，单点故障的识别，就是看这一点出错，会不会导致全局问题。然后针对此处进行相应的改进措施，如做局部热备之类的。问题3考查考生的实际设计经验，可扩展性是设计任何系统时需要考虑的一个因素。　　试题三　　试题三为一道嵌入式系统的试题。　　嵌入式的试题通常都是大段的题干说明加多个图表，在有限的时间下，很少有人选该方面的试题，因为看完试题就要花费不少的时间，所以嵌入式的试题一般只有本身是做嵌入式相关开发的考生在选答。　　本题以汽车电子基础软件开发为背景。问题1中给出了两种开发流程，要求考生指出更为合理的，其实选择的依据已经列在问题中了，即“尽量满足并发、可多次迭代的特性”。　　问题2需要从层次化的上下层调用关系来答题。问题3要求考生有相关的应用经验。　　试题四　　试题四为一道系统设计与开发工具集成的问题。其中涉及到ESB的功能特点以及设计模式的相关知识。ESB是SOA的一种实现方式，目前SOA作为一企业应用集成的架构，越来越受人们的关注，所以也是系统架构设计师与系统分析师考查的一个热点。　　本题中，第1问要求考生说明ESB的主要功能，同时要结合题目给出的信息说明为什么选用ESB架构，这实际上就是让考生分析ESB的优缺点。　　第2问涉及到集成中具体的一些问题解决，这其实是我们在进行架构设计或系统集成时经常采用的方法。即根据一系列的需求，说明解决方案，再通过对这些解决方案的整合，形成架构，或作为架构评审的一些依据。 第3问考查设计模式，设计模式的级别低于架构模式，用于解决系统中的一些局部设计问题。关于设计模式，我们需要掌握设计模式的应用场合、作用、结构。详细内容请参看《系统架构设计师教程（第2版）》（张友生，王勇，电子工业出版社）。　　试题五　　试题五考查的是系统可靠性问题。　　可靠性是软件质量属性中非常重要的一个，无论是进行系统架构设计还是架构评估，它都是一个核心指标。所以这个知识点也是架构考查的重点，上次考试它以论文题形式出现，本次考试中，案例、论文各有一道是可靠性方向的。　　可靠性技术通常包括：可靠性的计算、检错技术和容错技术，本题中，这三个方面都涉及到了。　　问题1要求解释可靠度与失效率，这是纯概念题，难度较低。　　问题2要求解释动态冗余和N版本程序设计技术，这两种技术即可用于提高软件的可靠性，也可用于提高软件的可靠性。至于可靠度计算，我们只需要了解两种最基本的，即串联可靠度计算与并联可靠度计算，然后把两者结合起来，就可以解决串并联混合的复杂可靠度计算。如本题的第2个计算，就是属于先并后串的模式。问题3考查检错技术，该技术用于检查系统出错状态，以便采用容错技术来对已发生的错误进行修正，以达到容错的目标。　3.系统架构设计文试题　　试题一 论软件的静态演化和动态演化及其应用本题考查的知识点是软件演化。一个软件系统开发完毕正式投入使用之后，如果需求发生变化，或者要将该系统移植到另一个环境运行，且新环境的需求也有相应的变化时，就要对软件进行修改，这就是软件演化。软件演化是一个程序不断调节以满足新的软件需求的过程，也就是对一个已有软件不断进行修改、补充、完善以适用新需求和环境变化的过程。由于软件演化一词并不多见，所以难倒了很多考生。其实换一种讲法，可能大家就倍感亲切了--“软件升级”，其实演化的本质就是在升级。既然是升级，静态演化与动态演化是怎么回事也就好理解了，即升级时是否停止系统的运行。所以如果有了上面的基础概念理解，写该论文的方向也就明晰了。　　试题二 论数据挖掘技术的应用　　本题考查数据挖掘技术的应用。其实从应用的角度，或者从商业的角度来看，数据挖掘这一词在业内出现的频度已不如以前那么高了。因为数据挖掘通常是不独立进行的，它涉及到数据源的获取问题，即先要建立一个数据仓库，再从中“挖”数据。这其实就是我们经常看到的是“BI”--商业智能。商业智能我们可以理解为是：数据仓库+数据挖掘。这也就确定了本文的项目背景。　　文章最好是把这一层关系讲清楚，写商业智能的项目，如果没有项目经验，直接杜撰出数据挖掘项目来写文章，风险会很高，很容易让人看出文章的“做假”行为。除此以外，文章可按传统的写法组织内容。即按问答方式组织文章的主体脉络，并加入项目信息，同时做好承上启下的句子进行段落衔接。对此，相信希赛教育的学员会有更深的体会。关于数据挖掘技术的详细内容请参看《系统架构设计师考试全程指导》（张友生，王勇，清华大学出版社）。　　试题三 论大规模分布式系统缓存设计策略 　　本题考查缓存技术的应用。缓存技术的应用非常广泛，从硬件到软件，从分布式系统到集中式系统，从操作系统到数据库，甚至于网络应用都能看到它的身影。它出现使得我们的应用系统性能大幅提升，提高了用户体验度，也节省了很多资源。　　在本题中，要求以大规模分布式系统为背景来应用缓存策略。这种设计中，不仅需要考虑常规的缓存技术的应用，也可以结合分布式数据库进行论述，因为缓存，是离不开数据的。分布式数据库系统，数据分布在不同的位置，当数据需要从一个结点到另一个结点时，需要开销，需要时间，这样缓存技术就有了他的应用空间。与此同时，本题还有一个值得关注的细节，即文章的内容安排，要以理论结合实践的提问作为主要响应对象。也就是说文章应该着重论述问题3，而问题2只需要按简答题的模式进行说明即可。　　试题四 论软件可靠性评价本题的考查方向是软件可靠性。这个主题与上次架构考试中的第4个论文题是一致的，都是可靠性，但需要注意的是，主题方向虽然一致，但要求却不同。这也就意味着同样的一篇文章，用在上次考试中合格，但用在这次，可能就无法合格了。这也是我们平时在做论文训练写作时一再强调的一点，论文的写作，不仅要看论文的主题，更重要的是紧扣试题中的3个问题来组织内容。　　在本题中，侧重点是可靠性模型的选择，通常选择一个模型时，会有相应的理由，其实理由就是“这个模型的优点与项目的实际情况非常符合”。这是一个通用的原则，在描述此段时，记住这个原则，并将该表现的信息合适的表达出来即可。当选定模型以后，应该说明，在使用这个模型时，遇到了什么问题，这些问题又是如何去解决的，这是真正体现作者功力的地方。与此同时，不建议把这个项目写得非常的完美、无懈可击，应留个BUG，即不足之处。到最后总结时，指出这个不足之处，再辅以解决方案，效果就非常好了。3层架构中各层职责分配用例解析 假设有这样一个应用场景通过分页的方式显示文章列表　　需求：　　1显示文章标题作者发布时间　　?如果标题超过15个汉字则截断并显示...　　3表如果是当前浏览的用户是作者本人还需要在后面显示编辑和删除按扭如博客园里的评论.　　现在的问题是在3层架构中我如何合理的分配他们职责呢？下面就这个问题做个分析在这篇文章中我刻意使他不会涉及到一些特定的web开发技术，所以不论是使用asp技术和还asp.net技术这篇文章应该是都适用的。 　　分析：　　通过在表现层调用业务对象的方法返回一个文章的实体的集合　　文章实体对象中应该有个作者的属性　　对于需求3这里需要完成2个动作。一是判断当前显示的文章是否是作者本人的，假如使用方法IsAutor(username)；二是如果是的话要完成控制按钮的显示，假如使用方法ShowControl()来完成。ShowControl这个应该在表示层实现相信这里是没有什么疑问的。判断作者这个功能可以直接使用文章实体对象的作者属性去判断它是否等于session("username")就可以得到结果。但是这个职责应该分配给业务逻辑层还是表现层或者是实体对象来完成呢？我们挨个来分析好了。　　1分配给业务逻辑层：判断文章的作者和和我们的业务有关吗？　　我认为回答这个问题的一个方法是把它放到不同的业务环境中去检查它的实现方式是否相同如果都是相同则说明它和业务无关。那么它就不属于业务逻辑层的职责。　　例如：在论坛里、贴吧里、B2B里面、我们判断当前登陆的用户是否某一文章的作者不都是用登陆的session来与文章的作者的属性做比较的吗。当然我们也有可能使用cookie来保存当前登陆的用户名，这时就要使用COOKIE里面的内容来做判断了。但是不管我们是用cookie还是用session或用其他的方式来保存当前用户。这些都是和业务逻辑无关的，这只是技术上的一种实现手段，所谓的业务逻辑应该是业务员或老板最精通和了解的东西。但是这些显然都不是他们所擅长的。　　所以我断定这个职责不属于业务逻辑层的。　　2分配给表现层：想把他放到表现层的原因是由于要完成文章列表的显示需要同时做IsAutor(username)和ShowControl()这两个动作。但是我们已经确定了ShowControl()这个是在表现层实现，而完成IsAutor这个功能所需要的信息session和作者名，在这里都具有，不需要做参数的传递。高内聚原则告诉我们相关的东西应该放到一起。信息专家模式告诉我们如果某个对象具有完成某项职责所需要的信息那么就把该职责分配给这个对象。结合高内聚，低耦合和信息专家这3个面向对象通用职责分配原则的知识所以给了我在表现层实现的理由。　　3分配给实体对象：为什么不把他分配给实体对象是因为应用中的各个层都需要用实体对象来进行通信，而且我所看的3层架构案例中一般情况下实体对象都是只有属性。另外OOD追求的目标是功能内聚数据耦合。所以我没有把他放到实体对象里。　　既然这样那为什么会考虑这种方式呢？因为当系统应用的其他地方需要输出文章列表时候我不想重复的来写这段实现代码。因为在.net里面一个aspx页面就是一个类.如果能有一个类可以把这段代码放进去让我用的就new它然后调用它的方法来完成这个功能就好了。　　综合以上分析我决定采用第二种解决方案，但我并不认为这个一定是对的或许还有更好方法，但是由于目前掌握的知识所限我没能发现，我就暂且先把它归纳到表现层完成。希望以后能找到。　　如果各位看到了这里，因为我是新手不确定说的是否正确，所以其他的一些分析我没发布出来。由于项目需要最近疯狂的在补这些知识，希望各位能给予一些指导性意见，谢谢大家！IOC字符和原子数据注入（面向具体编程人员）　　17.1.2 IOC字符和原子数据注入（面向具体编程人员）　　1)属性值注入　　2)集合值注入　　3)哈系MAP注入　　4)构造注入　　17.1.3模式应用IOC工厂模型（面向具体编程人员）　　1)BeanFactory支持两个对象模型　　2)XMLBeanFactory　　3)ClassPathXmlApplicationContext　　4)FileSystemXmlApplicationContextIPTV系统架构的分析与研究1引言　　IPTV业务是伴随着宽带互联网的飞速发展而兴起的一项新兴的互联网增值业务,它利用宽带互联网的基础设施，以家用电视机和电脑作为主要终端，利用网络机顶盒(STB,Set-TopBox)，通过互联网协议来传送电视信号.提供包括电视节目在内的多种数字媒体服务。IPrv简单来说就是交互式网络电视,它能为用户提供电信级的服务和使用简便的电视式体验。　　2IPTV系统概述　　到目前为止，IPTV虽然还没有一个十分明确的定义,但IPTV实现电视的网络化却是不容置疑的,它的具体表现形式一定是基于IP网的流媒体服务。整个IPTV系统的中心任务是如何为用户提供流媒体服务。围绕这个问题,必须充分考虑电信级系统所必要的一些保证体系。如运营支撑系统、网络管理系统等。一般认为IPTV系统在逻辑上可以划分成五个部分:媒体处理子系统、媒体管理子系统、电子节目单服务子系统、运营支撑子系统、流服务子系统。另外，为了更加直观地展现系统的协同工作情况,还可以根据设备的功能。将系统的相关组件按照功能划分为以下四个部分：媒体平台层服务支持层、运营支撑层、终端层。实际上，完整的IPTV系统还应该包括IP承载层。虽然IPTV系统的运作和IP承载层息息相关,但IP承载层并非IPTV系统独有的，只是IPTV系统对其有一些相对特殊的要求，例如对组播的支持、高带宽的需求等.所以本文中将不对其做详细介绍。　　3IPTV系统逻辑结构图l是IPTV系统的逻辑结构。它可以帮助大家更好地理解系统的架构、主要功能和实现方案。　　（1）流服务子系统流服务子系统是为用户直接提供流服务的子系统。是系统的核心。无论是视频点播，还是直播电视，或者其他的增值业务，IPTV系统最终都将通过流服务子系统来提供服务。终端总是和流服务子系统进行流媒体的交互。其他的子系统都是直接或间接地为流服务子系统提供服务的。流服务子系统对整个流媒体的服务提供保障，它是系统的关键逻辑组件，其他的相关子系统都是为其服务的，并围绕其设计的。 　　（2）媒体处理子系统媒体处理子系统的主要任务是将原始的节目源转化成符合规定编码格式的流媒体节目源。原始的节目源可能是电影的拷贝，也可能是DVD片。还可能是数字或者模拟的视音频信号源(数字电视或者模拟电视信号源)，媒体处理子系统的任务是将它转化成适合在互联网上传输的视音频格式的文件，用的编码格式必须是压缩编码方式.例如MEPG一4、WMV或者H.264等，今后的趋势是采用统一的H.264编码格式。当然系统对于其他格式的媒体文件也都是可以兼容的，关键是终端要支持相应的解码程序。媒体处理子系统本质上就是媒体进入到IPTV系统的入口。无论是TV节目。还是电影节目，都需要通过这一子系统处理后方可进入系统。之后才有可能为IPTV的用户提供相关的流媒体服务的资源。　　（3）媒体管理子系统　　媒体管理子系统的主要任务是对媒体资源进行管理。包括媒体的内容管理、计划的编排、EPG信息的采集与生成、报表信息的采集与生成。媒体的内容管理，包括媒体内容通过什么策略来进行存储和分发，比如在系统中如何保存、存储多少份拷贝、位置信息如何索引等，是关系到媒体存储和分发效率的关键因素，也是设备厂家重点考虑的问题之一。计划的编排，一般和TV节目相关，如果系统要提供时移电视的功能，必然要对电视节目进行录制，那么计划的编排目的就是为将来要进入存储区域的这些内容按时间段进行分割，时间段的划分一般基于电视台的节目表，这样可以保证这些文件在时移电视点播的时候，可以按时段和节目名称进行点播，按时间收看电视节目。EPG信息的采集和生成．一般是通过媒体内容来定制EPG画面，这样可以控制哪些媒体节目出现在EPG界面，可以为用户所使用，同时，它们可以根据一些编排计划。在界面中生成相关的节目单，这个就有点类似与传统电视的电视节目预告，它是EPG画面的资源。根据点播情况它可以生成热门影片列表，根据节目导入系统的时间可以生成最新影片列表。报表的信息采集与生成，可以理解成通过对媒体资源的状态、使用情况等数据库进行统计的一些情况，它的主要目的是通过查询数据库生成指定格式的报表文件，以供运营者进行相关的分析。比如，它可以提供影片的点击频率从而可以制定策略，使点击多的影片在系统中增加拷贝的数量。以保证为用户提供更优质的服务，而点播次数少的。则可以减少系统的拷贝数量，提高磁盘空间的利用率。　　（4）电子节目单服务子系统电子节目单服务子系统的主要任务是为用户提供业务的入口服务，是直接呈现给用户的界面，是供用户选择的系统服务索引，它同时要协助完成用户的接入请求。电子节目单子系统呈现给用户的是在某些权级下，可以享受到的服务。比如，如果是包月用户，那么电子节目单服务子系统将把所有的提供给包月用户的媒体资源以页面的方式呈现给该用户，用户也可以通过各种关键字进行查询。当然，用户也可以通过增加付费的方式，选择超出服务范围的媒体或服务资源。或者，在用户的服务范围内，用户还可以自行控制。对一些不适合儿童观看的影片进行密码保护，阻止儿童观看。 　　（5）运营支撑子系统运营支撑子系统是为运营商的运营管理服务的系统，包括用户管理、计费管理、定价策略管理、网络设备管理以及运营相关的一些管理工作。这部分无论是对增值业务运营商还是电信运营商都非常重要，一方面它管理着为用户提供服务的这些服务器和网络资源，另一方面它需要对相关服务的资费策略进行定制。资费管理功能的强弱。通常对于运营商的业务竞争力有很大影响，支持的策略越多样化，越能吸引更多的需要，同时适应市场竞争策略的变化，比如临时打折、业务捆绑。与此同时，一般它还会管理用户的资料，比如用户的开户、资料管理、状态变更，能够设定一些阀值来使系统自动开关用户的业务，避免用户的恶意欠费。在运营支撑系统中，运营商还希望能够对第三方的～些网络设备进行管理(一般来说.现在的系统是综合的系统，多厂家设备的融合是非常普遍的现象)，还有可能要求和原有的一些前台应用系统和后台营账系统进行一些自动数据传递的接口功能，从而实现平台的统一运营支撑系统与客户的一些使用习惯相关，与相关业务相关，正是因为个性化的原因，一般运营商会根据要求进行一些定制，采用一些开放式的架构，可以方便地进行相关模块的定制，满足各种个性化的要求。　　4IPTV系统功能结构　　前面介绍过。IPYV系统按照功能结构可以分为媒体平台层、服务支撑层、运营支撑层和终端层。但实际上，系统的分层结构根据对业务模型的构建的不同和实现方式的不同，会有所不同，平台之间的功能只有模糊的差异，并没有清晰的界限，比如说，内容编码服务器到底属于媒体平台层还是服务支持层，就存在分歧：而网络管理系统属于运营支撑层还是属于服务支持层，也会有不同的声音。明确地界定这些层所包含的设备，依赖于系统架构工程师，并和系统的相关业务流程息息相关，在这里只做了一些共性的探讨。图2是一种实现方案的结构，大家可以对整个IPTV系统有个大致的了解。在后面则将分别介绍各层的一些详细内容。　　(1)媒体平台层　　媒体平台层一般主要由一些和媒体相关的服务器组成。就目前提供的相关服务，主要包括媒体存储和分发的媒体工作站(有些厂家也称之为流媒体服务器)，媒体编码加密和导人的内容工作站。考虑到今后的业务扩展，还会增加更多的内容，比如说如果增加网络可视电话业务，必然还要增加相关的服务器来负责可视电话业务的媒体流处理；如果增加网络游戏服务，还需要相关的游戏服务器来处理相关事务。　　（2）服务支持层　　服务支持层。也称作在线业务支持层，一般可以采用分布式结构位于中心机房和城域网机房。其主要的任务是对IPTV相关服务进行控制：一方面是保证合法用户可以通过正常的渠道得到相关的服务，对用户进行认证和授权；另一方面，通过认证和授权措施来防止非法用户接人系统。一般来说，服务支持层包括所有的和媒体服务相关的一些服务器，主要包括DRM系统(包括许可服务器和其他的对密钥进行引用和控制的组件)、客户自服务服务器、网络管理服务器、媒体引人系统的一些内容编码服务器、认证服务器、EPG服务器等。DRM系统主要用于流媒体的数字版权管理，许可服务器主要用于License的分发，认证服务器主要用于用户的业务接人认证。其他的服务器都是为用户的媒体服务提供在线的支持。　　（3）运营支撑层　　运营支撑层，也称作后台服务支持层，一般位于用户的数据中心和网络管理中心。它是为业务运营和网络管理服务的，是运营商的业务管理和控制的核心平台，要适应不同的运营模式和管理风格，通常情况下要考虑更多的业务模型、管理模型等方面，运营商一般还会提出很多定制性的要求。一般主要包括客户管理、计费账务管理和媒体资产管理这几个相对独立的模块。一般来说，这三部分都是OSS的功能模块。OSS是一个为运营商进行节目管理、工作流管理、用户管理、计费及账务、用户自助服务的可伸缩、可扩展的业务支撑平台。同时，它提供各种后台解决方案，如用户管理、业务管理、资费政策管理、销账处理、营收管理、结算分摊、数据分析等功能。 　　（4）终端层　　EPG的客户端软件、解码设备(支持MPEG一1／2／4、WMV、REAL、H.264等格式)、媒体播放器与系统中的服务器进行交互从而控制媒体服务的进程，并且通过STB将媒体流数据转换为Tv终端支持的视频信号。未来还将包括3G手机等终端。终端层是整个系统用于和用户交互的平台，也是呈现在用户侧的惟一设备，其设计除了考虑技术层面，还要考虑很多因素，比如经济性、美观性等。终端层的主要设备一般是机顶盒。当然，如果是PC用户，只需要一套支持解码和播放技术的软件就可以了，可以认为它是一个软件机顶盒。　　5结语　　IPTV系统是构建在现有互联网上的业务系统，它必须适应现有的IP网络构建，这样才能保证系统的可靠性和稳定性。一般来说，IPTV的网络是一个分层的网络结构，分为骨干网层、城域网层和接人网层，IPTV系统的部署一般也和这种分层结构相吻合。　　（1）数据中心位于骨干层，部署相应的OSS和网管系统，同时些内容编码服务器、中心媒体服务器以及相应的服务支持层功能实体可以集中部署在这里。如果网络规模大，也可以将部分组件分布式部署延伸到城域网。　　（2）分布式的媒体工作站可以位于城域网层或者接人网层，取决于网络的规模，初期可以位于城域网，后期可以在城域网和接人网分层部署。　　（3）终端设备位于接人网中。这样的结构可以有效利用现有的各种网络资源，加快部署的速度，保证低成本地部署系统的同时还可以确保系统的可扩展性。　　IPTV系统是一种基于宽带网络的新型增值业务平台，伴随着互联网技术的发展，必然会不断发展，虽然其逻辑结构不会发生大的改变，除非互联网的架构发生大的改变，但逻辑架构下的功能模块必然会随着业务的发展而改变，适应用户需求的功能会不断被开发出来，IPTV业务也将在不断的业务创新中不断发展，在个性化的家庭娱乐中占据一席之地．为用户打造一个全新的娱乐甚至商务平台。ObjectRDBMSMapping原理简介介绍　　从微软开始推出.NetFramework来对抗Java开始，其主要卖点之一就是C#是一个可以快速的进行RAD开发，它可以使用数据感知组件DataSet，OleDbConnection等组件来非常快速的开发数据库应用。通常来说，只要在界面上摆放一些数据感知组件如DataGrod，设定同数据源的连接，以及对应的表和字段，一个简单的程序就搞定了。RAD的数据库开发方式非常适合于简单的数据库应用程序开发，比如桌面型数据库应用，以及Client/Server应用的原型开发。但是对于复杂的应用程序来说，使用RAD方式开发会产生很多的问题。　　首先，使用RAD和数据感知组件，就意味数据表现层同数据库表的紧偶合，每使用一个数据感知组件，都相当于将数据的显示视图偶合到了数据库的某个表或者某个字段上，这样构建的系统的扩展和维护的能力都非常不好。　　任何对数据模型的改变都会导致对所有绑定到改动的表或字段的数据感知组件的修改， 而从数据集中读取数据，通常是根据字段名来获取字段的对象的值，如DataReader["Spell"].ToString()，该方法是以字符串来获得数据集中的字段值，这时编译器是无法帮助我们发现这种组件的绑定是否全部被修正了，即便使用的字段名称错误了，编译器仍然会认为代码没有错误，这样需要改变的组件同库表之间的绑定很难被全部发现，经常会有所遗漏，而由改动引起的错误通常只能是在运行时才能被发现，这就意味着要花更多的时间才能发现错误。而且如果测试时，错误的代码没有被测试所覆盖的话，则错误可能要到客户使用时才会被发现，这时造成的后果可能已经无法挽回了。　　而使用面向对象的数据库开发框架的话，对业务域对象的操作都是通过对象的属性或者方法来进行的，如AObj.XXX方法，对对象属性名称或者方法进行了改变的话，编译器会帮助我们找到所有对该对象的不正确的操作，这意味着可以更早地发现和解决bug。　　同时，使用数据感知组件，意味着同数据库的特有特性的紧偶合，比如为了减少代码量和提高效率，经常需要使用一些数据库平台相关的特殊sql，或者将一些复杂的sql写成平台相关的存储过程。　　另外，使用基于数据集开发的系统象基于面向对象开发的系统那样直观和容易理解。　　面向对象的数据库开发框架　　近年来，越来越多的人认识到使用面向对象的数据库开发框架来进行大型数据库应用的开发有着很多的好处。在项目设计阶段，使用UML建模语言设计业务域对象模型，从模型出发，定义业务域对象，然后使用标准的美观的组件对业务域对象进行操作，设计某些方法将业务域对象保存到数据库，或者从数据库加载，这就是通常所说的ORMapping，对象－关系映射问题。　　同RAD开发方式相比，面向对象的开发方式比较适合信息模型比较复杂的大型系统，同时面向对象的数据库开发框架可以很容易的实现Lazyload的延迟加载技术，因此会产生更少的网络信息roundtrip，提供较好的性能。另外，框架一般都提供数据库平台无关性的支持，适合于对移植性有较高要求的开发。此外，可以将GUI同数据库解偶合，更容易扩展和维护。不过缺点是对程序员的素质要求的更高。　　一般的面向对象数据库开发框架的要求：　　对象持续性：框架必须能够以对象的方式存取数据，能存取复杂对象，如复合对象，支持对象之间的关联，比如继承，聚合，关联。　　支持对象查询：框架应该提供一种方式可以根据条件查询复合对象以及对象集合。支持标准的对象查询语言，如ObjectConstraintLanguage(OCL)或者ObjectQueryLanguage(OQL)。　　支持对象主键：大家都知道在关系型数据库中，主键可以用来唯一标识一条数据记录。面向对象的框架中也应该有一个对象主键来唯一标识一个对象。　　支持事务：创建还必须支持事务，一个交易必须是原子级别的，或者完全成功，或者完全失败，支持类似于数据库的提交和回滚操作。交易结果要求是一致的、独立于其它交易。　　支持XML:随着XML这种元数据语言的越来越广泛的应用，框架必须能从XML文件中存取对象。　　性能能够被优化：如果面向对象框架默认产生的操作性能不高的话， 应该允许用户优化性能。　　应该支持多种应用：应该即支持桌面型应用开发，也能支持C/S和多层数据库开发以及Web开发。　　应该是数据库及数据存取API无关的：可以随时切换开发及数据库发布平台。　　应该是兼容现有的数据感知组件的：这样在使用面向对象开发框架改动已有系统时，可以保证平滑的移植。SOA开放标准大观园——架构的导航鉴于SOA近几年在如此大的程度上影响了业界的思想，关于CORBA、企业级Java与Web服务等其它技术标准如此之少的确让人震惊。当然有着各种各样的WS-*标准和规范，许多人将其与SOA关联起来，但说到那些刻意的实现无关的标准，OASISSOA参考模型一枝独秀却已经很久了。今年早些时候OMG发布了SOA建模语言，TheOpenGroup宣告了SOA工作组的成立，同时还发布了SOA资料卷。　　在过去的几个月中，来自这些组织的所有成员联合其它力量一直在努力地调和各组织的成果，现在发布了一个新的白皮书，名为SOA开放标准大观园——架构的导航。（在它们的站点上都可以获取）。如这本白皮书所表述的那样：　　这一联合白皮书对于SOA参考模型、本体、参考架构、成熟度模型、建模语言以及治理相关的等等标准都进行了解释，并将它们置于了整个拼图中合理的位置。它勾勒出了哪些工作是相近的，强调了每个工作主体的优势所在，并涉及了如何将这些工作以一种互补的方式结合起来。它同时还可以作为这些规范的用户在选择最合适他们需求的技术产品时的参考手册，与他们现在的实际情况以及他们所计划的发展SOA过程相一致。　　这一白皮书所检验的规范及成果包括了OASIS的SOA参考模型、OASISSOA基础参考架构、OMG的SoaML规范、OpenGroupSOA本体论、OpenGroup的SOA参考架构、OpenGroupSOA治理框架以及OpenGroup服务集成成熟度模型。　　这对SOA资料库来说又是一个很好的补充。这一白皮书刻意地技术无关化了，回避了SOA的各种参考实现方案，比如Web服务或者JBI。一方面来说这可以看作是一个很好的想法，将供应商的吹捧保持在整体之外，潜在地增加了这一白皮书的生命周期。但从另一方面讲，可能会有这样那样的问题，询问这个白皮书从实践的角度到底作出了怎样的报道。　　根据这一白皮书的陈述，现有的标准可以被归纳到如下的几类组别当中：　　参考模型——一个抽象的框架，用于理解在一定环境中各个实体之间的重要关系。白皮书摘录了OASISSOA参考模型，它抓住了SOA了的“本质”，以及为SOA提供了词汇和通用的理解。这一参考模型的目标包括了一个公共的概念框架，可在不同的SOA实现之间得以一致性的使用；以及公共的语义，它可以被用于无岐义的建模特定的SOA解决方案，统一概念以解释和支持一个作为特定SOA支持的一般性设计模板，以及用于所有的SOA的定义。　　参考架构——可以在不同的抽象层次被定义，从基础架构到公共系统架构，以及业务或组织特定的架构。在这一类别有几种可用的技术产品。OASISSOA基础参考架构提供了 　　一个基于视图的抽象参考架构基础，从生态系统/范型的角度对SOA进行建模。它明确说明了三个观点；具体来讲就是，服务生态系统的观点，实现SOA的观点，以及拥有SOA的观点。　　TheOpenGroupSOA参考架构提供了：　　企业架构的基础，或者蓝图，因此企业架构师可以使用这些模板或者蓝图作为标准，将其实例化到每个开发中的单独项目或者解决方案中。这将在组织中被执行，这也是SOA参考架构将被实施的地方。这一SOA参考架构被设计为支持不同种类的场景，包括牵涉到客户组织、供应商、其它标准实体以及其它开放组织项目等等。　　本体——关于领域其及相互关系方面的明确的正式规范。白皮书引用了OpenGroupSOA本体论，它抓住了SOA范围内的一系列相关的概念，并且解释了它们是什么以及它们相互之间的关系。其目标是促进对于这些术语以及SOA上下文中的概念的理解，并且潜在的促进模型驱动的实现。该本体论用OWL(WebOntologyLanguage)来表达，以促进自动化以允许工具对其进行处理。　　成熟度模型——同时表达了评价和估算现有成熟度状态的方法。它们提供了发展一个价值主张与转化路线图的方法，以从现有的成熟度状态到达目标的成熟度状态。该白皮书引用了OpenGroup服务集成成熟度模型(OSIMM)，它为公司和IT实施者提供了在一个完整的SOA迁移路线中评估组织成熟度的方法。它提供了提供了一个流程，可以在整个路线的每个阶段为增量的实行（SOA）创建一个路线图，以达到业务价值的最大化。这一模型由七个不同的成熟度层次，以及由组织内或项目所定义范围内七个不同的考虑方面来组织，它可以作为一个量化模型来帮助对现有状态的评估与对设想的未来状态进行设计。　　建模语言——定义了一个元模型与符号，为在工具中展现工件以及在自动化环境与工具中交流信息提供了一个标准的方式。来自OMG的像UnifiedModelingLanguage（UML）这样的建模语言可以通过Profile的扩展来裁剪模型或建模语言以支持特定的领域和目的。该白皮书引用了OMG的SOAML，它扩展了UML，以提供附加的能力来对SOA风格所给予的内聚与耦合进行管理。SoaML在广泛的领域与抽象层次都可以得到应用，从业务服务到细节的IT服务。为这些不同的目的使用一个公共的语言简化了系统建模与关注分离的集成，提升了业务的灵活性，这可以通过业务架构模型如BMM和BPMN来表达。SoaML可以看作是OASISSOA参考模型的辅助性实例化，它为服务建模提供了一个坚实的平台...　　具体/解答架构——通过将模板里的一般性、逻辑性、抽象元素替换成供应商的产品、技术产品实例、标准、协议以及设计/架构性决定等等具体的，物理的实现，来将一个参考架构实例化。由白皮书所提供的业界参考架构的例子包括了零售业ARTSXMLSOA蓝图和面向服务的HTNG参考架构实现。　　就像该白皮书所解释的那样，尽管SOA标准的范围非常宽泛。　　关于SOA基础性的核心概念在许多独立的规范与标准之间已经有着很大程度的共识。　　这些标准是相互关联的，并且都是构建在相互的基础之上。　　这一白皮书是一个非常好的文献，它在不同的标准间提供了向导，指出了它们的关系以及每个标准应当用在什么地方，应当如何使用。SOA与中间件、基础件的发展  应运而生的SOA　　美国著名的IT市场研究和顾问咨询公司Gartner预测:到2006年，采用面向服务的企业级应用将占全球销售出的所有商业应用产品的80以上到2008年，SOA将成为绝对主流的软件工程实践方法。近几年全球各大IT巨头纷纷推出自己的面向服务的应用平台，纷纷表示自己将全面支持SOA。仿佛一夜之间SOA成为炙手可热的软件开发方法。其实SOA并非刚刚出现的新名词，而是很早以前就有人提出了面向服务的概念，只是以前没有现在这么多人关注而已。随着软件开发方法的不断发展，随着企业级应用系统愈来愈复杂，使得SOA成为了应运而生的软件工程方法。　　什么是SOA　　SOA是ServiceOrientedArchitecture的缩写，代表了一种软件开发方法。其核心思想是由擅长软件开发的技术人员把一个个的业务功能包装成一个个标准的服务，精通商业流程的专家通过组合这些服务可以很容易的搭建功能完善的企业应用，或者重新组合这些服务成全新的应用以满足企业的不断变化的需求。这里只是给出了SOA简单的介绍后面将会详细的讲述SOA架构。　　应用软件开发方法的演变　　应用软件开发方法在短短的几十年中经历了一次又一次的进化，然而每一次的进化给人们带来的好处都是一样的，那就是提高生产效率、减低生产成本，因此给投资者带来更丰厚的回报。回首软件开发方法的进化历程有如下几次重大的过程:面向函数(面向过程)、面向对象、面向组件以及迎面而来的面向服务软件开发方法。每一种软件开发方法都解决了特定的问题，但同时又不得不面对新的问题，因此不断的催生新的方法和手段。面向过程和面向对象的软件开发方法大家都已很熟悉了，因此不用多说，下面着重看一看基于中间件和基础件的面向组件的软件架构方法。所谓中间件是相对于以前的客户端/服务器结构而提出的把商业业务逻辑抽象成一个个组件，然后把这些组件放在中间层的应用服务器上运行，由应用服务器负责各个组件所需要的事务和安全等基础服务、以及组件的管理和监控等等。IT技术人员都知道要开发事务和安全这一类的基础服务需要专业的系统级的程序员来完成，而不是普通的应用程序员就可以轻松搞定的事情，或者说开发和维护这一类的基础服务需要耗费大量的人力财力，然而幸运的是事务和安全等基础服务可以独立于业务组件，因此有了当今正流行的各种中间件和基础件产品。这些中间件产品专注于基础服务的开发和维护，而应用程序员可以专注于业务组件的开发，因此对于开发各种企业应用如ERP，BPM以及电子政务等等各种应用系统的软件公司只需要购买专业的中间件产品，不用自己费时费力的开发和维护中间件和基础件产品。　　当今流行的中间件平台有:SUN公司领导的J2EE平台，微软主导的COM/DCOM平台以及OMG公司主导的CORBA平台。正如我们所看到的有这样三种主流的技术，因此应用软件公司在开发应用软件时不得不在其中做出选择。在他们选定了一种中间件技术之后，所有的软件组件都在这个选定的中间件平台上面搭建。也有的比较大的软件公司选择的了多个平台，比如说他的ERP基于.NET平台，而CRM基于J2EE平台。随着各种应用软件的不断开发，一个个“信息孤岛”也就被无形中建立了起来，然而应用软件也越来越复杂，应用软件的客户对应用软件的要求也越来越高，其中最为典型的技术上的要求是:要求集成各种应用软件，各种应用软件产品必须能够互连互通，各种应用软件产品之间可以共享信息，互 相之间可以共享某些功能模块，而不需要重复开发。这些要求成为了基于中间件的面向组件开发的软件开发技术的心头之痛。虽然各种EAI的产品可以缓解一下这个心头之痛，但还是无法从根本上解决问题。除此之外，基于中间件的开发的产品耦合度过高，导致无法适应不断变化的应用软件需求，因此基于中间件的面向服务的软件开发方法SOA成为了人们关注的焦点。因为可以互操作的特性是SOA的一个重要的基础功能之一。SOA要求把业务功能包装成标准的服务，所谓标准的服务是服务之间可以互相调用，服务的技术实现对于客户端来说是透明的。客户端不用关心服务是如何实现的，不管它是用什么编成语言来开发的。服务可以用JAVA来实现，也可以用MicrosoftC#来开发。　　因此可以用下图来表示应用软件开发方法的演变过程:面向过程、面向对象、面向组件、面向服务。　　　　SOA的抽象模型　　要理解实施SOA，首先要对SOA的架构有个认识，SOA架构分为四大功能模块:　　开发服务　　发布服务　　查找服务　　使用服务　　服务提供者开发出各种各样的有用的服务，经过严格测试后把服务发布到公共的服务注册表上，服务请求者通过查找服务注册表获得所需要的服务，然后便可以使用所需要的服务了。　　SOA架构可以抽象为如下的模型:　　 SOA的最佳实践　　WebServices作为SOA的最佳实践具有如下特征:　　标准　　WebServices的规范包括SOAP、WSDL、UDDI、XML，以及其他一系列的标准，这些标准是每一个WebServices实现必须要实现的。目前绝大部分的WebServices产品都支持这些标准，尤其是各大国际IT巨头。　　松散的耦合　　互操作　　每个WebServices产品之间的互操作在很大的程度上决定了WebServices的成败，因此国际组织WS-I为WebServices互操作制定了标准以及测试包。　　基于中间件　　WebServices的大部分产品都基于某个中间件产品，因此可以把遗留应用中的功能组件包装成服务。因而这在很大的程度上可以保证现有的投资不至于浪费。　　APUSIC与SOA　　金蝶中间件(APUSIC)作为专业的中间件公司一直专注于中间件产品的研发，其通过了Sun公司的J2EE国际认证的旗舰产品Apusic应用服务器在中国的中间件市场扮演了重要的角色。经过多年的实践，Apusic应用服务器已有广泛的用户，金蝶中间件公司不仅提供给用户高效稳定的中间件产品，而且培训用户如何正确的使用中间件产品，帮助客户对客户的应用进行架构设计，因此中间件公司对中间件的优势和局限性有深刻的体会，从而更加确认SOA对于构建将来的应用的重要性。为了更好的满足用户的需求金蝶中间件公司已在Apusic应用服务器3.0中集成了WebServices的功能，已经开始在实际应用中实施SOA。ApusicWebServices是完全基于国际标准来实现的，支持SOAP、WSDL、UDDI、JAX-RPC、SAAJ、JAXM、JAXP等等标准。在开发WebServices时Apusic一直非常注重与其他产品的交互，经过测试ApusicWebServices可以与BeaWeblogic和Microsoft.NET等产品的WebServices实现互操作。并且可以通过WS-I(www.ws-i.org)的WSBaseProfile1.0互操作性测试。Spring编程问题解答27Spring 编程问题解答　　27.1log4j　　利用Spring框架编程，console打印出log4j:WARNPleaseinitializethelog4jsystemproperly？　　说明你的log4j.properties没有配置。请把log4j.properties放到工程的classpath中，eclipse的classpath为bin目录，由于编译后src目录下的文件会拷贝到bin目录下，所以你可以把log4j.properties放到src目录下。这里给出一个log4j.properties的例子：　　log4j.rootLogger=DEBUG,stdout　　log4j.appender.stdout=org.apache.log4j.ConsoleAppender　　log4j.appender.stdout.layout.ConversionPattern=%d%5p(%F:%L)-%m%n　　27.2出现java.lang.NoClassDefFoundError?一般情况下是由于你没有把必要的jar包放到lib中。　　比如你要采用spring和hibernate（带事务支持的话），你除了spring.jar外还需要hibernat.jar、aopalliance.jar、cglig.jar、jakarta-commons下的几个jar包。　　27.3java.io.FileNotFoundException:Couldnotopenclasspathresource[....hbm.xml],提示找不到xml文件？　　原因一般有两个：　　(1)该xml文件没有在classpath中。　　(2)applicationContext-hibernate.xml中的xml名字没有带包名。　　27.4org.springframework.beans.NotWritablePropertyException:Invalidproperty''ofbeanclass？　　出现异常的原因是在application-xxx.xml中propertyname的错误。　　＜propertyname="...."＞中name的名字是与bean的set方法相关的，而且要注意大小写。　　27.5日志不要随意在代码中用System.out来做调试　　privatestaticLoggerlog=Logger.getLogger(*.class);　　我给大家解释一下log4j的用法log4j.properties　　log4j.rootLogger=ROOT,CON　　log4j.appender.ROOT=org.apache.log4j.RollingFileAppender　　log4j.appender.ROOT.File=c:indexLyd.log　　log4j.appender.ROOT.MaxFileSize=10000KB　　log4j.appender.ROOT.MaxBackupIndex=5　　log4j.appender.ROOT.layout.ConversionPattern=[%d]%t%c%-5p-%m%n　　log4j.appender.CON=org.apache.log4j.ConsoleAppender　　log4j.appender.CON.layout=org.apache.log4j.PatternLayout　　log4j.appender.CON.layout.ConversionPattern=[%d]%t%c%-5p-%m%n　　Weblogic应用　　线程的替代方案　　网络不稳定　　J2EE技术应用 Win32设备驱动程序的体系结构目前，由于需要支持新的业务和新的PC外部设备类型对驱动程序开发造成了新的挑战。新型总线增加了设备的数量和对设备驱动程序的需求。设备上各种功能的不断增加使驱动程序的开发变得越来越复杂。同时，快速反应的交互式应用程序要求将软件和硬件紧密的结合在一起。1997年，在用于Windows95和WindowsNT的统一的Win32驱动程序模型（WDM）有了进一步的发展，将这些因素全部考虑在内。WDM允许使用一个单一的驱动程序源（x86二进制）来同时在Windows95和WindowsNT中实现对新的总线和新设备的支持。　　WDM的关键目标是通过提供一种灵活的方式来简化驱动程序的开发，使在实现对新硬件支持的基础上减少并降低所必须开发的驱动程序的数量和复杂性。WDM还必须为即插即用和设备的电源管理提供一个通用的框架结构。WDM是实现对新型设备的简便支持和方便使用的关键组件。　　为了实现这些目标，WDM只能以WindowsNTI/O子系统提供的一组通用服务为基础。WDM改进了由一组核心扩展构成的功能实现对即插即用、设备电源管理、和快速反应I/O流的支持。除了通用的平台服务和扩展外，WDM还实现了一个模块化的、分层次类型的微型驱动程序结构。类型驱动程序实现了支持通用总线、协议、或设备类所需的功能性接口。类驱动程虻囊话闾匦允俏呒璞傅拿钌柚谩⑿椤⒑痛胫赜盟璧淖芟呓涌谑迪直曜蓟峁┍匾奶跫DM对标准类接口的支持减少了Windows95和WindowsNT所需的设备驱动程序的数量和复杂性。　　微型驱动程序允许通用类驱动程序的扩展实现对特定设备协议或物理编程接口的支持。例如，一个微型驱动程序可以被用于实现对IEEE1394总线类驱动程序的扩展，用于对特定主机控制器编程接口的支持。微型驱动程序非常易于开发，因为它们可以通过简单的扩展通用的类驱动程序接口功能来实现。尽管微型驱动程序设计简便，但是重复使用微型驱动程序模块所带来的优点也可以通过对标准设备编程接口的支持来实现。USB主机控制器接口（OpenHCI或UHCI）就是这方面的一个例子。　　模块化的WDM体系结构灵活统一的接口使操作系统可以动态的配置不同的设备驱动程序模块来支持特定的设备。模块化的WDM体系结构灵活统一的接口使操作系统可以动态的配置不同的驱动程序模块来支持特定的设备。一个典型的驱动程序堆栈由通用设备、协议、和用特定协议和特定总线的微型驱动程序联接的总线类驱动程序构成。例如，操作系统可以配置一个驱动程序堆栈来支持这样一个照相机，它的命令是用图象类定义的，并且它是根据来自IEEE1394总线类的功能控制协议（FCP）类而发表的。这种灵活性还使其可以很容易的支持一个多功能设备，仅需简单的实现一个微型驱动程序将多功能硬件与几个设备类的接口相连接。动态构造WDM驱动程序堆栈是实现即插即用设备支持的关键。　　WDM服务使实现一个用于WindowsNT和Windows 95快速反应的模型成为可能。WDM提供了多个执行优先级包括核心态和非核心态线程、IRQ级别、和被延缓的程序调用（DPC）。所有的WDM类和微型驱动程序都作为核心态（第0层）的特权级线程（不会被CPU调度程序中断）执行。32个IRQ级可以被用于区分硬件中断服务的优先级。对于每个中断，DPC被排入队列等到被启用中断的IRQ服务例程完成后再执行。DPCs通过有效的减少中断被禁止的时间，使系统对中断的响应获得了很大的提高。对于使用多处理器的基于x86的PC系统，在Windows　NT下对中断的支持是以Intel的多处理器规范1.4版本为基础的。　　对于需要活动的多媒体的应用程序，WDM在核心态提供了快速反应的接口来处理I/O流。WDM的流接口是通过标准的WDM类接口提供出的。对于WDM，一个多媒体流完全可以用一个或多个软件过滤器和设备驱动程序来处理。为了加速对I/O流的处理，WDM流可以直接对硬件进行访问，避免了由于进行非核心态和核心态之间的转换而造成的延迟，并且还省取了对中间I/O缓冲区的需要。　　要充分利用WDM提供的优点，建议你使用即插即用兼容的电源管理输入、声音、图形、和使用USB和IEEE1394的存储外围设备。　　WDM驱动程序可以在WindowsNT上与现有的WindowsNT驱动程序共存，也可以在Windows95上与现有的Windows95驱动程序共存。现有的WindowsNT和Windows95驱动程序将继续被支持，但是却不能使用WDM的先进优点。由微软提供的可扩展的WDM类驱动程序是支持新设备的最好选择。在开始开发一个新的WDM类驱动程序之前，硬件开发者应当请教微软公司以取得对特定设备类的支持信息。一旦有可能，就采用仅编写一次类驱动程序，然后通过使用WDM的微型驱动程序来将其扩展成针对特定硬件接口的驱动程序的方法。部署智能客户端应用程序部署智能客户端应用程序　　在最初部署您的智能客户端应用程序之后，您的工作尚未完成。过一段时间之后，随着您升级应用程序功能并且修复缺陷或解决安全漏洞，应用程序将需要更新。根据具体情况的不同，您可以使用也可以不使用与部署智能客户端应用程序的方法相同的方法来更新它。例如，如果您最初使用Windows安装程序软件包来部署应用程序，则可以使用自动更新来部署更新。您的环境的具体情况通常将决定哪种更新方法最为适合。部署更新时的一个常见要求是能够联合更新基础结构，以便多个更新不用在由单个实体控制的单个服务器或服务器场上竞争。例如，如果某个ISV已经创建了一个在客户的整个企业中部署的智能客户端应用程序，并且该ISV发布了该应用程序的一个更新，则该企业可能希望首先在他们的标准操作环境中下载并测试该更新，然后再将其传播到整个企业中运行的所有计算机。通过联合更新基础结构，可以使这样做变得可能。例如，更新服务器可能位于负责从该ISV获取更新的客户站点上。在该企业内部运行的客户端可以从本地更新服务器获取更新，但前提是IT管理员予以批准。使用该方法，还可以通过减轻单个服务器或服务器场的负载，提高更新基础结构的性能和可伸缩性。在部署应用程序的更新时，您具有下列选择：　　1)无接触部署。更新的程序集被添加到Web服务器，以供客户端自动下载。　　2)自动更新。应用程序被配置为自动从服务器下载并安装更新。　　3)从文件共享获取更新。更新的程序集被添加到网络共享，以供客户端自动下载。　　4)Xcopy更新。更新被直接复制到客户端。　　5)Windows安装程序软件包部署。更新了Windows 安装程序软件包，创建了新的软件包，者使用修补软件包更新客户端。对每个选择进行详细分析，以便您能够确定哪个选择最适合于您的环境，将是很有用的。从开发人员走向架构师三步曲2009年下半年全国计算机等级考试你准备好了没?考计算机等级考试的朋友,2009年下半年全国计算机等级考试时间是2009年9月19日至23日。　　很多架构师都是从好的开发人员逐步过渡而来的，但并非每个好的开发人员都希望成为架构师，而且他们并不是都适合做架构师。无论您是打算进行职业转型的开发人员，还是寻找能承担体系结构设计责任的合适人选的经理，都务必对此转型过程有个清楚的了解。本文将讨论从实现专家到架构师的过渡过程。　　在寻找优秀的指挥的时候，您首先要找的是一名优秀的音乐演奏家。但并非每个音乐演奏家都能成为优秀的指挥。架构师的专业发展方面也与此类似。越来越多的IT组织开始认识到良好软件体系结构的重要性，架构师职业正迅速发展为IT内一个独立的门类。由于要从相当小的候选范围内招募架构师，因此这就给管理带来了一些新挑战。即使人力资源部门找到了候选者，针对经验进行的筛选也比其他门类更为严格。跨越这些障碍的最快方式是要认识到，大部分好的架构师同时也是好的开发人员，因此寻找架构师人才时可能首先应该从普通开发人员中找起。招聘人员在对候选者(内部或外部)进行详细审查时，应该考虑这个观点。不过，对此资源进行挑选可能比较麻烦，因为只有极少的优秀开发人员具有成为架构师的特征或愿望。　　本文列出了开发人员成为架构师要进行的工作。我将从可能考虑进行此转型的开发人员和评估进行此转型的开发人员的经理这两个方面来探讨这一问题。我还将提供一系列在做出这些决策时要考虑的因素。　　个人特征　　软件开发团队和管理层之间的联系始终是IT中的一个关键所在。二者都倾向于以完全不同的方式考虑给定的问题。大部分相关技术都是讨论项目经理应如何跟踪和解释开发人员的进度和问题。但沟通不足的情况仍然非常普遍，而且这是项目失败的首要原因。好的架构师是解决这个问题的最有效办法。架构师的主要责任是提供开发人员和项目经理之间的共用沟通媒体。他们负责让业务规则及需求与工程实践及限制相适应，以确保成功。以下是成功架构师的一些主要特征。 　　愿意并有能力进行沟通：在开发人员中发现架构师的最有价值标?是有效的沟通。您需要技术娴熟、经验丰富的开发人员，这样的人员需要有就项目中的业务相关问题进行沟通的经历。架构师经常必须对理解方面的差距进行预计，然后才能有所贡献。他们必须愿意克服困难来确保技术和业务观点的融合。他们并不必对意见交换工作进行计划和协调;这仍然主要是项目经理的工作。他们的任务是确定表述系统设计时的最佳工具和构件，以促进有效的意见交换。他们必须能够判断当前方法显得不足而需要采用新方法的情况。写作技能也非常重要，还需要具有制作草图的技能或使用制图软件的能力。　　具有处理谈判细节方面的经验：架构师经常需要负责讨论系统开发的技术折衷方案。优先级的冲突可能会带来实践限制、风险规避或可能导致在各个不同业务组之间需求不同。优秀的架构师能够有效地评估技术可能性，并能在不损失项目的主要价值的前提下制订开发计划来处理各种利害关系和限制。这与前面讨论的沟通技能紧密相关，但同时也要体现架构师的技术能力。好的架构师候选者应该是经常帮助对有争议的讨论进行引导的人，能够使讨论得出新的想法，而不会使其在一个位置停滞不前。　　自觉主动：积极解决设计问题：架构师的日常工作目标经常并不明确。很多开发人员直接参考功能规范来列出任务清单。架构师通常则是向这些开发人员提供所需结构的人员，以便尽可能提高工作效率。好的候选者不仅进行沟通方面的工作，而且也会预计各种设计问题并加以解决——通常在没有任何具体指示的情况下自觉进行。无论所分配的职责如何，积极参与项目的开发人员都有机会从一起工作的人员中脱颖而出。　　抽象思维和分析：架构师必须能够理解表述模糊的概念并将其变成相关各方能够理解的项目构件。他们必须能够理解抽象概念，并以具体的语言对其进行沟通。开发人员中好的候选者经常要求或自己主动解释开发生命周期中容易混淆的问题。他们能迅速评估各种想法并将其纳入后续工作的操作建议中。　　开发人员经常具有很强的数学能力，而好的架构师则倾向于表现出更强的口头表达能力。管理人员经常说开发人员具有“工程意识”，而这是一个用于评估架构师的非常有意义的方面。架构师应该具有很强的解决技术问题的能力，但还必须能够准确获知更为全面的人员如何与技术交互的信息。这要求具有某种形式的抽象思维(而不再是代码的细节)，这种思维能力可能较难形成。　　有些人认为，某种级别的正式教育是成为优秀开发人员的必备条件之一，我并不同意这种精英论。我遇到了很多高中就辍学的优秀开发人员。不过，对于体系结构设计工作，我的个人经验以及我对所需能力的认识都让我相信，好的架构师通常至少获得了一个有挑战性的学士学位。　　跟踪生命周期　　好的架构师通常有在具备定义良好的软件开发生命周期(SoftwareDevelopmentLifeCycle，SDLC)的组织工作的经验。架构师必须理解在其所属专业内最重要的操作过程。这并不意味着需要有其他前提，例如，并不需要高能力成熟度模型(CapabilityMaturityModel，CMM)级别的工作经验。好的架构师可能来自使用SDLC的多个小型迭代的极限编程(ExtremeProgramming，XP)方法的组织。务必注意各种传统软件开发操作，如MichaelA.Jackson的方法：Jackson结构编程(JacksonStructuredProgramming，JSP)和Jackson系统开发(JacksonSystemDevelopment，JSD)。Jackson的研究对架构师职业发展的意义就像DonaldKnuth的研究对程序员一样重要。架构师可以偏爱任何经典的、经过时间考验的软件系统开发方法。　　SDLC也可以成为评估架构师合适人选的有用机制。每个SDLC阶段都具有能提供相关线索的特征。SDLC包含很多小的变体，但在此部分，我将使用几乎所有方法的公共基础部分。下面的列表详细说明了SDLC 的各个阶段，并列出了好的架构师候选者在每个阶段表现出来的特征。　　分析：在分析期间，好的架构师会考虑非技术影响，以便了解需求和将在其中进行开发的环境。架构师可为风险评估任务带来广泛的软件经验供参考。寻找具有丰富经验的开发人员，以帮助业务部门理解技术人员正确解释需求所需的信息。寻找在开发的早期阶段能够预计可能遇到的问题的开发人员。　　设计：在高级设计期间，好的架构师会收集问题空间的各个抽象元素，并就其进行沟通，以便开发团队草拟将要开发的系统的相关图表。架构师负责将需求谨慎地映射到所得到的系统体系结构的功能。在详细设计期间，他们所扮演的角色并不是核心角色，但为了根据整个系统的规则对特定模块的元素进行审查，仍然需要他们。寻找善于让团队能够预计设计决策对最终系统的影响的开发人员。寻找善于确定一些最佳构件来促进与技术和非技术受众沟通设计问题的开发人员。　　实现：在实现期间，架构师对项目进行引导，以确保其符合系统体系结构。他们在一线评估技术更改请求，并确定如何对设计进行调整，以最好地处理此类请求。架构师还要密切了解开发人员的进度，特别要跟踪系统中模块间的集成点的状态。寻找经常对讨论进行引导来连接多个子系统的开发人员。寻找项目经理可以依赖其快速地进行与更改和出现的问题相关的风险评估的开发人员。　　测试：架构师对系统集成和用户接受度测试进行指导，并负责评估进度的正确沟通的持续测试结果。寻找理解错误模式且善于将测试复查结果转换为行动计划的开发人员。　　维护：在维护期间，架构师将发起关于系统集成的讨论。无论处理IT基础设施问题，还是确保部门之间的技术合作，架构师都必须完全理解应用程序，必须快速学习姊妹应用程序的体系结构，而且必须就集成点和风险进行有效沟通。寻找具有系统集成经验且表现出快速掌握全貌的能力的开发人员。系统集成是一项独特的任务。　　架构师培养建议　　有些组织能比其他组织更有效地进行架构师培养。如果充分考虑到招聘此类新专业人才的困难，努力促成能鼓励开发人员发展为架构师的环境是非常明智的策略。但务必避免对不愿意或不适合走这条路的开发人员进行处罚。组织应该为开发人员制订多条发展路线，包括那些愿意继续担任开发人员的人。对架构师而言，资深开发人员不可或缺。他们可以实现系统中最关键的模块。通过对其他开发人员进行代码检查和测试支持，他们可帮助确保总体软件质量，而如果质量不能保证，即使最好的体系结构也毫无用处。　　组织应制订个人评估程序，以鼓励开发人员考虑其职业目标，其中要包含体系结构设计的选项。应该鼓励经理在其下属中寻找体系结构设计人才。应该实现指导计划，让架构师与希望成为架构师的开发人员协作工作。应该鼓励开发人员通过参加各种协会、撰写文章和参加会议，从而参与到专业领域中来。通过这样参与进来，可帮助开发人员从新的角度理解系统，并帮助他们更好地就其认识进行沟通。这样还能培养可提高效率的重要创新想法。 　　结束语　　开发人员一旦迈出了通向体系结构设计专业方向的第一步，就可以利用很多资源来获得帮助。有时候，此过程的最困难的部分就是第一步，而本文提供了一些线索和提示，经理和开发人员可以利用其来评估应该鼓励哪些人努力成为架构师。分布式架构非中间件大中型或高性能设计方案11分布式架构非中间件大中型或高性能设计方案　　11.1以新浪广告设计为例介绍　　1）多服务器配合　　2）请求格式定义　　3）线程池　　4）资源占用　　5）集群刷新　　6）务处理　　7）全问题分布式设计的性能问题　　13.4分布式设计的性能问题　　抨击CMP，认为CMP慢无用，实际最大的问题是他们的设计和使用问题。　　l)是否需要分布式事务处理　　2)由于每个CMP在内存中都有一个缓存，在实际应用中，如果使用CMP批量读数据库数据，几万条查询完毕，内存中充满了几万条CMP缓存，如果这时你的EJB容器设置不当，那么JVM的垃圾回收机制就会频繁启动，导致你的系统变慢甚至死机，这也是一些人抨击CMP慢的原因所在，其实他们使用方法不当，或者没有正确配置EJB容器CMP缓存。　　3)状态Bean和无状态bean的调优、集群　　4)是不是非要跨虚拟机（何时要本地化）　　5)缓存JNDI查找　　PortableRemoteObject　　6)对象池（重量级）CacheFullExceptoin和OutOfMemoryError　　1000　　10　　7)Static问题　　8)线程问题分布式设计是前面所有知识点的综合和改进版本 13分布式架构中间件大中型或高性能设计方案　　13.1分布式设计是前面所有知识点的综合和改进版本　　13.2中间件为我们解决了非功能性问题　　l)JTA全局事务　　2)JNDI的应用（分布式查找）　　3)线程池的变相解决方案―――对象池（重量级对象）　　4）业务逻辑层、表现层、持久分离　　1）减轻架构师的设计负担（这是我目前的工作，对这点我深有体会）以前一个架构师不光在设计时要考虑项目的业务需求，还要考虑如何仔细推敲用什么设计模式进行设计（当然现在还要考虑，只是少多了）、线程池、缓冲加速、远程调用、同步互斥、事务机制、数据库连接池技术等因素。现在由EJB容器代我们完成。　　2）面向对象的持久化技术以性能为代价增加了开发效率，引入数据面向对象的持久化思想　　3）EJB组件能提供真正的可重用框架　　4）（主题、队列）异步消息机制　　5）提供集群解决方案复杂系统层级原理与模型驱动软件体系结构最近看到模型驱动在国内渐渐被更多的人注意，前几天又看到一些关于UML优劣和应用方面的争论。作为繁忙工作中的一种休息，从过往的研究笔记中整理一点东西放在这里，与大家交流。层级理论是构建复杂软件体系的基本原则　　诺贝尔奖获得者赫伯特A.西蒙曾论述到：“要构造一门关于复杂系统的比较正规的理论，有一条路就是求助于层级理论……我们可以期望，在一个复杂性必然是从简单性进化而来的世界中，复杂系统是层级结构的”。对于软件这样复杂的人造事务，发现层级和运用层级，是分析和构建的基本原则。　　软件的体系结构是层级的　　粗略地观察一下软件表述方式（语言）的发展：从穿孔纸带（机器的语言）开始，首先是汇编语言，然后是高级语言，再往后有面向对象语言和所谓第四代语言（FGL）出现……应当留意：每一代的语言并不是在“取代”前一代语言，而是用上一代语言来“写”下一代语言。在这个自然的进化过程中，西蒙所论述的复杂体系的层级特征清晰地出现了。　　进一步看，在由简单到复杂的进化道路上，软件的体系结构、软件开发的体系结构、软件开发工具的体系结构等等，都呈现出层级的特征。“好”的软件体系具有更加清晰的层级。 　　一维语言之后是模型　　这里不想展开讨论这个问题，只是提出一些思考的结果。与自然语言类似，现有的“程序设计语言”是单维的，它的基本语法是以前后顺序为基础的。当系统的复杂程度提高时，用这样的语言精确描述复杂系统变得越发困难，更遑论有效地修改维护；可视化开发平台、代码管理工具（甚至某种意义上共享组件也可包括在内）等的出现对此是一种补充，但仍然不是最终的解决方法。软件描述体系进化到这里，面临着一次突变，将有新的物种出现，这个新物种可能就是模型。笔者认为，模型与程序语言主要的区别不在于图形化，也不在于抽象的程度，而在于表达方式突破了“单一顺序”的限制，最简单的例子就是二维表。模型可以更容易和直接地表达复杂的结构。　　模型和语言都是对系统的描述　　传统的编程语言和模型都是一种表述的体系，前者适合表述顺序过程，后者适合表述复杂结构。模型的必要性可以通过下面这个例子看出来：　　为了精确地复现，你可以用语言精确地叙述一个立方体，甚至10个立方体组合的形状，但你不会试图用语言描述一栋房子，适当的方式是用工程图纸。　　建立企业应用系统的情形可以从以上例子得到启发，企业系统要表述的，主要是复杂的结构，过程占的比重很小，因此，模型就变得更加重要乃至必要了。　　OMG组织的MDA战略　　OMG最新的战略，是建立模型驱动体系架构（ModelDrivenArchitecture,MDA），它的意义不是三言两语可以说清楚的，但从软件进化的角度来说，可能带有一种必然性，从上面的讨论，至少可以引申出两个理由：　　更有效地描述复杂系统的需要；　　系统复杂化带来的层级区分的需要。　　关于模型的几个分析要素　　以下特征对软件体系中模型的运用是十分重要，或者有特殊意义的：　　模型的时效性（time-effECtivenESsofmodel）：关于这一点最重要的区分在于，是“运行期模型”（Run-TimeModel），还是开发期模型？这个区别，有点类似于解释的语言和编译的语言间的区别，但其意义却非同一般，考试,大认为，“运行期模型”，揭示了模型驱动的本质。　　模型的可进化性（evolutionablenessofmodel）：是否可以在系统的应用过程中，持续地适应应用环境与需求的变化，不断地由应用者或自适应地对模型进行改进？这是对模型“性能”的一种度量。　　模型的层级性（hierarchyofmodel）：正如语言有多个层次一样，没有理由认为模型只有一个层次，当系统足够复杂时，模型的层次划分将会是必要的。　　UML和企业模型　　运用上面的要素分析一下，可以发现：　　UML是“紧贴”高级软件语言（例如C++）的模型体系，其时效是在软件生命周期的开发期间，而不是运行期间，其描述的层级是在软件的组件、对象一级，典型要素是软件中的对象，软件上一个操作的动作等。 　　企业模型（比如ARIS,CIM-OSA,GERAM），典型的要素是组织，产品，过程等，它们是从企业的业务对象着眼的。二者在层级上有差距，而且企业模型追求的最终结果，是从“开发期模型”到达“运行期模型”，并且，笔者认为它最终应当是一种可进化的模型，这与UML的设计目标并不符合。　　它们两者间并不相互排斥，而应当考虑它们的“层接”。按照笔者的理解，OMG的MDA即使全面实现，也仍然不能做为或替代企业模型，但有可能成为企业模型的基础，这不是模型好坏或能力的问题，而是层级定位的问题。　　面向对象（ObjectOriented,OO）作为软件体系结构方面的一种演进而出现，也曾经被一些人误解为对过程化语言（或面向过程的体系结构）的取代。笔者认为，尽管OO反应了一种世界观，是一种思维的方式，但并不代表一切；且从层级和进化的观点上，也不应当将它看作是对既有东西的一种简单的取代。模型或模型驱动同样如此，它可能是继面向对象之后，软件体系结构的又一个重大的进化，但不是用来取代面向对象或结构化设计。笔者在1998年撰写《迈向21世纪的企业信息技术应用》一文时，对于模型的地位和作用并没有今天这样的认识，现在我坚信，对于企业信息系统这样复杂的系统，要想做到有效、可控制地规划与构建乃至具有“柔性”、可在运行期间不断地调整，“模型”是必须的，而且，表达与构建复杂企业系统时所需的模型，可能是多层次的，所谓“通用企业平台上的专用执行系统”，就应当是一个由运行期模型驱动的系统。共享内存实现进程间大数据的交换引言　　进程间的数据交换和共享是一种非常重要和实用的技术。大、中型软件的开发设计多是由众多程序设计人员的合作完成，通常一个程序设计人员只负责其中一个或几个模块的开发，这些模块可以是动态链接库也可以是应用程序或是其他形式的程序组件。这些独立开发出来的程序模块最终需要作为一个整体来运行，即组成一个系统，在系统运行期间这些模块往往需要频繁地进行数据交换和数据共享，对于动态链接库同其主调应用程序之间的数据交换是非常容易实现的，但是在两个应用程序之间或是动态链接库同其主调应用程序之外的其他应用程序进行数据交换就比较困难了。尤其是在交换数据量过大、交换过于频繁的情况下更是难以实现，本文即对此展开讨论，并提出了一种通过共享内存来实现进程见大数据量快速交换的一种方法。 　　通讯方式的比较和选择　　进程间通讯的方式有很多，常用的有共享内存、命名管道和匿名管道、发送消息等几种方法来直接完成，另外还可以通过socket口、配置文件和注册表等来间接实现进程间数据通讯任务。以上这几种方法各有优缺点，具体到在进程间进行大数据量数据的快速交换问题上，则可以排除使用配置文件和注册表的方法；另外，由于管道和socket套接字的使用需要有网卡的支持，因此也可以不予考虑。这样，可供选择的通讯方式只剩下共享内存和发送消息两种。由于数据量比较大，这样在使用消息进行通讯时就无法通过消息参数将数据直接携带到接收方，只能以地址传送的方式进行。当一个应用程序向另一个应用程序发送数据时将会发出WM_COPYDATA系统消息，因此可以考虑通过向消息队列插入WM_COPYDATA消息的方法来实现数据在进程间的拷贝。　　在使用WM_COPYDATA消息时，由第一个消息参数指定发送窗口的句柄，第二个消息参数则为一同数据相关的数据结构COPYDATASTRUCT的指针，此结构原形声明如下：　　typedefstructtagCOPYDATASTRUCT{　　DWORDdwData;　　DWORDcbData;　　PVOIDlpData;　　}COPYDATASTRUCT;　　其中，只需将待发送数据的首地址赋予lpData、并由cbData指明数据块长度即可。消息发出后，接收方程序在WM_COPYDATA消息的响应函数中通过随消息传递进来的第二个参数完成对数据块的接收。但是在使用WM_COPYDATA消息时，只能用SendMessage()函数发送而不能使用PostMessage()，这两个函数虽然功能非常相似都是负责向指定的窗口发送消息，但是SendMessage()函数发出消息后不是马上返回，而是在接收方的消息响应函数处理完之后才能返回，并能够得到返回结果。在此期间发送方程序将被阻塞，SendMessage()后面的语句不能被继续执行。而PostMessage()函数在发出消息后马上返回，其后语句能够被立即执行，但是无法获取消息的执行结果。可见，在交换数据量较大的情况下实现数据频繁而又快速的交换用发送WM_COPYDATA消息的方法也是不合适的，当数据传输过于频繁时将有可能导致数据的丢失。　　比之以上几种进程间通讯方法，共享内存有着明显的优势。共享内存是通过直接操作内存映射文件来进行的，而内存映射文件又是进行单机数据共享的最低层机制，前面几种数据交换方式在低层都是通过内存映射文件来进行的。因此使用共享内存可以以较小的开销获取较高的性能，是进行大数据量数据快速交换的最佳方案。　　共享内存的使用　　在Windows操作系统下，任何一个进程不允许读取、写入或是修改另一个进程的数据（包括变量、对象和内存分配等），但是在某个进程内创建的文件映射对象的视图却能够为多个其他进程所映射，这些进程共享的是物理存储器的同一个页面。因此，当一个进程将数据写入此共享文件映射对象的视图时，其他进程可以立即获取数据变更情况。为了进一步提高数据交换的速度，还可以采用由系统页文件支持的内存映射文件而直接在内存区域使用，显然这种共享内存的方式是完全可以满足在进程间进行大数据量数据快速传输任务要求的。下面给出在两个相互独立的进程间通过文件映射对象来分配和访问同一个共享内存块的应用实例。在本例中，由发送方程序负责向接收方程序发送数据，文件映射对象由发送方创建和关闭，并且指定一个唯一的名字供接收程序使用。接收方程序直接通过这个唯一指定的名字打开此文件映射对象，并完成对数据的接收。　　在发送方程序中，首先通过CreateFileMapping()函数创建一个内存映射文件对象，如果创建成功则通过MapViewOfFile()函数将此文件映射对象的视图映射进地址空间，同时得到此映射视图的首址。可见，共享内存的创建主要是通过这两个函数完成的。这两个函数原形声明如下：　　HANDLECreateFileMapping(HANDLEhFile,　　LPSECURITY_ATTRIBUTES lpFileMappingAttributes,　　DWORDflProtect,　　DWORDdwMaximumSizeHigh,　　DWORDdwMaximumSizeLow,　　LPCTSTRlpName);　　LPVOIDMapViewOfFile(HANDLEhFileMappingObject,　　DWORDdwDesiredAccess,　　DWORDdwFileOffsetHigh,　　DWORDdwFileOffsetLow,　　DWORDdwNumberOfBytesToMap);　　CreateFileMapping()函数参数hFile指定了待映射到进程地址空间的文件句柄，如果为无效句柄则系统会创建一个使用来自页文件而非指定磁盘文件存储器的文件映射对象。很显然，在本例中为了数据能快速交换，需要人为将此参数设定为INVALID_HANDLE_VALUE；参数flProtect设定了系统对页面采取的保护属性，由于需要进行读写操作，因此可以设置保护属性PAGE_READWRITE；双字型参数dwMaximumSizeHigh和dwMaximumSizeLow指定了所开辟共享内存区的最大字节数；最后的参数lpName用来给此共享内存设定一个名字，接收程序可以通过这个名字将其打开。MapViewOfFile()函数的参数hFileMappingObject为CreateFileMapping()返回的内存文件映像对象句柄；参数dwDesiredAccess再次指定对其数据的访问方式，而且需要同CreateFileMapping()函数所设置的保护属性相匹配。这里对保护属性的重复设置可以确保应用程序能更多的对数据的保护属性进行有效控制。下面给出创建共享内存的部分关键代　　hRecvMap=CreateFileMapping(INVALID_HANDLE_VALUE,NULL,PAGE_READWRITE|SEC_COMMIT,0,,"DataMap");　　if(hRecvMap!=NULL)　　{　　lpData=(LPBYTE)MapViewOfFile(hRecvMap,FILE_MAP_WRITE,0,0,0);　　if(lpData==NULL)　　{　　CloseHandle(hRecvMap);　　hRecvMap=NULL;　　}　　}　　//通知接收程序内存文件映射对象的视图已经打开　HWNDhRecv=::FindWindow(NULL,DECODE_PROGRAMM);　　if(hRecv!=NULL)　　::PostMessage(hRecv,WM_MAP_OPEN,0,0);　　数据的传送实际是将数据从发送方写到共享内存中，然后由接收程序及时从中取走即可。数据从发送方程序写到共享内存比较简单，只需用memcpy()函数将数据拷贝过去，关键在于能及时通知接收程序数据已写入到共享内存，并让其即使取走。在这里仍采取消息通知的方式，当数据写入共享内存后通过PostMessage()函数向接收方程序发送消息，接收方在消息响应函数中完成对数据的读取：　　// 数据复制到共享内存　　memcpy(lpData,RecVBuf,sizeof(RecvBuf));　　//通知接收方接收数据　　HWNDhDeCode=::FindWindow(NULL,DECODE_PROGRAMM);　　if(hDeCode!=NULL)　　::PostMessage(hDeCode,WM_DATA_READY,(WPARAM)0,(LPARAM)sizeof(RecvBuf));　　当数据传输结束，即将退出程序时，需要将映射进来的内存文件映射对象视图卸载和资源的释放等处理。这部分工作主要由UnmapViewOfFile()和CloseHandle()等函数完成：　　HWNDhDeCode=::FindWindow(NULL,DECODE_PROGRAMM);　　if(hDeCode!=NULL)　　::PostMessage(hDeCode,WM_MAP_CLOSE,0,0);　　if(lpData!=NULL)　　{　　UnmapViewOfFile(lpData);　　lpData=NULL;　　}　　if(hRecvMap!=NULL)　　{　　CloseHandle(hRecvMap);　　hRecvMap=NULL;　　}　　在接收程序中，在收到由发送放发出的WM_MAP_OPEN消息后，由OpenFileMapping()函数打开由名字"DataMap"指定的文件映射对象，如果执行成功，继续用MapViewOfFile()函数将此文件映射对象的视图映射到接收应用程序的地址空间并得到其首址：　　m_hReceiveMap=OpenFileMapping(FILE_MAP_READ,FALSE,"DataMap");　　if(m_hReceiveMap==NULL)　　return;　　m_lpbReceiveBuf=(LPBYTE)MapViewOfFile(m_hReceiveMap,FILE_MAP_READ,0,0,0);　　if(m_lpbReceiveBuf==NULL)　　{　　CloseHandle(m_hReceiveMap);　　m_hReceiveMap=NULL;　　}　　当发送方程序将数据写入到共享内存后，接收方将收到消息WM_DATA_READY，在响应函数中将数据从共享内存复制到本地缓存中，再进行后续的处理。同发送程序类似，在接收程序数据接收完毕后，也需要用UnmapViewOfFile()、CloseHandle()等函数完成对文件视图等打开过资源的释放：　　//从共享内存接收数据　　memcpy(RecvBuf,(char*)(m_lpbReceiveBuf),(int)lParam);　　……　　//程序退出前资源的释放　　UnmapViewOfFile(m_lpbReceiveBuf);　　m_lpbReceiveBuf= NULL;　　CloseHandle(m_hReceiveMap);　　m_hReceiveMap=NULL;　　小结　　经实际测试，使用共享内存在处理大数据量数据的快速交换时表现出了良好的性能，在数据可靠性等方面要远远高于发送WM_COPYDATA消息的方式。这种大容量、高速的数据共享处理方式在设计高速数传通讯类软件中有着很好的使用效果。本文所述代码在Windows2000下由MicrosoftVisualC++6.0编译通过。关于复杂事件处理和事件驱动架构的争论复杂事件处理（ComplexEventProcessing，CEP）系统和事件驱动架构（EventDrivenArchitecture，EDA）都被认为会在目前和未来的精致繁杂的系统设计中扮演重要角色。但是它们的角色是什么？会对业界产生什么样的影响？最近又开始了关于这些问题的争论。DavidLuckham和RoySchulte还编撰了一个用于CEP和EDA的术语概览和词汇表。　　抛开实现细节，Luckham和Schulte对每个术语做了定义：　　首先“事件”这个最普遍的术语，是有问题的。基本上它包含两个截然不同的含义：（1）一个发生的活动；（2）计算机系统里面代表某个活动的事物。按理说，应该引入两个不同的术语，比如“事件（event）”和“事件对象（eventobject）”。但是，事实是在每个稍微长些的讨论中，你都会发现这样做太晦涩难懂了，它从【注：event和eventobject这两个分开的术语】的区别要不就是被误用，要不就是被忘记甚至忽略了。举个例子，如果要使用两个术语，那么很有可能导致你在说“事件处理（eventprocessing）”时，其实意思是指“事件对象处理（eventobjectprocess）”。所以说，最好的办法是复用“事件（event）”这个单词，通过每个词的上下文来理解它所要表达的意思。　　Luckham和Shulte将“复杂事件”定义成“一个对多个其它子事件的抽象的事件。”在提到穆迪投资者服务系统中的问题导致不正确的评级时，JoeMckendrick谈论到了复杂事件的话题。Mckendrick说“也就是说，目前即使没有上亿美元，也有数百万美元的投资决定是由此类系统产生的错设数据造成的。”Mckendrick的立场是，复杂的讲别和感应系统也许仍然需要人类的参与，以阻止问题或者错误的发生。　　Mckendrick提到K.ManiChandy博士，加州理工学院的一个正在做讲别和感应研究的计算机科学教授，他曾经表示在基于复杂事件做决策时，要保证这个过程中有人的参与。Chandy说在有些情况下，比如战术军事上的某个涉及到使用武器的操作，“它会一直有个对此事最终行为负责的人参与其中。”　　Chandy和MicahelOlson谈到为何事件处理与‘识别和感应’应用（PDF）也许将在业务活动监测和业务仪表盘领域普遍存在。Chandy和Olson对Web讲别和感应应用有非常深入的研究，这些应用仅从Web数据源提取事件和数据： 　　Web数据源可以是活跃的或者休眠的。客户端可以通过请求-应答协议轮询服务器，以获得信息。而信息也可以通过RSS或者ATOM流，或者其他的数据协议，推送给客户端。休眠的数据源也可以有个活跃的接口，方法是让代理定期轮询它，并在接下来的轮询中传输更改的信息。　　但是CEP真的需要一个完全不同的架构类型吗？　　BrendaMichelson就事件处理写了一篇文章--事件驱动架构概览。他定义了EDA中的5类组件：　　事件元数据：事件元数据包括事件说明和事件处理规则；　　事件处理：事件处理的核心是引擎和事件发生数据；　　事件工具：事件开发工具用于定义事件说明和事件规则，以及管理订阅等。事件管理工具提供事件处理基础架构的管理和监测，事件流的监测以及显示事件生成和处理状态等；　　企业集成：一个企业集成中枢在事件驱动架构中扮演着重要的角色。需要集成的一些服务包括：事件预处理（过滤、路由和转变等）、事件通道传输、服务调用、业务流程调用、发布和订阅，以及企业信息访问等；　　源和目的：创建事件和/或执行一个事件驱动动作的企业资源（应用、服务、业务流程、数据存储、人员和自动代理等）。　　Michelson还谈到了EDA和SOA之间的兰系：　　我相信SOA和EDA是平等和互补的。所以，我不认同那些努力传播SOA的同学们所说的“EDA只是SOA的一个子集”的论断。一个更广泛的事件驱动架构概念，不仅是超越事件驱动SOA的，还应该包括实时信息流和分析，以及复杂事件处理。　　IvarJacobson博士在EDA方面有自己独到的见解。Jacobson提出的问题是：我从需要事件驱动架构吗？在回答他自己的问题时，Jacobson说，“当EDA认为事件是系统中最重要的组成时，你最好注意那些组件或者服务，以及组件之间的‘通道’”。事件可以被生产、传递和消费，甚至在系统中被传播。这种类型系统的一个最大好处就是：　　最有意思的组件是那些服务。你同时有了面向服务的架构（SOA），甚至更多。　　不论哪一种情况，EDA和SOA都不会彼此不相容戒者排斥。它从都能被用来处理复杂事件处理系统，并为你的企业提供自动的戒者有效的产出国家文物总局文物平台同各省文物馆藏系统分析2.1国家文物总局文物平台同各省文物馆藏系统分析　　2.1.1原有软硬件设施分析　　分析评估原有设施对将要开发系统的影响　　l)各省提前购买sybase数据库　　2)各省提前购买了HP小型机3)实际业务流程报表得到第一手资料（数据库设计的基础）　　2.1.2系统硬件需求分析　　1)服务器选择　　2)磁盘阵列的选择及容量分析（对未来增长量的预留）及数据存储方式　　3)24*7不间断工作（镜象） 　　4)安全加密不用（走专线）　基于ASP．NET的Web应用系统架构探讨 摘要：提出了一种基于ASP．NET开发方式的四层架构的Web应用系统构造思想。其基本内容是：将面向对象的UML建模与Web应用系统开发相结合，将整个系统分成适合ASP.NET开发方式的应用表示层、业务逻辑层、数据访问层和数据存储层四层结构。以此方式构造的Web应用不仅达到了代码组织结构清晰明朗、高重用性、适用性，易于维护和移植的目标，而且可以提高web应用系统的开发速度。解决了目前大型Web程序开发中，代码适用性、重用性差，及难于维护和移植的问题。　　引言　　随着计算机网络技术的迅速发展，Web应用系统越发变得日益广泛起来。ASP.NET是微软推出的新一代Web开发平台，与其它Web开发技术相比，ASP．NET提供的Web页面级状态管理功能、服务器控件触发事件的工作模式、代码和内容分离的编程方式等?[1]，在一定程度上改变了以往的web应用系统的架构模式。在软件开发技术方面，面向对象技术和软件分层结构设计是代码组织的一些好方法。但是对于具体的开发平台而言，多层结构有着不同的具体表现；对于具体的项目开发而言，面向对象技术对具体问题进行类定义和对象划分也不相同。因此，如何基于ASP.NET这些新技术在ASP.NET平台上应用面向对象技术架构一个逻辑清晰、模块合理的多层结构的Web应用系统就成了文中讨论的内容。下面以笔者曾参与的《实验室信息管理系统》中的“论文管理子系统”为例，来阐述基于四层架构的设计思想。　　1ASP．NET下Web程序架构　　系统描述：学生可以登记自己的论文，也可以删除自己登记的论文和相关所有回复；老师和学生可以查看、回复论文，也可以删除、修改自己的回复；管理员可以查看、删除登记的所有论文和回复。笔者省略了论文管理系统的使用案例图和使用案例事件流图??[2,3]，只给出了修改自己回复案例的时序图(见图1)。对于基于ASP.NET的Web应用系统，用户直接面对的是客户端浏览器，用户在使用系统时的请求是通过HTTP协议传递给服务器端的ASPX页面，用户操作的事务逻辑处理和数据的逻辑运算由服务器与数据库系统共同完成。按照在系统中的用途分类，把负责系统与角色交互的对象称为边界类对象，把负责系统中访问数据库的对象称为实体对象，把系统中介于边界对象和实体对象之间，负责时序图中流程的对象称为控制对象。故在时序图(见图1)中，Papers．ASPX和Session对象属于边界类对象，Users对象属于控制类对象，Reply对象属于实体类对象。　　1.1ASP．NET下Web应用表示层的架构　　表示层是用户和软件交互的接口，对于Web程序设计而言就是基于HTML的界面。主要职责就是为用户提供信息，以及把用户的操作传送给逻辑层和数据处理层。从使用案例事件流图中，可以确定用于交互的页面个数，再从案例时序图中，可以确定用于和用户交互的页面和服务器端的ASPX页面关系。图2是修改自己回复案例用到的页面关系图。 Papers(View)页面对应用户查看某篇论文的页面，Papers(Edit)页面对应用户查看自己回复的页面。从案例时序图中可以得知它们都是Papers服务器页面在两个不同状态下产生的页面。为了克服传统Web窗体页本身无状态这一固有限制，ASP.NET页框架提供了一种“视图状态”(viewstate)的功能，此功能会在往返行程之间自动保留页以及页上所有控件的属性值，ASP．NET这种特性为数据表现层设计提供了极大的便利。ASP．NET还采用了由服务器控件引发的事件的工作方式。Web窗体控件事件模型要求在客户端捕获事件信息，并且通过HTTP发送将事件消息传输到服务器，框架再解释该发送以确定所发生的事件，然后在要处理该事件的服务器上调代码中的适当方法。通过上面的两项技术ASP．NET框架提供了可以创建传统客户端/服务器Web交互的抽象模型，使开发者能够使用支持快速应用程序开发(RAD)和面向对象编程(OOP)的传统方法和工具来进行应用程序编程。因此,可以根据角色与系统交互的事件流图和页面关系图来架构ASP.NET下Web表示层：　　(1)从页面关系图出发，确定系统中用到的主要功能界面。　　(2)根据ASP．NET中Web控件的特点，对确定的功能界面进行可视化页面布局：　　(3)从事件流图出发，确定功能页面之间以及页面状态之间转移逻辑关系，根据ASP.NET中Web页面级状态管理功能和服务器控件属性、事件编程模式，编写部分页面之间以及页面状态之间转移代码。　　在NET开发工具中，可以使用“所见即所得”页面设计工具对整个页面进行可视化布局，在实现这些页面之间以及页面状态之间转移逻辑关系代码时，可以在Web窗体设计器“设计”视图中，通过修改对象属性或编写事件完成页面的逻辑关系代码　1.2ASP.NET下Web业务逻辑层的架构　　业务逻辑层是整个Web应用系统信息和逻辑处理中心，在时序图中反应为由负责时序图流程的控制对象构成。业务逻辑层也是联系Web应用系统表示层和数据存储访问层的纽带，因此Web业务逻辑层在整个系统的架构中至关重要。从案例时序图中，可以确定控制对象以及控制对象与其它对象所需提供的服务。图3是“修改自己回复”案例的时序图中的users控制对象的类图。由于ASP．NET提供了一种所谓的后台代码，可用于分离用户界面和逻辑代码，而ASP．NET本身也完全支持基于模块与组件开发，因此，为采用面向对象的技术架构逻辑层提供支持，可以从系统用例图和时序图出发在ASP．NET下架构Web业务逻辑层：　　(1)大多数Web应用系统都是属于信息管理系统，所以控制对象可以按照使用系统的角色进行划分控制类。　　(2)从案例时序图出发，确定控制对象所需的功能。　　(3)采用.NET组件方式包装Web业务逻辑层中的功能，从而使逻辑层和表示层在物理上分开。　　在．NET开发工具中，可以采用“类”文件的方式实现Web业务逻辑层中的组件，在工程项目中可以采用添加引用的方式把“类”文件引入Web工程中，这样Web业务逻辑层的功能就可以以对象的方式在应用Web系统的开发过程中使用。　　1.3 ASP．NET下Web数据访问层架构　　数据访问层作为业务逻辑层访问数据存储层的数据访问接口，其主要职责是为数据存储层进行抽象封装，使数据存储层从业务逻辑层看来能完全透明。从案例时序图可以确定实体对象、实体对象的属性及实体对象为控制对象所需提供的服务。图4是“修改自己回复”案例的时序图中“Replys”实体对象的类图。点管理机制系统。它按照对等网络中节点的网络特性对节点进行分组，分组内节点按照传输性能进行分层，通过赋予网络自组织、自适应的功能来增强组播系统的传输性能。在一个大的对等网络中，节点根据分组标准自主形成中小规模的组播群，数据传输主要集中在组内进行。组内管理采用动态集中式控制，主节点掌握了组播组内成员的全局信息节点通过彼此交换信息动态调整组内位置，使得分组内的数据传输性能最优化，从而加强了整个网络的性能。另一方面，由于采取了分组的机制，服务器仅需维护分组信息即可而不用管理所有节点，节点的加入、管理和数据传输等完全由节点间P2P完成，极大地减轻了服务器的负担，提高了可服务的节点数目。采用这种节点分组、组内分层的节点自组织管理机制，能够调整各节点在对等网络中的位置，满足异构网络中各节点所处的不同网络环境。通过组内动态调整，使得输出带宽大的节点处于分组的顶端位置，加快数据的分发从而提高多播的效率以减少数据延时。采取这种上层以tree与下层以mesh为主体的混合结构，极大地增强了网络的鲁棒性。当网络条件变化时，整个网络会随之动态调整。如新节点的退出或失效不会导致转发路径的断裂，转发路径具有自我修复、自我最优化的能力。因此，这种节点管理机制可以应用于大型文件的共享、流媒体等多种场合。　　在实际的应用中，面对复杂的网络环境，如何较为准确地判断节点间的网络距离，进一步强化分组算法和组内管理算法，还有很多工作要做，这是在未来的工作中重点研究的内容。1.4ASP．NET下Web数据存储层架构　　数据存储层的主要功能是把数据访问层的数据处理功能转换为具体的数据库或文件操作。从案例时序图中，可以确定实体对象以及实体类型的属性。实体类中的每个属性可以与数据库中的字段相对应，即每个实体类可以与数据库中的一张表对应。因此，在ASP．NET的Web应用系统中，可以通过System．Data．OLEDB命名空间或System．Data．SQLClient??[4,5]命名空间中的数据库访问和控制类型构造与具体数据库相适应的类。在数据存储层对实体对象的属性和服务的访问中，可以通过这个类完成对数据库的访问和控制。　　2结论　　采用四层架构的思想，并运用UML的对象特点进行类的划分的架构设计，使得代码编写逻辑清晰，易于管理和维护，并且具有很好的代码的可重用性、适用性、易维护性和可移植性。四层架构的编写完全可以由四组人员同时进行，这样代码的维护管理上就更加清晰，并且可以缩短开发周期。但是同时进行的四层代码编写，需要有良好的前期的需求分析的支持。只有完备的需求分析(例如：使程序设计人员都清楚项目所包含或者项目中需要的类名和功能名称，当项目统一使用的时候，就不会因为名称不统一导致引用错误等问题)，才可能真正实现四层架构的并行设计。技术经理和高级程序员如何理解架构开发的实施 　　21技术经理和高级程序员如何理解架构开发的实施　　重量级模块开发实施方案　　轻量级开发实施方案　　22技术经理和高级程序员如何进行Spring的EJB整合（项目经理和高级程序员关注库的问题）　　JndiObjectFactoryBean　　SimpleRemoteStatelessSessionProxyFactoryBean　　LocalStatelessSessionProxyFactoryBean　　jndiTemplate技术经理和高级程序员如何利用Spring同WEB的整合　　25技术经理和高级程序员如何利用Spring同WEB的整合（项目经理和高级程序员关注库的问题）　　ContextLoaderListener　　ContextConfigLocation　　WebApplicationContextUtils　　26技术经理和高级程序员如何利用Spring整合Struts（MVC的一种）　　26.1如何最简便的整合　　26.2Spring给Struts带来了什么　　27Spring编程问题解答架构设计理念解决的实际问题　　8架构设计理念解决的实际问题　　8.1最原始的方式（jsp＝＝java）　　1）B/S不代表好的设计结构　　2）一种错误的思想设计是产品关心的问题，项目关心的是时间、是进度。以数据库为驱动的设计方式不可取　　3）制定相适应的设计结构（项目同样需要设计理念）　　8.2开发复杂度和时间、成本问题　　1）业务的多变性　　2）人员的流动性　　3）升级和可维护性　　4）前期节省的时间，后期成倍的补偿甚至导致整个项目的失败架构师如何设计简单的中小项目或产品(网通内部办公系统)　　9架构师如何设计简单的中小项目或产品(网通内部办公系统)　　1）突出了表现层和逻辑层、持久层的分离　　2）适合单服务器　　3）可控并发量　　4）业务逻辑不是很复杂 架构师如何应用MVC前台分层结构去设计业务逻辑比较复杂的系统10架构师如何应用MVC前台分层结构去设计业务逻辑比较复杂的系统　　10.1设计原理　　10.2解决的问题　　l）对于业务逻辑比较复杂的系统优势明显　　2）层次更加明显　　3）在多服务器中仍可将其推向前端　　10.3使用误区　　1）千万不要将其当作设计架构　　2）它只是前端的解决方案开发人员开发的软件应怎样直观？问题　　第一部分的问题是，用户的想法没有经验或缺乏对软件知识的了解，他们不知道软件的地址应该可以使用该软件。如果我坐在747的驾驶舱内，我不会期望只是看了一眼控制台，就知道如何起飞。(即使我已经做了无数个小时的空军中校)。然而，这正是用户在职责软件开发商时犯的第一个错误。“我不知道它要求我输入我的IP地址时意味着什么，因此该软件使用起来很难。”软件应该寻找一种方式，在没有用户帮助的情况下来获取信息。　　问题的另一部分是，如果该域名相当复杂的话，即使用户明白域名的问题也并不一定能“掌握”一个软件。文字处理器就是一个很好的例子。文字处理器是一种软件，它可以完成数以百计的任务，从书面杂货清单到法律简报再到剧本，所有这一切都有不同的工作流程要求，格式的需要等等。不用说，任何一款软件都不是只为某一个复杂的任务而设计，而是数以百计的复杂任务，这本身就让软件变得复杂。鉴于这些软件的复杂性，我们能期望那些写得一手好文章的人，就可以立即很好地掌握怎样使用文字处理器吗?　　ERP和CRM的应用软件最容易成为企业的攻击目标的。众所周知，出售给应用软件商的大量许可证，如SAP公司的，已经闲置。这些项目的高失败率令人大为震惊，当你考虑他们的标价时，确实是令人无法接受。典型的导致项目失败的一个原因是，经过一年的整合与数百万美元的顾问费和许可证费，用户觉得烦了，盯着屏幕五分钟，就会将它关闭，而软件也就被永远搁置在了架子上。把一个未受过培训用户放到一个复杂的软件面前，并且不提供任何教程不是一个好的方式。应该让用户在接触软件前对其进行培训才是合理的做法。　　对我来说，最令人沮丧的是事情往往不尽如人意。WordPerfect 5.1,是人们喜爱与藐视的混合体，它要求你购买一个键盘覆盖，100——200页的快速参考指南，以及一个500页的详细手册才能好好地使用它。而事实是，你真的需要阅读几百页的文字，才能坐下来对它进行操作。当然也有些时候，用户们有机会坐在一起交流心得，互相帮助。　　改善建议　　我们的行业需要对此问题做出些许努力。当然，我们偶尔会因无用的操作手册而恼怒。毕竟，当唯一在意去阅读它的人是那些能自主解决问题的人时，为什么要打乱程序说明的撰写呢?如此左右为难，因此，程序说明是第一位的。如果您的申请正在处理复杂的任务，你就不能指望一个直观的界面。　　一项复杂的任务会要求大量排练或一个像命令行的界面，或是挤满了按钮的工具栏和大量的键盘快捷键，又或是以其他方式在小小的屏幕里集中大量功能。如果选择像命令行的界面，那么对程序说明的要求更高。不同于向导驱动的界面会对你的每个选择给出解释。充其量，你只会有一个提示条用来解释图标所代表的功能。在这些情况下，用户必须依靠程序说明提供深入的信息。　　有些人误认为，为了使软件能够直观化，它需要有别于市场上“难使用”的产品。网络设备是个很好的例子。如果我要买卖网络设备，我将尽我所能去仿效CiscoIOS的每个细节。尽管思科公司的IOS不是直观的，几乎所有的网络管理员都花了很多时间学习互联网操作系统的复杂性。通过仿效一个真正的可恶的系统，您实际上是与现有用户的知识协作。如果可以的话，使用主流的用户界面或更好的替代物。可能的话，两者可以交替使用。　　我们也不要指望社群为我们提供支持。将一些免费wiki或论坛放到服务器上，把它链接到网页的支持部分，并希望用户互相帮助，这当然是巨大的诱惑，特别是在当前的经济不景气的时候。我并不是说这种情况不会发生，也不是劝你不要建一个wiki或论坛。我的意思是，即使有了这些工具，你的工作人员还是要在wiki或论坛上花大量的时间和精力，并提供许多的答案——至少在你得到一些的优秀人才编辑wiki之前是这样。　　另外，我希望看到更多的新用户和有经验的用户模式软件，特别是在超复杂的应用程序中。如果该软件可以完美过渡到要素到要素就更好了。例如，当用户在没有什么帮助的情况下执行任务甲若干次，该软件停止使用向导，但当使用者第一次执行工作乙时，该软件还在按车轮模式训练。把基于有向导的代理系统与实际指导相结合才是最棒的。　　最后，让我们诚实些，可能的话，把“容易使用”的观点放在营销材料中。相反，我们需要开始建立良好的教学课程以及为销售代表提供免费培训。你觉得哪种选择更花钱：派一个技术指导在现场进行为期一周的训练，让新用户更快上手，或者因为没有人使用系统，而没有一个客户更新其许可证，然后坏了你的口碑?从长远来看，为大客户提供免费的现场培训和为小客户提供免费在线培训更有其可取性。　　最后，对于非专业用户，软件并不需要是直观的。即便是对那些了解软件工作原理的用户，复杂的任务也会有相对应复杂的软件。但是，软件开发人员需要不断寻找途径，以确保用户可以提高速度，可以自己操作 框架不是框框—应用框架的基本思想软件构件化是21世纪软件工业发展的大势趋。工业化的软件复用已经从通用类库进化到了面向领域的应用框架。GartnerGroup认为：“到2003年，至少70%的新应用将主要建立在如软件构件和应用框架这类‘构造块’之上；应用开发的未来就在于提供一开放体系结构，以方便构件的选择、组装和集成”。框架的重用已成为软件生产中最有效的重用方式之一。然而——　　一、构件与框架有何关系？　　1.什么是框架？　　框架（Framework）是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法;另一种定义认为，框架是可被应用开发者定制的应用骨架。前者是从应用方面而后者是从目的方面给出的定义。　　可以说，一个框架是一个可复用的设计构件，它规定了应用的体系结构，阐明了整个设计、协作构件之间的依赖关系、责任分配和控制流程，表现为一组抽象类以及其实例之间协作的方法，它为构件复用提供了上下文(Context)关系。因此构件库的大规模重用也需要框架。　　构件领域框架方法在很大程度上借鉴了硬件技术发展的成就，它是构件技术、软件体系结构研究和应用软件开发三者发展结合的产物。在很多情况下，框架通常以构件库的形式出现，但构件库只是框架的一个重要部分。框架的关键还在于框架内对象间的交互模式和控制流模式。　　框架比构件可定制性强。在某种程度上，将构件和框架看成两个不同但彼此协作的技术或许更好。框架为构件提供重用的环境，为构件处理错误、交换数据及激活操作提供了标准的方法。　　应用框架的概念也很简单。它并不是包含构件应用程序的小片程序，而是实现了某应用领域通用完备功能（除去特殊应用的部分）的底层服务。使用这种框架的编程人员可以在一个通用功能已经实现的基础上开始具体的系统开发。框架提供了所有应用期望的默认行为的类集合。具体的应用通过重写子类(该子类属于框架的默认行为)或组装对象来支持应用专用的行为。　　应用框架强调的是软件的设计重用性和系统的可扩充性,以缩短大型应用软件系统的开发周期，提高开发质量。与传统的基于类库的面向对象重用技术比较，应用框架更注重于面向专业领域的软件重用。应用框架具有领域相关性，构件根据框架进行复合而生成可运行的系统。框架的粒度越大，其中包含的领域知识就更加完整。　　2. 框架和设计模式　　框架、设计模式这两个概念总容易被混淆，其实它们之间还是有区别的。构件通常是代码重用，而设计模式是设计重用，框架则介于两者之间，部分代码重用，部分设计重用，有时分析也可重用。在软件生产中有三种级别的重用：内部重用，即在同一应用中能公共使用的抽象块;代码重用，即将通用模块组合成库或工具集，以便在多个应用和领域都能使用；应用框架的重用，即为专用领域提供通用的或现成的基础结构，以获得最高级别的重用性。　　框架与设计模式虽然相似，但却有着根本的不同。设计模式是对在某种环境中反复出现的问题以及解决该问题的方案的描述，它比框架更抽象；框架可以用代码表示，也能直接执行或复用，而对模式而言只有实例才能用代码表示;设计模式是比框架更小的元素，一个框架中往往含有一个或多个设计模式，框架总是针对某一特定应用领域，但同一模式却可适用于各种应用。可以说，框架是软件，而设计模式是软件的知识。　　二、为什么要进行框架开发?　　框架的最大好处就是重用。面向对象系统获得的最大的复用方式就是框架，一个大的应用系统往往可能由多层互相协作的框架组成。　　由于框架能重用代码，因此从一已有构件库中建立应用变得非常容易，因为构件都采用框架统一定义的接口，从而使构件间的通信简单。　　框架能重用设计。它提供可重用的抽象算法及高层设计，并能将大系统分解成更小的构件，而且能描述构件间的内部接口。这些标准接口使在已有的构件基础上通过组装建立各种各样的系统成为可能。只要符合接口定义，新的构件就能插入框架中，构件设计者就能重用构架的设计。　　采用框架技术进行软件开发的主要特点包括：　　领域内的软件结构一致性好；　　建立更加开放的系统；　　重用代码大大增加，软件生产效率和质量也得到了提高；　　软件设计人员要专注于对领域的了解，使需求分析更充分；　　存储了经验，可以让那些经验丰富的人员去设计框架和领域构件，而不必限于低层编程；　　允许采用快速原型技术；　　有利于在一个项目内多人协同工作；　　大粒度的重用使得平均开发费用降低，开发速度加快，开发人员减少，维护费用降低，而参数化框架使得适应性、灵活性增强。　　三、与框架相关的概念　　1.白盒与黑盒框架　　框架可分为白盒(White-Box)与黑盒(Black-Box)两种框架。　　基于继承的框架被称为白盒框架。所谓白盒即具备可视性，被继承的父类的内部实现细节对子类而言都是可知的。利用白盒框架的应用开发者通过衍生子类或重写父类的成员方法来开发系统。子类的实现很大程度上依赖于父类的实现，这种依赖性限制了重用的灵活性和完全性。但解决这种局限性的方法可以是只继承抽象父类，因为抽象类基本上不提供具体的实现。白盒框架是一个程序骨架，而用户衍生出的子类是这个骨架上的附属品。　　基于对象构件组装的框架就是黑盒框架。应用开发者通过整理、组装对象来获得系统的实现。用户只须了解构件的外部接口，无须了解内部的具体实现。另外，组装比继承更为灵活，它能动态地改变，继承只是一个静态编译时的概念。 　　在理想情况下，任何所需的功能都可通过组装已有的构件得到，事实上可获得的构件远远不能满足需求，有时通过继承获得新的构件比利用已有构件组装新构件更容易，因此白盒和黑盒将同时应用于系统的开发中。不过白盒框架趋向于向黑盒框架发展，黑盒框架也是系统开发希望达到的理想目标。　　2.热点、食谱以及好莱坞原则　　成功的框架开发需要确定领域专用的“热点”(Hotspot)。应用开发者在框架的基础上进行开发，只须扩展框架的某些部分，“热点”就是在应用领域的一种扩展槽，开发者根据自己的需要填充这些扩展槽。“热点”使框架具有灵活性，如在具体的实现中，扩展槽可以被看成是一些抽象类，开发者通过重写抽象方法获得具体实现。　　“食谱”(Cookbook)就是描述如何使用框架方法的文档。在“食谱”中包含了许多“烹饪”方法，这些“烹饪”方法相当于一些具体的操作步骤，描述了为解决某一专门问题如何使用框架的详细方法。框架的内部设计和实现细节通常不出现在“食谱”中。　　框架的一个重要特征就是用户定义的方法经常被框架自身调用，而不是从用户的应用代码中调用。这种机制常称为“好莱坞原则”(HollywoodPrinciple)或“别调用我们，我们会调用您”。如何保障软件测试的质量2009年上半年计算机技术与软件专业技术资格（水平）考试日期：2009年5月23、24日。另外，部分考试科目从2009年上半年开始将采用新修编的考试大纲，具体见：　　在51Testing软件测试论坛里看到了这样的问题——如何保障软件测试的质量，下面是我对这个问题的一些看法：　　对于过程的质量来说，通常要研究这几个单词“Target，Plan，Do，Check，Act”，而对于测试过程的质量来说，从上述几个方面入手，我们可以做的工作就可以分解为如下这些：　　Target：目标——本次活动要达成什么样的目标，或者说测试活动的标准是什么，什么样的情况下可以开始，什么样的情况可以视为结束？测试通过的准则是什么？这个要在活动策划时就明确下来。　　Plan：计划——有了目标后，就开始定制计划了，要包括测试过程的时间，什么时候开始，什么时候结束，本期要分几次迭代，有几个里程碑，通常测试活动划分为如下几个里程碑，有策划过程、计划过程、测试设计过程、测试开发过程、测试执行过程、测试总结与分析过程等，可以按照项目的需要制定这个测试过程需不需要裁剪或增加哪些过程的迭代，并且建议在各里程碑期间都要经过评审，还有测试所需资源、工具、测试工作所需的配置管理和保证方案、初始的测试策略、任务划分等等。　　Do：执行——测试执行期间需要跟踪其执行效率，随时根据需要调整测试策略，以及从缺陷的产生到结束的生命周期管理过程，收集测试过程中产生的各种有效数据，分析并评估问题对用户和系统的影响等等。 　　Check：检查——对上述过程需要随时跟踪以便于及时发现测试期间发现的问题并着手解决问题，这种问题不是测试发现的缺陷，而是测试过程本身某些环节可能会出现与计划不符的地方，可以利用评审会议的形式，也可以是审计文档或对过程审计，有可能是执行有偏差，也有可能是计划本身的问题。　　Act：行动——当测试结束后，需要对测试工作进行分析与总结，我一直强调测试报告里要有两个方面的分析，一种是对测试产品的质量分析和评估，一种是对测试工作过程自身的分析与评估，因为只有有效的过程才能保证有效的输出结果，同时总结经验与教训，对下一次测试活动的过程进行改进。如何利用Spring对JDBC支持　　23技术经理和高级程序员如何利用Spring对JDBC支持　　23.1DataSource　　23.2JdbcTemplate简化数据库操作　　24技术经理和高级程序员如何利用Spring同Hibernate集成（项目经理和高级程序员关注库的问题）　　LocalSessionFactoryBean　　24.1Hibernate　　Hibernate是Java应用和关系数据库之间的桥梁，负责Java对象和关系数据库之间的映射的ORM中间件。简单的说就是　　1)封装了通过JDBC访问数据库操作。　　2)向上层应用提供访问面向对象数据访问的API。如何利用Spring对JDBC支持23技术经理和高级程序员如何利用Spring对JDBC支持　　23.1DataSource　　23.2JdbcTemplate简化数据库操作　　24技术经理和高级程序员如何利用Spring同Hibernate集成（项目经理和高级程序员关注库的问题）　　LocalSessionFactoryBean　　24.1Hibernate　　Hibernate是Java应用和关系数据库之间的桥梁，负责Java对象和关系数据库之间的映射的ORM中间件。简单的说就是　　1)封装了通过JDBC访问数据库操作。　　2)向上层应用提供访问面向对象数据访问的API。 软件架构:DSL领域特定语言初探所谓DSL领域专用语言(domainspecificlanguage/DSL)，其基本思想是“求专不求全”，不像通用目的语言那样目标范围涵盖一切软件问题，而是专门针对某一特定问题的计算机语言。DSL之于程序员正如伽南地之于以色列人，是最初也是最终的梦想。几乎自计算机发明伊始，人们就开始谈论DSL使用DSL了。而前几年随着被誉为“Web开发领域专用语言”的RubyonRails迅速走红，DSL又一次成为人们讨论的热点话题。很多人都认为，DSL将会是软件业的“nextbigthing”。然而随着DSL的日益流行，围绕着DSL出现了很多质疑和误解，比如下面这几个：　　DSL的目标受众是非程序员，业务员或者最终用户　　在很多人的心中，DSL等同于“非程序员的编程语言”(programminglanguagefornon-programmers)，因此DSL的最终受众应该是非程序员，一切不直接被最终用户使用的DSL都不是真正的DSL，仅仅是另一种使代码看起来不像代码的无聊技巧。　　这是一个很有趣的观点，事实上在计算编程语言发展的历史上，的的确确出现过“非程序员的编程语言”，而且还非常有名，它们就是FORTRAN，COBOL这些第一代高级语言。在当时的那个时代，计算机的主要目的是科学计算，而程序员则是专指那些摆弄开关，继电器，纸带以及汇编语言的geek们。而计算机的主要受益者非程序员——也就是那些学者和研究员——不得不委托这些人帮助它们完成从数学公式到机器指令的转换。于是第一代高级语言的主要目的是缩短计算公式和可执行的代码之间的差距（比如Fortran），或者是简化信息管理员的日常工作（比如COBOL）。有趣的是，恰恰是这些当年的“非程序员”把软件开发发展成了一门正当且颇为体面的职业。　　其实当年的“非程序员的编程语言”与今日的DSL境况颇为相似，所不同的是，当代企业级信息系统更为复杂，所关注的焦点逐渐从计算转移到数据上，业务领域和计算机的物理过程也不再具有简单直接的对应关系了。而且随着社会分工细化，就算是通过DSL，我们仍然不太可能把那些衣冠楚楚的HR们，销售们，部门经理们统统拉下水变成新新程序员。　　我仍然要承认，以最终用户为目标受众的DSL是一个很引人侧目很有意思的主意，但是在相当长的一段时间内都是不太现实的。或许我们需要新的方法（比如精益）来协调IT部门和业务部门，或许我们需要全新的软件工程理论，或者某些非常具有独创性的工作方式。谁知道呢，预言未来总是吃力而不讨好的，但我觉得在目前情况下，简单把DSL的受众限制在非程序员，业务员或最终用户上，是值得商榷的。　　DSL＝整洁的代码　　这种观点与前面的观点正好相反，把DSL完全当作程序员的游戏，把一切能将代码写得整齐好看的技巧都归结为DSL。　　虽然从形式上看DSL和“整洁的代码”都具有简洁清晰的特征，但并不能因此将简单将两者草率地归为等同。从概念上说，程序的编写过程就是把业务领域中的问题通过代码或者程序模型表达出来： 　　由于计算机的程序模型较为单一（归根结底都是运算和存储），就算是在面向对象技术成为主流的今天，通常情况下，计算机程序不太可能做到与业务领域中的概念一致，或者具有某些直觉的对应。也这正是因为这样，软件的修改和可维护性并没有想象中的容易。我们必须不断地将业务领域中的概念转换成相应的代码模型，然后再进行修改。这种间接性直接造成了软件的复杂度。　　而DSL的主要目的就是要消除这样的复杂度（或者说，以构造DSL的复杂度代替这种复杂度），DSL就要是要以贴近业务领域的方式来构造软件。因此，DSL的简洁性往往是一种思维上的简洁性，使我们不用费太多的气力就能看懂代码所对应的业务含义。　　从这里我们可以看出DSL和“整洁的代码”的根本不同，“整洁的代码”只是泛泛的要求代码简洁易懂，而不太在意是否贴近业务领域。比如对于一个J2EE开发者来说，DAO，DTO，FormBean，Action已经足够清晰了，但是这却跟DSL沾不上一丝的关联。DSL更注重强调使用业务词汇，尽可能贴近业务模型来编写代码，使业务模型和程序模型之间具有简洁的对应关系。　　因此我们不能将DSL等同于“整洁的代码”，只能说DSL是一种“整洁的代码”而已。　　DSL必须以文本代码的形式出现　　DomainSpecifiedLanguage顾名思义，是一种语言，因此DSL一定是文本代码形式出现的，不是通过文本代码描述的就不是DSL。　　我们之所以偏爱使用文本代码，主要是由于文本代码易于修改且修改效率极高。多年来软件工程实践表明文本代码是最有效率的编辑形式。但是对于DSL，问题则有些不同。　　正如我们前文所说过的，DSL首要的目的，是使程序尽可能地接近业务领域中的问题，从而消除不必要的间接性和复杂性。对于大多数业务领域而言，文本代码的形式一经足够好了，我们可以很容易通过特定格式的文本，描述业务领域中的问题。然后也确实存在着一些较为特殊的领域，在这些领域中，文本代码并不是最佳的表现形式。为了更好的贴近业务领域中的概念，我们可能回选择使用一些图形化的DSL。比如时下颇为流行的一个DSM（DomainSpecificModeling）工具GEMS（GenericEclipseModelingSystem）中就大量地使用了不同的图形化的DSL来表述系统的各个不同侧面。所以我们并不能简单的把DSL局限在文本形式上面。　　DSL的语法应该尽可能地接近英语或者其他自然语言　　由于大多数DSL是描述性的，因此我们应该尽可能地让DSL接近日常使用的英语或者其他自然语言，这样可以增强DSL的表现能力。　　业务自然语言（BusinessNatureLanguage）是DSL的一个重要分支。它的产生是基于这样的一些事实：对于大多数企业应用而言，使用一些类似自然语言的语法和结构构造DSL是不错的选择；通过业务自然语言，可以推动和促进业务人员和程序员之间的沟通；类自然语言的DSL相较其他形式的DSL重用起来较为容易。正是由于上述这些特点，BNL类DSL在DSL的实践中是最流行的。我个人就曾在三个不同的项目里实现了针对不同领域的BNL类DSL，我甚至在Smalltalk语法的基础上修改提炼，得到了一种具有通用语法表达的脚本语言。利用它可以方便地构造DSL。 　　虽然BNL是我实践得最多也是最为喜爱的一种DSL形式，通过前文的分析，我们仍然不能把它当作唯一的DSL形式。我们必须时刻谨记，DSL的首要目的，是使程序尽可能地接近业务领域中的问题，从而消除不必要的间接性和复杂性。合理且恰当地选择语法形式永远是构造DSL的重中之重。软件架构:构建下一代软件架构SOAWeb服务一种作为炙手可热的技术，应用到企业的IT系统和商业流程之中，并给企业带来直接的经济效益，一直以来得到了国内外企业管理者的推崇。而在近两年，伴随着企业需求的不断变化，一种被誉为下一代Web服务的技术架构，再一次引起业内关注，这就是SOA（Service-OrientedArchitecture，面向服务架构）。　　早在1996年，Gartner最早提出SOA的预言，2002年12月，Gartner又提出了SOA是“现代应用开发领域最重要的课题”，并预计到2008年，SOA将成为占有绝对优势的软件工程实践方法，主流企业现在就应该在理解和应用SOA开发技能方面进行投资。　　更好地支持商业流程　　SOA并不是一个新事物，IT组织已经成功建立并实施SOA应用软件很多年了，BEA、IBM等厂商看到了它的价值，并且纷纷跟进。SOA的目标在于让IT变得更有弹性，以更快地响应业务单位的需求，实现实时企业（Real-TimeEnterprise，这是Gartner为SOA描述的远景目标）。而BEA的CIORhonda早在2001年6月就提出要将BEA的IT基础架构转变为SOA，并且从对整个企业架构的控制能力，提升开发效率、加快开发速度、降低在客户化和人员技能的投入等方面取得了不错的成绩。　　由于SOA是在计算环境下设计、开发、应用、管理分散的逻辑（服务）单元的一种规范，这就决定了SOA的广泛性。SOA要求开发者从服务集成的角度来设计应用软件，即使这么做的利益不会马上显现。SOA要求开发者超越应用软件来思考，并考虑复用现有的服务，或者检查如何让服务被重复利用。SOA鼓励使用可替代的技术和方法（例如消息机制），通过把服务联系在一起而非编写新代码来构架应用。经过适当构建之后，这种消息机制的应用允许公司仅通过调整原有服务模式而非被迫进行大规模应用代码的开发，使得在商业环境许可的时间内对变化的市场条件做出快速的响应。　　SOA也不仅仅是一种开发的方法论，它还包含管理。例如，应用SOA后，管理者可以方便地管理这些搭建在服务平台上的企业应用，而不是管理单一的应用模块。其原理是通过分析服务之间的相互调用，SOA使得公司管理人员方便地获取什么时候、什么原因、哪些商业逻辑被执行的数据信息，这样就帮助了企业管理人员或应用架构师迭代地优化他们的企业业务流程、应用系统。 　　SOA的一个中心思想就是让企业应用彻底摆脱面向技术的解决方案的束缚，轻松应对企业商业服务变化、发展的需要。企业IT架构环境中单个应用程序是无法包容业务用户的（各种）需求的，即使是一个大型的ERP解决方案，仍然不能满足这个需求在不断膨胀、变化的缺口。对市场快速做出反应，商业用户只能通过不断开发新应用、扩展现有应用程序来艰难地支撑其现有的业务需求。通过将注意力放在服务上，应用程序能够集中起来提供更加丰富、目的性更强的商业流程。其结果就是，基于SOA的企业应用系统通常会更加真实地反映出与业务模型的结合。　　服务是从业务流程的角度来看待技术的——这是从上向下看的。这种角度同一般的从可用技术所驱动的商业视角是相反的。因为服务的优势很清楚，它们会同业务流程结合在一起，能够更加精确地表示业务模型、更好地支持业务流程。相反，我们可以看到，以应用程序为中心的企业应用模型，迫使业务用户将其能力局限为应用程序的能力。　　企业流程（EnterpriseProcess）是流经企业框架的空气，它赋予业务模型里的组件以生命，并更加清晰地定义了它们之间的关系。流程定义了同业务模型进行交互操作的专门方法。例如，会计可能是企业服务系统的一个组件，但是将发票寄给客户却是一个业务流程。服务被定义用来支持业务流程，因而自始至终地贯穿整个流程：各种服务组件在流程和逻辑实现过程中的装配操作，理解业务流程是定制服务的关键所在。　　有利于企业业务的集成　　传统的应用集成方法，如：点对点集成、企业消息总线或EAI、基于业务流程的集成等，都很复杂、昂贵，而且不灵活。这些集成方法难于快速适应基于企业现代业务变化不断产生的需求。　　基于SOA的应用开发和集成可以很好地解决其中的许多问题。它描述了一套完善的开发模式来帮助客户端应用连接到服务上。这些模式定制了系列机制用于描述服务、通知及发现服务、与服务进行通信。　　不同于传统的应用集成方法的是，在SOA中，围绕服务的所有模式都是以基于标准的技术实现的。大部分的通信中间件系统，如RPC、CORBA、DCOM、EJB和RMI，也同样如此。可是它们的实现都不是很完美的，在权衡交互性以及标准定制的可接受性方面总是存在问题。SOA试图排除这些缺陷。因为几乎所有的通信中间件系统都有固定的处理模式，如RPC的功能、CORBA的对象等等。然而，服务既可以定义为功能，又可同时对外定义为对象、应用等等。这使得SOA可适应于任何现有系统，并使得系统在集成时不必刻意遵循任何特殊定制。　　SOA帮助企业信息系统迁移到“leave-and-layer”架构之上，这就意味着在不用对现有的企业系统做修改的前提下，系统可对外提供Web服务接口，因为它们已经被可以提供Web服务接口的应用层做了一层封装，SOA可以将系统和应用迅速转换为服务。SOA不仅覆盖来自于打包应用、定制应用和遗留系统中的信息，而且还覆盖来自于如安全、内容管理、搜索等IT架构中的功能和数据。因为基于SOA的应用能很容易地从这些基础服务架构中添加功能。所以，基于SOA的应用能更快地应对市场变化，使企业业务部门设计开发出新的功能应用。　　与传统的企业应用集成架构的主要区别在于，基于SOA的企业应用系统使用基于标准的服务，并包括过程/数据服务、编排和组合。基于标准的服务成了应用间的集成点。服务的编排和组合增加了服务的灵活性、重用性和集成性。 　　两种粒度实现SOA服务　　可以按基于服务的功能及发送和接收的数据数量来定义服务，如细粒度服务、粗粒度服务或组合服务。　　在SOA中服务粒度有两种相关的意思，即服务是如何实现的，服务使用和返回了多少数据或多少消息。细粒度服务执行了最小的功能，发送和接收少量的数据。粗粒度服务执行了较大的业务功能，并交换了更多的数据。　　细粒度服务是供粗粒度服务或组合服务使用的，而不是由终端应用直接使用的。如果应用是使用细粒度服务建立的，则应用将不得不调用网络上多个服务，并且发生在每个服务上的数据量较少，因而会对对系统整体性带来影响。所以，粗粒度服务的用户不能直接调用他所使用的细粒度服务。然而，由于粗粒度服务可能使用多个细粒度服务，因此它们不能提供粒度级的安全和访问控制。　　组合服务可以使用粗粒度服务和细粒度服务进行组装。数据数量不是粗粒度服务和组合服务之间的区别。粗粒度服务例子，如创建新客户，在这一过程的操作是：需要通过一些外部服务验证对客户进行验证，并在CRM应用系统中创建客户记录。组合服务例子可以是提供一个新的DSL线，这需要一个服务调用来验证订单、创建或验证客户，确认产品库存及为数据线分配资源。　　通过一组有效设计和组合的粗粒度服务，业务专家就能够有效地组合出新的业务流程和应用程序了。　　成就商务自主　　作为面向服务的计算架构，SOA简化了IT的计算环境，其兼容性、互通性以及最终实现的商务自主的能力，满足了高度动态的商务环境（DynamicBusiness），实现了IT对业务从数月到分秒的响应。专家指出，SOA的最终价值在于让IT和业务同步，在规划上以面向提供弹性的业务服务为目标。从CIO到负责规划的架构设计师，都需要和业务部门之间有充分的沟通。因此，SOA的建立，将会是一个为期数年的承诺，基础建设和标准必需逐步实施。　　在中间件领域，SOA架构日益成为中间件软件供应商争夺的新焦点，谁都希望自己能够先于竞争对手提供最优的SOA技术实现平台，BEA也不例外。从技术上来说，Web服务、组件技术的采用将有助于SOA的进一步普及；从业务上来说，企业用户要求性价比更高的应用系统，SOA恰恰适应了这样的趋势。　　5月底，在美国旧金山举办的BEA第九届技术年会eWorld2004上，来自全球的BEA技术精英将会在现场尽情体验到BEA的技术专家在现场带来的在BEAWebLogicPlatform8.1上的SOA系统设计模式和最佳实践，即有关如何构建SOA系统的技术准则，BEA要让全球的企业用户的信息系统都能够最大化地享受到SOA带来的商业价值。　　GartnerGroup预计，到2008年，SOA将成为占有绝对优势的软件工程实践方法，它将结束传统的整体软件体系架构长达40年的统治地位（可能性：70%）。Gartner建议，主流企业现在就应该在理解和应用SOA开发技能方面进行投资。总之，如何把握，如何运用到自身的企业建设中，SOA已经给出了一个很好的基础 软件架构:理解Rational分析三层结构观点三层结构的简单描述及优点　　三层体系结构，即用户层、应用层和数据库服务器。用户层主要指用户界面，它要求尽可能的简单，使最终用户不需要进行任何培训就能方便地访问信息；第二层就是应用服务器，也就是常说的中间件，所有的应用系统、应用逻辑、控制都在这一层，系统的复杂性也主要体现在应用层；最后的数据库服务器存储大量的数据信息和数据逻辑，所有与数据有关的安全、完整性控制、数据的一致性、并发操作等都是在第三层完成。　　采用J2EE的三（N）层结构的特点　　1．能有效降低建设和维护成本，简化管理　　多层应用结构在各层次上的组件能单独更新、替换或增加、拆除。因此，系统维护更方便，代价相对低得多。而且，因各组件互相独立，更换组件就好比更换组合音响的一个部件，对系统其它部分并无影响，所以更新维护更加安全可靠。　　客户端采用瘦客户机。因为，客户机不必进行大量的计算或数据处理，它的硬件配置就不需要太高。　　通过将业务逻辑集中到中间层，系统获得了对业务逻辑的独立性，即当用户的需求改变时，开发人员可以迅速地在中间层（应用服务器）上更新业务逻辑，而无需将更新后的应用提交到众多的PC终端系统上去，即客户端无需任何改动（改动众多的客户端并不是件轻松的事）。　　2．适应大规模和复杂的应用需求　　如果说结构化方法使软件开发从一门手工艺术走向科学的工程方法，考试,大提示组件技术则使软件工程从个体作坊走向大规模工业。虽然，结构化方法对中小型系统开发能够行之有效，但对大型系统，结构化分析的结果往往是错综复杂的网状结构，而不是结构清晰的层次结构。这也正是面向对象方法学诞生的原因。组件技术能使复杂系统的设计变得简单可行，具有良好的伸缩性。　　三层或多层结构，可以将数据处理从客户端转移到应用服务器和数据库服务器上。这样，尽管客户端与应用服务器之间可能存在着多个甚至数百个的连接，但是应用服务器与数据库服务器之间的连接却只有少数几个，从而达到减少通信线路上传递的数据量的目标。这样的功能分配提供了很强的系统可伸缩性，使得在用户数量急剧增加时还能保持系统性能的稳定。使用传统的客户机/服务器模式根本无法胜任上千个客户机同时运行同时需要访问数据库的工作。即使在用户数量很大的情况下，数据库仍能保持良好的工作负载，保持系统的快速的响应速度。　　3．可适应不断的变化和新的业务需求　　任何应用系统实施的重点不在于需求确定以后能否实现这些需求，而是在系统实施后如何适应变化的需求。J2EE系统结构和组件式系统的开发和维护过程中，技术人员可以按照新的需求，通过在不同系统层次上调度更新的组件或新加入的组件来调整旧的系统，以适应新的与不断变化的要求。以往的系统只能靠专业维护人员或系统开发商的再次开发或修改原有系统，才能满足新的需求，代价往往很大，无法保证时间上的要求。 　　4．访问异构数据库　　多层结构的中间层即应用服务器能够提供广泛的异构数据库访问和复制能力。传统的客户机/服务器结构则需要在客户端安装许多访问异构数据库的驱动程序，而三层/多层结构只要在中间层有相应的驱动程序就可以访问异构数据源。　　5．能有效提高系统并发处理能力　　传统的一体化集中式系统或客户服务器架构，在处理大信息量业务时，都可能形成瓶颈。而多层体系架构的组件式系统将界面、界面发布、业务应用逻辑及数据存储分为多个层次分散管理，逻辑或物理地将它们分开，可减轻系统压力，提高整体性能。并且中间层可以采取多机并行的方式，相互备份的方式，保证系统的高可用性。　　一般情况下进行数据分析时，每次查询可能涉及到大量的数据，往往需要较长的响应时间，特别在分布式数据环境下，响应时间有时长得令人难以忍受。三层（多）层结构提供了客户端与服务器之间的异步通信，使得客户不必等待提交的分析处理结果而可以继续执行其他处理任务。　　6．能有效提高系统安全性　　多层体系结构将数据与程序、数据控制与应用逻辑分层独立管理，能更严格地控制信息访问；信息传递中采用数据加密技术，可进一步减低信息失密的风险。应用服务器内建安全控制数据库，实现应用服务器与数据服务器的双重权限控制，对权限的划分更准确、灵活、严格。新系统在信息访问、传递和存储三个环节上均有严格的安全措施。软件架构:软件架构设计的三个维度　　架构设计是一个非常大的话题，不管写几篇文章，接触到的始终只是冰山一角，更多的是实践中去体会。这篇文章主要介绍面向对象OO、面向方面AOP和面向服务SOA这三个要素在架构设计中的位置与作用。　　架构设计有三个维度，或者说是我们在考虑架构时需要思考三个方向。　　这三个维度分别为面向对象、面向方面、面向服务。　　这三个维度可以看作是正交的，但不同维度会互相印证，互相支撑，整个架构的示意图如图所示。　　图：架构三维度结构图 面向对象　　面向对象技术最初是从面向对象的程序设计开始的，它的出现以上世纪60年代Simula语言为标志，并在Smalltalk语言的完善和标准化过程中得到更多的扩展和对以前思想的重新注解。　　上世纪80年代中后期，面向对象程序设计逐渐成熟，被计算机界理解和接受，人们又开始进一步考虑面向对象的开发问题。直到现在，面向对象已经成为一种非常流行的编程方式，以及软件设计的架构。　　面向对象提出有三个主要目标:重用性、灵活性和扩展性，强调对象的“抽象”、“封装”、“继承”和“多态”。它能让人们以更加接近于现实世界的方式来思考程序，这点可以说是面向对象最大的进步。　　在OO思想的运用上，业界出现了很多好的经验与技巧，从而涌现出大量的设计模式，可以说面向对象是系统分析与设计时的一个很重要的方面。　　面向方面　　面向方面最初来源于hook技术，本质上就是满足扩展的需求，可以在程序中自由扩展功能。　　面向方面不仅仅是一门编程技术，同样也是一种架构设计的思路。如果说OO是纵向地分析、切割整个系统，那么可以认为AOP是横向地对系统作切片。　　简单地理解，OO与AOP分别从两个不同的角度给我们提供了分析系统的思路。面向方面可以弥补面向对象的缺陷，两种方式有机的结合在一起，可以更加有效地对系统进行分析。　　我们认为OO是接近于人类认识自然的思维方式，但对于东方而言却并不一定是这样的。　　当西方人看到一个复杂系统的时候，只会有一种思路，就是“分解”，将系统分解成一块一块，然后每个部分进行研究。　　当东方人看到一个复杂系统的时候，更多地会关注系统中存在的关系，将系统作为一个有机的整体进行研究，这也是东方和西方在事物看法上存在的差异。　　这两种思维方式都没有问题，如果结合起来分析问题，解决问题会更好。面向对象与面向方面也同样如此，都能对应到人类认识自然的思维方式上。　　面向服务　　面向服务可以说是最近炒得比较火热的概念。包括现在提到的SaaS（Softwareasaservice），软件即服务。准确而言，面向服务不仅仅是软件行业的概念，这个要从社会的产业结构说起。　　社会产业总共分为三个，第一产业农业，第二产业工业，第三产业服务业。最早社会的主要产业是第一产业农业，将近有几万年的历史。　　十八世纪下半叶在英国开始的工业革命，对人们的生活产生了根本性的影响，社会的主要产业成了第二产业工业。　　现在仍然属于工业时代，或者有人说的“后工业时代”。而在后工业时代，社会的经济体制必定要向第三产业服务业逐渐转型。面向服务其实是社会经济体制重心的一种迁移。　　还是说回到软件行业，社会的主要产业将转变成服务业，自然软件行业也会出现对应的变化，那就是这里提到的面向服务。面向服务今后会影响到软件的交付模式，会对整个软件行业的体制产生影响。　　而说到架构层面，面向服务是系统发布功能的一种方式。并且基于这种方式下不同的系统之间能有效地通信、协作。常见的实现技术就是WebService。 　　软件全局观　　软件架构设计的三个维度：面向对象、面向方面、面向服务。　　最年长的一个维度就是面向对象，发展了好几十年，也是相对而言比较成熟的一个维度。它解决的问题是系统内部结构的设计。　　面向方面思想的提出能够弥补面向对象的缺陷。面向对象的方式不能实现横切关注点的分离，而面向方面正是为了解决这个问题。面向方面与面向对象一样都是解决系统内部结构的设计。　　面向服务更多的是涉及到系统的外部，简单地说就是发布功能。它并不关注系统内部结构的实现，所以说面向服务与面向对象或者面向方面并不冲突。　　这三个维度并不是绝对孤立的，它们之间会互相影响、制约，相互发展的。我们在分析架构的时候需要同时考虑到这三个维度的问题，这样有助于我们设计出更加优秀的架构。软件架构:软件系统设计层次与内容 　　一般来说，系统设计分为系统总体设计、子系统（组件）设计、模块设计三级，特殊情况下，设计可以分两级或更多级别来完成，遵循层次细化的原则，以保证设计工作的有效性和顺利实施。在不同的设计层次所需要设计的内容如下表。　　总体设计　　子系统（组件）　　模块（单元）设计　　功能设计　　总体功能结构　　子系统及组件物理部署　　系统层次结构　　公共组件　　子系统功能结构　　子系统模块物理部署　　子系统模块层次结构　　公共组件功能结构　　模块功能流程，主要包括业务逻辑。　　数据结构设计　　全局数据结构　　子系统（组件）内全局数据结构　　通信接口组件　　外部接口数据　　总体测试数据　　子系统公用数据结构　　模块内公用数据结构　　子系统测试数据　　模块内局部数据结构（包括协议包结构等）。　　模块测试数据　　数据库设计　　总体数据库结构　　数据库公共管理组件　　公共数据库表结构　　子系统通用数据库表　　子系统专用数据库表　　模块专用数据库表　　界面设计　　系统主界面　　用户功能子系统切换界面　　统一登录界面　　功能子系统界面　　用户功能模块单元界面　　安全设计　　权限划分与管理　　子系统权限　　功能模块单元权限 　　数据安全管理设计　　系统性能设计　　设计完成的交付产物　　总体设计说明书　　数据模型文件　　子系统（组件）设计说明书　　数据模型文件　　子系统（模块）详细设计说明书　　数据模型文件软件架构:再说权限设计我在通用权限的设计(上)以及通用权限的设计(下)两文中简单的介绍了一种权限设计的思路。　　为了把做法说清楚，我采用了最简单的设计来说明问题，其他涉及到的实际问题，我都没有详细说明。并且我在通用权限的设计(下)一文中已经说了这种方法必然有其适用的范围，在这里我不妨把这个适用范围说得清楚一点：首先是权值的存放，功能点的权值必须满足2的n-1次方，也就是说如果我们存放权值的类型是int类型的话，那么理论上我们这种做法只能适用32个功能点，也就是2的31次方为最大那个权值。如果我们采用bigint类型来存放，那么我们理论上可以做64个功能点的，也就是2的63次方为最大那个权值。但是如果我们的系统所需要的功能点远远不止64个，那是不是就无法采用这种二进制按位与、按位或的做法了？其实答案是否定的，我们不妨把功能点分组，也就是所谓的按模块划分，假设有如下的情况：　　公告模块　　增加——00010001　　删除——00010010　　修改——00010100　　查找——00011000　　新闻模块　　增加——00100001　　删除——00100010　　修改——00100100　　查找——00101000　　我们假设系统有公告以及新闻两个模块，我们用八位二进制码的前四位来表示所属的模块，用后四位来表示模块下面对应的功能点，模块与功能点又各自满足2的n-1次方的规律，也就是有公告模块的增加操作的功能点是00010001前四位代表模块，不同模块前四位必须满足2的n-1次方，不能重复，后四位代表对应模块下面的功能点，功能点必须满足2的n-1次方，但是只要求在模块内不重复就行。也就是如果有公告的增加操作为00100001，与新闻模块的增加操作00010001比较可以看出前四位是不同的，并且满足2的n-1次方，后四位却是相同的，但是二者总体来看的话却是代表不同的数，分别为17以及33。 　　讲到这里你是否已经明白怎么回事了？　　如果我们采用这种模块划分的做法的话，我们创建角色以及更改角色的时候，只需要把功能点的权值相加改成功能点的权值按位或操作即可，即如果角色B具有公告模块的增加操作与新闻模块的增加操作的时候就应该进行00010001|00100001=00110001；其他判断与操作均与通用权限的设计(下)说的一样。　　那么假如我们用64位来存放权值，并且前54位我们用来保存模块，后10位我们来保存模块对应的功能点（实际上大部分模块的功能点都只是增删改查4个就够了），也就是说我们实际上可以支持的功能点总数就是：54*10=540个，一般系统应该够用了，如果你的系统的模块较多，模块对应的功能点又较少，我们可以调整模块与功能点所占位数的比例，以此来适用你的系统软件架构的艺术之软件架构的误区在现实中，我们会发现很多从业人员对软件架构的认知有着明显的局限和偏差，具体体现在以下几点。　　误区一：不知道架构与设计的区别　　虽然许多从业人员的头衔为“架构师”，但是他们并不能回答下面的一些问题：　　系统架构与设计有区别吗？区别在哪里呢？　　什么样的人能满足系统架构师的要求？　　什么样的人能满足设计人员的要求？　　一般地，架构师都是技术出身，他们可能长期从事过编码、设计领域的工作。很自然，他们可能认为设计、编码工作就是软件架构的一切。但是真正的架构师必须有长期设计的工作经验，并在系统化的提升之后才可能成为合格的架构师。他们需要考虑商业概念、商业运作、系统结构、结构优化等这些更为宏观的方面，然后选择那些最经典的实践参考模型，才能构建出合格的软件架构。　　误区二：不知道系统架构该如何做　　让我们回到日常的软件系统活动中来。其实通过一些实践，我们已经逐步建立起一些对软件架构及设计活动的认知。直觉和经验告诉我们，一个软件系统或软件架构在构建之初就给架构师留下了充分的创作空间。但是，一个单纯为了一系列功能的实现而构建的架构，还不能称作严格意义上的软件架构。一个真正意义上的软件架构，是需要考虑如下的一些系统要求：　　好的系统，一定是一个架构灵活的系统。　　我们需要一个方便维护的系统来满足可维护性的要求。　　当系统用户数量随着业务的扩展而增加，我们的架构还能应对。　　架构设计人员能够确定当前运行系统的下一个时刻的状态。　　最大峰值时，系统还能保持运行，系统性能不会明显下降。　　我们的系统能够与其他系统进行集成。　　但是许多架构师并不知道在系统架构构建时期，他们应该完整考虑哪些因素，应该采用怎样的手段，应该完成什么任务，才能够构建出一个久经考验的系统架构。 　　误区三：只盲目追随业界通用框架　　事实上，我们在工作中，也许还会听到这样一些声音：　　我们要解决一个分布式的问题，CORBA很好而且还很标准化，用这个架构就行了。　　我们要做一个电子政务的应用，J2EE框架不就很流行嘛，就选这个架构吧。　　我们要做一个车载电子系统平台，OSGI就是一个好的嵌入式平台，就用它吧。　　上述只不过是我们经常能见到的一种对框架或中间件的依赖现象。如果我们每开发一个应用或产品，都要自己手工设计一个框架，确实是一件令人痛苦的事。当然，我们承认现在有很多产品化的、很成熟的框架或中间件，确实极大方便了我们的应用及产品开发。这似乎给人们一种错觉，以为应用和产品开发是一件很容易的事。但是，我们也要清醒地认识到这些框架或中间件背后实际上隐藏了很多技术、设计、应用场景，也就是说为设计开发人员隐藏了很多系统设计开发的复杂性。于是当产品开发或项目结束时，你就可能听到这样的抱怨：　　我们应用CORBA架构的系统在运行时速度很慢，而且很复杂，出了问题却不知道症结在哪里。　　我们的J2EE架构让我们使用了大量的EJB和JavaBean，简直就是构件的海洋，太难维护了。　　我们的车载电子系统根本就不工作，打开汽车车门，插入车钥匙，点火，需要等上几十秒，电子系统都没有反应。　　所以，系统架构并不是简单地应用一个流行的、通用的、看似很唬人的某某通用框架，从而使自己的系统过分地依赖流行的框架或中间件，同时把所有的系统级质量要求统统扔给这些框架或中间件，以寄希望于这些通用框架代替你去思考和处理你应该解决的问题。　　实际上，我们应该寄希望于自己来构建系统架构，使其能够做到：　　即便是最大峰值运行时，系统也要有很好的性能。　　当系统面对大量并发事件时，能够很好地进行调度和并行处理。　　当系统资源使用频繁且负荷增加时，系统能够很好地协调资源的运用。　　当我们设计的重要实时系统（例如航空管制系统）出现错误时，能快速实现系统的自我恢复。　　这些都是软件架构及设计人员自己应该动手解决的问题。引用FrederickP在1986年《NoSilverBullets》一文中说过的一句经典名言"Silverbulletsdonotexist"，即"世上没有万能的解药"。FrankBuschmann也曾经说过"Anyframeworkormiddlewarecanonlyhelpyouindoingyourjob,butitcannotdoyourjobforyou"，即"框架或中间件是用来帮助你的，而不是代替你去思考和工作的"。所以我们必须根据现实的系统要求（功能和非功能要求），自己去构建适合现状的软件架构！软件系统架构对测试的影响分析2009年上半年计算机技术与软件专业技术资格（水平）考试日期：2009年11月14、15日。另外，部分考试科目从2009年上半年开始将采用新修编的考试大纲，具体见： 　　我们知道软件系统的架构会对系统测试产生影响，而到底会产生哪些影响呢?　　首先看一下软件系统架构到底是如何定义的?　　软件系统架构就是组成系统的主要重要模块、过程、数据的管理和分配、用户界面的种类和风格，以及系统运行平台等。其中包括它们的结构和彼此间的准确关系，他们可被扩展和修改的方式，他们依赖于某种技术，是怎样得到系统性能和灵活性的，又是如何确定系统实施或修改计划的。　　软件架构之所以重要是因为优秀的架构是确保软件长期成功的关键因素。而对于我们测试来说，其软件架构会对测试实施产生哪些影响呢?　　首先是稳定性。稳定性可以降低在版本更新时扩展系统功能的重复老师，并减少实施过程的总成本。它巩固了开发团队的基础，使其专注于开发更大价值的特性，而并非浪费精力关注在经常变更的问题上。对于良好的系统架构，会使测试设计更稳定，减少因变更带来的测试工作量。　　对变更的度和性质。架构决定系统中发生变更的性质。有些变更很容易被察觉，而察觉另一些则很难。在我们为吸引更多客户而需要提高客户满意度或增加功能时，如果能够简单实现预期的变更，那么各种架构通常被认为是好的。系统的功能需求变更，使系统受影响的部分最小，避免大量的回归测试。　　社会架构。优秀的架构为创建它的团队而工作。它可以平衡团队内部的个体在实力和能力上存在的差异，而且可以弥补各自的弱点。例如团队对C++的内存管理经常使用不当，而如果使用Java、Perl或C#等系统自动进行内容管理的开发语言可以减少这方面的问题。而我们测试中，则对于内存方面的测试则可以考虑的较少一些。对我们招募测试团队的人员的技能也产生影响。　　边界的决定。在架构的设计过程中，团队会就哪些应该被加入到系统中，而哪些不应该被加入到系统中做出很多决定。例如，是团队自己写数据库访问层，还是购买许可?团队是使用开源的Web服务器还是购买许可?那个子团队应该负责用户界面的设计?成功的解决方案确实能够创建技术边界来支持业务的特殊需求。这些边界选择可直接影响我们的测试，例如，服务器监控、服务器性能参数调优等。　　可持续的、不可替代的优势。这一点可以概括前面的几点，但是一个好的架构能够使系统在市场竞争由于难于复制而占据优势地位。例如在性能和易用性方面获得优势。这对于我们测试来说，可以减少缺陷，性能更能达到目标而减少系统调优后反复测试的过程。　　创建系统架构的实际方法就是探索多种已被文档化的模式，所以关于开发模式的书籍比较畅销，也正是很多研发管理人员必读的书籍。　　测试团队要对软件系统架构进行理解，应该着重分析研发团队提供的一些视图，以增加对系统架构的理解。 　　逻辑视图。它提供了系统开发中对象间或实体间相互关系的静态快照。这种视图实际上可能有两个或更多的表现层。一个概念模型，另一个是数据库模式中模型的实现。往往现在数据库架构师使用PowerDesigner描述实体的逻辑关系，所以需要我们测试工程师学会查看数据库实体描述，从而了解系统中的数据库设计，例如关键字，索引、表实体之间的关系等。　　过程视图。过程视图描述设计的并发性和同步性因素。我们了解过程视图，从而会了解系统中各个模块之间的时间、空间关系。原来的结构化编程中经常用流程图来表示，而现在面向对象的编程经常用一些建模工具描述对象实体。例如，架构师经常使用Rose等建模工具，建立实体的序列图、状态图等来描述过程。而我们测试工程师应该学会看懂序列图或状态图等。　　物理视图。物理视图描述软件到硬件的映射，其中包括实现高可用性、可靠性、容错性和性能等目标的处理部件的分布情况。常用Rose部署图来描述物理视图，也可以使用Visio等绘图工具绘制系统架构图来描述。　　开发视图。开发视图描述软件在开发环境中的静态组织结构。研发团队通常用Rose等建模工具绘制实体关系图，描述各个实体之间的静态关系。　　了解了系统的架构之后，对于测试来说，就应该做相应的准备工作。包括招募具有相应技能的人员。针对特定的结构采取相应的测试设计。例如，对于J2EE架构，则要考虑如何集成测试，采用何种集成策略。对于性能测试，考虑哪些测试。例如研发采用Weblogic作为应用服务器，则我们要考虑该服务器哪些配置参考会影响系统的性能。物理架构中具有中间件服务器，则我们对中间件服务器如何测试。　　总之，了解一些软件系统架构，对于测试人员尤其是测试管理人员是非常需要的。使用BeginUpdate和EndUpdate使用BeginUpdate和EndUpdate　　许多Windows窗体控件（例如，ListView和TreeView控件）实现了BeginUpdate和EndUpdate方法，它们在操纵基础数据或控件属性时取消了控件的重新绘制。通过使用BeginUpdate和EndUpdate方法，您可以对控件进行重大更改，并且避免在应用这些更改时让控件经常重新绘制自身。此类重新绘制会导致性能显著降低，并且用户界面闪烁且不反应。例如，如果您的应用程序具有一个要求添加大量节点项的树控件，则您应该调用BeginUpdate，添加所有必需的节点项，然后调用EndUpdate。下面的代码示例显示了一个树控件，该控件用于显示许多个客户的层次结构表示形式及其定单信息。　　[C#]　　//SuppressrepaintingtheTreeViewuntilalltheobjectshavebeencreated.　　TreeView1.BeginUpdate();　　//CleartheTreeView.　　TreeView1.Nodes.Clear();　　//AddarootTreeNodeforeachCustomerobjectintheArrayList.　　foreach(Customercustomer2incustomerArray)　　{　　TreeView1.Nodes.Add(newTreeNode(customer2.CustomerName) );　　//AddachildTreeNodeforeachOrderobjectinthecurrentCustomer.　　foreach(Orderorder1incustomer2.CustomerOrders)　　{　　TreeView1.Nodes[customerArray.IndexOf(customer2)].Nodes.Add(　　newTreeNode(customer2.CustomerName+"."+order1.OrderID));　　}　　}　　//BeginrepaintingtheTreeView.　　TreeView1.EndUpdate();　　[VisualBasic.NET]　　'SuppressrepaintingtheTreeViewuntilalltheobjectshavebeen　　created.　　TreeView1.BeginUpdate()　　'CleartheTreeView　　TreeView1.Nodes.Clear()　　'AddarootTreeNodeforeachCustomerobjectintheArrayList　　ForEachcustomer2AsCustomerIncustomerArray　　TreeView1.Nodes.Add(NewTreeNode(customer2.CustomerName))　　'AddachildTreeNodeforeachOrderobjectinthecurrentCustomer.　　ForEachorder1AsOrderIncustomer2.CustomerOrders　　TreeView1.Nodes(Array.IndexOf(customerArray,customer2)).Nodes.Add(_　　NewTreeNode(customer2.CustomerName&"."&order1.OrderID))　　Next　　Next　　'BeginrepaintingtheTreeView.　　TreeView1.EndUpdate()　　即使在您不希望向控件添加许多对象时，您也应该使用BeginUpdate和EndUpdate方法。在大多数情况下，您在运行之前将不知道要添加的项的确切个数。因此，为了妥善处理大量数据以及应付将来的要求，您应该总是调用BeginUpdate和EndUpdate方法。注调用Windows窗体控件使用的许多Collection类的AddRange方法时，将自动为您调用BeginUpdate和EndUpdate方法。使用SuspendLayout和ResumeLayout　　使用SuspendLayout和ResumeLayout　　许多Windows窗体控件（例如，ListView和TreeView控件）都实现了SuspendLayout和ResumeLayout方法，它们能够防止控件在添加子控件时创建多个布局事件。如果您的控件以编程方式添加和删除子控件或者执行动态布局，则您应该调用SuspendLayout和ResumeLayout方法。通过SuspendLayout方法，可以在控件上执行多个操作，而不必为每个更改执行布局。例如，如果您调整控件的大小并移动控件，则每个操作都将引发单独的布局事件。这些方法按照与BeginUpdate和EndUpdate 方法类似的方式操作，并且在性能和用户界面稳定性方面提供相同的好处。下面的示例以编程方式向父窗体中添加按钮：　　[C#]　　privatevoidAddButtons()　　{　　//Suspendtheformlayoutandaddtwobuttons.　　this.SuspendLayout();　　ButtonbuttonOK=newButton();　　buttonOK.Location=newPoint(10,10);　　buttonOK.Size=newSize(75,25);　　buttonOK.Text="OK";　　ButtonbuttonCancel=newButton();　　buttonCancel.Location=newPoint(90,10);　　buttonCancel.Size=newSize(75,25);　　buttonCancel.Text="Cancel";　　this.Controls.AddRange(newControl[]{buttonOK,buttonCancel});　　this.ResumeLayout();　　}　　[VisualBasic.NET]　　PrivateSubAddButtons()　　'Suspendtheformlayoutandaddtwobuttons　　Me.SuspendLayout()　　DimbuttonOKAsNewButton　　buttonOK.Location=NewPoint(10,10)　　buttonOK.Size=NewSize(75,25)　　buttonOK.Text="OK"　　DimbuttonCancelAsNewButton　　buttonCancel.Location=NewPoint(90,10)　　buttonCancel.Size=NewSize(75,25)　　buttonCancel.Text="Cancel"　　Me.Controls.AddRange(NewControl(){buttonOK,buttonCancel})　　Me.ResumeLayout()　　EndSub　　每当您添加或删除控件、执行子控件的自动布局或者设置任何影响控件布局的属性（例如，大小、位置、定位点或停靠属性）时，您都应该使用SuspendLayout和ResumeLayout方法。讨论轻量级和重量级架构 　　18.3讨论轻量级和重量级架构的各自优缺点和我们面对具体项目的选择，没有最好只有适合。　　19系统架构师如何看待测试技术（千万不要开发完毕才去测试）　　你当然不用亲自去测试，可你必须指导技术经理或项目经理去制定测试方案，如何在项目初期，让跌代开发和测试相结合呢。　　白箱测试、黑箱测试、单元测试、集成测试、功能测试　　性能测试　　负载测试　　压力测试为了使用拦截器要做三件事 17.2.1为了使用拦截器要做三件事　　1)创建拦截器　　MethodBeforeAdvice用于在目标方法调用前触发；　　AfterReturningAdvice用于在目标方法调用后触发；　　ThrowsAdvice用于在目标方法抛出异常时触发；　　MethodInterceptor用于实现Around通知（Advice），在目方法执行的前后触发。　　如果要实现相应功能，则需要实现上述对应的接口。例如：实现Before通知（Advice）需要实现方法voidbefore(Methodmethod,Object[]args,Objecttarget)，实现After通知（Advice）需要实现方法voidafterReturning(Methodmethod,Object[]args,Objecttarget)，invoke(MethodInvocationmethodInvocation)。　　2)注册切入模式　　RegexpMethodPointcutAdvisor　　3)切入　　ProxyFactoryBean开发SpringAOPAdvice很方便，可以借助代理类快速搭建SpringAOP应用。　　4)对象池的应用　　CommonsPoolTargetSource无接触部署更新　接触部署更新　　如果您已经使用无接触部署方法部署了简单应用程序或更为复杂的应用程序的组成部分，则通过在Web服务器上放置新文件即可更新这些程序集。在应用程序加载程序集之前，NETFramework会自动在本地以及在Web服务器上检查该程序集的时间戳，以便确定是否需要重新下载该程序集，或者是否可以只是从用户的程序集下载缓存中运行该程序集。　　注:无接触部署具有许多限制，使其不适合于部署大多数智能客户端应用程序。有关详细信息，请参阅本章前面的“无接触部署”。　　尽管使用无接触部署方法发布更新通常非常简单，但您的客户端有可能在升级过程中由于缺少对事务性安装的支持而出现问题。如果您在客户端使用应用程序的过程中 更新目录，则客户端最初可能下载旧代码，然后尝试下载自那时起已经更新的其他代码。这可能导致不可预知的结果，并且可能导致您的应用程序失败。该问题最简单的解决方案是将任何重要的更新都部署到Web服务器上的单独目录中，然后在部署完成后，将所有链接更改到这一新位置。　　注:如果您选择使用带有自动更新存根的无接触部署方法来部署您的应用程序，则请参阅下一节“自动更新”无接触部署更新接触部署更新　　如果您已经使用无接触部署方法部署了简单应用程序或更为复杂的应用程序的组成部分，则通过在Web服务器上放置新文件即可更新这些程序集。在应用程序加载程序集之前，NETFramework会自动在本地以及在Web服务器上检查该程序集的时间戳，以便确定是否需要重新下载该程序集，或者是否可以只是从用户的程序集下载缓存中运行该程序集。　　注:无接触部署具有许多限制，使其不适合于部署大多数智能客户端应用程序。有关详细信息，请参阅本章前面的“无接触部署”。　　尽管使用无接触部署方法发布更新通常非常简单，但您的客户端有可能在升级过程中由于缺少对事务性安装的支持而出现问题。如果您在客户端使用应用程序的过程中更新目录，则客户端最初可能下载旧代码，然后尝试下载自那时起已经更新的其他代码。这可能导致不可预知的结果，并且可能导致您的应用程序失败。该问题最简单的解决方案是将任何重要的更新都部署到Web服务器上的单独目录中，然后在部署完成后，将所有链接更改到这一新位置。　　注:如果您选择使用带有自动更新存根的无接触部署方法来部署您的应用程序，则请参阅下一节“自动更新”性能测试总结(B/S架构系统)参考及其引用1、概述　　对于目前以B/S结构为主的产品来说，性能是一项必测的内容。　　关于性能方面的测试，在很多地方又被细分为：负载测试、强度测试、容量测试、压力测试等等。这种细分在概念描述上有一些用处，但在实际工作中很少会只单独的进行其中的某一项测试，实际测试基本上都是交叉性的。我们这里把所有与性能相关的测试统称为性能测试，不做具体区别。　　我们在这里所说的性能测试，指的是对系统整体性能的测试，不涉及单元模块的性能检测。　　我们在这里讨论的内容主要是基于B/S 架构的应用。　　要讨论性能测试，很难不涉及测试工具，我们在这里以MI公司的LoadRunner为默认的测试工具。　　2、性能测试的介入时机　　性能测试应该在什么时候开始?对测试人员来说，在产品的功能稳定下来后，就应该尽早开始对产品进行性能测试。一般建议在产品的3轮完整功能测试后开始。　　3、测试过程　　性能测试的整体测试过程如下：　　3.1制定性能测试计划　　3.2搭建测试环境　　3.3编写测试程序/脚本　　3.4测试执行和分析　　3.5编写测试报告，结束测试　　4、过程说明　　各个子过程的具体说明：　　4.1制定性能测试计划　　分析被测试系统的情况，收集性能测试需求。制定测试计划，形成文档。测试计划应考虑以下内容：　　测试对象和场景。即我们要测试的内容是什么。系统最后对外提供的功能有很多，我们不可能也没有必要对系统所有的功能点都进行性能测试。挑选性能测试对象的一般原则是：选取那些在系统实际投入使用后，并发访问量较大的、算法比较复杂的、占用系统资源较多的功能点，也就是压力点。设定好要测试的压力点后，需要详细的描述出具体的操作过程，以及预期应该达到的性能指标。　　注：在制定测试计划时，对于系统预期应该达到的性能指标，常常是不能获得一个准确的数字。但即使是在没有任何参考数据的情况下，也应该和开发人员一起，设定一个初步的性能指标，作为后面测试的一个参照。有一个初步指标，也比没有任何指标要好。　　测试环境。具体包括：选用什么样的硬件环境(计算机配置，网络结构);什么样的软件环境(操作系统，数据库，应用服务器，Web服务器);多大的数据量(数据库，文件系统)。　　需要监控的资源。进行性能测试时，需要监控的系统软硬件资源的占用情况。这和产品的具体情况有关，一般可以考虑的因素包括：CPU使用情况、Memory的使用情况、磁盘的I/O、网络的占用情况、数据库运行状况、Web/应用服务器运行状况等。　　测试工具。选用什么工具进行性能测试，是自己开发，还是选用第三方的测试工具。　　进度安排。各阶段的工作内容、时间安排。　　4.2搭建测试环境　　依照测试计划中的测试环境要求，搭建实际的测试环境，安装配置还好硬件、软件，准备好测试数据。　　4.3编写测试程序/脚本　　编写实际的测试程序或脚本。如果能够使用现有的成熟测试工具则尽量选用，如果现有工具不能满足测试要求，则需要编写定制的测试程序。　　同时，要为脚本编写说明文档，文档的内容主要是脚本的名称，以及其对应的测试内容。 　　4.4测试执行和分析　　设定多种测试场景组合，反复运行测试，记录结果数据，逐步优化系统，最后达到一个可接受的性能结果。测试执行过程中，注意每次测试后下次测试开始前的测试环境恢复工作。　　性能测试和功能测试一样，也有测试迭代的过程，也会有产品版本的更新。在性能测试过程中，需要和开发人员协同工作，一起调优系统。　　4.5编写测试报告，结束测试　　整理测试数据，总结测试结果，编写测试报告，结束测试。　　附录1保证LoadRunner测试脚本的正确性　　在用LoadRunner编写完测试脚本后，要保证脚本在以下情况下能够正确运行：　　在脚本编辑器中：单用户单循环运行脚本;单用户多循环运行脚本。　　在controller中：多用户单循环运行脚本;多用户多循环运行脚本。　　附录2性能测试术语解释　　测试场景：包含一个或多个脚本，设定并发数量，运行方式，模拟系统在现实中的一个情景。　　事务：是指一组相关的操作，是性能测试中的计时单位。比如‘登录应用系统’就可以作为一个事务。　　集合点：设置集合点后，先到达的请求会等待，直到所有的请求都到达，然后一起发送请求。设置集合点，是为了进行更严格和精确的并发测试。　　checkpoint：也叫检查点。和功能测试一样，性能测试也需要检验结果的正确性。当返回标准的HTTP错误时(状态码不是200+时)，Loadrunner能够识别出来，但如果返回的不是标准HTTP错误，Loadrunner则无法识别，这时只能通过我们设置的checkpoint来发现错误。　　参数化：为了更真实的模拟现实操作，我们经常需要对测试输入进行参数化。比如登录时的用户名。　　关联：对于脚本中动态变化的部分，需要对其进行参数化，Loadrunner提供了对这种变量进行参数化的功能，叫做关联。比如下面这种情况：在一个基于WEB的应用中，用户每次登录时会被服务端赋予了一个SessionID，该用户的后续操作都必须给出这个SessionID。在这种情况下，由于被赋予的SessionID是由服务端给出的，每次执行脚本时，获得的SessionID都会不同，因此就需要在脚本中取得用户每次登录，服务端返回的SessionID，在后续步骤中使用。这时我们就需要对SessionID进行参数化。即Loadrunner提供的关联功能。　　迭代次数：在性能测试中，对于一个场景，我们需要运行多次取其平均值，即迭代运行多次。目的是为了避免意外因素对测试结果的影响。　　thinktime：思考时间。在进行长时间的稳定性测试时，要考虑在脚本中加入适当的thinktime，来更好的模拟现实中的情况。选择正确的更新方法 　　在某些情况下，您选择的更新方法由您为应用程序选择的部署方法限定。但是，最适当的方法通常由您要部署的更新的性质决定。例如，您可能只是复制新文件以覆盖旧文件，或者您可能希望更新的应用程序与旧应用程序并列运行。更新可能涉及到将新的程序集添加到全局程序集缓存，或者更改注册表中的配置信息。如果您要部署对具有强名称的程序集的更新，则更新将变得更为复杂，因为调用具有强名称的程序集的每个程序集都将在调用中使用版本号。在许多情况下，自动更新是部署应用程序更新的最有效的方法。但是，在部署重大更新或涉及到对客户端进行复杂配置更改的更新时，您可能需要使用Windows安装程序（它也具有自动版本控制支持的好处）。　　小结　　部署智能客户端应用程序要比过去部署胖客户端应用程序容易得多，这要归功于.NETFramework所具有的功能。但是，要成功完成部署，您需要进行大量重要的选择，包括如何设计您的应用程序以便于部署，以及您为应用程序和.NETFramework本身选择哪种部署方法这两个方面。在大多数情况下，部署应用程序的最佳选择是使用Windows安装程序软件包，或者使用无接触部署和应用程序更新存根的组合。您将需要考虑在部署应用程序之后如何有效地维护该应用程序以及部署更新。同样，在大多数情况下，最佳选择很可能是Windows安装程序或由应用程序本身控制的自动更新。一封普通的SOA检讨书近来有好几篇文章，主题都是关于SOA是否应当被看作是一个失败。Gartner分析师们也参与了这场争论，写了一封虚拟的信，以项目经理、企业架构师或首席开发工程师的名义，致“CIO、CEO、CFO、CTO和所有股东”，表明为什么作者承认SOA完全是场失败：　　作为下述情况的结果，我只能得出SOA是场失败，对于SOA的任何尝试都会以失败收场。在我的领导下：　　尽管下列失败的原由都是以调侃的口吻来叙述的，但它们却与人们在考虑SOA时所识别出的可能的失败原由息息相关：　　我忘记了将SOA项目与我们的业务需求联系起来，因此我不能证明所创建的这成百上千的服务价值何在，　　我做不到合理的创建和支持一个SOA卓越中、指导委员会或是能力中心　　我没办法将决策层招集进来，让其作为我们SOA进展真正的支持者和倡导者　　我还没真正搞明白我们SOA基础设施的需求就草草地购买了ESB（实际上真的不怪我嘛，供应商说它超级牛逼，无比重要） 　　我从未让我的工程师们尝到过重用成果物的甜头　　我也没有义务去关心隔壁那堆做BPM的家伙在干嘛啊，实际上我们是两个不同的项目嘛　　我坚信SOA就是超酷的CORBA或COM　　显而易见的是，为了获取成功，上述的部分或全部都应该被考虑周详并好好实现。　　尽管我啥也没做，SOA还是挂了。对于被全世界很多公司都成功证明的最佳实践，我却疏于确认并实现，这又给了我的SOA一刀。　　正如一条评论所说：　　我告诉我的客户，SOA是处于一个关系逆转、分手埋怨的境地。当事情变糟的时候，SOA会看着你的眼睛，怀着对这段破裂的关系的诚意，轻轻的对你说“真的，别怪我，都是你不好。”我们有足够的例子来说明现在的SOA并不差，但仍有着太多拙劣的SOA。这些真的是非常好的提醒。　　尽管如另一条评论所指出，SOA绝非太上老君的仙丹，也绝不该被当作一样：　　SOA在某些情况是管用的，而有的时候就不灵了－并且，并不仅仅因为是组织或人员的过错。你得面对它，在有些时候它对于你的公司架构真是一点意义也没有。是的，作为概念来说它非常棒－而且，它可能适用于一些口袋，这取决于你的组织是如何组织的，但这并不意味着所有的都可以。　　这封信结尾时对这一片儿（相对而言）刚来的新生儿也狠狠给了一下：　　谢谢你们的理解，我得提前说，对于云计算、虚拟化和SaaS，我也是绝佳杀手哦～!　　那么等着收到“云计算是个恶梦”或者“SaaS是个谎言”这样的邮件，又会需要多久呢一个优秀系统构架师应具备的能力作为软件开发的设计架构师，那么必须拥有一定的编程技能，同时有高超的学习新的架构设计、程序设计技能。另外，我觉得作为软件架构师，还必须了解一定的硬件、网络、服务器的基本知识。要不然，你都不知道有些什么材料可以用，你怎么去根据实际情况去规划你的软件架构呢？忽视程序设计能力的持续跟新，是永远不能够成为一个成功的系统架构师。　　一般来讲，系统架构师应该拥有以下几方面的能力：　　1：具备8年以上软件行业工作经验；　　2：具备4年以上C/S或B/S体系结构软件产品开发及架构和设计经验；　　3：具备3年以上的代码编写工作经验；　　4：具备丰富的大中型开发项目的总体规划、方案设计及技术队伍管理经验；　　5：对相关的技术标准有深刻的认识，对软件工程标准规范有良好的把握；　　6：对.Net/JAVA技术及整个解决方案有深刻的理解及熟练的应用，并且精通WebService/J2EE架构和设计模式，并在此基础上设计产品框架；　　7：具有面向对象分析、设计、开发能力(OOA、OOD、OOP)，精通UML和ROSE，熟练使用RationalRose、PowerDesigner等工具进行设计开发；　　8：精通大型数据库如Oracle、SqlServer 等的开发；　　9：对计算机系统、网络和安全、应用系统架构等有全面的认识，熟悉项目管理理论，并有实践基础；　　10：在应用系统开发平台和项目管理上有深厚的基础，有大中型应用系统开发和实施的成功案例；　　11：良好的团队意识和协作精神，有较强的内外沟通能力。应用软件系统架构设计的“七种武器”对于软件架构这一概念，有太多的版本，目前在业界由大师级人物或组织提出的对这一概念的阐述就超过十种以上，我个人比较赞同RUP(RationalUnifiedProcess)中对软件架构的定义，即软件架构包含了关于以下问题的重要决策：　　软件系统的组织；　　选择组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为；　　如何组合这些元素，使它们逐渐合成为更大的子系统；　　用于指导这个系统组织的架构风格：这些元素以及它们的接口，协作和组合。　　本文我们并不是要探讨软件架构的定义，只是想基于上面这种定义来谈谈在软件系统架构设计的过程中，我们会常常用到的一些“武器”。　　●长生剑：UML(UML2)　　UML(UnifiedModelingLanguage)这一建模语言已经成了软件设计人员的必备工具，几年前就曾有过“苦干年之后，不通UML者无法染指软件开发”的言论，虽然从目前来看，UML的应用还并未达到如此程度，但使用UML最大的好处在我看来就是减少了沟通的成本，让我们把一些想法能够很清晰直观的表达出来，在设计的过程中，使用得较多的是用例图，类图，组件图，部署图和时序图。当下，各种设计和建模工具对UML都有良好的支持，UML本身也是一门不断发展的语言，现在UML2已经成为主流。UML本身也极为简单，对于初学者来说可能有些概念比较难懂，可以结合实际的程序来理解，这样会事半功倍，但我认为也不会太高深，熟练使用就达到了应有的境界。　　剑谱：　　UML官方网站　http://www.uml.org/　　《UML基础、案例与应用(第3版)》，此书作为UML入门较为适合，书中也以详实案例来教会我们怎么使用UML。　　●孔雀翎：Office　　架构设计的成果就是两项重要的产出物，一是框架代码，二是架构设计文档。在架构设计文档中，除了包括一些UML图之外，还有一些UML无法表示的图表，采用Office来制作和撰写这份文档再合适不过，最常用的就是Word，Excel和Visio。　　掌握这门“武器”不难，可利用这门武器把各类文档写好就难了，除了专业能力，良好的文字表达能力也是十分重要的，一个成熟的架构设计师在我看来应该也能写得一手好文章，最基本的要求就是能够准确的表达你想要表达的意思。　　秘籍：　　《Word排版艺术》，在大陆十分有名的台湾IT作家候捷的作品(之所以这样说是我曾经跟我们公司在台北的同事聊起过此人，几乎没人知道此人)，此书一度借着他的名气卖得很火，因为他出书很多，在这方面也有很多优秀的经验，值得借鉴。 　　●碧玉刀：IDE(IBMRSA或BorlandTogether)　　通常我们所说的IDE(IntegrationDevelopmentEnvironment)是指集成开发环境，在这里我借用这个词，指的是集成设计环境。随着软件业的发展和进步，支持一整套开发流程的全系列软件越来越多，越来越好，这其中以IBMRationalSoftwareDeliveryPlatform最为突出，RSA(RationalSoftwareArchitect)就是其中一项，作为建模工具，对领域模型的设计，UML及SOA(Service-OrientedArchitecture)等都有较好的支持，同时可以与RMC(RationalMethodComposer)结合，充分发挥MDA(ModelDrivenArchitecture)的思想，把RUP流程发挥到极至。　　不过发现RSA也有不好用和不听话的时候，最新的RSAV7.0里面的反向工程就不是很好用，反向过来后很多关系消失了。　　Together作为老牌儿的建模工具，也有着先进的思想和设计，其核心包括四个方面：只维护单一模型库(LiveSource技术)；符合最小的元模型；扰乱改变模型；支持持续的质量测量。同时，对正反向工程也有良好的支援。也正是因为其有自己的思想和独特的一套，Borland公司也才会将其并入旗下。　　刀譜：　　IBMRSA之《教学指导》，Eclipse平台都有这东东，大家自己去发掘吧，通俗易懂。　　IBMRSA相关的Redbook(http://www.redbooks.ibm.com/)，大名鼎鼎的红宝书，相信入行不久就一定会知道的(其实在大学的时候就人有看什么GRE的红宝书，TOEFL的红宝书，估计红宝书一词来源于此)　　《GettingStartedGuideforBorlandTogether2006forEclipse》官方教你怎么玩转Together，权威信不用质疑，英文版，但看起来并不难懂。　　●多情环：架构设计类经典书籍　　架构设计类好书不多，但也不是没有，我也没有认真读过几本，但觉得有那么两本还值得推荐：《PatternOfEnterpriseApplicationArchitecture》，MartinFlower的经典之作，几乎是架构设计人员的必读之书，详细论述了企业应用各layers上的模式和设计思想；《Large-ScaleSoftwareArchitecture》，告诉你什么样的人才是架构师，然后以构件为粒度深入探讨架构的方方面面，同时用UML呈现，也是一份UML在架构设计中应用的最佳实践；《J2EECorePattern》，设计Java平台应用系统的经典参考书，对GOF(GongOfFour)的设计模式在Java中的应用和扩展进行了深入的讨论，看看你的设计中可以运用其中的哪些核心模式。　　秘籍：　　有一套适合自己的学习知识的方法，对于IT行业的人来说，要看的书籍和资料远远超过其他行业，面对如此繁杂的知识，要有自己的方法学会去整理，要做到看必有收获，否则不如去温习古龙或是金老爷子的小说。我常常喜欢用MindManager等软件把读书笔记和心得记录下来，也常常回过头来看看这些笔记，以前喜欢手抄，信奉什么好记心不如乱笔头，但后来发现有些落后，不能与时俱进，方式肯定会被淘汰，人自然也会被踢出局。　●霸王枪:Internet/Intranet　　当今时代，离开网络这条枪对于IT从业人员来说寸步难行，大多公司目前都还没有自己完善的Intranet，公司知识库的资料与Internet的资源相比可谓是小巫见大巫，但千万不要忽视了公司通过SEPG(SoftwareEngineeringProcess Group)或相似职能部门积累起来的知识，这些东西往往关注于行业，领域或适合于你所在公司的实际状况，从这个方面考虑的话，其力量超越Internet，是很好的模板。常常我们会遇到自己不能解决的问题，这个时候就需要去网上百度一下；在架构设计文档中，我总喜欢弄个术语表，而对于有些术语的解释，你会发现百度原来也是一本好辞典。　　枪谱：　　百度，谷歌　　利用搜索引擎，可以快速的获得自己需要的资料，大幅提高效率，也不至于让你淹死在浩如烟海的信息海洋中。　　之所以将百度写在前面，是因为我的个人习惯，常常在搜索的时候会优先考虑用百度，在百度搜不到的情况下才去谷歌，百度出来的大都是中文资料，对于母语是中文的人来说，会提高我们的阅读速度和理解效率，命中率较高，较好的分词技术，值得推荐。谷歌当然不错，相信不用多说。　　●离别钩：评审　　邀请你公司的架构设计同行，资深技术专家，公司领导，或行业中的其他专家，还有你的PM(ProjectManager)，充分利用团队的力量，对于你所做的架构设计的初稿进行评审，在评审前先把重点部分，特别是你想跟大家一起讨论更好解决方式的部分整理成简单的演示文稿(PPT)发给大家，同时把详细资料也发给大家，请大家在有空的时候提前了解。在评审会议时，要先向与会人员介绍一下项目背景，需求，千万不要忘了非功能性需求(包括性能，安全，可扩展性等方面)，然后再从重点的议题开始与大家一起讨论，这样可提高效率。　　秘籍：　　虚心听取各方面意见。评审时大家会提出各种各样的问题，有时候可能会提出各种让你很生气的问题，这个时候一定要克制住自己的情绪，虚心的听取他们提出的建议，对各种问题进行解释，让他们真正明白你的意思，同时也从他们那里获取有用的建议。　　●拳头：激情　　这也是与人最密切相关的一样武器，拳头是你身体密不可分的一部分，激情也是你思想密不可分的一部分，要想把架构设计做好，有做好一件事的激情是必不可少的，你要对新知识，新技术充满好奇心，要有创新精神，在前人的基础上，结合自己的所学去进行一些小的创新，其实人类的进步也就是靠这样的一次次的小创新，以最大程度的确保架构的稳定性和可扩展性，同时也尽可能的提高程序开发的效率。　　秘籍：　　确定自己的发展方向就是做一个技术专家。如果你对自己的职业规划有一些想法，不妨可以考虑一下这个方向，国外的很多大师级的人物因技术牛而成就了卓越的事业，国内目前也有向这个方向发展的趋势。　　认为做一个技术专家与向管理方向发展并不冲突，技术专家也可以是管理行家，软件行业的很多人都是“技术优则管理”，否则你在管理者的位置上却不懂得基本的技术，在各方面都会遇到绊脚石，也没有人真正的服你。 　　正如古龙所说，“武器是死的，人却是活的”。“武器”是否能令你觉得神奇刺激，主要还得看使用它的是什么人，虽然架构设计不是人人都可以做的，但我相信这几种武器通过大家自己的努力一定可以掌握。优化Windows窗体性能优化Windows窗体性能　　Windows窗体为智能客户端应用程序提供了内容丰富的用户界面，并且您可以使用许多种技术来帮助确保Windows窗体提供最佳性能。在讨论特定技术之前，对一些可以显著提高Windows窗体性能的高级原则进行回顾是有用的。　　1)小心创建句柄。Windows窗体将句柄创建虚拟化（即，它动态创建和重新创建窗口句柄对象）。创建句柄对象的系统开销可能非常大；因此，请避免进行不必要的边框样式更改或者更改MDI父对象。　　2)避免创建带有太多子控件的应用程序。Microsoft?Windows?操作系统限制每个进程最多有10,000个控件，但您应该避免在窗体上使用成百上千个控件，因为每个控件都要消耗内存资源。本节的其余部分讨论您可以用来优化应用程序用户界面性能的更为具体的技术。使用BeginUpdate和EndUpdate许多Windows窗体控件（例如，ListView和TreeView控件）实现了BeginUpdate和EndUpdate方法，它们在操纵基础数据或控件属性时取消了控件的重新绘制。通过使用BeginUpdate和EndUpdate方法，您可以对控件进行重大更改，并且避免在应用这些更改时让控件经常重新绘制自身。此类重新绘制会导致性能显著降低，并且用户界面闪烁且不反应。例如，如果您的应用程序具有一个要求添加大量节点项的树控件，则您应该调用BeginUpdate，添加所有必需的节点项，然后调用EndUpdate。下面的代码示例显示了一个树控件，该控件用于显示许多个客户的层次结构表示形式及其定单信息。　　　　即使在您不希望向控件添加许多对象时，您也应该使用BeginUpdate和EndUpdate方法。在大多数情况下，您在运行之前将不知道要添加的项的确切个数。因此，为了妥善处理大量数据以及应付将来的要求，您应该总是调用BeginUpdate和EndUpdate方法。注调用Windows窗体控件使用的许多Collection类的AddRange方法时，将自动为您调用BeginUpdate和EndUpdate方法。使用SuspendLayout和ResumeLayout许多Windows窗体控件（例如，ListView和TreeView控件）都实现了SuspendLayout和ResumeLayout方法，它们能够防止控件在添加子控件时创建多个布局事件。如果您的控件以编程方式添加和删除子控件或者执行动态布局，则您应该调用SuspendLayout和ResumeLayout方法。通过SuspendLayout方法，可以在控件上执行多个操作，而不必为每个更改执行布局。例如，如果您调整控件的大小并移动控件，则每个操作都将引发单独的布局事件。这些方法按照与BeginUpdate和EndUpdate方法类似的方式操作，并且在性能和用户界面稳定性方面提供相同的好处。下面的示例以编程方式向父窗体中添加按钮：　　[C#]　　privatevoidAddButtons()　　{　　//Suspendtheformlayoutandaddtwobuttons.　　this.SuspendLayout();　　ButtonbuttonOK=newButton();　　buttonOK.Location=newPoint(10, 10);　　buttonOK.Size=newSize(75,25);　　buttonOK.Text="OK";　　ButtonbuttonCancel=newButton();　　buttonCancel.Location=newPoint(90,10);buttonCancel.Size=newSize(75,25);　　buttonCancel.Text="Cancel";　　this.Controls.AddRange(newControl[]{buttonOK,buttonCancel});　　this.ResumeLayout();　　}　　[VisualBasic.NET]　　PrivateSubAddButtons()　　'Suspendtheformlayoutandaddtwobuttons　　Me.SuspendLayout()　　DimbuttonOKAsNewButtonbuttonOK.Location=NewPoint(10,10)　　buttonOK.Size=NewSize(75,25)　　buttonOK.Text="OK"　　DimbuttonCancelAsNewButtonbuttonCancel.Location=NewPoint(90,10)　　buttonCancel.Size=NewSize(75,25)　　buttonCancel.Text="Cancel"　　Me.Controls.AddRange(NewControl(){buttonOK,buttonCancel})　　Me.ResumeLayout()　　EndSub　　每当您添加或删除控件、执行子控件的自动布局或者设置任何影响控件布局的属性（例如，大小、位置、定位点或停靠属性）时，您都应该使用SuspendLayout和ResumeLayout方法杂谈架构:杂谈架构和架构设计师2009年上半年计算机技术与软件专业技术资格（水平）考试日期：2009年5月23、24日。另外，部分考试科目从2009年上半年开始将采用新修编的考试大纲，具体见：　　系统架构通俗的说起来就是系统的结构组织方式。原则上说，架构只有好坏之分，而不存在有无的问题。软件的体系架构可以直接体现为代码的类结构，也可以表现为文档性的编码规范和全局约定等。如果软件架构中能够抽象出一些稳定的元素，那我们就可能得到一些所谓的框架代码。一般业务架构是很难重用的，目前常见的框架代码所描述的多半是与业务无关的技术架构。　　良好的系统架构应该体现出应用本身的结构要求。所谓各个为自己，架构为大家。只要各个局部符合规格， 应该由架构负责在合适的时刻按照合适的方式把它们组装在一些。一个良好的架构中，应该很少出现结构性的if语句，不需要应用代码自己通过动态判断来定义某个特殊的触发时刻。架构是一种规范，当然也就是一种局限。架构的可退化性是非常重要的，否则一旦出现抽象泄露，需要超出原有架构设计做出编码补充的时候，往往无法将代码自然的融入原有的框架结构，则整个框架出现大面积的失效情况。而有的时候更糟糕的情况是一些关键性的资源处在原有技术架构的私有控制之中，我们为了克服架构限制不得不采用各种trick来hack原有框架，造成错误的累加和传播，而补丁的补丁是最难维护的。　　架构问题并不是一成不变的。在一些情形下无关紧要的问题在另一种情形下可能会成为灾难性的架构问题。例如在多层B/S架构下，如果现在要求为每一个表增加一个对应的历史表，并对其进行查看和维护操作。为了最大限度的重用代码，这要求我们的多层结构中的每一层都能够参数化，这样我们才能用同样的代码处理不同的数据表。如果我们的money很足，小弟够多，有足够的人月砸上去，那么我们完全可以把业务表和历史表分开处理，但如果反之，我们就会遇到一个典型的架构问题。　　架构师未必有自己的框架，因为设计不等价于创造，架构师只要知道如何把系统中的各种元素按照可行的方式组装在一起就可以了。但是一个架构设计是非常依赖于我们所能采用的技术手段的，当现有各种可用的技术元素都无法满足我们的需求的时候，某些架构师可能会选择创造一种技术元素。当然，创造是艰难的，它所要求的甚至是不同的技能。Sun的Green项目创造了java语言，从而开启了一个伟大的时代，这绝对不会是大多数架构设计师的选择(有趣的是，Green项目本身失败了)。EJB现在还有多少人在真正使用，想想当年多少架构师在吹嘘这些东西。他们对于技术的把握真的就那么幼稚吗?架构设计并不是凭空出现的，当时可选的东西就是如此，而spring和hibernate这些都不属于架构设计本身的内容。它们是一种创造。　　架构师未必是团队的领导者。确实，他的工作类似于编剧，负责执行的一般是导演。事实上，一个建筑设计师是极少直接领导一个工程队的。架构师也未必比高级程序员要高明，他们负责的是不同的内容。至于产品的“商标及商标的相关元素”和“技术市场架构”等也不属于架构师的工作范畴，他不能去抢产品经理的饭碗。当然，在国内的现实情况下，很多所谓的架构师所做的最重要的工作可能是公关工作，向客户秀出所谓的理念，与实际开发是不搭嘎的。　　理论上说，架构师可以不是编程的强者，也可以不决定一些具体数据结构的选择，但他不能不了解各种技术抉择潜在的影响。这就如同一个建筑设计师可以不精通工程力学，但是他不能愚蠢到藐视重力，设计出倒三角式的大厦。与建筑不同的是，在软件中我们所面临的不是一种“凝固的艺术”，我们无法以完全静态的方式理解代码，而必须在头脑中把它们运行起来。架构师应该写下一些实际的代码，以检验各个接口的可配合性并获得对于代码结构的直接感觉。实际上，按照现在软件业的成熟度，一般我们无法实现建筑中建筑设计师与土木工程师的分工，很多时候软件架构师都需要直接面对实现的细节。如果组内缺乏非常强悍的coder，有编程能力的架构师亲自操刀实现关键性代码的时候也是很多的。 　　架构师必须有经验，但他所依赖的不能只是经验。只要算一算架构师的年纪，就会知道以他们在这个世界上的存在时间，并不足以使得他们经历各种技术细节。架构设计更多的是依赖我们对于系统结构原理的理解，而经验可以让我们规避那些原理失效的地方(例如系统级bug)。君子非异能也，善假于物也。很多时候，我们更应该从有经验的朋友或者技术支持那里搜集技术细节，以确保它们能够满足我们在架构上的原理性需求。KnowWhy而不仅仅是KnowHow是非常重要的。一个农民发明家也许可以得到某个巧妙的机械设计，但是没有系统的掌握工程力学，他们是无法去开发精密的导弹控制系统的。当然，软件开发还处在非常原始的阶段，掌握一些设计原理和设计模式多半也不过是五十步笑百步而已，经验的地位是无可替代的。　　架构师不是预言家。在多变的业务环境中，架构师的目标不应该是预测到所有的变化可能，并把它们表达到系统架构中。这个世界上不乏一些耗资数十亿，设计三四年，但最终每个谈到它的人都要说一句shit的产品开发项目。架构设计所能做到的最好的程度是自然的标注出系统的结构边界，成功的delay各种技术抉择。　　架构师不是超人，他所考虑的东西也许要远一些，所需要平衡的利益也许要多一些，但是单独一个人是无法对整个产品或者项目的成败负责的。如果ThoughtWorks的MartinFollower来处理国内的某些项目，我估计他会死得很难看。架构师也是人，也会犯错误，甚至是很低级的错误，而每个人都会有一些独特的想法。经历的多了，你就会回归到终极的认识，一切都只是浮云，只有money才是硬道理。正视架构设计的重要作用要讨论软件架构设计在软件开发中的重要作用，首先让我们来了解一下目前国内软件的开发现状。　　总的来说，国内的多数企业仍然是采用“瀑布模型”作为软件开发过程的主要模型。虽然在采用瀑布模型的同时可能会引入原型法以及诸如MSF等其它软件开发方法与过程，但随着项目时间的推进，这种“瀑布模型”会慢慢演化为“边做边改模型”。　　从事过软件项目开发的专业人士都有这样的困惑:为什么到了项目接近尾声的时候，仍然还有那么多没有解决的问题？　　理论上讲，应该是先分析，后设计，再编码，那为什么项目在交货以后，我们还在不断的编写设计文档？为什么每次客户需求发生变更，我们又要投入大量的资源来应对不断变化的客户需求？为什么软件开发会碰到这么多困难，我们天天加班加点，不断地去解决开发中碰到的种种问题，可是问题越解决越多，得到的效果却那么不尽人意？　　项目出现这些问题，原因很多，概括起来可以分为两种:管理因素和技术因素。国内普遍重视管理因素，而忽视技术因素，所以出现层出不穷的问题也就无法避免。 　　软件架构设计属于技术因素，它位于软件开发过程的前期阶段，架构设计的过程，是分析客户需求、挖掘非功能性需求、并将客户需求所定义的领域知识转化为软件系统模型的过程，由此可见，架构设计所涵盖的范围非常广泛。　　目前,国内对于软件架构的认识,还存在这样或那样的误区。难道只有当设计人员在为软件项目配备了充足的资源，然而却得不到预期的结果时，才会反思:是不是软件开发本身出现了问题?　　架构设计源于客户需求　　在进行需求分析的过程中，系统分析员将客户需求转化为计算机模型，然而在这个过程中，系统分析员本身的特性也就决定了这一角色很难把握住客户的非功能性需求。　　需求需要挖掘，尤其对于大型的软件系统而言，光靠系统分析员这个单一的角色，很难完成需求分析与挖掘的艰巨任务。在需求分析的过程中，架构设计师更为关注的是系统的非功能性需求，例如稳定性、可扩展性、可维护性、安全性、高效性等等，这些需求都是需要挖掘的。　　如何挖掘？挖掘方式取决于核心需求。举个很简单的例子，客户需要实现两个系统的数据传输，这是个核心功能性需求，而在这个需求的背后，还包括了“传输过程要求可靠”、“需要采用一种特定的数据格式进行传输”、“由于数据包含一定的机密因素，因此需要加密，并需要选择合适的加密算法”等等一系列的非功能性需求。　　此时，架构设计师不仅需要了解客户本身的功能需求，还需要能够发掘非功能需求。因此，优秀的架构设计师一定是一个经验丰富的需求工程师，需求分析让架构设计师知道，我需要考虑哪些因素，而深厚的软件技术功底让架构设计师知道，如何去考虑这些因素。可见，架构设计源于客户需求。　　架构设计源于对知识的不断积累　　首先应该认识到，没有对领域知识、软件系统特性与软件技术等的深刻理解，就无从谈及架构设计，而深厚的领域知识与技术经验则是源于不断的积累。　　目前，市场上确实很多产品在架构上已经非常成熟和稳定，但这些产品的成熟架构也是通过长期不断的实践与积累才逐步形成的。经验丰富的架构设计师可以在开发产品的同时总结出一套架构模式，这对维护产品的体系结构，以及开发同类产品都有深远的意义。　　从另一个角度讲，产品的架构并非一成不变，随着技术的不断创新与发展，新技术一定会被应用到现有的系统架构中。此时，软件架构可能需要进行调整，我们也不能再说，我们没有必要去关心这些产品架构了。　　架构设计是一种取舍过程　　实现某一非功能性需求，可以有很多种方法，但并不是每种方法都是最合适的，这在架构设计的过程中需要做出取舍。例如，为了使得软件系统具有易扩展、易更改的能力，我们可以采用插件体系结构或内嵌脚本系统结构，两者都可以使得软件系统具有方便扩展的能力。　　然而，如果客户的业务流程会经常变化，或者软件系统产品会应用到具有不同业务流程的多个客户时，采用后者可能会更加符合软件本身的特点。　　当今IT业技术层出不穷，在特定的应用场景中，采用何种技术何种模式最合适，这就是架构设计的取舍。JAVA和.NET孰好孰坏？讨论这样的问题也不再有意义。软件工程大师MartinFowler曾经说过:架构师是对所有重要事情做出决定的人，这一决定也囊括了取舍。 　　架构设计将服务于整个开发过程　　良好的架构设计不仅使得软件系统能够满足客户需求，它更为软件系统带来了安全性、稳定性、可扩展性等属性，而这些属性在应对客户需求变更、提高软件可测试性与可维护性、降低维护成本、提高开发效率等各方面都起着非常重要的作用。　　客户所需要的是可以用于生产实践的最终产品，他们自然不会去关心你的软件系统采用何种设计和架构，但作为软件系统的分析者、设计者和开发者，我们必须为软件产品寻求一种合理的架构设计，因为它不仅能够使系统满足非功能性需求，而且能够降低开发成本和维护费用。　　总之，架构设计是软件开发过程的重要组成部分，它不是单纯的技术，也不具有一种特定的形式，更不是与客户需求无关的。良好的软件架构能够服务于整个开发过程，有效地降低项目风险，确保项目能够朝着健康的方向发展。因此，我们必须重视架构设计在软件开发中的重要作用智能客户端应用程序性能摘要：本章讨论如何优化您的智能客户端应用程序。本章分析您可以在设计时采取的步骤，并介绍如何调整智能客户端应用程序以及诊断任何性能问题。　　智能客户端应用程序可以提供比Web应用程序更丰富和响应速度更快的用户界面，并且可以利用本地系统资源。如果应用程序的大部分驻留在用户的计算机上，则应用程序不需要到Web服务器的持续的往返行程。这有利于提高性能和响应性。然而，要实现智能客户端应用程序的全部潜能，您应该在应用程序的设计阶段仔细考虑性能问题。通过在规划和设计您的应用程序时解决性能问题，可以帮助您及早控制成本，并减小以后陷入性能问题的可能性。　　注:改善智能客户端应用程序的性能并不仅限于应用程序设计问题。您可以在整个应用程序生存期中采取许多个步骤来使.NET代码具有更高的性能。虽然.NET公共语言运行库(CLR)在执行代码方面非常有效，但您可以使用多种技术来提高代码的性能，并防止在代码级引入性能问题。　　在应用程序的设计中定义现实的性能要求并识别潜在的问题显然是重要的，但是性能问题通常只在编写代码之后对其进行测试时出现。在这种情况下，您可以使用一些工具和技术来跟踪性能问题。本章分析如何设计和调整您的智能客户端应用程序以获得最佳性能。它讨论了许多设计和体系结构问题（包括线程处理和缓存注意事项），并且分析了如何增强应用程序的Windows窗体部分的性能。本章还介绍了您可以用来跟踪和诊断智能客户端应用程序性能问题的一些技术和工具。中间件的解决方案并不完美（要评估）　　13.3 中间件的解决方案并不完美（要评估）　　1)是否逻辑分层非要逻辑分层　　2)是否暴露接口一定要支持远程接口　　3)依赖于应用服务器　　4)实体beanESQL不完善，不支持一些特殊的SQL语句访问大数据量困难用BMP简直就是恶梦多对多的关系，虽然引入关联表，但关联更新、删除很头疼、很受伤.　　5)涉及知识面庞大学员如对XML、反射、RMI、设计模式、JDNI了解不深，很难快速掌握，团队的培训时间过长。