朱律玮：长风联盟的SOA研究与实践

　　12月1日第四届中国企业信息化用户大会在北京世纪金源大饭店隆重召开，本次大会重点探讨“深度应用背景下的中国SOA路径”。大会从不同的视角解析了SOA在中国的发展路径，并和用户一道分享SOA在中国的成功实施经验。长风联盟SOA-RA-TF主席、东方通首席架构师朱律玮作主题演讲。

　　各位来宾下午好，我是长风联盟SOA工作组的主席，也是东方通科技公司的首席架构师，我汇报一下长风联盟SOA方面的工作，希望通过简单的介绍，让大家对SOA在中国的研究和情况有一些了解，也对自己的工作有所帮助。
　　我下午介绍的主要内容分三各方面，首先简单介绍一下SOA的基本特性，这也是我们后续接招的内容，以及我们工作所关注的重点。第二方面我们会介绍一下长风联盟工作组里，在SOA架构方面做的主要工作。最后我们会通过简单的案例介绍一下在SOA这样的模式下如何真正实现应用系统。
　　对于SOA基本概念来说，大家已经了解了很多，对于它的基本概念有可能我们不需要再重复。我再重复的是有关SOA的基本特性，这些基本特性正是我们所有后续的工作的基础。我先简单介绍一下长风联盟这个组织，长风联盟实际上是在北京市科委倡导下，由北京市几个主要软件厂商大家自发组合起来的民间的团体组织，现在也有50家会员参与到其中，其中包括北京市主要的一些软件企业以及科研院所、用户都参与到其中。长风联盟现在主要是有两个侧重点，一个是国产软件另外就是SOA。因为我们认识到SOA是未来一段时间内很重要的发展方向。
　　在长风联盟的架构下，我们围绕SOA现在成立了三个工作组，以我们东方通科技牵头，组成了SOA架构的工作组，主要是底层架构实现。中间有一个应用推广组，会侧重在应用推广的实施。另外有一个叫SOA测试工作组，主要工作提供一些SOA的实施规范标准的工作，验证一下用户建立的SOA的系统是不是符合SOA的特性，符合程度到底是什么情况。
　　下面我的主要介绍还是围绕参考架构方面的工作，给大家汇报一下我们的研究成果。对于SOA的基本特性来说，我们认为主要还都是围绕服务这个词为中心展开的，这个服务更多强调的是业务的服务，而不是技术上的服务。对于IT部门来说或者软件厂商来说有可能更多关心的都是技术问题，但对于真正用户来说如何建立一个系统，我相信目标不是建立IT系统而考虑建设的过程，而是真正要解决实际的业务问题。建设一个IT系统只不过为了解决业务需求的手段而已，同样讲到SOA，现在更强调的是服务围绕业务的服务，里面有可能会需要用到一些技术的手段来实现SOA这样的思想，对于我们现在的理解来说，实现SOA可能利用一些传统的技术也可以解决一些基本问题，但有可能使用起来会有一点难度或者不能很好的体现这样的思想。有可能考虑到现在的技术，需要满足这样SOA的理念。
　　但从现在实际情况来看，无论国外厂商还是国内软件厂商所做的工作，我们觉得SOA仅仅处于起步阶段，里面还有很多工作要做，也包括相关技术，对于现在来说，我们认为还是处于起步阶段，有可能通过三到五年实践阶段，这个技术才有可能成熟，有可能SOA广泛应用在三年以后。对于SOA来说，强调的是业务服务，所有工作都围绕这个服务来开展的，很重要有几个方面，包括服务如何定义，有了服务以后如何组合在一起，能够呈现出新的业务流程，或者解决一个具体的业务问题。第三这些服务运行起来以后如何监控服务的运行，了解服务的运行信息，搜集信息最终目标是优化业务的流程，或者我看是不是达到了业务目标。所以说对于SOA来说，这三个是重点考虑的方面。对于相关厂商来说，提供的解决方案有是围绕这方面。对于用户来说，如何考虑这些相关的问题，有可能是说更多的需要从业务的该度，对于业务人员来说和技术人员来说需要两边一起考虑，真正解决业务和技术之间的鸿沟。
　　对于SOA的基本概念来说，其中很重要的一点就强调松耦合，这也是真正需要解决服务互用的因素，只有讲到服务的松耦合，对于服务的互用才能真正展现出来。最后一个很重要对标准的支持，业务服务如何描述，这是需要相关的标准支持，服务如何整合在一起形成业务流程也需要标准的支持，对于业务系统还说，现在考虑的是业务的整合场景，如何把各个系统整合在一起，满足自己的实际业务需求，就需要有业务的标准。在业务上，实现不同业务的整合，需要互操作性的标准也是支撑因素。
　　对于SOA来说，这样提出一个概念，真正解决一些什么问题。提出这个概念一定需要解决一些具体问题，我们结合到具体的实际情况来看，从SOA的特性来看，提出这个概念的时候是要解决业务的敏捷性，在国外来说更多有可能是每个单个系统建立差不多了，这时候需要考虑如何把这些单一的系统整合在一起，在全球化的环境内如何面对变化很快的市场。但对于我们国内实际情况看，就要看看自己的现状是什么样，我们也在讲SOA，需要SOA解决什么问题。下面会简单介绍一下我们认为在国内现在一些实际的业务需求有可能什么样子的。
　　对于SOA来说，有了解决业务敏捷性问题，都会提到保护用户投资、节约建设成本，讲到任何技术都会提到这些概念。这实际上也说，对于SOA的理念来说，不强调建立单个系统，而是要把已有的系统整合在一起，资源都要很好的保护。SOA可以逐步的改进业务目标，这也是SOA理念的可以推导出来的一个概念，可以逐步的改进业务目标。因为我们一开始讲ERP的，时候大家都有这样的概念，一开始讲很多ERP的好处，但是真正应用好，实际上和业务的模式改变都是非常相关的，对于企业来说，要强调敏捷性，实际上就强调不是革命，而是说需要渐进的改革，就和我们进入社会主义一样，我们要做的工作是逐步的达到我们的目标，一步步走。
　　对于SOA来说，还有一个相关好处，是强调技术的独立性，这也是对用户来说很期望达到的方面。因为我们不希望某一个技术是绑定在某一个厂商上，因为一但和厂商技术绑定，所有的工作都会依赖于这个厂商，如果厂商的服务不到位，或者发展有问题，都会对我们业务发展有很大的影响。所以对这些内容来说，大家讲SOA希望得到的内容。但我们现在也要具体看一下，现实的目标是什么样。
　　在这之前看一下标准化的工作，实际上讲到标准我们现在需要强调两方面，一个是技术标准一个是业务标准，技术标准更多的是需要针对软件厂商的，有了技术标准实现不同产品的互联。刚才提到，给用户带来的好处，用户可以有更多的选择余地。这些方面围绕SOA相关的技术有可能强调实现方式的标准，比如WS、SCA/SDO，JBI很重要的是建设业务标准，在业务标准中有可能一个企业的内部标准，这时候要建设SOA的系统就是企业内部系统的整合，也可能是行业内部的业务标准，比如实现一个供应链的过程，会涉及到若干企业，如何把他们很好的集合在一起，涉及到行业的标准。在国际实际情况看，也有一些行业标准，比如金融行业内，也牵扯到各个金融机构之间如何很好的交换数据，这时候人民银行牵头制订一些标准，有可能和国外银行接口就有一些其他标准。一定有标准的情况下才能更好的实现整合，包括企业内部的整合也包括行业之间的整合。对于业务标准来说有可能考虑这几方面，一个是业务的服务本身，哪些业务能够成为服务，这是要考虑的。中间可能考虑业务的颗粒度有多大，多大的服务比较合适。比如我们到银行，或者电信计费，有可能用不同的方式，有可能是基本的计费也有可能是有套餐、优惠，我们是作为完整的服务还是拆成若干小的服务，根据业务的需要进行整合。除此之外还有数据的标准、流程的标准，也很重要的是需要考虑管理方面的工作。有可能也需要考虑相关的标准化的工作，这更多的是讲到SOA的管制，讲如何去考虑整个规划怎么做，包括实施过程中需要考虑什么问题，比如有了服务以后，谁来发布、维护这个服务，谁来监控这个服务，如果进行升级改变的时候，会对谁产生影响等等都需要从业务方面进行考虑。
　　下面我们来看一下从现在实际了解到的情况，SOA在国内为我们认为怎么做有可能更合适一些。对于我们现在来说，更现实的比较大的应用范围还是围绕数据整合的工作，对于现在的业务需求来说更切合实际一些。因为SOA一开始提出就是强调业务敏捷性，所以要考虑的是业务流程化的工作。但是业务流程化的工作不仅仅技术层面解决的问题，技术可以支撑业务的流程化，可以很好的定义或者很容易的支撑业务的流程，也可以根据业务情况的改变调整业务流程。但是很多实际情况来看，不是技术问题，这实际上也涉及到企业内部如何优化自己的业务模式的问题，看自己的业务流程是不是合适。从这个角度讲这就不是技术问题，而是业务上的问题了。你看能不能有这样的调动能力，在企业范围内实现业务流程的整合。或者你有很好的协调能力，把上下游的企业整合在一起，大家很好的规划业务流程出来。
　　但是对于数据共享这块来说，有可能对现阶段来说更实际。因为我们碰到的更多案例情况来看，数据共享有可能对于现有的工作模式改变有可能不需要，一个部门或者一个企业可以提供这个数据，有可能也需要使用这个数据，这样情况下对自己本身的业务改变都会很小，通过这种方式可以先去用数据整合的方式积累经验，有了经验之后考虑业务方面整合的工作，逐步推进企业不断优化的目标。这个角度来说，我们也可以看到SOA可以支撑逐步改进的特点。
　　在一个实际业务中，数据共享可能有一些具体的技术点或者业务需求需要关注。这有可能是说业务的服务特性如何展现，这也是实际的需求。比如说在讲到电子政务里，需要建立一个应急指挥系统，有可能需要涉及到若干委办局提供相关数据，或者我们正在实施的案例，讲到应急指挥系统，建立若干系统，比如有船舶系统、船员系统还有船舶动态的信息，都有可能需要获取这些信息才能在危急情况下起到指挥的作用。这时候可能需要相关的数据，这些数据提供哪些具体信息描述，这时候就是业务特性的描述，这时候对于业务人员来说需要关注的。对于船舶系统来说能提供哪些数据，这些数据稳定性怎样，按照什么样的周期进行展示或者进行更新，比如每天更新还是每小时更新。比如讲到船舶动态信息，有可能需要实时的信息，需要更新的频率很快，可能以分钟、小时这样的级别来更新。这些方面都是业务特性的表述，对别人使用业务服务就可以做到心里有数。比如银行提供的存款服务，现在讲到跨行提供的收费标准，都是不一样的，有可能是1%，这可能是转帐服务的特性，可以根据自己的需要选择一个合适的服务。
　　有了业务服务描述之后，另外很关键的一点，服务监控的管理。这时候有可能需要了解这个服务是不是能提供72小时的服务，比如说只是提供8点钟到下午5点钟的服务，响应时间提供什么程度，实际运行起来真正是不是能做到这些信息，或者接收到的数据多少，接收到的请求多少，成功处理的请求是多少，这都对服务的管理包括优化以及在服务中间是不是有效，是不是需要选择另外一个服务都是很重要的参考依据。
　　同样也需要有相对的技术上的需求，这有可能说主要针对技术人员有可能需要提供很方便的开发环境、监控的环境，因为讲到SOA是强调缩短开发周期，势必要有方便的工具，这个工具有可能是很重要的一点。在SOA模式下，更多的是强调通过配制方式实现开发的工作，而不是说做大量编程工作，只是重新组合的工作，可能需要配制工作做的。有可能有调试也有可能有很大的影响，如何提供模拟的调试，能不能符合实际的情况，这也是从技术的角度关注的。除此之外还需要考虑效率、安全性的问题，对于后台可能考虑的是我是不是一定要使用Web服务器。
　　我们有一个总体的总结经验，对于业务来说，有可能是说首先业务的入手，然后一定要从小的项目试点开始，逐步积累经验，这样真正体现逐步改进的目标，如果一开始上来规划很大的系统，你的投入会很大，而且很多因素是不可控的。从技术角度要有相应的工具产品支撑，包括业务建模、设计、开发的工具，也包括运行过程中的产品支撑，比如ESB、流程引擎等等。
　　下面我们看一下长风联盟的角度，规划了一个参考架构，这是底层架构的角度，而不是建设一个应用系统的角度规划的。那部分工作由另外一个工作组做，我们从底层架构来说，从SOA实现的角度看有哪些方面的内容。里面包括几个大的包括开发工具、服务库、运行管理系统，有很多技术性的服务支撑整个系统的基础运行。我们看一下架构本身的特点，我们设计这个架构的时候，参考两个因素，一个是国际标准，这肯定要跟踪的，如果不去跟踪相关的工作，你的技术先进性方面得不到保证。另外是真正的需求，这也是我们考虑架构很重要的方面，比如说刚才提到得如何对这些业务运行监控，都是我们实际项目中用户给我们提出的具体需求。
　　我们架构本身也体现了松偶合的通行，长风联盟有很多企业组成的生产耦合体，也符合架构松偶合的特性，有可能每家企业擅长的技术点不一样，有可能做里面若干服务或者工具，然后每家做的内容不一样，这样需要整合在一起，就需要体现架构的松偶合的特性。也可以满足不同场景或者分开使用，这个架构里所有部分可以根据实际需要选择使用。我们考虑架构的时候，也考虑技术的无关性，具体使显得时候可以用传统方式实现及也可以用Web实现，不同技术解决的问题可能不一样，有时候可能需要更多的强调效率，更强的实时性和安全性，这时候用传统技术解决更好，对Web来说效率方面可能存在一些问题。
　　下面我们看看我们考虑建设整个SOA系统中的问题，首先是服务子管理中心，刚才讲SOA强调的是服务，首先要把服务本身管理起来，有可能考虑服务的描述，有可能有几个方面及有可能从业务方面的描述，比如说是不是收费、可提供的服务时间，这是从业务角度的描述。第二层面有可能从技术接口层面，要转换到技术层面实现的，要转换成另一种实现的方式，所以要定义服务接口。也有可能定义服务质量，是不是提供可靠性、安全性，这也需要对服务加以描述。最后有可能描述服务运行的时候监控哪些信息，这样在真正运行中可能把相应的内容抽取出来，有可能放到运行的信息库里。这些信息都是需要存储在一个服务资源中心来，有了这些信息涉及到如何使用这些信息，如果服务量不是很大，管理比较简单，如果服务量一旦增加，如何管理、查询、找到合适的服务，相关的管理工作就变得很重要。所以有可能进行分类管理，或者提供分层次的管理，使我们很容易的找到自己需要的服务。从资源服务中心的角度来说，有可能考虑服务的描述性如何存储，我们的架构里不强调存储的具体实现，使显得技术可以是数据库、软件，我们也规定一些要提供的标准服务，比如说如何对它进行分类、如何提供查询、如何进行存储和提取。
　　这个信息有了以后，还包括如何进行管理这样的一些标准服务。我们还有一些其他服务资源，比如我们的流程，或者把若干服务组合在一起，或者有一些新开发的服务，新视线的服务存储都有可能存储在资源中心中，所以资源中心有可能是一个大杂烩，可能存储服务的描述信息也可能是代码的信息。这个服务资源中心要给别人提供服务，比如需要提供集成开发工具、分析建模工具、调试工具有可能都需要使用资源中心的数据，我们把服务资源中心提供的功能以服务的形式展现出来。
　　第二集成开发工具，要有很快捷的建设SOA的系统，没有很好的工具支撑是做不到的，实际上就是为了方便业务人员、技术人员来建设这个系统，我们现在考虑的建模工具不仅仅是技术角度及也需要提供分析建模的工具，这可能有很大难度，但我们从最基础做起，后面的有可能是技术层面的，这些工具也希望能在统一框架里很好的整合在一起，很好的互用这些数据，而不需要每个系统都是独立的使用。有了基本工具以后还需要提供扩展工具，针对特定的场景提供使用方式。比如对于数据整合的时候，有可能使用数据库，我们有可能提供一个针对数据库的工具很容易的把数据库中的信息提取出来，比如表、字的信息，这些信息可以很容易的展现在客户面前，获取里面所需要的数据定义成一个服务。在这个架构中。
　　第三很重要的方面就是服务总线，需要把若干独立的服务串接一起，大家能把这些服务挂接到一个总线上很容易的交换数据、信息，所以说核心是围绕消息处理的过程。业提供了一些标准的服务，也支持不的通讯协议，比如支持JSM等等协议，满足不同场景如果在企业内部，为了效益的角度考虑，可以用JSM支撑。在框架中很重要的是服务之间的接口，真正接入这个系统的服务有可能不一样，有数据库、应用，他们的实现方式不一样，但要有统一的服务形式展现出来。
　　为了更好的应用这些服务，需要有一个流程引擎，是从三各方面介绍的，一个是流程涉及工具、资源库还有流程监控工具。整个流程的运行状态讯息需要有一个库存储。对于流程里有很多活动支持的，我们定义成一个服务，系统有可能是人工的操作或者简单的实现，但这些实现分布在不同的地方，所以对服务的访问来说，就从流程引擎里剥离出来了。
　　刚才讲到总线的时候讲到和已有的系统如何衔接，这里有一个特定的技术来支撑。适配器的技术分两部分，一部分用连接已有的系统，可以由ERP提供的APR衔接。另外一个层面要游服务的展现方式，在这个中间可能考虑一些安全、连接管理的问题、效率的问题。
　　也会提供一些标准的服务，这些是为了更好的使用系统，比如用户的管理、日志的服务，也会提供一些安全服务，这些有可能有底层的安全服务，比如签名、验证这些服务，也有高层的安全服务，比如统一的身份证认证、单点登录等等。我们主要考虑为数据整合提供更容易的高层服务，比如数据的提取、交换、集成的服务。以统一的方式来对数据集成的功能提供更方便的应用。
　　对这个架构说，还有一个很重要的工具就是监控管理，这个中间我们分成两大块，一个是展现一个是管理，我们也对被管理对象进行定义，可以进行分类，管理不同的对象，对每个对象有不同的管理操作。管理对象可以是一些物理性的结点或者服务总线，也可以是业务的服务。建模管理工具也可以包括第三方的共聚和服务消费者都可以使用运行管理工具提供的功能。刚才举的例子，比如说一个服务消费者有可能根据你提供服务运行的质量选择，比如服务相应时间在两秒内。
　　最后看一下参考架构如何部署和运行，总体来说分成三大块，一个是设计阶段，主要是说开发阶段使用的，支持不同的角色的工作，这些不同的角色可以在一个统一的资源库的环境下实现团队的开发。第二个环境是实际运行环境，有若干实际的结点，这些结点可以在局域网内，也可以在广域网运行的环境。相关的运行时的组建、服务的标准都可以部署在不同的结点，把结点组件在一起。最后是运行管理的部分，管理可以是技术的管理员也可以是业务管理员，可以从全局角度管理，也可以局部的某一个结点的管理员，只需要管理关心的内容。
　　下面我们看一下SOA的模式下的应用开发和传统应用开发之间有什么细微的差别，对于软件系统开发来说，都是按照这样的过程，分析、涉及、调试、部署，现在这个架构可以很好的支撑这个开发模型。角色有可能很传统的应用开发角色会有略微的差别，这个差别有可能体现在服务组装的工程师，因为也是为了体现快速开发的需求，有可能已经有很多的标准服务，这时候需要把服务整合在一起，需要游服务组装的工程师，把这些服务组合在一起，或者定一个流程把若干服务之间通过流程线联结在一起，所以有服务组装的工程师。
　　整个开发过程中有两个点显得比较重要，一个是业务建模，如果有了业务建模工具，就更容易从业务角度描述业务服务，有可能需要描述数据、流程也有可能描述企业的组织架构。另外很重要的是会提供一些模拟的工具，有可能是从业务过程中提供，也有可能需要在开发过程中的工具。比如是不是有效、是不是正确的调动相关服务，需要一些模拟测试的工具支撑开发的过程，你实现一个服务的时候，有可能你需要的服务没有，也需要一个模拟的服务支撑整个调试的过程。
　　最后我们以一个简单的事例看一下，按照这样的架构设计出的工具如何建立一个业务系统，我们假设这样一个案例，有一部分数据是存放在舍车，比如建设流动人口的管理，实际的管理地方可能是社区，通过租房的情况监控流动人口的信息。这时候想实现流动人口统一的管理，需要把相关数据抽取到综合的库里，假设从社区的数据库获取数据，进行加工处理，最后到综合数据库，这时候可能建立三个基本服务，一个是数据提取、一个是数据入库还有数据加工处理的服务。在这基础上可能形成一个合成的服务，有可能提供给公务人员使用，比如展现到网站上，通过点击实现社区库中到综合库中。
　　首先需要一个基本的工具支撑对数据库的管理，有了这个工具可以通过简单的配制和数据苦挂接在一起，我们可以工具获取数据库的信息，比如可以看到把数据库的相关信息提取出来，在这个基础上要定义一个服务，有可能起一个名字，也可能去定义它的方法，服务是提取数据还是把数据插入到数据库里，所以要定义一个操作方法，还需要定义操作的数据对象有了这些东西之后还可以定义一些数据，比如是人工操作还是定时运行。用另外一个工具提供JAVA的服务，实现一些数据加工的处理，因为我们数据加工可以简单的工具定义，对复杂的数据加工处理也需要通过编程的工作做，所以我们需要工具定义好，之后可以形成代码的框架，需要在框架里填写数据加工处理的实现代码。有了基本服务以后，需要创造一个合成服务，对于合成服务就可以通过拖拉的方式拖到框架中，也可以起一个名称，封装成更大颗粒的服务发表出来。同时需要把已有的服务和实际的外系统建立对应关系，也可以通过拖拉建立。
　　这些工作相当于你的开发过程，你要把这个过程通过调试部署到实际的环境中，这时候有可能定义一个环境，可能定义若干个结点，每个节点IP地址的信息，需要把相关的服务托拉到结点上去，相当于把服务部署到某个节点上。最后的工作就是部署，运行起来提供一些工具监控整个系统的运行，这时候需要从不同角度进行监控管理，有可能从物理结点的角度看，某一个结点的运行情况，也有可能从项目的角度看业务服务的运行情况，这时候可以通过不同的视角来看，可以对监控的对象进行察看和管理，比如说监控的时候可以看到运行状态，可以起动、停止这个服务，或者可以运行到某一个业务过程终止这个服务，我的介绍就到这里，谢谢大家。