服务框架，这个名词已经出现了很多年了，很早以前系统的架构就希望是以基于服务框架的方式来搭建的，turbine、phoenix、avalon等都是朝着实现服务框架的目标而去，如今的SCA，也可以说就是为了提供一个可用的服务框架，服务框架在系统中到底承担什么角色呢，为什么它会显得那么重要呢，如果要实现一个服务框架，不太可能从最底层做起，那么我们又需要怎么样去选择呢？
服务本身是个挺形象的名词，在系统设计中我们非常强调输入和输出，服务呢，可以说是更形象的去强调了这一点，每个模块都会对外提供一定的功能，而这些对外提供的功能我们就可以作为服务了，细到模块内，我们也会发现模块内各个类其实也是以服务的方式来交互的，在这样的情况下，服务框架自然就成了整个系统的核心基础框架，那么服务框架能帮我们来提供哪些功能呢，如果我们要实现一个服务框架，有哪些要素是需要考虑的呢，欢迎大家拍砖，多多交流！
1、如何注册服务
怎么样注册出服务这东西呢，:)，这是我们在做考评时的第一要素了，最理想的莫过于通过xml将一个pojo描述为服务了，或者是java annotation的方式了。
另外个可以附加考评的点就是在注册服务时是否支持部署到指定的服务中心，类似websphere的远程部署。
2、如何调用服务
如何调用服务，这个可以说是考评中很重要的一个因素，而且也是比较复杂的考评点。
从调用的方式上来讲，服务的调用需要考评的有是否支持injection方式和显式调用方式、本地调用和远程调用的区别、同步调用和异步调用的区别、lazy式的调用还是固定的引用调用，从考评的期望上来讲，我们当然是希望injection和显式调用都支持，本地调用和远程调用、同步调用和异步调用能透明式的配置，lazy式的调用是指注入或调用的服务只有在切实调用到相应的方法时才会获取到真实的服务对象，而固定的引用调用时指当调用服务时即获取到真实的服务实例对象，lazy式的调用和固定引用调用的支持对于集群应用场景会产生很大的影响。
调用服务同时涵盖了查找服务的概念，在查找服务方面考评的点就是是否支持按需查找服务、查找多个服务，由于同样的服务在系统中可能存在多个不同的实现，按需查找服务的意义就在于可以准确的指定所需的服务，这对于需要按规则准确查找服务的应用场景而言是很重要的；查找多个(0..n)服务呢，对于需要调用可用的所有服务的应用场景很重要，这个功能对于当调用的服务不是必须的时候也是非常重要的，例如引用了日志服务，但即使当日志服务不可用的时候也需要不影响当前类的功能的应用场景。
在调用服务上还需要考虑调用服务的安全性，例如认证、权限控制等。
在调用服务上还需考虑此框架中的服务是否可以很容易的被第三方进行调用，例如在spring中调用、在其他的语言中调用等，呵呵，是不是有点SCA的感觉。
3、如何测试服务
服务的测试无疑也是考评的重要点之一，要知道当年webwork能在MVC框架领域争得一席地位和其action更好的支持了单元测试有很大的关系，所以服务框架在此方面支持的怎么样也是需要考评的要素之一。
4、服务的生命周期
由于服务的生命周期是由服务框架来控制的，因此服务的生命周期是如何转换的这也是我们在考察服务框架时需要知道的。
另外一个考评点就是如果服务的生命周期发生转变时，引用此服务的类是否能得到通知等，当然，如果是lazy式的调用的话，完全不存在这问题。
5、服务的管理和维护
这个对于服务框架而言应该是比较基础的功能，包括的有提供服务列表，在服务列表中应该有服务的名称、所属的服务中心、服务的状态、服务的处理日志以及服务访问的压力记录等等。
服务的管理就包括了服务的安装、升级、启动、停止和卸载。
6、服务的组装
服务的组装的概念是指可以灵活的将多个服务组装为一条链，然后链式的调用，这个呢是附加的考评要素了。
7、服务的出错处理
需考评当位于此服务框架下的服务处理出错时会造成什么现象，最理想的结果自然是服务的调用停止，并记录相关的日志，另外的服务对此情况做出纠错处理，有点像erlang的容错思想，:)，最基本的一点就是不能影响到服务框架和其他服务的正常运转。
8、服务事件的广播和订阅
允许服务在处理时能对外广播事件，同时也可订阅事件，以触发某些动作，这里可以附加考评的就是是否支持多种灵活的服务触发方式，例如定时的触发等。
其他可考评的要素还有服务框架对于AOP的支持、是否可建立服务库，就像bundle repository一样，:)
当然，目前开源界应该说是没有此类框架的直接存在的，但我们可以基于Equinox、Newton等已存在的类似框架来实现一个这样的标准的服务框架，考评时就可以根据这些点去判断基于哪个已有的框架是较好的选择了。