SOA的一些联想

昨个下午获得一些新的启发，在本子上略微画了几笔，是关于SOA，面向服务架构的方面。

以前，自己曾就BI趋势谈了一些观点，提到实时性、嵌入性。现在想想，这个嵌入性其实就是一种"服务"。在SOA里面，我想最主要的特点恐怕有两点。一是整个系统中每个功能都可以以服务的形式出现，有标准的输入、输出接口。（甚至作为一种"服务"存在，是至少有一些共通的接口的）。每种服务提供单一的功能，这符合"高内聚"的设计思想。而另一个特点，是有一个代理，英文叫做broker，不是proxy。这相当于一个注册机构，所有的服务都在这里登记，通过它来转发对服务的请求。这符合"低耦合"的设计思想。

如此边联想到BI系统中应用SOA架构的情景。通常说的ETL、数据质量、元数据管理、分析、数据提取，甚至是数据存储，是不是都能够以"服务"的形式出现？

说到这里，我觉得"服务"这个词是个不太确定的名词，有些滥用而让人不知其本意。因此想在此处给出一个稍微明确的定义，当然是自己的理解和表达——"提供单一功能的自动化模块"。通过这个定义，将它和我们平时在餐馆吃饭时，或是打电话给客服时享受的"服务"区别开来。此处说得时一种自动化的东西，而非人工。而定义中的"单一功能"，仍然是一个模糊的名词，什么程度是单一的？可能这个"单一"指的是"相类似"，但现在恐怕只能想到这样的表达方式，暂且如此吧。

放到BI系统中，ETL是一块相类似的功能，可以作为一种服务。但显然，如果去规定其标准的输入输出，却并非易事。即便标准化了，恐怕出于性能、数据质量原因。例如为一个"ETL Job"服务，输入是数据源、目标数据、转换规则的元数据，输出是运行信息等。并且可以将这个服务登记到另一个"ETL调度"服务，让他受其他Job的约束，或者影响其他Job。

这里就碰到问题了。将单个的ETL处理过程和流程调度分成两个服务，从结构上看，确实是种比较好的思路。但一般来说，如果我们在项目中使用工具，这两者都给包了。如果这个工具提供开放的接口，我们还可以将这两者分成两个服务。但如果接口不够开放，那就不能区分。而只能将整个ETL处理看作一个黑盒子，中间过程是不受控的。

前两天，chenming提到的数据挖掘算法，看上去到的确可以作为一种服务，符合功能单一的特点。不过那也是在一个挖掘工具产品中充当服务，而非在BI系统中的服务。挖掘算法是在开发时用的，运行时这个服务应当是挖掘模型。例如最近我们做一个分析模型，就是一个非常典型的服务。它能够提供一种对客户最适合套餐的推荐——"你提供一个用户号码，我告诉你它适合什么套餐"，很明确，很直观。

恐怕是因为这是个应用层的服务，所以更加明确、直观一点。对于底层数据层面的，诸如ETL、数据质量、元数据管理等等，将他们看作一种服务，还是有些模糊。需要时间去将他们的职责分清楚，本身SOA架构也不是非常成熟的东西。但这种面向服务的思路却并非什么新玩意儿。Corba、J2EE、Web Service都是基于这种思想的。可以肯定地说，未来BI系统的架构，也必然基于这种思想。

或多或少地，即便在现在的架构中，也会用到面向服务的思想，只是可能没有将它放在最上层的架构，或者没有表达成面向服务罢。譬如原来我提到嵌入性，也就是将分析功能当作一种服务存在的。

Jeasonzhao 20060622

SOA难控制在于 服务之间的关联关系和服务授权

刘庆 20060622

"SOA难控制在于 服务之间的关联关系和服务授权"，这句话能进一步解释一下吗？

现在在数据仓库系统中提SOA很是热闹，用google搜了这两个关键词。最近的新闻是06年5月19日，ncr组织了一帮人在三亚腐败，顺便忽悠了一把，提到了SOA。他们的技术头目叫做阿宝。

