从此我再也不能好好看文字了
Java技术架构有哪几种技术架构
开始的架构设计也是最难的，需要调研同类产品的情况以及技术特征，了解当前世界上对这种产品所能提供的理论支持和技术平台支持，再结合自己项目的特点（需要透彻的系统分析），才能逐步形成自己项目的架构蓝图。
比如要开发网站引擎系统，就从Yahoo的个人主页生成工具到虚拟主机商提供的网站自动生成系统，以及IBMWebpherePortal的特点和局限从而从架构设计角度定立自己产品的位置。
好的设计肯定需要经过反复修改，从简单到复杂的循环测试是保证设计正确的一个好办法。
由于在开始选择了正确的方向，后来项目的实现过程也验证了这种选择，但在一些架构设计的细部方面，还需要对方案进行修改，属于那种螺旋上升的方式，显然这是通过测试第一的思想和XP工程方法来实现的。
如果我们开始的架构设计在技术平台定位具有一定的世界先进水平，那么，项目开发实际有一半相当于做实验，是研发，存在相当的技术风险。
因此，一开始我们不可能将每个需求都实现，而是采取一种简单完成架构流程的办法，使用最简单的需求将整个架构都简单的完成一遍（加入人工干预），以检验各个技术环节是否能协调配合工作（非常优秀先进的两种技术有时无法在一起工作），同时也可以探知技术的深浅，掌握项目中的技术难易点。
这个过程完成后，我们就对设计方案做出上面的重大修改，丰富完善了设计方案。
设计模式是支撑架构的重要组件架构设计也类似一种工作流，它是动态的，这点不象建筑设计那样，一开始就能完全确定，架构设计伴随着整个项目的进行过程之中，有两种具体操作保证架构设计的正确完成，那就是设计模式（静态）和工程项目方法（RUP或XP动态的）。
设计模式是支撑架构的一种重要组件，这与建筑有很相象的地方，一个建筑物建立设计需要建筑架构设计，在具体施工中，有很多建筑方面的规则和模式。
我们从J2EE蓝图模式分类http://java.sun.com/blueprints/patterns/catalog.html中就可以很清楚的看到J2EE这样一个框架软件的架构与设计模式的关系。
架构设计是骨架，设计模式就是肉这样，一个比较丰富的设计方案可以交由程序员进一步完成了，载辅助以适当的工程方法，这样就可保证项目的架构设计能正确快速的完成。
时刻牢记架构设计的目标由于架构设计是在动态中完成的，因此在把握架构设计的目标上就很重要，因此在整个项目过程中，甚至每一步我们都必须牢记我们架构设计的总体目标，可以概括下面几点：1.最大化的重用：这个重用包括组件重用和设计模式使用等多个方面。
比如，我们项目中有用户注册和用户权限系统验证，这其实是个通用课题，每个项目只是有其内容和一些细微的差别，如果我们之前有这方面成功研发经验，可以直接重用，如果没有，那么我们就要进行这个子项目的研发，在研发过程中，不能仅仅看到这个项目的需求，也要以架构的概念去完成这个可以称为组件的子项目。
2.尽可能的简单明了：我们解决问题的总方向是将复杂问题简单化，其实这也是中间件或多层体系技术的根本目标。
但是在具体实施设计过程中，我们可能会将简单问题复杂化，特别是设计模式的运用上很容易范这个错误，因此如何尽可能的做到设计的简单明了是不容易的。
我认为落实到每个类的具体实现上要真正能体现系统事物的本质特征，因为事物的本质特征只有一个，你的代码越接近它，表示你的设计就是简单明了，越简单明了，你的系统就越可靠。
更多情况是，一个类并不能反应事物本质，需要多个类的组合协调，那么能够正确使用合适的设计模式就称为重中之重。
我们看一个具备好的架构设计的系统代码时，基本看到的都是设计模式，宠物店（petstore）就是这样的例子。
或者可以这样说，一个好的架构设计基本是由简单明了的多个设计模式完成的。
3.最灵活的拓展性：架构设计要具备灵活性拓展性，这样，用户可以在你的架构上进行二次开发或更加具体的开发。
要具备灵活的拓展性，就要站在理论的高度去进行架构设计，比如现在工作流概念逐步流行，因为我们具体很多实践项目中都有工作流的影子，工作流中有一个树形结构权限设定的概念就对很多领域比较通用。
树形结构是组织信息的基本形式，我们现在看到的网站或者ERP前台都是以树形菜单来组织功能的，那么我们在进行架构设计时，就可以将树形结构和功能分开设计，他们之间联系可以通过树形结构的节点link在一起，就象我们可以在圣诞树的树枝上挂各种小礼品一样，这些小礼品就是我们要实现的各种功能。
有了这个概念，通常比较难实现的用户级别权限控制也有了思路，将具体用户或组也是和树形结构的节点link在一起，这样就间接实现了用户对相应功能的权限控制，有了这样的基本设计方案的架构无疑具备很灵活的拓展性。
Java架构设计软件架构作为一个概念，体现在技术和业务两个方面。
从技术角度来说：软件架构随着技术的革新不断地更新其内容，软件架构建立于当前技术和一些基本原则的基础之上。
先说一些基本原则：分层原则：分层是为了降低软件深度复杂性而使用的关键思想，就像社会有了阶级一样，软件有了层次结构。
模块化原则：...
Java的有几种技术架构
Java架构：软件架构作为一个概念，体现在技术和业务两个方面。
从技术角度来说：软件架构随着技术的革新不断地更新其内容，软件架构建立于当前技术和一些基本原则的基础之上。
先说一些基本原则：分层原则：分层是为了降低软件深度复杂性而使用的关键思想，就像社会有了阶级一样，软件有了层次结构。
模块化原则：模块化是化解软件广度复杂的必然手段，模块化的目的就是让软件分工。
接口实现分离原则随着软件模块化的不断深入改进，面向接口编程而不是面向实现编程可以让复杂度日趋增高的软件降低模块之间的耦合度，从而让各模块更轻松改进。
从这个原则出发，软件也从微观进行了细致的规范化。
还有两个比较小但很重要的原则：细节隐藏原则很显然把复杂问题简化，把难看的细节隐去，能让软件结构更清晰。
其实这个原则使用很普遍，java/c++语言中的封装原则以及设计模式中的Facade（外观）模式就很能体现这个原则的精神。
依赖倒置原则随着软件结构的进一步发展，层与层之间、模块与模块之间的依赖逐渐加深，而层、模块的动态可插拔要求不端增大。
依赖倒置原则可看视为接口实现分离原则的深化，根据此原则的精神，软件进入了工具时代。
这个原则有点类似于知名的好莱坞法则：Don't call us, we'll call you。
以上这些原则奠定了我们的软件架构的价值指标。
但软件架构毕竟是建立在当前技术之上的。
而每一代技术都有架构模式。
过去的不再说了，让我们现在就来看一下当前流行的技术，以及当前我们能采用的架构。
因为面向对象是当前最流行开发技术，且设计模式的大量使用使面向对象的走向成熟，而数据库是当前最有效的存储结构、web界面是当前最流行的用户接口，所以当前最典型的三层次架构就架构在以上几项技术的基础之上，用数据库作存储层、用面向对象来实现业务层、用web来作为用户接口层。
我们从三层次架构谈起：因为面向对象技术和数据库技术不适配，所以在标准三层次架构的基础上，我们增加了数据持久层，来管理O-R双向映射，但目前一直没有最理想的实现技术。
cmp和entity bean技术因为其实现复杂，功能前景有限，已接近被淘汰的边缘。
JDO及hibernate作为o-r映射的后期之秀，尤其是hibernate，功能相当完备。
推荐作为持久层的首选 在业务层，因为当前业务日趋负载，且变动频繁，所以我们必须有足够敏捷的技术来保证我们的适应变化的能力，在标准j2ee系统中session bean负责业务处理，且有不错的性能表现，但采用ejb系统对业务架构模式改变太大，且其复杂而昂贵，业务代码移植性差。
而spring 作为一个bean配置的轻量级架构，漂亮的IOC模式实现，对业务架构影响小，所以推荐作为中间层业务框架。
在用户结构层，虽然servlet/jsp/jstl/javaBean 能够实现MVC架构，但终究过于粗糙。
struts对MVC架构的实现就比较完美，Taperstry也极好地实现MVC架构，且采用基于事件的方式，非常诱人，惜其不够成熟，我们仍旧推荐struts作为用户接口层基础架构。
因为业务层是三层次架构中最有决定意义的，所以让我们回到业务层细致地分析一下，在复杂的业务我们常常需要以下基础服务的一种或几种：事务一致性服务acid(tool:jta/jts)、并发加锁服务concurrent&&lock、池化管理服务cache、访问控制服务（tool:jaas）、流程控制服务workflow、动态实现服务IOC，串行化消息服务（tool:jms）、负载平衡服务blance等。
如果我们不采用重量级应用服务器（如weblogic,websphere,jboss等）及重量级组件（EJB），我们必须自己实现其中一些服务。
虽然我们大多情况下，不需要所有这些服务，但实现起来却非易事。
幸运的是我们有大量的开源实现代码，但采用开源代码却常常是件不轻松的事。
随着xml作为结构化信息传输和存储地位日渐重要，一些xml文档操作工具（DOM,Digester,SAX等）的使用愈发重要，而随着xml schema的java binding工具（jaxb,xmlbean等）工具的成熟，采用xml schema来设计xml文档格式，然后采用java binding来生成java bean 会成为主要编程模式，而这又进一步使数据中心向xml转移，使在中小数据量上，愈发倾向于以xquery为查询语言的xml数据库。
最近还有一个趋势，microsoft,ibm等纷纷大量开发中间软件如（microsoft office之infopath），可以直接从xml schema 生成 录入页面等非常实用的功能。
还有web service 的广泛应用，都将对软件的架构有非常重大的影响。
至于面向服务架构（SOA）前景如何，三层次架构什么时候走入历史，现在还很难定论。
aop的发展也会对软件架构有很深的影响，但在面向对象架构里，无论aspectJ还是jboss-aop抑是aspectWerks、nanning都有其自身的严重问题：维护性很差，所以说它将很难走远。
也许作为一个很好的思想，它将在web service里大展身手。
rdf,owl作为w3c语义模型的标志性的语言，也很难想象能在当前业务架构发挥太大影响。
但如果真如它所声称那样，广泛地改变着信息的结构。
那么对软件架构也会有深远影响。
有关架构设计的一些忠告：尽量建立完整的持久对象层.可获得高回报 尽量将各功能分层，分块，每一模块均依赖假定的其它模...
系统架构师要具备哪些能力？
展开全部 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：良好的团队意识和协作精神，有较强的内外沟通能力。
什么是系统架构设计？
展开全部 “架构”一词最早来自建筑学，原意为建筑物设计和建造的艺术。
但是在软件工程领域，软件架构不是一个新名词，只是在早期的著作中人们将软件架构称为软件体系架构。
这就是架构的概念。
所谓架构，就是人们对一个结构内的元素及元素间关系的一种主观影射的产物。
系统架构的主要任务是界定系统级的功能与非功能要求、规划要设计的整体系统的特征、规划并设计实现系统级的各项要求的手段，同时利用各种学科技术完成子系统的结构构建。
在系统架构中，由于对软件越来越深入的依赖，软件架构的任务也体现出重要的作用。
而且系统架构与软件架构是紧密联系和相互依赖的。
1997年，Eberhadrt Rechtin 与MarkW Maier 在其论著中，为计算机科学总结了系统架构方面的实践成果，从而奠定了系统科学和系统架构在计算机科学中的基石： 无论何种系统架构应用领域，目的都是一样的，即完整地、高一致性的、平衡各种利弊的、有技术和市场前瞻性的设计系统和实施系统。
...
一个优秀的系统架构师要具体哪些能力？
系统架构师的职责：一、理解系统的业务需求，制定系统的整体框架（包括：技术框架和业务框架）二、对系统框架相关技术和业务进行培训，指导开发人员开发。
并解决系统开发、运行中出现的各种问题。
系统架构师的目的：对系统的重用、扩展、安全、性能、伸缩性、简洁等做系统级的把握。
系统架构师能力要求：一、系统架构相关的知识和经验。
二、很强的自学能力、分析能力、解决问题的能力。
三、写作、沟通表达、培训。
角色软件架构师Software Architect 定义主导系统全局分析设计和实施、负责软件构架和关键技术决策的角色 职责l、领导与协调整个项目中的技术活动（分析、设计和实施等） 2、推动主要的技术决策，并最终表达为软件构架 3、确定和文档化系统的相对构架而言意义重大的方面，包括系统的需求、设计、实施和部署等“视图” 4、确定设计元素的分组以及这些主要分组之间的接口 5、为技术决策提供规则，平衡各类涉众的不同关注点，化解技术风险，并保证相关决定被有效的传达和贯彻 6、理解、评价并接收系统需求 7、评价和确认软件架构的实现 专业技能l、技术全面、成熟练达、洞察力强、经验丰富，具备在缺乏完整信息、众多问题交织一团、模糊和矛盾的情况下，迅速抓住问题要害，并做出合理的关键决定的能力 l、具备战略性和前瞻性思维能力，善于把握全局，能够在更高抽象级别上进行思考； l、对项目开发涉及的所有问题领域都有经验，包括彻底地理解项目需求，开展分析设计之类软件工程活动等 2、具备领导素质，以在各小组之间推进技术工作，并在项目压力下做出牢靠的关键决策 3、拥有优秀的沟通能力，用以进行说服、鼓励和指导等活动，并赢得项目成员的信任； 4、以目标导向和主动的方式来不带任何感情色彩地关注项目结果，构架师应当是项目背后的技术推动力，而非构想者或梦想家（追求完美） 5、精通构架设计的理论、实践和工具，并掌握多种参考构架、主要的可重用构架机制和模式（例如J2EE架构等）； 6、具备系统设计员的所有技能，但涉及面更广、抽象级别更高； 活动确定用例或需求的优先级、进行构架分析、创建构架的概念验证原型、评估构架的概念验证原型的可行性、组织系统实施模型、描述系统分布结构、描述运行时刻构架、确定设计机制、确定设计元素、合并已有设计元素 工件软件构架文档、参考构架、分析模型、设计模型、实施模型、部署模型、构架概念验证原型、接口、事件、信号与协议 系统架构师
人事管理系统的技术要求有哪些？ 爱问知识人
性能需求，系统有完善的缓存管理工具，以针对各种压力场景进行配置调优。
安全性需求，设计安全的物理网络和网络架构扩展性需求，系统应具有良好的扩展性与二次开发能力。
可用性需求，完备的应用的可用性措施可集成性需求，与其他应用统一认证、统一授权（SS0）兼容性需求，数据库服务器和应用服务器支持WindowsServer系统操作系统，软件系统基于微软.net平台开发。
“软件开发”职位具体做什么？需要什么技能？
件工程师是从事软件开发相关工作的人员的统称。
它是一个广义的概念，包括软件设计人员、软件架构人员、软件工程管理人员、程序员等一系列岗位。
这些岗位的分工不同，职位和/或级别不同，但工作内容都是与软件开发生产相关的。
软件工程师的技术要求是比较全面的，除了最基础的编程语言（C语言/C++/JAVA等）、数据库技术（SQL/ORACLE/DB2等）、.NET平台技术、C、C/S B/S程序开发，还有诸多如JAVA SCRIPT、AJAX、HIBERNATE、SPRING、J2EE、WEB SERVICE、STRUCTS等前沿技术。
除此之外，关于网络工程和软件测试的其他技术也要有所涉猎，以利于操控全局。
软件工程师可谓是软件项目开发的掌舵者，一名优秀的软件工程师应当具有较强的逻辑思维 能力，对于技术的发展有敏锐的嗅觉。
虽然要求技术全面，但无须偏执于门门技术都精通，任何软件工程师都有自己的技术特长和偏向，对于自己手中的技术，可有精通-掌握-熟悉-了解之分，根据工作需要和职业发展的具体情况来划分
