`
youxinrencwx
  • 浏览: 66506 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

与普元技术交流后对于SCA框架的一点认识

 
阅读更多
最近一直在考虑平台的总体结构以及服务框架的问题,粗粗的接触了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落地的东西到底是否能踏踏实实的干活,还是需要实践来检验的。
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics