朝晖

引子：

伴随福特流水线模式的百周年，回顾软件业也已经走了近四十年的光景。而全球软件行业似乎已进入到了中年期，成熟的商业模式，缺乏雨后春笋般的创新型小公司，大公司增长乏力进而带来诸多的并购等。这些都让我们感受到软件行业早已今非昔比，大部分的软件公司都变成了鸡肋。软件从业人员也都从梦想的憧憬回到了实际的运营成本控制中。即使近几年炒得火热的SOA也无法为软件公司带来多少的利润和股价提升。难道软件业真的就这样了，还是在等待新的一次飞跃？

我们小时候都读过这段“生产力的提高会促进生产关系的改变，而生产关系的改变又会反过来促进生产力的发展”，所以我们看待软件业的未来发展还得要从最为本质的提升软件生产力和改变生产关系入手。

构件化通过模块化、层次化和专业化，质变软件生产力

工业化相比较之前的生产方式，给了社会生产力质的提高，而福特的流水线模式正是工业化的代表作。这让我们清晰地看到对于复杂业务的高效处理方式，就是通过层次化设计和模块化分工把复杂的问题分层和模块分解，然后通过‘流水线’协同的方式再层层组合，完成整体的任务。而处于某个层面的被分解的模块，就会有相应领域的专业份子来解决，这个模块又可以再继续递归细分到更小的模块来分解问题。这样某个层面的模块就可以专注于自己所处的相对环境和自身的目标问题。这种模式从本质上改变了模块之间的生产关系，专业化解决相对的问题，从整体提升了解决问题的能力，尤其是解决复杂问题的整体能力。

由此，我们要提升我们的业务和管理生产力就得从此着手，软件世界中的构件化（Componentization）正承担了这一使命。原来的应用系统则不断地被构件化所打破，企业逐渐走上‘一个应用’的进阶。企业渐渐不再有固定的应用系统，取而代之的是处于各个层面的模块构件来实现某个层面的相应功能。下图是构件化企业应用的一个范例。

企业应用通过底层的技术构件来作为实现应用的基础技术功能，技术构件的适用性往往是最为广泛和跨行业的，在各种应用中都会被高度复用。而再上一层的则是企业根据业务总体模型设计出来或是在不断的应用项目实践中不断提炼归纳出来的某个业务或是管理域的业务构件，这些业务构件往往是企业最为重要的资产和竞争能力。有了这些业务构件，企业就可以根据具体要实现的业务和管理流程，组成具体的应用实现，满足业务的需求。

业务构件化和技术构件化的逻辑模式首先让企业可以开始不断规划设计、项目积累和梳理回归不同层次上的技术构件、业务构件和业务流程，通过专业化分工和流程协同达到组织级能力的提升。并且在此过程中和基础上可以更为精细化地运营和管理。企业根据需要灵活注入对于业务和技术构件的管控和治理策略，从而找到自身的核心能力模块，找到自身的高利润业务职能模块。进而不断投入、扩展和优化自身的核心优势能力，限制、调整和外包自身的劣势能力，达到不断提升企业整体竞争能力和赢利能力的目的。

构件化通过模块化和层次化，梳理优化生产关系；通过专业化和流程协同提升组织级生产力。

SOA通过构件标准化和服务契约化，推进软件生产力

构件化在不同的技术背景和时代有着不同的能力表现，在SOA到来之前构件化只能有效实现技术层面的模块化、层次化和专业化的能力水平。而SOA时代则真正带来了业务和管理的模块化、层次化和专业化。下图就是SOA编程模型SCA中定义的标准原子构件。

很显然它的技术无关性和消费使用（Consume）特征，如：服务、引用、属性、实现，是实现业务构件化的关键所在。原子构件就可以是一个事实上的业务构件，当然也可以在原子构件的基础上进行业务组装形成更大粒度的组合构件（Composite）。进而若干个组合构件和资源配置文件形成构件包（Contribution），成为独立可部署的业务功能模块。业务功能模块有了SOA标准下的逻辑构件形态和物理构件形态后，就可开发、可部署、可运行和可管理了，也就真正实现了标准的业务构件化。

下图是一个构件化SOA应用的范例。

