OSGi和SCA到底能有什么关系呢，确实，至少从现有的OSGi规范以及SCA规范分别来看，两者没有直接的关联，由于OSGi规范是对于嵌入式领域的软件而制定的，其特别注重软件的动态性的支持，而SCA规范是对于企业应用领域的软件而制定的，并且是基于SOA的，其特别注重对于企业应用而言的基础设施的实现，同时又尽量的去屏蔽对于SCA容器使用者而言SOA带来的技术实现细节的难度；但根据OSGi规范以及SCA规范，同时又能发现两者有个共同希望解决的问题，那就是规范的模块化，这是OSGi规范和SCA规范中的一个共同目标。

　　TT SOA编辑推荐：OSGI教程

　　在规范的模块化上无疑OSGi占据了优势，OSGi规范详细的定义了作为OSGi框架应该如何去实现以支撑规范的模块化，同时也定义了应该如何规范的来建设模块，而在SCA规范中只定义了如何规范的来建设模块，并未定义如何规范的来实现SCA容器，既然是这样，SCA规范是否可以考虑直接使用现有的好轮子—OSGi作为SCA容器实现的基础呢，在使用OSGi的情况下，SCA容器就没必要费劲就考虑怎么样实现自己规范的模块化了，这个就有点象当年的Java Module System规范，除非SCA小组能够有突破性进展的实现规范模块化的方法，那另当别论。
使用OSGi的话自然的就给SCA带去了一个好处，那就是动态性的支持上，这是OSGi的核心也是最大的优势，Peter在他最新的blog中也提及Module Layer是OSGi规范中最为关键的部分，正是因为Module Layer才使得OSGi其他部分得以搭建。

　　当然，基于OSGi去实现SCA容器必然会碰到这样那样的技术难题，这可以依靠OSGi框架的实现者们和SCA容器的实现者们来协作的解决，就像Spring and OSGi。

　　那么对于OSGi而言呢，基于OSGi去实现SCA容器又会给OSGi带来什么好处呢，其实非常明显，在这样的情况下OSGi就真正的进入了企业应用领域，真正的成为了以后企业应用领域的核心基础，所以我在之前的blog中说过，SCA非常象是OSGi在企业应用的延伸或扩展形成的规范。

　　当然，要做到上面所说的，不仅仅是想就有用的，需要去努力做到，近期准备发封mail先试探着问问OSGi EEG们对于SCA有什么想法，是否可以考虑直接让SCA变成OSGi EEG的规范，同时让SCA规范制定小组纳入OSGi Core作为SCA容器实现的规范的部分。

　　近期Spring and OSGi的进展非常可喜，现在Spring and OSGi的project已经提升为了正式的project，而且在提升之前也对外正式公布了Spring and OSGi的repository，Spring and OSGi project的网站地址位于：http://www.springframework.org/osgi