从报道上摘出ncr对SOA的看法，基本上是这样的：

SOA能够帮助企业实现低成本高效率，更快地把决策流程和交易服务以及其他各种流程结合起来。此外，在性能特性上，传统的数据挖掘做法中，通过记分和批处理的手段，当天的数据要到第二天才可以获得，但是通过SOA，就能实时或者说是准实时地获取数据，这是一种完全实时动态的处理过程。企业可以根据客户行为的变化，特别是客户在不同时段的行为，把这些变化的数据实时记录下来，然后进行评估和分析，供企业做出最及时、最快速的决策。

这段话能看出啥来？有些莫名。似乎SOA就是为了解决实时分析、决策之用的。可我想，这只是一种期望吧，其实要达到实时的目的，未必需要SOA。而他的好处恐怕还有一点，在于能够让整个IT环境中的各个系统可控。

当然，开会的时候发言就得说得如此虚。昨天收到一篇文章，介绍如何抵挡开会时不可抑制的睡欲。

可以尝试如下步骤：

1、准备一张方形的纸，用笔在上面画成25个方格，横向5栏，纵向5栏；

2、在每个方格中填一个词，诸如协同、战略、与时俱进、我告诉你、创新、以客户为中心....等等；

3、开会时，当听到发言者说到上面25个词中间的任何一个，就将相应的方格图黑；

4、当纸上有5个图黑的方格连成一线（可以是横着、竖着或对角线的5格），就站起来大叫一声，"bullshit"。因为这是从国外文章翻译过来的，这个bullshit不符合中国人的习惯，叫出来人家还以为是"不谢"呢。因此，在中国，可以尝试大叫一声，"好"。

阿龙立即尝试了一把，据说效果不错。不过在开类似上面ncr那种忽悠大会，你得将那25个词改一下。可以是决策、分析、实时（准实时）、数据仓库、商务智能、平台、动态、闭环反馈、业务流程、客户服务、激烈市场竞争、合作伙伴、战略、元数据、数据质量、数据挖掘、最领先的、total solution、全面的、创新的、开放式、投资回报、架构、客户细分（市场细分）、信息整合。

Goldenfish3 20060622

就NCR的那套说辞，其实也没错。

"SOA能够帮助企业实现低成本高效率，更快地把决策流程和交易服务以及其他各种流程结合起来。

此外，在性能特性上，传统的数据挖掘做法中，通过记分和批处理的手段，当天的数据要到第二天才可以获得，但是通过SOA，就能实时或者说是准实时地获取数据，这是一种完全实时动态的处理过程。企业可以根据客户行为的变化，特别是客户在不同时段的行为，把这些变化的数据实时记录下来，然后进行评估和分析，供企业做出最及时、最快速的决策。 "

它第一句应该就表达了“在于能够让整个IT环境中的各个系统可控”这种含义。

对于DW这种以批处理为主的模式中揉进SOA，是希望解决两方面的问题：

1.实时的数据处理，即业务系统实时变动的数据如何加入DW，DW实时处理出分析结果；

2.业务流程整合。

对于实时的数据处理，就是这段话中“通过SOA，就能实时或者说是准实时地获取数据，这是一种完全实时动态的处理过程......做出最及时、最快速的决策”所说的内容。但DW既然是以批处理为主体架构，揉进实时的东西，如何做？有两种可能：

1.实时数据反映在ODS，ODS实时反映给集市到BI应用，但从ODS到仓库，仍是保留批处理；这种做法比较符合常理。

2.全DW体系都改为实时，则不可避免出现以SOA方式替代批处理的ETL，变成基于消息的实时ETL。这个说法就有点古怪了，动摇了原来DW处理的根基。 这种做法太夸张了，效率未必能达到批的要求。

以前只有BI产品提过实时BI的说法。DW也提实时，倒是顺应潮流。

