SCA/SDO双截棍 启动软件编程新纪元

多少年来，Three Tier的架构似乎已经成为了教科书式的软件体系范本。它不断地提高软件灵活性和高聚合性的，时至今日，当软件复杂度更上一个数量级的时候，这种体系也开始孕育又一次重生。这就是最近的Buzz Words: SOA，也即SCA + SDO

　　受CHRIS在BLOG上所托，稍微关注了一下这方面的。

　　其实SDO已经有比较长的历史了，IBM去年就在从事该规范相关的开发。

　　而SCA相对来说更新鲜一些，主要是针对在面向服务的计算环境里，组件的实现方法。同时，它强调了这些组件与现有的平台，组件之间的关联，并描述怎样通过已有的技术、平台甚至于现有的组件来实现面向服务组件。另外，在将这些服务组件实现以后，它们的接口以及这些接口的语义是怎样描述的。其实，新的组件描述应该是技术独立、平台独立、语言独立的，也就是说它是一个开放的规范，这样就可以让很多IT厂商在不同的平台上用不同技术和语言来参考和实现这些技术。

　　除此之外，面向服务的组件需要相互之间的交互，这种交互应该是松耦合的，也就是说需要打破过去那种紧耦合的现象。因为不管是.NET、J2EE还是更早的CORBA等技术，它们在支持分布式计算时，其组件往往和平台、语言以及实现技术紧密相关。

　　过去，如果一个组件要调用另外一个组件的功能，它需要知道后者的接口在什么位置，使用什么协议和消息格式，这往往与其实现技术有直接的关系，所以技术、平台、语言和位置等各种各样的因素的透明性对于组件之间的交互就是非常重要的一件事情了，而SCA恰恰就规定了这一部分的内容。

　　另以方面，SDO其实与SCA是一对具有对应关系的规范。我早先就说过:软件=服务+数据。SCA更加关注业务逻辑，而SDO则更侧重于业务数据。

　　过去我们所采用的技术中，不管是.NET也好，J2EE也好，它们都有基于自身平台下的规范，比如在J2EE环境下，我们就会通过JDBC、Entity Bean这样的方式访问数据库或者其它数据源;而在.NET下同样有类似ADO这样的方式来访问各种不同的数据源。这里面的问题在于，平台透露了太多的技术细节，程序员需要了解很多相关的内容，比如他需要创建一个JDBC或ODBC的数据源，再利用这些规范所提供出来的编程接口来想办法得到数据源中的数据，为达成这个目标，程序员还需要去做对象-关系映射，以实现对象到关系数据库或者与之相反的数据转换。目前有一些技术可以用来解决这些问题，比如前段时间在Java社群中一直都非常流行的Hibernate等，诸如此类的方法和工具很多，他们都是用来协助程序员处理上述工作的。但无论如何，你都无法逃避地要看到很多这些方法中非常底层的技术细节，而且，程序员需要学习所有这些不同的技术，了解它们适应于什么情况，处理各种情况下的不同技术细节。事实上，程序员需要抽象层次更高的东西，比如业务数据对象(Business Object)以及它内部各种细粒度数据对象之间的关联，这是可以用一致、通用的方式来表示和操作的。有了抽象层次更高的模型，程序员就可以通用的方式来定义和访问业务数据，从而以统一的方式来描述和访问不同的数据源，降低对程序员技能的要求，提高生产率，更容易在不同的应用环境交换。

　　这样，不管是Java或者C++语言描述下，程序员都不必去了解平台上的技术细节，用一个XML Schema描述这样的通用、简单的的业务数据模型，然后在运行将对象持久化到你的关系数据库、XML或者其它数据源中。

　　从技术上看，SDO规范做了如下几件事情:它定义了一个连接器，可以使用JDBC、ADO等各种不同的方式去和多种数据源交互，数据源也是多种多样，不单单局限于关系数据库，也可以是不同类型的XML文件，甚至是内存中的一块区域。同时它还提供诸如连接池、缓存(Cache)、断开连接时数据访问(Disconnected Access)等高级特性，提供了跨越B/S,C/S的边界。

另外，SDO还定义了一个中介转换器(Mediator)，它与连接器交互，来完成数据持久化的工作，这个协调器能够理解我们定义好的Schema，让程序员能直接看到一个直观的对象图表(Object Graph)。它根据业务的语义定义一个完整的Schema，不仅能清晰地定义各种数据对象，而且还能有效地描述各种对象之间的联系，充分利用了XML强大的自描述能力。通过它，人们可以很方便的操纵数据对象。

　　综合起来说，SCA/SDO都是基于已有的技术，它们所要做的就是怎样在现有技术的基础上，为异构、分布的松耦合计算环境提供一个统一、开放的组件及其服务的描述。

　　IBM在其SCA的实现中，也就是WPS 6.0所提供的SCA运行时环境，有多达八种不同的组件实现形式可供选择。我想更理想的实现应该是提供一个可以扩展的接口。即使在语法上、数据结构上有很大的不同，甚至是某公司自己语义上的东西，也可以方便地纳入SOA的架构里。

　　这样一个规范目前受到了IT技术主流的技术厂商的支持，它的建立为基于SOA的下一代计算环境下的编程模型打下了一个坚实的基础。

　　与古老的CORBA技术(请允许我用这样的词来描述它，呵呵～)想比，两种技术的背后都有很一致的哲学。但是受限于当时的技术发展条件，我们回顾历史的时候，CORBA在很多细节上的处理并不是太好，而且，CORBA是基于面向对象思想的，与之不同的是SCA基于面向服务的思想，其实抽象程度要相比过去的提高很多。

　　这里我引用一下Gartner的报告:

• 　　随着商业和技术的推动，SOA将成为将来的发展趋势已经没有人怀疑了;
• 　　2007年，超过50%以上的公司将SOA作为IT战略来考虑;
• 　　2008年还没有将SOA引入到公司的IT实现中去，那么该公司将成为一只恐龙，也就是说这个公司很落后了。

　　目睹这些年软件的迭代更新，我有时也在想，是不是这就是软件自己的“摩尔定律”，所不同的是，用来度量软件的不是单晶片上可以集成的晶体管数，而是单个软件工程师所能Handle的软件复杂度，姑且叫它"logic per brain"吧。