Hivemind使用指南
serviservice的定义
1、概述
在hivemind中，一个service是一个简单的实现特定接口的对象，你可以提供此接口的核心实现，使用者可以通过实现此接口来覆盖你的实现。模块的定义可以包含<service-point>元素来定义服务，一个模块可以包含任意多的服务。
2、创建模式
Service有四种创建模式:primitive（主要的）、singleton（单例的）、threaded（线程的）和pooled（池化的）。在primitive和singleton模式中，每一个服务最终只会生成一个实例。在threaded和pooled模式中，同时可能有多个实例，但是每个线程只会有一个实例。各个模式的定义如下：
Primprimitive：服务在第一次参考时被构造
Singlsingleton：服务在第一此调用接口的方法时被构造
Threthreaded：第一次调用接口的方法时构造，并绑定到当前线程
Poolpooled：同Threaded，但服务的实现被储存在池中
Hivemind使用代理模式来创建实例，除了primitive创建模式。代理类实现了服务接口，按需要构造实际的实现类。
3、定义方法
一个服务包含一个实现类和任意多的拦截类，拦截类可以实现日志、安全、事务定义和性能观测等功能。一般一个服务代理将首先创建，当代理类的方法被调用时，实际的服务实现类被构造和配置，所有的拦截类被创建。
定义如下：
<service-point id="MyService" interface="com.myco.MyServiceInterface"> <create-instance class="com.myco.impl.MyServiceImpl"/> <interceptor service-id="hivemind.LoggingInterceptor"/></service-point>
属性定义如下表所示
属性 类别 必需 描叙
id 字符串 是 服务扩展点的简单id，
全写的id通过前边加上模块id来获得
interface 类名 否 此服务扩展点支持的接口的名字，
如果没有定义，则默认为服务id，
全协的名称通过前边加上模块的报名
来获得
parameters-schema-id 字符串 否 用来参考模块中定义的schema，
schema定义了此服务需要用到的参数，
当服是通过
ServiceImplementationFactory或者
ServiceInterceptorFactory.
类定义时。
parameters-occurs unbounded 否 参数元素允许的数量：
| 0..1 | 1 | 1..n | unbounded: 无穷
none 0..1: 可选
1 (default) :必须
1..n: 至少一个
none:不允许
服务定义中可以包含 <create-instance>、 <interceptor>、<invoke-factory> 、<parameters-schema>定义。
服务可以通过两种方式来构造实例创建和实现工厂，实例创建表现为<create-instance>元素，实现工厂表现为<invoke-factory>元素
<create-instance> 直接实例化一个接口的实现类
<invoke-factory> 通过另一个服务来实例化一个接口的实现类，它包含一个service-id属性，定义了一个实现ServiceImplementationFactory接口的服务。通过此方式创建的service将通过service的接口类型自动绑定各个服务。
5、拦截器的定义
拦截器使用<interceptor>来表示，属性service-id标识一个服务拦截器工厂服务，工厂服务实现了ServiceInterceptorFactory接口。
属性--------类别----必需----------描叙
service-id--字符串--是------------ 服务的id
before-----字符串---- 否---------- 一个服务id的列表，这些服务需要在此服务后执行
after----- 字符串--- 否--------- 一个服务id的列表，这些服务需要在此服务前执行
name-- 字符串---- 否-------- 用来排序，没有指定的话，默认为service-id
* HiveMind强制针对接口编程；
* HiveMind使用module概念来分组管理service，利于并行和迭代开发；
* HiveMind使用的配置文件格式更清楚简明，特别是将接口和实现统一定义成1个service，而Spring可能要定义好几个bean元素；
* 在增加或移去interceptor时，HiveMind只要修改1行配置文件，而Spring至少要修改两个bean元素；
* 在定义interceptor时，HiveMind采用javassist类库，性能优于Spring采用的JDK proxy。
HiveMind首先是一个Service Oriented Architecture，直接和EJB，SOAP相竞争。整个Business层被分解为众多Service。这些Service通过配置文件互相依赖。这一架构大大增强了可复用性，可扩展性，易维护性，也非常适应小迭代增量开发。
和EJB不同，HiveMind的service全都位于同一个JVM中，不存在远程调用，因而不适用于大型分布式系统，但对于小型系统而言是绰绰有余的。本地调用也免去了网络性能开销的担忧。
开发EJB需要两个interface和一个class，而且这些interface和class必须extends特定的接口和类。在HiveMind中定义一个service只要一个任意定义的interface和一个实现这个interface的核心实现class。简化了开发工作，也使得business层不依赖于任何第三方代码。
HiveMind使用Dependency Injection技术。service的核心实现class使用Plain Old Java Object风格，基本上就是定义一些field和setter方法，定义一个可选的初始化方法（在setter方法执行之后执行），实现接口中定义的业务方法。Service的生命周期由HiveMind统一管理。HiveMind在初始化service时会自动按照配置文件设置所依赖的其他service，因而在业务方法中可以假定所依赖的其他service已经准备就绪，从而减少了代码量。
HiveMind通过在配置文件中为service声明Interceptor而在一定程度上提供了AOP的功能。目前只提供了LoggingInterceptor。
HiveMind建议使用javassist来开发Interceptor，这种技术有利于提高运行时性能，但也增大了开发难度。如果使用JDK proxy，则开发难度较低，但因为使用反射技术而导致运行时性能下降，同时不能被javassist识别，在配置文件中必须将JDK proxy interceptor放在javassist interceptor前面。
HiveMind是多线程安全的。在开发自己的service时，建议使用默认的singleton生命周期模型，并且保证自己的核心实现是多线程安全的。为了做到这一点，第一将service定义成stateless的，使用参数来传递状态；第二利用ThreadLocalStorage service来保存状态。
HiveMind提供了一个ThreadEventNotifier service来管理需要监听线程终止事件的listener。
HiveMind的service默认使用singleton生命周期，从而减少了对象的数目，降低了内存开销。
HiveMind采用lazy loading策略，只有在第一次调用某个service的业务方法时才会去初始化某个service的核心实现。如果需要强迫HiveMind在启动时就加载特定的service，可以在配置文件里将这个service声明为EagerLoad service的contribution。样例代码如下：
《contribution configuration-id="hivemind.EagerLoad"》
《load service-id="hibernate.SessionSource"/》
《/contribution》
HiveMind提供了强有力的XML配置文件。你甚至可以通过定义scheme元素来控制HiveMind怎么解析配置文件。HiveMind本身提供了大量默认值，配置文件结构也很简明，降低了维护开销。
针对Web开发，HiveMind提供了一个HiveMindFilter。这个Filter方法可以初始化HiveMind，在每个request到达时将Registry设为request attribute，并在执行完成后触发ThreadEventNotifier service的fireThreadCleanup()方法。
由于Service的核心实现仅仅是POJO，因而很容易使用一些mock object来针对每个service做单元测试。
1、概述
在hivemind中，一个service是一个简单的实现特定接口的对象，你可以提供此接口的核心实现，使用者可以通过实现此接口来覆盖你的实现。模块的定义可以包含<service-point>元素来定义服务，一个模块可以包含任意多的服务。
2、创建模式
Service有四种创建模式:primitive（主要的）、singleton（单例的）、threaded（线程的）和pooled（池化的）。在primitive和singleton模式中，每一个服务最终只会生成一个实例。在threaded和pooled模式中，同时可能有多个实例，但是每个线程只会有一个实例。各个模式的定义如下：
Primprimitive：服务在第一次参考时被构造
Singlsingleton：服务在第一此调用接口的方法时被构造
Threthreaded：第一次调用接口的方法时构造，并绑定到当前线程
Poolpooled：同Threaded，但服务的实现被储存在池中
Hivemind使用代理模式来创建实例，除了primitive创建模式。代理类实现了服务接口，按需要构造实际的实现类。
3、定义方法
一个服务包含一个实现类和任意多的拦截类，拦截类可以实现日志、安全、事务定义和性能观测等功能。一般一个服务代理将首先创建，当代理类的方法被调用时，实际的服务实现类被构造和配置，所有的拦截类被创建。
定义如下：
<service-point id="MyService" interface="com.myco.MyServiceInterface"> <create-instance class="com.myco.impl.MyServiceImpl"/> <interceptor service-id="hivemind.LoggingInterceptor"/></service-point>
属性定义如下表所示
属性 类别 必需 描叙
id 字符串 是 服务扩展点的简单id，
全写的id通过前边加上模块id来获得
interface 类名 否 此服务扩展点支持的接口的名字，
如果没有定义，则默认为服务id，
全协的名称通过前边加上模块的报名
来获得
parameters-schema-id 字符串 否 用来参考模块中定义的schema，
schema定义了此服务需要用到的参数，
当服是通过
ServiceImplementationFactory或者
ServiceInterceptorFactory.
类定义时。
parameters-occurs unbounded 否 参数元素允许的数量：
| 0..1 | 1 | 1..n | unbounded: 无穷
none 0..1: 可选
1 (default) :必须
1..n: 至少一个
none:不允许
服务定义中可以包含 <create-instance>、 <interceptor>、<invoke-factory> 、<parameters-schema>定义。
服务可以通过两种方式来构造实例创建和实现工厂，实例创建表现为<create-instance>元素，实现工厂表现为<invoke-factory>元素
<create-instance> 直接实例化一个接口的实现类
<invoke-factory> 通过另一个服务来实例化一个接口的实现类，它包含一个service-id属性，定义了一个实现ServiceImplementationFactory接口的服务。通过此方式创建的service将通过service的接口类型自动绑定各个服务。
5、拦截器的定义
拦截器使用<interceptor>来表示，属性service-id标识一个服务拦截器工厂服务，工厂服务实现了ServiceInterceptorFactory接口。
属性--------类别----必需----------描叙
service-id--字符串--是------------ 服务的id
before-----字符串---- 否---------- 一个服务id的列表，这些服务需要在此服务后执行
after----- 字符串--- 否--------- 一个服务id的列表，这些服务需要在此服务前执行
name-- 字符串---- 否-------- 用来排序，没有指定的话，默认为service-id
* HiveMind强制针对接口编程；
* HiveMind使用module概念来分组管理service，利于并行和迭代开发；
* HiveMind使用的配置文件格式更清楚简明，特别是将接口和实现统一定义成1个service，而Spring可能要定义好几个bean元素；
* 在增加或移去interceptor时，HiveMind只要修改1行配置文件，而Spring至少要修改两个bean元素；
* 在定义interceptor时，HiveMind采用javassist类库，性能优于Spring采用的JDK proxy。
HiveMind首先是一个Service Oriented Architecture，直接和EJB，SOAP相竞争。整个Business层被分解为众多Service。这些Service通过配置文件互相依赖。这一架构大大增强了可复用性，可扩展性，易维护性，也非常适应小迭代增量开发。
和EJB不同，HiveMind的service全都位于同一个JVM中，不存在远程调用，因而不适用于大型分布式系统，但对于小型系统而言是绰绰有余的。本地调用也免去了网络性能开销的担忧。
开发EJB需要两个interface和一个class，而且这些interface和class必须extends特定的接口和类。在HiveMind中定义一个service只要一个任意定义的interface和一个实现这个interface的核心实现class。简化了开发工作，也使得business层不依赖于任何第三方代码。
HiveMind使用Dependency Injection技术。service的核心实现class使用Plain Old Java Object风格，基本上就是定义一些field和setter方法，定义一个可选的初始化方法（在setter方法执行之后执行），实现接口中定义的业务方法。Service的生命周期由HiveMind统一管理。HiveMind在初始化service时会自动按照配置文件设置所依赖的其他service，因而在业务方法中可以假定所依赖的其他service已经准备就绪，从而减少了代码量。
HiveMind通过在配置文件中为service声明Interceptor而在一定程度上提供了AOP的功能。目前只提供了LoggingInterceptor。
HiveMind建议使用javassist来开发Interceptor，这种技术有利于提高运行时性能，但也增大了开发难度。如果使用JDK proxy，则开发难度较低，但因为使用反射技术而导致运行时性能下降，同时不能被javassist识别，在配置文件中必须将JDK proxy interceptor放在javassist interceptor前面。
HiveMind是多线程安全的。在开发自己的service时，建议使用默认的singleton生命周期模型，并且保证自己的核心实现是多线程安全的。为了做到这一点，第一将service定义成stateless的，使用参数来传递状态；第二利用ThreadLocalStorage service来保存状态。
HiveMind提供了一个ThreadEventNotifier service来管理需要监听线程终止事件的listener。
HiveMind的service默认使用singleton生命周期，从而减少了对象的数目，降低了内存开销。
HiveMind采用lazy loading策略，只有在第一次调用某个service的业务方法时才会去初始化某个service的核心实现。如果需要强迫HiveMind在启动时就加载特定的service，可以在配置文件里将这个service声明为EagerLoad service的contribution。样例代码如下：
《contribution configuration-id="hivemind.EagerLoad"》
《load service-id="hibernate.SessionSource"/》
《/contribution》
HiveMind提供了强有力的XML配置文件。你甚至可以通过定义scheme元素来控制HiveMind怎么解析配置文件。HiveMind本身提供了大量默认值，配置文件结构也很简明，降低了维护开销。
针对Web开发，HiveMind提供了一个HiveMindFilter。这个Filter方法可以初始化HiveMind，在每个request到达时将Registry设为request attribute，并在执行完成后触发ThreadEventNotifier service的fireThreadCleanup()方法。
由于Service的核心实现仅仅是POJO，因而很容易使用一些mock object来针对每个service做单元测试。