作者为北大博士，从06年开始发表了一系列关于服务池，服务社区的论文。其个人主页：http://sei.pku.edu.cn/~liuxzh/chinese.htm
本论文发表在： Proceeding of Second International Symposium on Service Oriented System Engineering (SOSE 2006）
论文笔记：
S2：当前存在的问题，以provider为中心，是一种端到端的服务发现与订阅。发现时，主要为发现provider，如果需要比较Qos，则比较费时。
提出CoI的概念，将相似或相同功能的服务（Qos可能不同）聚集到一起，用户只需要与col发生关系即可，不需要与每一个满足要求的服务进行交互。而且能保证可靠性：如果一个服务发生问题的话，用另一服务来替换。
s3:论述了在加入Col的情况下WEB service三方在功能上的变化，对其框架的改进。以及面临的问题：1）coi的建立2）基于coi的发现与订阅3）coi的组织与协调等。
- 建立：有提前建立与根据需求建立两种，各有利弊。都涉及到三个问题：1以本体为基础进行服务的组织。2性能保证：功能保证其其功能相似。行为保证其逻辑关系的正确，在高一级的组合时可以进行替换。语义性能保证在验证和生效时能保持本义。3 功能测试：必须进行验证方能成为coi中的一员。
- 发现和匹配：从功能级与语义级两方面进行匹配。动态订阅，可接受多个请求。
- coi的管理：主要是对服务的验证（用agent来实现）及对列表的维护与更新。实施的策略：一是管理社区自身，如基于本身限制服务社区的成员，另一是组织成员的交互与关系的管理。如：状态的复制、同步与补偿机制等。
S4：相应框架并介绍了每部分的功能。Service Broker，Management，Monitoring，Policy Control，CoI Core，selection engine.在selection eingine能够满足特定请求的任务构成服务池（service pool)。它还执行如异常处理、补偿机制，协调等方面的功能。CoI Core是针对多用户的，所以它还承担着协调各消费者之间的关系和各服务成员之间的关系，担当着“社区管理员”（community portfolio）的职务。
s5:实验：从可靠性和响应时间两个属性去考虑，用coi与随机选择相比较。
总结：从coi的角度定义了一个发现和订阅服务的框架，整个框架需要做哪些工作，可分成哪些功能模块等。