对于业务流程整合，在DW中就更古怪了，DW本来是做数据处理的，本来就没有交易系统那种业务流程的概念。除非DW上支持的分析应用还要返回业务系统，正如很多用户面临的问题，分析型CRM的结果不能方便的返回操作型CRM。但这似乎已经超出了DW的范围。

刘庆 20060623

对于ncr、ibm、bo这些主流BI大厂来说，都在嚷着soa，不用想，这在未来几年会是趋势的。

我想从目前的dw架构往soa架构发展，有点类似从面向过程到面向对象的发展，不是一种颠覆，只是一种进化而已。面向过程的思想，重内部流程；面向对象，将接口和实现分离，重对象的封装。soa也是如此，每个服务的的接口和实现是分离的。所谓接口，就是要告诉消费者，是这个服务能够干什么，不能干什么。现在各种应用架构都是这样的模式，如j2ee、corba、dcom以及web service都是如此。

goldenfish提到，在交易系统中，因为业务流程是明显的，采用soa似乎还比较好理解。但在dw中，对于批量数据处理也采用soa，比较难以理解。我也有同感，但觉得问题不应该是在是实时或批量处理的区别上，还是在于"流程"。在dw中，并非没有流程，而是目前没有形成清晰的流程，或者说是这些流程变动频繁。在一个交易系统中，可以根据流程清晰界定出参与方，每个参与方发起的行为，这些行为就可以形成一种服务。对于dw系统，这些流程的不清晰，例如如何分析客户，看起来有无数种分析思路（无数种，其实也就是无）。因此，也无法界定哪些服务，譬如有的服务专门用来给客户打分，或者得到一批目标营销号码。

这又像是社会分工，大家都知道社会分工是越来越细的。早先一个公司一个人可以从谈合同，到最后系统维护，将需求、设计、编码、测试维护都包了。以前家里盖房子，也是十几个人的包工队，也不用图纸，三四个月就砌起两层小楼。不过要作大项目，盖大厦，恐怕就得分工明细一点。端茶倒水可能都得有个专门的人来做。

从粗放到精细，也得有过程的。

即便你现在国内一个BI项目硬上soa架构，恐怕效果也不好。就拿最近几个月的项目来说。涉及到和其他分析人员的接口，需要向他们提供数据，也从他们那里拿到反馈数据。按照我们预想的，希望能够将这些接口标准化，因此早早写在了需求书中，并且也设计出一些评估报表。但到了实际工作过程中，这些接口内容总是要变动的，譬如字段信息不够，需要增加一些新的字段。甚至是根本就不按照接口规范来，或者打了个电话，然后通过mail就将数据发过来。如此，怎能够让整个流程顺畅起来？

假设此时我们用的是soa架构。可以认为我们向外提供数据接口是一种服务，这项服务可能接受客户若干输入数据。实现，我们已经将接口的信息都注册到broker中，如果接口都是稳定的（或是比较稳定的），到还好。可他们就是一直在变化的。每次变化之后，都修改注册信息？那岂不是累死人？

呵呵，soa确实是个好东西，对于架构者来说。它能够让整个系统可控，管理的井井有条。但也像管理制度一样，对管理者方便了，恐怕被管理者就要受点罪。至少在一些支持手段跟不上的情况下是如此。比如从上个月开始，去客户这边要严格登记，临时出入证又迟迟办不好，因此只有每天早上在他们的登记册上练练书法了。软件架构也是一样，例如在访问数据库的环节，经常会设计一个持久层。将关系数据库的一个表映射成对象语言中的一个类，字段映射成属性，并且有删除、增加、查找记录的方法。干这活可没什么创造性，人工地映射会累死人。得有个工具来自动生成这些对象，并且还能与库表的变化同步才行。你要是没这个工具，程序员就会选择最直接的访问数据库方法，绕开你的持久层。

看来对于管理、架构这种高层的东西，有了制度、原则还不行，要落地执行还得有配套措施。