Chaaaaaaaaaaaaaaa-ching!（收银机的响声）

　　这种现象又出现了，又一个供应商的收银机发出了清脆的响声，这意味着又一个客户购买了SOA使用工具，而这位顾客有可能购买产品时并没有什么合理的依据，只不过是受宣传影响罢了。那么近期客户购买产品究竟是为了瞬时的部署灵活还是为了重用软件呢？还是客户希望尽快提高生产力，并且减少在集成方面所做的工作，要做这份工作只需编写一个带有数字的效验就可以了。

　　我们熟知SOA客户理解SOA中的A代表架构。只有当工程分析得出结论，购买产品的策略和发展方案与客观系统的架构目标相吻合时，这笔交易才是合理的。就这一条来看架构的定义有可能和SOA的定义一样。在这篇文章中，我创建了一个定义，并将这个定义作为基础。

　　软件架构={要素，形式，基本原理}

　　要素代表处于软件系统核心的开发产品：类、线程、组件及流程。例如为系统提供核心功能的流程。形式的特性就是描述了要素是如何依照部署组件的类相、流程之间的连接相互联系的，并且描述了流程是如何分配到节点的。基本原理描述了将要素按照特定形式分组的动机。例如开发生产线软件极大的影响了要素的共同性目标，软件的形式将会按照可部署组件进行描述。另一方面，它的等待时间短、性能高，这也是系统的驱动基本原理。要素的颗粒性要更粗糙些，要素可以按照一定的形式组合，并且可以在相同的处理器中执行。

　　一个系统的品质特性是基本原理对相应系统要素和形式进行描述的依据和基础。这些产品特性经由包括性能、伸展性、安全性、生产线、生命力这一系列组合表现的，而安全性必须给予足够的重视，成为程序范围内的信标以及指导所有技术性和纲领性决策的依据。同时还要执行一切建立在个体性能基础上的设计和开发工作，重温过去的经验，做出推断。

　　有些SOA的痴迷爱好者，没有遵从真正QA驱动的方法开发软件架构，而是沉醉于SOA的灵活性，使能特性，没有考虑其它的QA，例如性能和安全性，匆忙的做出结论。设计师最为重要的职责就是应该认识到，并不是所有的QA都能满足理想中的真实性，而建立在权衡基础上的优先性必须要保证平衡性。

　　那些了解我的人，或者通过UML Fever读过的人都知道，我并不倡导进行庞大的软件建模，假定UML设计师和架构收益成正比。就是说创建设计模型有很大的价值，这个模型能够展示软件架构的整体走向。其中最受人欢迎的模型就是架构的4+1视图模型，每一个视图表示了架构的不同侧面。逻辑视图描述了类以及能够实现系统功能要求的类与类之间的关系。实现视图展示了逻辑视图的要素是如何分成可部署实体小组的。流程视图展示了逻辑视图的要素是如何映射到流程和线程中的。部署视图展示了流程视图是如何映射到系统的计算资源的。“+1”视图代表具有架构意义的使用实例套装，这些使用实例经过了分析，并用于驱动开发以及其它四个视图的演进。

　　除了把时间荒废在SOA无休止的争论上，还是认为SOA和以前的“基于CORBA的系统”截然不同，设计师应该把更多的时间放在对系统需要的理解上，并且选择顺应系统需求的技术和设计策略。我在大学里学到的十分重要的一课对于SOA的使用方面可能具有指导意义：那些说的最多的人，往往是做的最少的。我也曾遇到过一个真正的SOA专业人士和有些供应商和设计师一样的要使用SOA，并证明设计策略的合理性，必须建立在实现其功能和质量属性的基础之上，而不是把全部的注意力都放在技术层面。这些人盲目的倡导使用最新的软件设计银弹从而避免繁重的工作。