由业务模块形成的标准化构件（Component/Composite）实现各自分工的业务功能，并通过契约化的SOA服务和引用互相协作，从而实现了一个典型场景下的业务应用。这样构件化的SOA应用，业务分工明确,组织协同关系清晰，可管理性、业务复用度和组织级灵活性都更为高效。

这就是SOA从面向构件开始，梳理优化生产关系，协同专业化发展组织能力，进而实现软件生产力的跨越。

后注：1969年6月23日，美国司法部通过了著名的反托拉斯法案后，IBM不得不宣布不再免费随机提供软件，从而开始为其硬件和软件分别定价。那一天可以称为软件业的官方元年。

Key Findings（主要发现）
• Common challenges are faced by many financial services firms in pursuing SOA.
（金融客户在推进SOA时遇到的挑战具有共性）
• Organization and service definitions are bigger challenges than technology itself in defining services and achieving reuse.
（在服务定义和实现重用上，企业组织本身和服务的定义比技术本身更具挑战性）
• Both veterans and newcomers to SOA share similar issues in achieving governance and buy-in.
（不管SOA领域的老人还是新人，他们在实现治理和获得认同上所遇到的问题是类似的）

Recommendations（建议）
• Begin by defining a long-term development and acquisition architecture; then decide if SOA is an appropriate part of your future and determine what role it should play.
（起点要从定义长期的开发和包容性架构开始；然后决定SOA是否对你的未来合适并决定它应该扮演什么角色）
• Ensure that sponsorship is committed and able to bridge the business and IT divide.
• Create and empower a centralized function, such as an enterprise architecture group, to support centralized responsibilities, roles and resources. Ensure both business and IT
participation.
（组建和授权一个中央职能部门，例如企业架构组，来支持组织级的职责，角色和资源。保障业务与IT的共同参与）
• Focus on defining processes and workflows to match service requirements and interdependencies.
（专注与定义流程和工作流来满足服务的需求和相互的依赖）
• Improve governance, and provide incentives and rewards to encourage creation of reusable services, and then encourage their reuse.
（加强监控和治理，对于创建可重用服务的要鼓励和激励，并鼓励他们多多复用）
• Communicate value in business terms — not technical terms — to gain business buy-in.
（多用商业的语言沟通价值—尽量不要用技术的词汇—要获得业务的认同）
• Use early wins to gain experience that can be shared across development teams.
（通过早期的尝试来获得经验，并在开发团队中分享）

主要观点阐述：

• 构件：是构造应用软件的标准基础单元
• 面向构件：是基于构件的软件开发方法和技术，用于构造应用
• SOA：面向服务的企业总体架构，服务成为企业应用的新资源层
• 是与非：一切从应用出发，以应用为根本
• 远景：SOA成就企业架构，应用软件都用构件来造

构件：是构造应用软件的标准基础单元。

作为标准的应用软件构造基础单元，有两方面的作用和功能：

• 应用软件可以通过构件中的Services(服务), References(引用)和Properties(属性)来构造更为高层和更粗粒度的应用软件模块（如后面要讲到的组合构件(Composite)）
• 也可以通过构件中的Implementation(实现)来封装更为低层和更细粒度的逻辑实现。

构件的编程语言无关性特征，得以在更高层次抽象、屏蔽了具体的底层实现技术。基于构件来构造应用的时候更多地脱离了底层复杂技术和它们的差异性，而是站在更高层的构件和服务的层面来构造。其中构件的几个基本概念和元素解释如下：

• 服务(Services)：服务是构件的一种组成元素，是构件功能的暴露和被使用的方式；构件是服务的载体，构件也会需要依赖(References)其他构件的服务，构件的具体实现(Implementation)也可以是个其他软件实现的服务。
• 引用(References)：构件自身需要用到的其它构件的服务。
• 属性(Properties)：构件自身运行时的可注入参数。
• 实现(Implementation)：构件具体实现时支持各种具体的逻辑实现技术，如Java, C++, PHP, Java Script, BPEL, SQL, XQuery, Composite等。

面向构件：是基于构件的软件开发方法和技术，用于构造应用。

