51START

• SOA概念及特点释疑

  2006-05-04

  Tag：SOA技术导引

  先来看看什么是SOA：SOA是能够通过松散耦合关系组织交互软件模块（服务）的软件架构。再来看看什么是Service：服务是服务提供者提供的能完成请求服务的用户所希望功能的处理集合。

  那么SOA具有那些关键特点呢？

  （1）独立运行（standalone）：所谓的service, 它与组件（component）的根本不同首先在于service是独立于调用者自行运转的，即访问service的接口相对狭窄，我们只需要知道service如何满足我们的功能需求，而不需要管理它的生命周期，不需要理会那些维持service运行所需要考虑的种种细节。即我们对于service的了解只需要局限于功能接口即可，不需要理会它的那些管理接口，配置接口等。软件的发展趋势是智能化（intelligence），而智能化的第一步是自治（autonomous）, 即软件要具有自己的独立性，这首先意味着软件的生命周期要脱离其他软件的控制（standalone）。服务无论调用者是否存在，它本身是独立存在，独立发展的。这与一般的对象是不同的，一般的对象是由调用者创建并控制其生命周期的。

  
  （2）异步调用（asynchronous）：异步特性是SOA包容真正的商业智能的关键所在，同样是一个函数调用，只有异步特性才能够包容真正的商业智能，才能真正模拟真实世界中各种各样的异步情况，才能在函数这种最小的程序结构单元中引入最复杂的处理过程。现在SOA的宣传往往集中于机器之间的互相调用，强调异构系统之间的一种包容性，但事实上异步特性所能承载的内容要远远超越机器世界本身。当然，同步调用方式也是SOA架构的自然组成部分，就像我们既需要email，也需要手机一样。

  （3）基于消息（message based）：基于消息的调用方式是分布式系统的一种内在要求，消息是一种数据，它并不是远程对象指针，不需要维持其状态并将状态通知所有需要知道的调用者，远程对象这种基于proxy-stub的方案其要求是远程状态同步，即状态的一致性，而分布式系统是由众多独立的状态空间（进程空间）所构成的，这种内在的不协调是造成分布式的对象方案难以实现可扩展性的关键原因。

  （4）纯文本协议+元数据（Plaintext Meta）：SOA架构中基于纯文本协议是一个非常关键的技术抉择，当需要跨越众多硬件平台和软件系统的时候，各种二进制的远程调用方案总是存在着难以彻底解决的可理解性的问题。凭借纯文本的结构透明性加上元数据的自描述特性，我们希望实现一种语义透明性，使得各种中间层都能够以通用的方式传递经过的消息，并理解其中需要理解的部分。与OOP中的传统模式不同的是，SOA架构中强调的是结构（structure）与内容（content）的分离，而不是数据与行为的耦合与封装。说到纯文本的元语言，XML无疑是最好的选择，作为一种半结构化的文本表述，XML天然就是人机共享的信道。

  在SOA架构中，松散耦合是延迟绑定（late binding），独立运行（standalone）和基于消息（message based）等多种技术策略综合作用之后所达到的一种效果，这为外部灵活的流程配置做好了铺垫。

  然后解释一下SOA并不能等同于Web服务：Web服务是一套技术体系，包括XML、SOAP、 WSDL和UDDI，可以用来建立应用解决方案，解决特定的消息通信和应用集成问题。随着时间的推移，我们发现这些技术在不断发展、不断成熟，也会更好地帮助你实现SOA。但是，Web服务不是SOA：SOA是一种软件架构，而不局限于某个技术的组合（例如Web服务），它超越了技术范畴。在一个商业环境中，纯粹的SOA是一种应用软件架构，其中所有的功能都是相互独立的服务模块，通过完备定义的接口相互联系起来。只要按照一定的顺序来请求这些功能模块所提供的服务，就可以形成完整的业务流程。

  Web服务的出现，为SOA的应用提供了一种标准。到目前为止，业界已经形成了一些基本的标准模块——SOAP用于服务请求的建立；WSDL用于服务请求的发布；UDDI用于服务请求的目录列表；另外还有一些关于安全和数字签名的标准。

  SOAP：Simple Object Access Protocol

  WSDL：Web Service Description Language

  UDDI：Universal Description, Discovery, and Integration
  
  SeraphZhang 发表于20:32:03 | 阅读全文 | 评论 0 | 编辑 | 分享 0

