SCA初学习（3）--SCA与其他技术的融合

作为一个开放的框架技术规范，SCA如何与现有的技术向融合呢？
书上有这么一句话：绑定策略和实现策略。
如何看待绑定策略与实现策略，或者说何时使用绑定策略何时使用实现策略呢？
首先看看绑定和实现的概念区别;
[color=red] 绑定：绑定是访问服务所使用的方式，在SCA中主要用在唉服务和引用里。服务中的绑定表示该服务的客户端调用该服务时所需要使用的访问机制，而引用中的绑定表示该引用调用其他服务时所使用的访问机制。

实现：指提供了特定业务功能的代码段。[/color]

从概念上来看，绑定时访问服务所使用的方式，也就是说，绑定是为了消除访问该服务的方式的不同而创立的概念。访问方式也就是是通过java虚拟机访问、web service方式访问、jms访问等等。而对于实现，由于每一种实现类型都代表了一种特定的实现技术。包括底层框架和运行时环境。
举个例子。比如现在SCA要兼容hessian，hessian是一种访问机制，所以当然要用绑定的扩展来实现hessian的响应扩展。再比如SCA要兼容Spring，访问spring当然要得到spring的ioc容器，那么spring的容器可以看做是一种特定的实现技术，而非访问机制，从来没有说一个服务发布为spring这种话的。
而对于sca与osgi，书上说有三种集成方法：
1.绑定
2.osgi作为sca的一个实现
3.用osgi实现sca，sca作为osgi的一套bundle运行。
我个人认为：
第一个方案可行但不可取，但是如同书上说的，osgi和sca两者对于服务的理解本身出发点就不同，osgi的服务是细粒度的（更进一步是偏向软件内部，如计算器的加法服务和面板服务的调用），sca的服务是粗粒度的（更进一步说是更偏向软件协作，如计费中心的计费服务和用户中心的用户信息服务协作），所以这种方式很不可取。
第二种方案，SCA将osgi看做是特定的业务功能的代码段，这种方式只是为了能让SCA使用osgi中的代码，在这种情况下osgi是被作为一个“黑箱”纳入SCA中，丢失了osgi的特性，也就是说，[color=red]这种方式的集成导致SCA并没有吸收OSGI的任何优点。[/color]
第三种方案，这种方案是充分考虑了两种技术的长短，SCA主外，OSGI主内，你种田来我织布。这种方案是对于两种技术特长的最好搭配，各司其职。