构件封装和实现了我们更低层次的代码和逻辑实现，而面向构件则在此基础上开创了我们全新的应用软件的开发模式。应用软件的开发不会再是无休止的重复性的低层次编码劳动。而是基于构件的高度复用的软件图形化组装的开发方式。这就是面向构件所带来的软件工程和开发的革命。任何的革命实际都是要解决这个时代遇到的关键问题。面向构件正是关注和解决了我们现代应用软件开发中的三个核心关键问题：

1：全流程管理(Process)：应用的流程实现是通过构件的组装(Wire)来完成，而且是支持全流程的实现。全流程也就是对于三层不同逻辑资源的一体化使用：

• 代码逻辑(Code Logic)：也称为功能逻辑，可以支持细到各种语言(Java, C++, BPEL…)编写的代码逻辑的流程，它们一旦被封装到标准的构件中，就可以被用来组装成更高级的业务构件(Composite)，或是被暴露成构件中的服务(Service)而被使用。在业务组装开发环境中，原来的实现技术和语言已经被屏蔽了，对于应用开发来讲具体的实现技术和语言已经变得透明和不再重要了。
• 构件逻辑(Component Logic)：也称为应用逻辑，可以支持到基于构件的逻辑组装，而开发出更粗粒度的业务构件(Composite)，业务构件实现了具体的业务模块和流程。
• 服务逻辑(Service Logic)：也称为集成逻辑，同样可以在构件或是业务构件中访问和使用外界的服务资源，以实现更高层次的业务构件。具体可以通过构件中的实现(Implementation)，或是依赖(References),也或是业务构件(Composite)中的依赖(References)来访问外界的各种服务(Services)，甚至是企业服务总线(ESB)上的各种服务。

2：无缝访问各层资源(Access)： 对于各种资源的无缝访问是现代应用的索求。而构件正是实现了标准的无缝访问。无论是访问逻辑/流程，还是访问数据/信息，甚至是访问页面/展现。构件可以封装任何已有的和新建的模块功能，通过暴露构件的服务可以被更多的使用者访问。构件的服务(Services)提供了被人访问的能力；构件的依赖(References)提供了访问别人功能的可能；而构件的实现(Implementataion)则把底层的代码、逻辑和服务一并纳入构件的标准体系中，供应用软件来无缝访问。构件提供的标准化访问能力让我们应用中遇到的集成(Integration)问题得到迎刃而解。过去那些专有化的集成和访问方式将一去不复返了，取而代之的是构件和服务的与生俱来的无缝访问和集成能力。

3：易于根据需求而改变(Change)：变化是现代应用的主要特征，尤其是在中国。很多客户的需求还没明确，项目就已开始，一切都在应用开发的过程中不断沟通、不断实践、不断改变而成。因此面向构件技术必须更好地解决这个应用的关键问题即‘变化’，才能有真正的实际使用价值。构件和业务构件(Composite)可以让改变易如反掌，应用的改变可以通过重新的属性(Property)注入，重新的绑定(Binding)调整和依赖(Reference)调整，甚至于重新的实现(Implementation)及组装(Wire)。这些构件和业务构件(Composite)的属性和特征，这些面向构件的组装(Wire)、绑定(Binding)带给了我们过去任何开发技术所无可比拟的改变能力。

暗示：面向构件这个开发方式是最好的服务的制造方式，它所造出的构件和业务构件是全粒度的服务，为我们应对新一代应用的需求游刃有余。这就是“SOA从面向构件开始”的第二层逻辑验证。

庄子谈’Think Liquid’缺乏内容，SOA一场时装秀

2005年12月7日，首次以合作伙伴和观众的身份聆听了BEA公司创始人、董事长兼首席执行官庄思浩（Alfred Chuang）先生的主题演讲‘Think Liquid’。应该说我听‘庄子’先生的演讲也不下10次了，可是坦白来讲这次是最让我失望的。之所以称之为‘庄子’，表达出我对其的敬佩和尊重，可是我又在担心他的思维创新力的衰退。

