对让SOA落地SCA的一点理解

2019独角兽企业重金招聘Python工程师标准>>>

 

Author: 岑文初

Email: wenchu.cenwc@alibaba-inc.com

    最近一直在考虑平台的总体结构以及服务框架的问题，粗粗的接触了 OSGI 和 SCA 等思想，有了一些思路，但是还不是很清晰。昨天很好的机会，和普元公司做了一次交流，看到了很炫的 IDE 功能，同时也看到了 SCA 思想真正运用到了实际平台中的效果，中间的工作流也给我留下了很深的印象。

    1. 程序员就是技术工人，使用好的工具就是为了提高生产率。刚出学校大门，遇到了 JAVA ，真正的了解了面向对象编程，看到了面向对象带来的优势，封装让我们这些初出茅庐的小劳工知道了如何将做好的成果，下次再用，一次一次的重构，将小零件作的越来越顺眼，这个过程中，也让我们在重构中积累了经验，我想这也是每个程序员必经之路，有了这个阶段的积累，将来收益无穷。接着遇到了被大牛们说的神乎其神的 J2EE 的 EJB ，这时候，从简单的类复用逐渐转变成为了组件复用，同时 J2EE 容器提供了功能强大的容器。在 EJB 的世界里，传说只需要关心业务逻辑，开发人员不必再为一些重复的细节和非业务的功能反复重构轮子，我们只需要根据客户的爱好，给车子上面点缀一些装饰即可。但是结果并非如传说这样，对于 EJB 的组件的误用造成了性能瓶颈，对于容器的过分依赖，以及发布部署的复杂，调试的繁琐，不仅让原来支持他的大牛对它丧失了信心，也让新人们敬而远之。此时，大家开始迷惑究竟怎样的模式才能够真正适合开发人员。这是， spring 的出现，无疑给了每个人新的亮点， IOC 的思想，回归 POJO 的原始，让大家知道了，原来简单才是我们需要的，就好比现在流行绿色健康生活，吃粗粮，回归简朴生活就是最好的。但各大厂商当然不能让这个状况永久的保持下去，后面有千千万万口要吃饭呢，这时候又掀起了 SOA 的狂潮，一种思想，一种理念又类似于当年的 EJB 开始蔓延，这次他所提倡的就是更高级别的复用，服务的复用， Internet 提供了开放的环境，但是没有一种统一的服务访问模式，让各个企业之间成了信息内部丰富的孤岛，需要将这些孤岛串联起来，同时要最大限度的复用有限的资源，因此提出了面向业务的服务概念。但是很可惜， SOA 喊了很多年，但都还是一个概念灌输阶段，一直都没有一个机构给出一个真正的实施标准，因此大家都采取的观望态度。服务的复用也就停留在了理论阶段。

     2.SCA 和 SDO 的出现，给 SOA 来了点实际的。 SCA （ Service Component Architecture ）其实就是将过去 EJB 的成果继续下去，基于 Component 的复用，同时吸收了 IOC 的思想， Component 之间的组装是通过 SCA 框架来实现的，但是很重要的一点，他没有走 EJB 的老路，而是学习 spring 的轻量级框架，不再为开发者作的面面俱到，其实，特别对于中国的程序员来说，不需要太多的框架去限制他们，只需要给他们一个可以订制的灵活的框架即可，他们的手艺都不错，同时也可以在这个订制的阶段学到很多，这也是为什么开源项目吸引那么多高手的原因，因为参与和创造才能给程序员一种自我实现的快感。 SCA 的 Component 和 OSGI 的 Bundle 一样其实是对 Java 封装的一种贯彻，它有需要 Import 的服务引用，需要 Export 的服务，很重要一点就是它对于 Component ， service,reference 的实现都没有作限制，这类对象只需要有个接口定义和实现描述即可，当前规范中支持的接口定义可以是 java 接口也可以是 wsdl 文件（最终也是转换成为 java 接口），实现的话那么更加广泛 java,webservice,rmi,jms, 脚本语言等等，同时提供了扩展接口，所以只要你想的到，就可以实现的了。然后多个 Component 组装成为一个 Composite （对于业务开发来说，也就是一个业务的 Model ）。 

    3. 一种约束。对于 JAVA 开发人员来说，看你是否有经验，其实看看你写的代码就能略知一二，能够抽象设计，能够针对面向接口考虑，那么这个开发者多多少少对于面向对象就有一些认识。在我们现在的业务开发者开发的系统来说，让人很头痛的一件事情就是，我们可以约束 Java 的规范性，但无法约束业务开发的规范性，好比客户模块一堆类，实现了一大堆功能，订单模块需要查询客户信息，这时候开发者不会去和开发客户模块的人员交流，自己开发了直接访问客户信息代码，结果就是，维护成本大，客户模块修改了，他不知道到底有多少模块需要去更新，反复的重写同样的逻辑，最要命的就是系统的耦合度增加，无法单独的将这些业务模块独立出来，系统没法根据业务模块来拆分。而如果基于更高级的组件复用和服务复用，那么模块间的信息交互不得不通过接口的方式来调用，这就提供了一种业务开发的约束。

    4.SCA 和 OSGI 的互补。记得在论坛上有人讨论过 SCA 和 OSGI 的优劣，但其实作为这两个规范面向的解决问题都是不同的， SCA 是 SOA 的一个实现， SOA 是解决分布式服务的互通问题，而 OSGI 是针对单机服务的动态绑定义及组装，因此两者不存在着可比性，但是在我看来，两者却有着很好的互补性，在平台的现有情况下，用 SCA 来实现服务框架，同时通过 OSGI 来实现组件装配，这无疑是很好的一件事情，同样有个开源项目也正在做这件事。

    其实，任何技术开发人员都喜欢采用最新最流行的，但是作为架构师，却需要选择最合适的，因为我们是在为公司的盈利作出自己的贡献，而不是为实验室作出 Fancy 的效果，因此自己玩可以用最炫的最新的，而真正考虑做一个项目，开发一个框架，那么需要慎重的选择一种合适的技术规范，利用可以利用的资源， Solve Problem 。后续将会把自己前段时间整理的 SCA 的实践整理一下，毕竟这个让 SOA 落地的东西到底是否能踏踏实实的干活，还是需要实践来检验的。

 

转载于:https://my.oschina.net/pangzhuzhu/blog/331862