• SOA与超越SOA——从人类社会变迁和软件熵看软件系统进化（二）

  2006-05-04

  Tag：头脑风暴

           文接上段，软件系统架构发展到今天，虽然时间不长，但是其发展速度确实惊人的，这本身与IT产业的发展是同步的。SOA概念的提出从某些角度上展示了未来一段时间内软件架构的发展态势和主流，但是否存在影响其的深层次的产业原因呢？还是说它仅仅是自身矛盾统一的发展结果？我个人认为：其实IT产业的发展及IT产业与其他产业的融合是促进了软件架构发展的最根本的因素！

          首先，先说明一下软件架构本身的内部矛盾为什么不是其发展的主要因素和动力呢？因为软件架构内部的矛盾仅仅是其外部适应性的一种内在反映，它实际体现的是某种软件架构是否符合使用者的需要，是否适应当时软件产业的发展需要。换句话说，软件架构本身并不存在本质上的矛盾，它仅仅是人们创建出来的为了适应某种需要的“模式”而已，仅仅是人为的一种“创造物”，存在的理由也仅仅是因为它适应需要，而被淘汰的理由也仅仅是因为它不适应需要，所以如果硬要说软件架构存在矛盾的话，这种矛盾本质上应该是外在的而不是内在的。这与哲学上讲的内部矛盾是事物发展的主要动因并不冲突，因为软件架构本身根本无法构成存在矛盾的独立统一体，它自身是根本不存在矛盾的。

           其次，解释一下为什么IT产业的发展及IT产业与其他产业的融合是促进软件架构发展的最根本因素呢？软件作为IT产业的重要组成部分，其反映IT产业的发展并接受其影响是再正常不过的事情了，而且除此之外，软件架构并不与其他因素构成必然联系，它虽然是人为的产物，但是各种软件架构的发明者或方法论者仅仅是按照产业的发展需要将已经存在于人脑中的某些“事实”进行抽象和总结而已。从紧耦合到松耦合的这种架构发展趋势来讲，本身也是非常符合IT产业的发展趋势的。任何一个产业的发展都必将至少经历三个过程：萌芽期、成熟期、衰落期。在萌芽期，核心竞争力的形成以及飞速的增长速度是最明显的特点；在成熟期，适应产业融合的发展成为了主流；在衰落期，发展速度缓慢甚至倒退则明显地体现出来。目前的IT产业正在逐步从萌芽期向成熟期过渡，虽然目前没有找到明确统计数据，但是已经能够明显地体验到IT产业逐渐融入到了其他产业之中，成为其他产业发展的核心原动力之一。随着这一过程越来越明显，软件系统架构也必将要逐步适应——只有降低粒度、提高灵活度、摆脱僵化死板的体系架构才能更好地适应融合的趋势，这也是为什么软件系统架构从紧耦合向松耦合趋势发展的深层次的产业内在原因。

           所谓超越SOA就是研究未来SOA将向何处发展，如果想做到超越SOA就必须了解SOA对于未来发展趋势的不适应性。在SOA中系统服务总线ESB是其最核心的部分，所有的服务都是要挂接在其上，这使得SOA本身集中化、中心化。借用上一篇的观点，软件外熵就全部体现在了ESB的组织上，而软件外熵是不断增大的，这就必然会使ESB分崩离析成为分布式的服务结构组织方式。其实这种“单元简单、组织复杂”的系统于人类自身就有最明显的体现——神经系统，人类的神经系统可以说超级强大和复杂的，但是每个单独的神经细胞却又是及其简单的，它强大的记忆、联想、推理、计算等能力都是由复杂的组织结构支撑和完成的，我们不得不承认人类的神经系统是经过数百万年进化得到的内熵及其小而外熵及其大的典型系统。目前软件系统尚不足以进化到如此程度，如真的如此，恐怕呈现在我们面前的就是如骇客帝国中的母体Matrix一般的庞然怪物了。

           其实这种从紧到松进而形成“耦合性外化”的转化形式不仅仅体现在神经系统、软件体系架构上，在人类社会发展的历史进程中也可以找到蛛丝马迹。随着人类社会的发展，分工越来越细化，每个人所能熟练掌握的领域也越来越狭窄，这种趋势造就了每个人都逐步成为了社会发展的“螺丝钉”，即缺了你照样跑不会影响大局的变化。不得不承认英雄人物出现的可能性也越来越小了，因为英雄人物需要对整个社会层面的各个领域施加影响，这就需要他能对各个领域都有所涉及，这在目前来讲是及其困难甚至就是不可能的，这也是为什么几乎所有的机构都在强调“Team Spirits”，脱离了团队的人是无法干成任何事情的，就像这次大赛一样，我们必须团结如一人才能发挥1+1+1+1+1>5的力量！

           以上是从“模块”组织方式即软件外熵的角度考虑的问题，那么从软件内熵的角度考虑每个“模块”在未来会有什么样的变化呢？又是怎样超越SOA的呢？SOA中的每个“模块”就是服务，现在要考虑的是这种划分是不是完全合理呢？明显在某些服务中是可能存在有交叉的，举个简单的例子，财务管理和库存管理中都存在并发控制的问题，不可否认这两种并发控制的对象是不同的——分别是资金和库存，但是明显其控制机制应该是一致的。如果分开实现部署的话，那么显然每个服务的重用性是会降低的，因为它只能在也需要并发控制的地方才可以复用，况且如果并发控制机制不同的话，所有模块中所有的并发控制功能就要全部都重新修改才能移植使用。那么如果将这种相应的Aspect从每个实体对象中剥离出来形成独立的Aspect对象，无疑是降低了实体对象（也就是我们现在所说的“模块”）的耦合度，同时将这种耦合外化至整个系统之中。

           说了这么多，其实所谓超越不过是在现有事实基础之上通过对规律的总结进而对未来的一种预测，这个世界上是没有人知道未来的，只能是预测未来。遗传还有变异呢，更何况这里预测的是飞速发展、变化多端的IT产业，预测需要事实来证明，让我们拭目以待，目前是要做好现实的工作，加油加油～～
  SeraphZhang 发表于17:43:24 | 阅读全文 | 评论 0 | 编辑 | 分享 0