CEO是公司远景和战略的制定者，又是战略执行的责任人和推动者。‘庄子’抓住了3-Tier TPM客户机/服务器的机会，又最早进入Web架构，现在开始拥抱SOA。目前我还无从判断SOA何时进入企业应用的主流技术，但是‘庄子’带领BEA对SOA的推动，却显得有点弱，今天的演讲未见与1年前的差别。一年前的BEA eWorld 2004已经在讲‘Deploy SOA Now’/‘现在就来部署SOA’，可是今年又回到了更虚的‘Liquid’,而且在过去的一年中未见在客户与合作伙伴的实际绩效出来，未见SOA的应用出来。

同样地，会上中国的两位客户代表的如实报告中也未给SOA增添什么色彩，演讲内容基本上与主题关系不大，还是Tuxedo、WebLogic Server和WebLogic Portal的老产品应用，也未谈到SOA和‘Think Liquid’的未来规划。可以看到中国的这些IT领先客户还是非常务实地在构建自己的业务和管理系统，而BEA的SOA似乎与中国还很遥远。

在绚丽的T台上，中国客户千万不要急急忙忙地穿上了华丽的标有名牌IBM、BEA、Oracle、Microsoft的SOA外衣，以期赶上世界时装界的步伐。那些对于中国客户来讲终究是美丽的外衣，我们中国客户目前阶段更需要的是自己的强身健体，把内在核心业务和管理系统建立起来。等到了强身健体的那么一天，中国客户自然需要更时尚的外衣(Service)，到那时候才会有SOA在中国市场的需求。

也可参见全球IT领先杂志《信息周刊》的《SOA负重前行》，了解更多大客户对于SOA的反馈，如联邦快递FedEx，花旗集团CitiGroup，平安保险等

SCA，软件开发的3G时代

－－－新十年解决客户关键问题的主流技术

面向构件，新一代的软件开发模式和方法。那么它的规范和标准又是什么呢？现在这个答案越来越清晰：SCA。回答这个问题的时候，可能现在绝大部分的人都会说SOA，其实‘SOA’这个回答是错误的！（似乎现在的软件界不提SOA就落后了？！）但是在这个问题上‘SOA’的的确确是个错误的答案。SOA不是软件开发的方法，不是软件开发的标准。他只是一个更大的软件架构概念，有着不够明确的内涵和超强的外延，就像‘中间件’这个词一样。而SCA则不同，它有着清晰的内涵和规范标准，当然SCA也是在SOA的巨大范围之内，不过更有现实的意义。

可以这么说，随着7月初SUN公司的加入SCA/SDO国际构件标准组织，标志着Java和JavaEE将在未来五年内逐渐退出‘解决客户关键问题的主流技术’的地位。也随着SUN加入SCA/SDO组织的这一刻，Java/JavaEE的客户价值领导地位大势已去，JavaEE应用服务器将进入低价值和同质化的时代。SUN公司晚于普元软件（Primeton Technologies）加入这一组织，正说明了两点：一就是在激烈的思想斗争中，加入代表了承认领导地位的失去；二就是将逐步放弃自己的JBI。但是明眼人一看就知道，不加入就等于再造一个十多年前的Novell，进入边缘化的市场。

JavaEE在市场上的努力也有了一段时间，在新一代（SCA/SDO/BPEL）技术还没有成型前，他们还在扮演着‘解决客户关键问题的主流技术’的脚色，可是近几年来越来越显出力不从心。直接导致一大堆五花八门技术的出现来弥补其不足：Spring, Struts, Hibernate, AOP......。这些属于2.5G的技术在一段时间内解决了一些问题，不过也在带来更多的问题（彼此的集成，开源的问题等等）。

SCA/SDO/BPEL就是新十年的软件开发的主流技术，是软件开发的3G时代，之所以是主流正是他是在彻底的解决新十年客户的关键问题。将来Java/JavaEE就会成为一个企业运营需要的同质化的平台，解决分布式计算的问题，也是一个成熟的平台，就像PC机、操作系统一样，发展缓慢。另外‘2.5G’的那些技术 （Spring, Struts, Hibernate, AOP......）将会融入到‘3G’ （SCA/SDO/BPEL）中，并将逐渐退出独立发展的市场，而SCA/SDO/BPEL则发展迅猛，不断解决着客户的关键性问题：

