回忆几个镜头：
在21世纪初的时候，有三家代表性的公司都在思考着简化Java那繁复的开发，去创造下一代更为简单高效的开发模式。回顾起来他们的发展轨迹各自不太相同。
普元软件(Primeton)于2001年4月1日成立，志在探索下一代基于互联网技术的应用平台。历经整整五年，磨出一把亮剑‘EOS 5.1’，提出了面向构件开发的技术思想和实践平台，把组装与图形化完美结合，把开发技术推向了新一轮的潮流。并在这5年中积累了几百个企业级的客户。
而在当时的同年7月全球领先的中间件公司BEA收购Crossgain，成立Workshop产品线，由其后来的首席架构师Adam Bosworth担任当时的产品负责人。旨在创造下一代的编成模式（Programming Model），提出了基于Control组装的开发技术思想。但后来历经2年，市场效果不好，不得不放弃封闭模式走向开源，把Workshop中精华的Framework等开源到了Apache的Beehive项目中。
IBM则从大客户中来，又要回到大客户中去，为了解决大客户那繁复的开发方式，也相继推出了WSBCC(WebSphere Business Components Composer)，利用框架与组装技术简化企业级应用的开发。可是推行的也不是很理想，渐渐缩到了银行业，利用他们在银行业的构件积累，还算是用了些客户。
这么先进的技术，应该说在过去的五年中，市场没有能很好的起来，关键还是在于产品技术的成熟和市场的需求上。IBM/BEA所定位的美欧日市场，在过去的五年中忙着集成老的系统，很少需要建立新的应用系统，因此这样的开发技术没有了市场的土壤。反倒是普元在中国这个特殊的‘应用开发’市场上，对于快速开发和适应变化的市场需求使得这样的技术有了一个好的土壤来完善和成熟。
前瞻一下未来主流：
应该说这三家公司当时的技术发展很先进，现在来看将会引导出未来的软件编程新模式(New Programming Model)。一个核心目标就是要脱离Java编码(Coding)的低级开发模式，而更上一层楼，利用更高的抽象编程模型、框架技术和图形化开发来发展新一代的开发平台。新的编程模式的核心思想就是用组装(Composition)和图形化(拖拉画线)来代替编码(Coding)。这样的技术才能满足未来业务与管理发展的需要：‘快速’和‘变化’。而这样的技术也不再依赖于具体的编程语言和API（Application Programming Interface），将脱离具体的开发语言来面向业务和管理进行编程(Programming)，而不再是编码(Coding)。编程与编码正式分离开来，当然很多程序员会不适应或是抵制。可是我们想想看，每一次技术的改进和革新都会被老的*所阻碍。熟悉汇编语言的不会愿意去学COBOL，熟悉COBOL的同样不会愿意去学C，而C的高手就更看不上Java了。其实这个世界很辩证，现在的领先和主流可能就代表着未来的落后。目前的情况也是如此，程序员们看到没有了语言编码的编程，简直是视作自觉坟墓。殊不知，自己在时代的潮流中正面对着一次选择，要么提升一步选择代表未来主流的编程技术，要么缩到社会的一角死抱着现有的不放，不定沦落到细分市场中。
我们可以有这样明确的判断：将来的应用不再是在编码层实现，而是在图形化组装层来实现（注：我这里指的是应用编程，而非系统软件编程）；因此面向服务构件组装的一个层次和环境将会诞生，并主导未来软件的开发新模式。绝大部分的应用都会在这个层面上开发，如行业的业务应用和横向的管理类应用，甚至于一些通用业务管理平台也会在服务构件层之上实现，而不是Java的语言层上，如工作流管理、报表管理、规则管理。也就是将来的流程、报表、规则都是一种构件、一种服务调用和访问，这样的话才可以在开发应用的过程中无缝地使用和拖拽。
下图的goCom EAT 2.0，清晰地表达了未来主流企业级应用架构的蓝图。服务构件层独立出来，作为一个完整的环境（开发、部署、管理），提供上层应用所需的各种服务，应用不再基于分布式计算环境，而是基于服务构件环境。
图中我们可以清晰地看到：
-
分布式计算环境(DCE)：处在最下层，将继续提供企业级的系统能力：稳定、安全、可靠、可扩展、跨平台、交易的完整性、消息的可靠传递、专有系统的访问等。这层上的产品Java EE和.NET具有广泛的市场，目前也已成熟和同质化（尤其是Java EE），技术上的发展已经比较的缓慢。如同PC机一样，需求大量、功能雷同、价格走低。
-
服务构件环境层(SCE)：是未来编程的关键。它提供了以服务构件为核心的一整套环境，包括了开发、逻辑运行、数据服务、管理、安全、策略和基础服务等。围绕服务构件的一套完整系统环境。
-
业务管理平台层(BMP)：是面向业务流程管理平台。早在2005年时计世咨询就提出了这个层面的概念，但是当时还是从功能模块的角度来阐述。未来的业务管理平台将在服务构件层的基础上，以服务构件库和配套引擎的方式，以业务流程模型和管理为代表，加上规则管理、报表管理、第三方构件库和富客户端控件库，从而更加灵活地提升业务管理的可视性(Visibility)、可变化(Adaptability)和高效率(Efficiency)。
-
集成开发环境(IDE)：面向构件的集成开发环境，从页面展现，到业务逻辑，到数据访问在同一的环境中设计开发、跟踪调试和部署上线。不管是工作流的开发，还是报表的定制，或是规则的设定，还是富客户端的开发，都在统一的、一体化的环境中得以实现。
-
业务管理应用层(BMA)：处在最上面，不管是行业的应用如电信的OSS、BSS、MSS，还是银行的财富管理、资产管理、网上银行，还有横向的管理应用如CRM、SCM、HR、OA等，都是利用业务管理平台把服务构件图形化组装而成，并可以在业务管理层面得到最大程度的复用。
应该说，服务构件是上图的核心概念和不同点。作为更高层次的抽象和复用技术，给现代业务和管理带来了前所未有的优势：快速搭建、适应变化和高度复用，如下即是服务构件的特征对比表：
服务构件与以往的技术相比，对于客户的价值表现为：
- 简化开发
- 组装和服务的实现
- 多语言支持（Java、C++、BPEL、PHP）
- 运行时访问各种服务，如Web Services, JCA, JMS, Data等
- 利用SCA的绑定和策略模型，最自然的暴露构件(Component)成服务(Service)，用以与具体技术无关地实现集成和被集成
- 灵活的QoS
- 广泛的业界支持
透露一下厂商和标准的发展：
不断完善的服务构件环境将代表了未来的主流应用平台技术，在这点上三家厂商都在努力发展产品和技术标准。去年底由IBM/BEA/Oracle/SAP发起的SCA组织正是为了这样的使命而诞生，中国目前唯有一家中间件公司普元积极加入其中，并把多年积累的经验和技术贡献到组织中，共同制定相关的业界标准。普元除了五年的服务构件实践经验和成熟产品外，在此之上的面向构件的业务管理平台也是推动服务构件环境得到广泛实践的重要推动力。
而在具体的标准上，覆盖业务逻辑的SCA(Service Component Architect)和覆盖数据服务的SDO(Service Data Object)都已有了参照规范，SDO略为成熟些，不过正式的SCA 1.0也将于年底发布。并首先支持Java和C++的实现标准。完整的规范将包括：
-
一套与开发语言无关的组装模型规范(Assembly Model Specification)，用来简化组装和业务服务的开发，称为Service Component Architecture。
-
一套Java语言规范，用以实现SCA的服务构件
-
一套C++语言规范，用以实现SCA的服务构件
-
一套Java语言服务数据对象(SDO)规范，用以描述一套通用的客户端与服务端的数据交换方法。
-
一套C++语言服务数据对象(SDO)规范，用以描述一套通用的客户端与服务端的数据交换方法。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=909110