• 从企业SOA进程看SOA赛事安排

  2006-05-04

  Tag：头脑风暴

          为了更加灵活、更加快捷的响应变幻莫测的需求，要求软件架构有高度的业务灵活性，SOA（面向服务的架构）应运而生。

          SOA高度的灵活性来自于它把业务流程和相关的IT基础设施中的元素看作安全的、标准化的组建（服务），通过对这些组件的重用和组合，即可灵活应对变化的业务流程和业务需。基于SOA的系统中，具体应用的功能是由一些松耦合并且具有统一接口定义方式的组件（服务）组合构建起来的。

          工具以及成熟的过程指南能够简化和加速面向服务的应用程序的业务流程建模以及设计、构建和继承过程。但是，工具只是能够起到辅助作用。在企业SOA的进程中，对企业业务流程的分析是SOA的关键。是否能够准确的描述业务需求，决定了SOA的成败。

          在企业SOA的进程中，如何分析企业的业务流程？如何准确的描述业务需求呢？

          我认为，可以分为两类情况。

          第一，对于业务流程较为成熟的企业。业务模式的相对成熟，对于适用SOA是非常有好处的。这一点可以从IBM与COSCON的成功案例中得到印证。在有成熟业务模式的前提下，对企业的业务需求分析较为简单，可以直接把成熟业务流程中的每个步骤集成到一个组件中。这样，每个组件内部可以是面向对象的，紧密耦合的结构。但是，每个组件之间是松散耦合的。从而，整体上仍然是松散耦合的，是面向服务的。SOA 系统原型的一个典型例子是通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA），它已经出现很长时间了，其定义的概念与 SOA 相似。

          第二，对于业务模式不成熟的企业。业务模式的相对成熟，对于适用SOA是有好处的，这是不可否认的。但是，这并非意味着成熟的业务模式是实施SOA的必要条件。因为业务流程随时间的变化，并不会引起业务能力的变化，而SOA反映的是业务能力。只是，业务成熟度较低的企业在实施SOA时，需要行业咨询机构的介入，以保证服务需求分析深入、透彻。进而在分析透彻后，将业务需求中不重合的部分集成到独立的组件中。在应用中，通过对组件的重用和组合满足不断变化的业务流程和业务需求。

          上面两类情况的共性在于，都首先要对企业的业务需求进行深入、透彻地分析。这体现了SOA中由业务需求驱动服务的设计和构建的理念。也就是说企业的信息系统建设不能够单纯的从IT技术出发，跟据已有的技术和自己的揣测盲目建设，而是应该结合业务部门的需求，有的放矢。由此可见，在进行技术开发之前，对业务流程和业务流程每个环节的深入分析、把如何把每个环节巧妙的集成到各个组件的设计工作决定了项目的成败。
          SOA大赛的安排也体现了这一理念。

          初赛阶段，需要提交“设计文档（系统架构，组件设计）”、“系统开发计划安排”、“解释SOA思想和方法在本系统开发中的应用”、“业务模式分析和设计”和“服务模型分析和设计”等。这对应于企业的SOA进程中的业务需求分析。在这一阶段，我们需要对比赛题目中“凤凰医疗设备有限公司”的业务流程进行分析。分析要做到抽取成熟业务流程，分离非成熟业务流程，并设计对应的组件（服务）。在组件的设计过程中，要根据组件功能不重迭，分工明确，接口统一，耦合松散的原则。

          复赛阶段，进行面对面的演讲与问答。进一步对项目进行探讨，演示项目模型等。这对应于企业SOA进程中完成业务需求分析后，使用业务需求分析的结果与技术开发人员进行可行性讨论。探讨业务需求分析是否准确，组件粒度是否合适等等问题。是对前一步工作的审核和确认，也是下一步工作顺利进行的有力保障。

          决赛阶段，进行全职开发，并接受IBM”青出于蓝”项目的专职辅导。这对应于企业SOA进程中最终确认合作伙伴，进行系统开发的过程。SOA作为新鲜事物，选择好的合作伙伴是保障项目成功的又一关键因素。作为专业的SOA厂商，IBM提供的除了像IBM WebSphere Server Foundation和IBM WBI Monitor这样可以作为支撑平台的组件，还以先进的技术支持来推动项目的进展。比如，IBM组建了一个10人组的技术支持队伍，将J2EE的开发技术和迭代式开发方法带给COSCON的开发团队，帮助他们构建了所有的服务模型（Service Model）,这些为SOA在COSCON的实施提供了重要保障。

          从以上可以看到，这次SOA大赛本身遵循了SOA的基本理念，也反映了企业SOA进程的步骤。
  发表于15:36:49 | 阅读全文 | 评论 0 | 编辑 | 分享 0

