这些Service有些是需要重新开发的，有些是原有的，有些是原有东西基础上组合起来，东西会映射到原有的环境里面，我们有MS，有J2EE等等，我怎么去做。不同的边界都有技术的边界，都是刚性的，为了打破这些刚性的边界，首先需要提供标准化描述的接口，通过XML，通过Service描述形成的世界。
我们刚刚提到的WCF，还是J2EE等等这些东西，把这些不同的块黏结在一起。
接下来我们要看一些例子，大家可以看一下我们是怎么做的。
这个实际上是我们在给三星做的，整个这个工程里面一小部分，是韩国三星总部做的，就是给三星CTU的报告其中一小部分。
首先是一个背景的分析，我们肯定整个是关于它的销售管理的系统，跟客户关系管理和销售方面的东西。
我们看得到现有的系统状况是这样的，有一些老系统，有些是靠人相互打交道做完的。我们也会看到有BA的东西，也有IBM的东西，还有一些主机的做法。现在的做法有很多人和人之间靠邮件的传递来做的，他们希望能够将这样一个过程改变成端到端整合起来的东西，最关键是希望所有应用里面，现在被这些应用竞合的功能和数据变成一个成文的东西。
做这个事情，你会发现对原有的系统进行改变，这些是相关的数据和接口的调用，这就是现有系统之间的关系。即便它现在没有端到端，也是用这样的方式做起来了。实际上它再这样继续下去是很痛苦的一件事情。
我们怎么做的呢？基本上这是一个部署图，事实上在这个地方我们是这样的做法，首先这是它应用，基于甲骨文数据库做的东西，估计老一代的程序员对这个都很熟。然后就是用ASP ，他们用的是甲骨文的数据库，然后是J2EE，我们不希望用以前的这些老东西，所以我们帮他们开发了一些新的东西，它用ASP做的，没有什么MVC，一个结合没有，都是乱成一团的东西。所以我们事实上提供了大家看到的，在这个基础上提供了一些必须的东西，把他们接进来，然后将这里面的数据和能力接出来，然后在借助于IBMWBIS/F的能力把它们暴露出来的。
做法是非常简单的，我们做一个业务层次的建模，做一些粗粒度的服务出来，有数据相关的服务，有业务应用和处理相关的服务。
紧接着粗粒度业务层次的东西转化为Service的描述和DB的描述，当然也有工具来做这个事情。在具体做服务的分析和标识的时候，其实是一系统化的工程，有一套方法叫索马，今天是没有太多的时间去讲这个东西。这个是我们看到的一些DOWN。首先我们有一些标识服务的方法，需要Botton-up，为什么需要这个呢？因为很多业务人员不知道什么是这个，需要你按着那个一个一个给他描述，这个是不是，这个是不是，所以我们要了解相关过程数据是上来的。然后是一个校验的过程，我们要看这个服务是不是有必要，力度是不是合适的时候，其实有一些有趣的标准，我们找到了一个比较好的做法，这些事情跟具体的业务指标和业务目的是不是相关联，比如说你可以去问，今年这个企业有一个很大的目的是希望业务利润提升5%，我的成本下降2%。那你去看利润提升的指标和 成本下降的指标，去跟这些服务或者跟这些业务的过程联系起来的时候，有些东西是完全没有关系的。这些东西大多都不是合格的服务。
做完分析之后，我们想办法用业务的语言把这个服务描述出来，并将它转化为XML描述。同时会考虑用VS描述跟这个业务相关的业务规则，业务相约，包括安全方面的要求等非功能的要求，包括一些性能等等的要求。
然后会进入到服务实现决策层次。 你看得到，高层的工作做完以后，就映射到传统的J2EE里面，你可以看到ESB没有一些若干的项目，这是我们新建的Service，所以创建了J2EE的插件，这个东西是跟已有的数据库，跟SGDP跟原有的数据打交道，让应用做一些事情。
也有一些技术层次被贡献的，有时候我们叫它Service，你不管它叫Service也没有关系。你可以看到高层的时候，这边是用PS将来自这个世界和这个世界的东西结合在一起，还有网络服务。这些东西用BQ连接起来。
你到了这个地方以后就跟传统的东西没有什么区别了。
这个是我们的物理部署。
表面上它只是做了一个流程，在这个流程里面所做的服务，在做别的流程都可以用的，比如说这个我增加一个CM系统就比较容易重新组装，如果做SOA的事情，这个就少了。
这个就是我们做完了以后，利用VS的编写，WDN来看运行的业务流程，以及一些实例，以及通过这些实例找到的KPI。
这个就是当时我们跟他们的业务人员，IT团队和业务团队一起做这个事情，所以你可以看到，不同的系统提供不同的能力，然后这些能力通过CP和ESR曝露出来的。这个能不能成为一个服务，是通过服务的建模分析来决定的。
这个是我们在三星所做的。
我们还可以看一下在中远集运所做的。中远集运的问题就比较多一些，它有很多的VIP的系统和要求，还有在美国等等全球的点，每个点都有很多的应用，通过EDI的平台，传递这些电子商务的数据，主要是这些客户希望透过这样的一个平台来做什么呢？来要求定集装箱的仓位，改变运货时间等等。这需要通过改变订单和EDI调整这些事情。它的分支部门还有一个很重要的事情，就是报关，报关压力很大，美国911之后，就是24小时报关，你这个东西要在美国卸下来，必须在48小时把报关手续拿下来，否则就不得靠近海岸，这样对远程航运公司就麻烦了，多在海上待一个小时，损失就大了。而且有些客户经常提要求，改的地方非常多，这是很可怕的事情。
但是现有的系统是很乱的，总部用了24个小系统来处理这些事情，加上外面的东西，怎么样将所有的应用放在一起，形成一个富有弹性，同时又端到端连在一起的这样一个东西，对于VIP变来变去的要求，对于各种各样法律上的变动、口岸的变动，怎么去处理它，我们做了一些东西。我们从业务角度分析了一些USKS。
所以我们建立了一些业务场景，做了分析以后，我们对它现有的IT也做了分析。我们发现一个客户的订单跑了很远，牵涉到很多的系统，这是海关的系统，这是税务的系统，这是重要客户的系统，这是后面核心的业务系统等等。所以这个单有很多的问题，我们有一些策略。
在这个开发过程中这个地方可以提的一点，SOA特别适合敏捷软件的开发，当你用SOA方式构造一个系统的时候，它其实给了你一个特别好的机会。起码在中远集运这个地方，过去的开发模式比较多的是初步的模型，所以我们跟他们讲，我们用敏捷的方法来做，实际上是高力度的一个开发部门，这对他们的IT部门也是一个很好的事情。
事实上我们当时的分析和设计过程是什么样的呢？前面都是给大家一个高层的算下来。你发现我们对它整体的业务过程，先从这个大的业务过程，SHIPMENT，这是一个比较大的，然后对它进行分解成业务人员能够理解的过程和活动，这个过程是我们跟他们的业务人员一起做的。在这个过程中其实并不轻松，因为做这些事情不能完全依赖业务人员来做的，因为业务人员没有这个概念，搞的很乱，如果你按六西格玛的一些规则来看，其实有些业务人员的做法是错的，所以我们不能完全按照他的方法来做的。这些是我们通常做一个应用的时候眼睛都集中在一些细腻的USKS。
这边是非常粗粒度的，这只是我们开发的一个工具，你们可以用你们的工具，这边是细粒度的USKS，这个更多是技术层面的，功能层次上的，实现层次的，这个是业务层次上的，粗粒度的，你发现它有一个组合的关系，这边的小点就是细粒度的组建能力。所以我们谈的不仅仅是业务上的粗粒度的能力，也存在一些技术世界上细粒度的组件等等，对粗粒度的服务共享到什么层次。这两个层次都打通了，这个SOA就有点意思了，不是只开发一个VS就可以了。
1