• 应用开发与集成的效率 －〉 业务响应能力和低成本
• 应用模块复用、变化性维护和管理 －〉 应用资产价值提升和随需应变
• 开放性、标准化、高性能和应用监控 －〉　企业级运营和管理能力

SOA中间件的心从此开始跳动

－ 暨SCA/SDO标准全球发布

新闻一则：

“2007年3月21日，18家致力于联合推动创建SOA（面向服务的架构）行业标准的领先技术厂商，宣布了SCA　（Service Component Architecture，服务构件架构）和SDO（Service Data Objects，服务数据对象）规范中关键部分的完成，并将正式提交给OASIS（The Organization for the Advancement of Structured Information Standards，结构化信息标准促进组织），通过其开放式标准过程进行推动”。

这则新闻似乎有些波澜不惊，不过它对于未来商业软件业(Business Software)的意义和冲击力将大大超出我们现在所能感受到的程度，一个改变未来软件的新的生命力开始萌芽。

新闻可参考：

OASIS: http://www.oasis-open.org/news/oasis-news-2007-04-11.php 

OSOA: http://www.osoa.org/pages/viewpage.action?pageId=4178

Oracle: http://www.oracle.com/corporate/press/2007_mar/SCA-SDO-Oasis.html?rssid=rss_ocom_pr

Primeton(普元): http://www.primeton.com/about/read.php?id=569&his=1

BEA: http://www.bea.com/framework.jsp?CNT=pr01790.htm&FP=/content/news_events/press_releases/2007

SOA的开发标准(SCA/SDO)进入实质性的标准化阶段。

在2005年成立的OSOA民间组织（http://www.osoa.org）在于制定符合SOA架构的开发规范和标准，即SCA和SDO。目前该组织已经正式把规范提交给了OASIS（http://www.oasis-open.org/home/index.php），并把OSOA从民间升级到官方工业标准组织OASIS下的Open CSA（http://www.oasis-opencsa.org）。

这些组织级的支持推进，可以看出SOA时代的开发标准正在形成和推进。

时间：美国2006年7月20日上午8点（北京时间7月20日晚11点），总共1小时6分钟。

地点：电话会议（Skype还是让我们远隔重洋，却又近在咫尺。）

参加者：Oracle的分析师关系负责人Claire Dessaux女士来主持。来自普元Primeton、BEA、IBM、Oracle、SAP、TIBCO等的十多家公司的代表出席了会议。

内容：主要是彩排将于7月24日和25日在全球同步举行的分析师沟通会，因此大家还是围绕着最近的SCA/SDO的标准进展、新加入的成员情况、SCA组织结构、官方网站等作了沟通和更新：

• 首先的号外是SUN公司终于放下了架子，正式签署了加入SCA和SDO的协议。SUN公司知道Java时代的主导地位已经一去不复返了，还是务实点加入，免得落后太多。
• 普元软件（Primeton）继6月加入SCA组织后，又在本周一正式加入了SDO标准组织。
• 官方SCA/SDO网站www.osoa.org加入了中文社区的索引，并指向普元软件的goCom面向构件社区：http://gocom.primeton.com/modules/osoa/，也就是goCom的SCA/SDO专区成为了国际SCA/SDO组织的官方中文社区。
• 明确了18家分析机构将参加与7月24日和25日举行的沟通会议，这些分析师分别选择了适合自己的一天。我们熟知的Gartner、IDC、Forrester、AMR和Yankee的多位专家名列其中。可惜没有中国的分析机构，不过不久后还会针对中国市场搞一次。

更多关于组织的会议参见：

