【IT168 信息化】

    我们回头看一下，在这三个典型应用场景里面我们发现要解决的问题是非常有挑战性的，如何去实现一个大型企业里面将所有的应用都通过模块的方法搭建出来？我看到的不是ABCD的应用，而是几千上万个模块，并且模块很容易被管理起来，为了应对敏捷度实现快速的业务交付，我们希望由客户或者业务方直接去定制业务，因此我们需要提供客户定制的能力。最终我们会发现，现有的事件里面有大量的服务，我们会发现在网站上面有一系列支付的相关服务，我们如何将现有的服务能够快速编制，形成新的服务，以服务的形式交付呢？面临很大的挑战就是，我们需要什么样的架构去解决这样的问题。所以我今天给大家带来了一个很关键的问题，就是我们在这种形态下面需要什么样的技术架构。

    我们看整个技术架构的时候，做一个架构的评估。片子里面我们可以看到早期系统里面有主机，或者是我们会看到客户服务器的这种体系结构，或者是客户服务器的一个变量。但是我们发现一个很重要的特点，客户服务器里面很好的解决逻辑和数据分流的问题，并且通过接口的编程实现了模块的结果。但是我们发现面临很大的挑战，这种大量的应用时候都会面临很大的问题，就是应用系统很多孤岛。而对于这些孤岛我们怎么办？我们会发现通常意义上面会成为ESB的这种技术来解决这个问题，但是可能在座的有很多技术人员，大家也有人实施过。我们发现作为一个EI实施的时候，甚至比做原来的服务花的代价更大，那我们怎么办？这是什么原因？因为我们原来所有的架构都面临着这种单一应用去考虑这个问题。因此回顾一下我们很重要的特征就是，我们现在企业已经从单应用架构走向了多应用架构体系，而在多应用架构演进里面，我们希望现在的大系统都不是从原来的模式里面建一个大而全的。比如我们很实际一点，像电信运营商，他们希望在原来巨大的架构下分解成下的架构实施。或者我们在银行发现，建设企业应用的时候，我们真正用模型的方法拆分出来，所以我们要给用户一个非常好的统一的视角。使得我们只有在这种架构里面，开发的时候就考虑了技术问题，而不是等我做完了，然后说我要做一个EI，把我的业务通过服务的方法，通过界面的方法表现出去，这样的话你的代价成本是极其高昂的，需要一个天然具有集成能力的应用体系结构。但是基于现有的应用体系结构里面会有什么样的技术特征？Garther当中有五个关键的技术特征，分布式部署、模块化、服务和客户端、可共享与管理，文档接口风格。我下面会针对这五种技术特征阐述一下整个架构的内容。

    在分布式部署模式里面，我们很重要的希望解决One应用的问题，我们以前做的大量的应用系统里面都是一个系统里面包含了所有应用的模块，我们会发现一个很重要的问题，最简单的问题，如果发现我里面有一个特别重的操作，比如一个报表，我里面一个报表的操作访问量非常少。在这种情况下我们面临很大的挑战是什么呢？我会需要一种一堆的机器解决。所以我们可以看到，像e-Bay和淘宝，他在进行集群当中，我们很容易看到已经非常成熟了。很重要的一个特征就是我们希望逻辑本身是横向可以伸缩的，比如说把报表那一小块功能，在部署里面统一部署，只留了一种机器专门解决报表的问题，进行系统的开销和访问。这样的话我们需要应用架构设计的时候，就需要考虑能不能够随时的将一组功能模块随时的拆除、独立部署出来。还有一个很重要的关键概念，我们会发现因为互联网的应用，我会发现我们的客户数据是海量的，你有没有能力将我们的数据从单一的数据库走向分离的数据部署模型？所以我们可以看到，现在有很多应用架构可以解决很多的问题，我们可以看到基于数据，比如电信的系统里面，可以针对本地接入号的区号来决定数据库在哪儿，容易根据区号的方式，注入到我们访问的逻辑里面去。这样的话对于我们的业务来说表现是一样的，但是本身很容易体现到分布式的部署，这是我们在分布式部署当中考虑的问题。

    然后我们看一下第二点，我们要解决模块化的问题，我们模块化谈了几十年了，只要做计算机的人都说，这模块化我们读书的时候天天都在讲，但是我们发现一个很重要的概念，就是模块化真正能不能做到独立部署，可插拔呢？能不能把你的应用系统的某一个模块拿出来，使得系统能够正常运行？你会面临很大的挑战。因此我们看到，一个非常经典的模块化的设计，它应用了这种技术很好的去解决了每一个软件模块的加载、启动的过程。并且很容易的通过应用的实现，业务进行伸缩灵活的变化。比如普元我们的开发工具需要在上面加注一项对于我来说，只要有一个插件进去，因为我在这个里面有了这个业务以后，很容易的去实现插拔的效应。但是对于我们的企业应用来说有同样的道理，比如我们在数据访问的时候，希望通过组织机构进行数据的过滤，有没有能力很容易的纠正一个插件，我整个数据过滤的方法和内容呢？这就需要我们整个架构里面去考虑这种业务点，很容易被插拔的，这是我们解决模块化一个很重要的技术和特征。

    然后我们可以看到，要解决我们企业业务之间的收入问题，我们会发现不要直接访问别人系统的数据，那是标准的设计语言，只有一种方法才能保证对方的业务变化不会影响自己。并且这样还可以很好的提高高可用的问题，但是在SOA时代里面是怎么回事呢？实际上并不像大家以前想的那种特征，我们还会有新的元素，我希望客户访问我们服务的时候，他随着部署的位置自动的调用模型，在北京调用的时候对于这种来说怎么办？肯定是希望在你的架构设计里面就已经考虑了位置的问题。所以我们回头看一下，只有这种方法才能很好的去解决模块双耦合的问题。

    所以我们再往下看具体的第三个特征的时候，就是服务的共享，我们可以看到Garther对于一个服务具体的定义的时候，我们发现现有三种形式的SOA服务应用，第一种的服务是怎么做的？70%的服务是已经有了，我只是有30%通过组合的方法利用。还有一种方式就是只要把系统包装出来变成服务，还有第三种就是全新的开发。但是我们回头看一下，对于上面这三种类型服务的时候，我如何实现共享呢？第一种就是服务的组装，第二种就是服务的编制，具体的服务组装我们可以看到，在服务组装里面我们描述了构件之间的关系，我如何去描述两个构件之间如何形成一个他们之间的依赖关系，然后再包装起来形成一个更大力度的构件呢？形成更大力度的构件还需要以不同的形式暴露出去，这是在我们产品里面一个很重要的特征，就是引入了SOA的技术规范，描述了构件之间的理论关系，描述了小颗粒构件变成大颗粒构件的模式。还能够解决我们支持服务方式的调用，但是在这个图里面很技术化，看不懂，因为服务组装是解决具体的实际问题，给大家看一下，服务组装是解决了为已有服务提供的基础，我们具体如何去提供服务基础呢？可以参考一下，我们看看具体的设计方式。在Java时代里面，很好的解决了两者之间的关系，以及很容易解决双耦合的问题。它需要解决这一块的实现是什么，属性是什么，引用的对象名称是什么，通过这种方法就很好的解决了Java时代里面的各种方法。但是我们会发现在SOA时代里面，上述的问题是不能够解决所有的场景的，使得你的变成更加的透明，但是在SOA时代里面我们会发现，很实际，你的Java不能解决任何的问题，我会发现调用的方法形式是不一样的，因此很容易的去引入不同的协议，在这一套模型当中加入了协议。还有我们的实现也有特殊的，我的实现并不止是Java，因此我们回头看一下，在SOA的时代里面，SCA就像一个SOA时代的Spring，所以给大家阐述的就是，SOA时代里面你的服务组装是用这种全新的架构模型装起来的，很容易将现有的服务组装出来。

    我们会看到一个很重要的概念，将现有的服务暴露出去以后，还需要有更快捷的服务附用模式，我们在现有应用系统里面服务重新打包编制起来，我们用流程的方法。可以将一些很多无编制的服务变成有编制的服务，并且串在一起。而流程本身编排出来的结果也是服务，因此在我们系统里面，我们对流程里面还会有更多的体验，来解决人的业务流程的处理，还有解决业务模型的处理，在后续我们的演示里面会给大家看到如何编制这一方面的内容。

    通过这种方法，使得我们的服务能够快速的定制，因为是图形化，可以使得服务快速的实施，所以服务编制提供了基础。而我们刚才提到了还有一点，就是我的接口是希望文档风格的接口，我们以前在面向对象模型的时候，大家会提到那里面希望我的数据和对象是一体的，你的数据和风险和企业行为在一起的，需要给你一个非常一致统一的数据业务定义，使得你很清晰的知道对方需要什么样的数据，而他具体操作行为里面内容是不用关注的。所以我们会给他提供一种文档结构风格的接口，而这种接口里面还有一个很重要的概念，就是接口的灵活性。因为数据定义本身就是伸缩的，如何解决伸缩的问题？因此在这一点我们引入了关键的标准，就是SBO，它帮助你很好的解决了跨语言的定义。不同的系统里面之间，大家用统一的数据定义，然后因为有动态和静态的接口，使得我的数据很容易去伸缩。在一个对象里面额外增加一个属性怎么办？SBO里面很容易解决动态的属性问题，还提供了统一的数据导向，使得这种技术实现了数据的读取和访问的方法。并且通过标准的数据序列化的方式，使得在这个平台里面进行数据的交付，很容易将SBO对象展示，这个是这种风格接口的技术特征。

    因为有了以上几个关键的技术特征之后，因此我们普元在整个SOA的技术架构，就是围绕解决这五个标准技术特征实现的。前面也提到过，在上一个时代里面大家提到的都是MAC，给大家一个标准的编程模型，可以实现界面和逻辑的问题，因此在SOA架构里面，我们可以看到最下面的就是资源层，提供统一的数据访问，我们会使用SBO的规范，我们还会有一层逻辑层，逻辑层很好的去解决了逻辑的编制，提供了多种实现，并且可以实现可插拔。通过构件的容器，对于这种扩充点的支持，很容易使我的构件插拔进去，并且通过短流程的方法使得我快速的编程。有了逻辑的具体实践之后，上面就是这种形态，很容易的告诉我，如果去解决外部访问的时候，给你一个标准的访问单位，并且解决了服务注册的路由等等一系列的问题，很好的解决了服务的包装形态。在这一层我们很欣喜的看到，再下面告诉大家就是服务的提供者。它提供的服务，上面就是服务的消费，这边有一个流程图，我们有一个BPM的产品，我们解决了统一的任务中心，使得业务流程被管理起来，我们最终流程的消费是需要通过人的方法去把业务实施起来，因此最终的这一层实际上是协同，它最终解决了人、流程、信息之间的这种协同交互的过程，我们会通过这种方法，不同的接入形式，使得我们接入的方式非常丰富，并且很好的满足了我们业务的需求。而里面会有一系列的规范，使得界面的风格各方面都是统一的，这就是我们普元SOA整个技术架构，通过这些技术架构，最终支持了One应用，支持了快速业务的交付和快速业务的定制。而我们最终落实到具体的里面，我们会通过两个产品来支撑我们整个SOA的中间件内容。

    下面就是BPS6.0，解决了SOA应用的平台，为快速的服务构造提供了稳定的运营和开发的平台，还会有一个SOA的流程平台，很好的解决了中国特色业务流程，并且通过业务的定制能力实现了快速业务的定制。