• 团队工作讨论

  2006-05-04

  Tag：工作日志

  各位同志哥，上次安排的大赛题目初步分析做的咋样了？按照我们安排的例会制度，应该尽快组织一次讨论进行交流，然后才能开始后续的工作啊。

  另外，告诉大家一个好消息，用于参赛工作平台的服务器已经设置完毕了，多谢SuperZhang同学的积极工作啊，我买了一台新机器，P4 2.66GHZ的CPU，1G内存，160G硬盘，足以跑各种EPR以及IBM的解决方案了，呵呵。

  我来谈谈我对大赛题目的认识：

  1.首先，这是一道纯粹的应用题目。分析并理解现实需求、设想并假定未来需求是第一步工作，也是最重要的工作。从应用角度来看，这道题目强调的是如何搭建一个良好的、符合SOA理念的企业信息环境，从而为其今后的业务增长奠定坚实的基础并开拓广阔的空间。技术刚出现的时候是满足现实需求，技术成熟以后就会引领现实需求。因此我们所有技术团队的人员必须从企业发展的角度着眼，把需求理解为现实困难和长远希望两个部分。因此我急迫的等待着BXQ同学的业务分析报告，呵呵。

  2.其次，这是一道追求系统架构能力的题目。它并不简单强调技术细节的创新，而是强调稳定、灵活而又极具扩展性的系统架构。我们在系统架构讨论班中已经提到了SE理论中的几种常见设计模型，其实SOA是结合了ECC与SLS两种模型的一种复杂应用，某些细节地方还采取了CBS或BCS的形式。因此我们在进行系统结构分析时要注重内涵体现，SOA不是简单的ESB加上Web Service，最重要的是SOA系统的Framework，这是立足点。基于Framework再来拓展各种特殊具体的技术服务模块，从而形成完整的Architecture。所以我同样急迫的等待着麦卡同学的系统架构设计思路，呵呵。

  3.第三，这是一道考察技术选择能力和系统集成能力的题目。它要求我们遵循SOA概念，推荐使用用友ERP以及IBM的技术平台，那么我们如何选择各种组件？如何配置一个贴近真实应用环境的企业信息化模拟空间？如何将不同的应用程序有机的集成在一起？这是Donkey同学的主要任务，希望你抓紧啊。

  4.第四，这是一道推崇新的应用思路、启发新的管理思路、引入新的技术概念的题目。虽然SOA是比较新的概念，但是它不是第一天出现，而是经历了较长的发展阶段。因此现在我们讨论SOA，不但要讨论设计、还要考虑实现、更要畅想未来可能的种种变化，创新无极限，一定要多做幻想啊。这是Zhang同学的主要任务，呵呵。

  我建议各位同志看过本贴后尽快回复，我好了解大家的进展，而后我们再深入的开展工作，对不？

  Zhang同学，你能不能再转贴一些SOA的概念以及知识性信息？

  Donkey同学，你也别藏着了，发一些关于用友ERP以及IBM技术框架的介绍性材料吧。

  麦卡同学，探探你的系统架构思路，直接发到博客上就行了。

  BXQ同学，大家翘首以盼你的业务分析呢，先说说思路也好阿。

  大家加油，五一长假我在加班，好辛苦啊！
  沙中世界 发表于14:27:04 | 阅读全文 | 评论 1 | 编辑 | 分享 0