SCA标准会议实录(2006-06-30) (http://gocom.primeton.com/blog/index.php?op=ViewArticle&articleId=689&blogId=6)

SCA标准会议实录(2006-06-26) (http://gocom.primeton.com/blog/index.php?op=ViewArticle&articleId=677&blogId=6)

商业之道：摆正视角，永不迷失

通常一家公司创新了技术，做出了产品，推广了品牌，期待着商业的巨大回报。但是在这成长过程中总会有不少的困惑和迷茫：该依托那种技术？还需要创新哪些技术？做出怎样特征的产品？口碑和品牌又如何去塑造？当这些问题不断摆在我们面前，那我们如何才能保持正确的发展方向，做到永不迷失呢？

我觉得把握三点原则可以让我们永不迷失方向。

首先，技术是社会的。大家都知道要做出一个好的产品必然会依托众多的社会上好的技术，普元的EOS就是依托了众多的社会上的技术而产生，比如：XML、Web Services、Java EE、Eclipse。同时也借鉴了社会上的很多技术，比如：Hibernate、Spring、Struts等等。这些技术哪里来的呢？还是众多的厂商或是团队开发出来，并贡献到了社会上，使得社会上更多的产品可以依托和借鉴。假如没有了这些技术，可想而知普元的EOS是不可能做出来的。同时，在做产品的时候是要解决客户的一个领域问题，比如应用平台这样的一个领域问题。EOS依托和借鉴了这些社会上的技术后，根据客户的领域问题发现还需要创造性地开发一些新的技术，来更好地完善地解决‘应用平台’的领域问题。因此普元的研发专注于此，创造了‘面向构件’的核心技术，加之依托和借鉴于社会的这些技术，不断打造出好的‘应用平台’的产品EOS，成为客户业务管理应用的依托平台。当然回过头来，自主创新的‘面向构件’技术也要回馈于社会，不能把它搞成个私有的技术，那是没有前途的。普元06年6月加入了SCA/SDO标准组织的目的之一也正是如此，贡献自己的‘面向构件’技术于社会。当然在应用平台的技术众多，普元也只是在尽自己的力量，推动应用平台领域问题的不断解决。技术也有它的生态圈或是价值链。你所依托、借鉴和自主创新的技术能够放到一个更大、更好成长的生态圈里，这将是决定你的技术和产品在未来的Marketing Share的关键要素。

谁买单就是谁的理论I：主流技术都是由众多厂商、研究机构、学校、团队等各自出钱共同投入而来，因此它不应该局限地属于某个机构或是个体，而是应该归属于社会，是大家的。TCP/IP、HTTP、Web Services、XML、Java等主流技术的发展正说明了这一点，SOA和面向构件技术（SCA/SDO）也应如此。如果某个机构觉得自己的贡献大而要私有化，那么该技术是不能得到更多社会资源的持续投入而不断发展，必然背离主流或是死亡。这就是“技术是社会的”，“主流技术更是社会的”。

-------------------------------------------------------------------------

其次，产品是客户的。产品该如何定位，如何需求，如何特征，如何质量，如何时机，如何定价等等，本质上都是由客户而定。由客户的领域问题和需求而定。你的产品实际解决了多少客户的问题，应用后的价值到底有多大，这些都直接和你的产品的营销范围、价格和销量直接相关联。在竞争的市场环境中，你的产品和解决方案具有多大的解决问题的能力和客户需要付出的代价，决定了哪类客户会将多少的钱放进你的腰包。进而决定了你在市场上的Wallet Share。

谁买单就是谁的理论II：是客户花钱买产品，因此产品在本质意义上是客户的，客户是买来解决它的具体问题的。当然平台类产品不是一个客户在购买，而是成千上万的客户在购买，因此像普元做出的应用平台产品EOS就是这些客户的，需要更好地解决这些客户在应用平台的领域问题，这样客户才会出更多钱让你继续为他做出更好的产品。这就是“产品是客户的”，“主流产品更是一类客户群的”。

-------------------------------------------------------------------------

最后，品牌是自己的。我们投入的每一分钱都有很大的部分是在塑造我们自己的口碑和品牌。我们做的市场营销，我们销售们跑客户去讲价值，我们服务工程师解决客户的技术问题和咨询，都在塑造着我们的口碑和品牌。好的技术、好的产品、好的服务、好的营销所塑造的品牌是竞争对手拿不走的，是我们自己的。因此我们就需要像对待我们自己的名誉一样呵护我们的品牌。品牌是有商业价值的，它会占据人们的Mind Share。

谁买单就是谁的理论III：厂商类似普元，广义上讲花的每一分钱都与其品牌塑造有关，不管是营销活动，还是技术服务；不管是研发产品，还是标准化技术。一切都在投入到自己的品牌塑造中。因此这些投入就变成了价值进入到普元的品牌中，不断提升自己的品牌价值。这就是“品牌是自己的”。