cobra - 2008-9-2 12:27:00
考虑这样一个场景：你为之工作的公司是由完全独立的站点组成的联邦，而且在各种不同平台上用了半打不同编程语言来实现。每个独立站点都有其自己的数据库与模式，被拥有不同技术集合的各个团队管理，分布在美国和欧洲的八个站点上。别忘了，公司还在扩张。
你的任务？使这些截然不同的系统能彼此之间方便快捷的共享关键数据。
你的设计准则是：
Atom
Atom由两份规范组成：Atom聚合格式，它基于XML定义了描述web feeds的语言；Atom发布协议，它描述了检索和操纵feeds的一种RESTful HTTP协议。
Atom被认为是RSS（Rich Site Summary，富站点摘要）的接替者，后者通常包含了人为撰写的内容，比如博客条目。因此，一个Atom条目或feed（XML元素和属性）内部结构传达了诸如作者、语言、标题等发布内容的语义。可别被这一点给骗了；Atom条目非常适合将所有类型数据作为有效负载进行传送。
Atom条目是数据记录个体，Atom feeds是条目的列表。因为Atom是RESTful协议，所以对资源的访问是通过对标识资源（这里指的是条目和feeds）的URI执行HTTP方法来完成的。举例来说，获取一个博客条目的feed可能是通过对http://your-atomserver/entries/myblog这样的URI执行GET方法来完成的，而响应可能会是：
Code
Atom还支持可被应用于条目的类别概念。类别是任意的字符串标签，可被应用于条目，使其成为某个分组的一部分。然后，可修改Feed URI包含过滤功能——只从feed返回那些应用了特定类别的条目。
有些术语在Atom上下文中具有特殊含义。条目被组织成固定的两级层次结构：工作空间和集合。工作空间包含着一定数量的集合，集合包含着一定数量的条目。一个feed的URI由其工作空间和集合组成。
http://your-atom-server/workspace/collection
而一个条目的URI就由工作空间、集合和条目id来组成。这一标识符在包含该条目的集合内必须是唯一的：
http://your-atom-server/workspace/collection/entryid
像RSS一样，Atom也为web聚合框架提供了基础。支持Atom的客户端有很多，包括浏览器，新闻阅读器，以及几乎每种流行语言中的可编程客户端。再加上，Atom实际上是建立在HTTP与XML之上的一个精简约定集合，因此几乎任何支持web的编程平台都可以很容易地访问它。
扩展和分层协议
核心Atom协议描述了操纵feed和条目的基本操作，错误报告与处理的方法，并特别提供了扩展概念。Atom扩展是可在Atom XML文件中出现的附加XML元素和属性，以及可被应用于URI的附加HTTP请求参数，它可被用来修改支持Atom的服务器的行为。两个重要的扩展是：
当你不再将Atom条目局限于博客与新闻feed等web内容，并将其扩展到一般性的数据管理时，你就得到了Atom存储；一个由互联Atom条目组成的通用数据存储，你可以用Atom发布协议来编辑它，用OpenSearch来搜索它。AtomServer正是在这样的期望中成长起来的：利用这一策略实现对我们数据的分布式访问。
数据访问的分布式控制
使用Atom协议的好处之一就是其系统内含的分布式特性。在AtomServer里，我们将分页概念与向服务器轮询feed更新的机制相结合，限制了每次请求返回的条目数量。客户端最初从头请求feed，接着按页请求数据，直到没有新数据。之后，客户端需要定期检查新数据（例如，在上次成功处理的数据之后，是否有新的一页数据传送？）
每次变更的时候，Atom都会用一个递增的计数器来标记每一个条目，而客户端被要求为每个它请求的feed保存被处理的计数器的最后一值。在随后对feed的轮询时，下一页数据的起始位被设置成上一页的终止位。这一方法能够有效应对使用AtomServer来处理大容量、快速变化数据的场景。
当你不使用起始位“拉取”feed，它将默认从0开始。举例来说，
GET http://your-atom-server/widgets/acme
将返回http://atomserver.org/namespaces/1.0/名字空间中一个名为endIndex（终止位）的扩展标签作为这个feed的子元素。它将包含当前检索页的最后一个标志位：
<as:endIndex>23</as:endIndex>
在下次轮询时，这个数字将被作为start-index（起始位）查询参数传送：
GET http://your-atom-server/widgets/acme?start-index=23
当被请求页没有新数据了，服务器将会返回一个304 NOT MODIFIED（304未修改）响应。该信号表明，在请求下一页数据之前最好等待一段可配置的轮询间隔时间。
（文/Bryon Jacob and Chris Berry 译/黄璜 出处/Infoq）
你的任务？使这些截然不同的系统能彼此之间方便快捷的共享关键数据。
你的设计准则是：
- 高传输能力——该服务在启动后每天需要传送大约1M的数据块。
- 事务的正确性——作为所有客户端数据的权威来源，该服务必须是精确的。
- 弹性——当数据因格式变更而重新发布时，该服务必须能够方便地进行无缝升级。
- 松耦合——对于如此多的系统，每个都必须能自我独立管理。
- 可采纳——对于以各种语言(Java、C#、PHP、Ruby和ColdFusion)实现的客户端而言，采纳该系统的门槛必须足够的低。
- 自适应性——该系统必须能够支持多种不同类型的数据并能按照需要进行扩展以增加数据类型。
Atom
Atom由两份规范组成：Atom聚合格式，它基于XML定义了描述web feeds的语言；Atom发布协议，它描述了检索和操纵feeds的一种RESTful HTTP协议。
Atom被认为是RSS（Rich Site Summary，富站点摘要）的接替者，后者通常包含了人为撰写的内容，比如博客条目。因此，一个Atom条目或feed（XML元素和属性）内部结构传达了诸如作者、语言、标题等发布内容的语义。可别被这一点给骗了；Atom条目非常适合将所有类型数据作为有效负载进行传送。
Atom条目是数据记录个体，Atom feeds是条目的列表。因为Atom是RESTful协议，所以对资源的访问是通过对标识资源（这里指的是条目和feeds）的URI执行HTTP方法来完成的。举例来说，获取一个博客条目的feed可能是通过对http://your-atomserver/entries/myblog这样的URI执行GET方法来完成的，而响应可能会是：
Code
Atom还支持可被应用于条目的类别概念。类别是任意的字符串标签，可被应用于条目，使其成为某个分组的一部分。然后，可修改Feed URI包含过滤功能——只从feed返回那些应用了特定类别的条目。
有些术语在Atom上下文中具有特殊含义。条目被组织成固定的两级层次结构：工作空间和集合。工作空间包含着一定数量的集合，集合包含着一定数量的条目。一个feed的URI由其工作空间和集合组成。
http://your-atom-server/workspace/collection
而一个条目的URI就由工作空间、集合和条目id来组成。这一标识符在包含该条目的集合内必须是唯一的：
http://your-atom-server/workspace/collection/entryid
像RSS一样，Atom也为web聚合框架提供了基础。支持Atom的客户端有很多，包括浏览器，新闻阅读器，以及几乎每种流行语言中的可编程客户端。再加上，Atom实际上是建立在HTTP与XML之上的一个精简约定集合，因此几乎任何支持web的编程平台都可以很容易地访问它。
扩展和分层协议
核心Atom协议描述了操纵feed和条目的基本操作，错误报告与处理的方法，并特别提供了扩展概念。Atom扩展是可在Atom XML文件中出现的附加XML元素和属性，以及可被应用于URI的附加HTTP请求参数，它可被用来修改支持Atom的服务器的行为。两个重要的扩展是：
- OpenSearch——定义了一个搜索协议，包括确定支持哪类搜索的服务器内省方法。一个支持OpenSearch的服务将会将搜索结果作为Atom feed返回，其中每个结果被表示为一个条目。
- Feed分页——为基于时间的数据提供了分页功能，定义了Atom feeds的下一页和上一页链接类型，这样客户端就能使用它在多页Atom feed中前后翻页。
当你不再将Atom条目局限于博客与新闻feed等web内容，并将其扩展到一般性的数据管理时，你就得到了Atom存储；一个由互联Atom条目组成的通用数据存储，你可以用Atom发布协议来编辑它，用OpenSearch来搜索它。AtomServer正是在这样的期望中成长起来的：利用这一策略实现对我们数据的分布式访问。
数据访问的分布式控制
使用Atom协议的好处之一就是其系统内含的分布式特性。在AtomServer里，我们将分页概念与向服务器轮询feed更新的机制相结合，限制了每次请求返回的条目数量。客户端最初从头请求feed，接着按页请求数据，直到没有新数据。之后，客户端需要定期检查新数据（例如，在上次成功处理的数据之后，是否有新的一页数据传送？）
每次变更的时候，Atom都会用一个递增的计数器来标记每一个条目，而客户端被要求为每个它请求的feed保存被处理的计数器的最后一值。在随后对feed的轮询时，下一页数据的起始位被设置成上一页的终止位。这一方法能够有效应对使用AtomServer来处理大容量、快速变化数据的场景。
当你不使用起始位“拉取”feed，它将默认从0开始。举例来说，
GET http://your-atom-server/widgets/acme
将返回http://atomserver.org/namespaces/1.0/名字空间中一个名为endIndex（终止位）的扩展标签作为这个feed的子元素。它将包含当前检索页的最后一个标志位：
<as:endIndex>23</as:endIndex>
在下次轮询时，这个数字将被作为start-index（起始位）查询参数传送：
GET http://your-atom-server/widgets/acme?start-index=23
当被请求页没有新数据了，服务器将会返回一个304 NOT MODIFIED（304未修改）响应。该信号表明，在请求下一页数据之前最好等待一段可配置的轮询间隔时间。
（文/Bryon Jacob and Chris Berry 译/黄璜 出处/Infoq）