• SOA与超越SOA——从人类社会变迁和软件熵看软件系统进化（一）

  2006-04-28

  Tag：头脑风暴

      题目中所谓的系统指的是广义上的，即为了解决某些事情而建立起来的独立软件系统或整体解决方案。今天要讨论的是不针对任何具体事务的泛化的系统概念，这里的系统仅仅是指以某些协作关系为联系并存在的功能集合而已。

      “系统进化论”系统和进化论怎么联系到一起的呢？其实不难想像，就像人类社会亦或人类本身都存在一个进化的过程一样，系统组织结构也存在着一种因对外界环境的适应性而发生进化的过程，这一点在对外围环境有极强依赖的软件系统则体现得尤其明显。就像人类社会从初期的氏族社会，经历了奴隶社会、封建社会、资本主义社会、社会主义社会等不同形式的社会组织形式一样，软件系统的形式同样经历了历史性的变迁，从早期的面向过程，逐步经历面向对象、面向组件，再到现在的面向方面、面向服务等等，所不同的是由于不同软件组织形式不存在必然颠覆对方的不可调和的矛盾，所以软件组织架构现在呈现出了百家争鸣的景象，我们所能把握的也只是潮流和方向，并不能肯定地说哪个软件系统组织结构一定是最好的，只能说在某些特定背景条件下某种软件组织结构更加适合。

      在早期，软件系统由于每个组件的功能低下（当然如果函数甚至简单的功能语句块也能看作组件的话）且计算机本身应用大多局限在科学计算领域，这就像在人类早期的氏族社会——同一个部落中的人与人保持着非常紧密的关系但同时几乎与其他部落没有任何联系且每个人的单独生产力都很低下，如果想保证基本的生存必须紧密的联系在一起一样，早期的软件系统也因为同样的原因自然而然地采用了紧耦合的系统架构。

       随着需求的不断增长和计算机能力的迅速提高，软件系统面临越来越复杂的问题，这种复杂不仅仅是问题本身更是体现在问题所处的环境上，而复杂性则更多地表现为“多变”、“多边”和“多需求”。所谓“多变”是指软件系统所处的环境随时可能面临各种各样的变化，而这种变化所带来的就是软件系统任何时候都有可能突然失效；所谓“多边”是指软件系统所涉及的领域是多样化的，软件系统必须适应各个领域的领域知识以及领域内普遍认同的解决方法；所谓“多需求”是指软件系统所涵盖的功能越来越多，众所周知，涵盖的内容越多、关系越复杂，错误传递的可能性越大，即使每个部件的错误率都很低，也会因多个部件之间的多重连接关系导致复杂性成幂指级上升。

       如何解决所谓的“多变”、“多边”和“多需求”问题呢？松耦合为我们提供了良好的解决方案：松耦合关系虽然不能抑制“多变”问题的出现，但是由于其松散关系易于拆解和组装，则可以更好地适应“多变”问题；松耦合同样不能使软件系统不进入“多边”的问题领域，只是由于松耦合关系可以使各个组件独立地适应一个领域内容而不必过多地关心其他领域，从而减少单独组件的负担；松耦合关系最大程度的降低了每个组件之间的耦合性，使一个组件的错误被传递到另一个部件引起其他错误的可能性大幅度降低，在这种情况下虽然没能解决多重连接的本质但是却把错误可能性极大地降低了。

      SOA本身就是一种采用了松耦合关系的体系结构，每个服务组件之间的关系不再是紧密连接的了，其实相比较而言，SOA在获得松耦合关系的同时，其通讯机制的设计却使得软件系统的设计与实现变得更加严格了。换句话说从我个人的观点来看，系统架构的变迁没有本质上改变系统的复杂程度变大的趋势，只是适应性地缩小了这种复杂度增加的幅度，只是逐渐把复杂度因子从内部向外部移了。从热力学第二定律的角度来思考这个问题，软件系统的熵（混乱度或复杂度）是在不断变大的，软件熵包括两个方面的内容，我们可以暂时把它们称为“内熵”和“外熵”，就目前软件系统架构的发展趋势来看，其“内熵”，即组件内部的关联度，并没有发生明显的变化；而“外熵”，即组件之间的关联度，是不断增大的。对于这个结论可以得到如下的解释，现在的每个组件其实就相当于原来紧耦合关系下的独立软件系统，因此其软件熵并无明显的变化；而组件之间的“外熵”却随着组件的不断独立和增多而越来越大；唯一可以使软件熵降低的因素来自于组件之间通讯协议的限制，但是这种限制只是使组件之间的通讯得到尽量统一，它虽然在一定程度上减弱了“外熵”但并不足以起到完全消除“外熵”增长的程度。由此可见，熵变化的时间箭头理论在软件系统架构发展过程中同样是有效的。它也成为了我们合理地预测软件系统架构的未来发展趋势的一个参考依据。

      再来看一看，究竟什么是像生产力生产关系矛盾推动人类社会发展一样推动着软件系统架构的进步呢？我们知道，矛盾统一的哲学理论实践是无所不在的，在软件系统进化过程中也一样——实际需求与软件架构本身能满足的需求之间存在着不可调和的矛盾，这组矛盾是推动软件系统进化的关键内因所在。同样，这组矛盾不仅在过去，在现在和将来也必将继续推动软件系统的进一步发展。也正是基于此，它同样成为了我们合理地预测软件系统架构的未来发展趋势的参考依据。

       以上的内容从另外的多个侧面审视了软件系统架构的发展历程和其必然趋势，证明了以SOA为代表的松耦合架构是软件系统发展的必然产物。当然所有这些也都是自己突发奇想的一点点感触而已，并没有严格的理论和数学证明，也欢迎大家多多讨论同时也希望能够在和大家进行足够的头脑风暴之后完成本文的第二部分——“超越SOA”
  SeraphZhang 发表于22:04:03 | 阅读全文 | 评论 0 | 编辑 | 分享 0