存储的MessageItems往往需要到期或自动回收，来处理用户不在的情况。举例来说，某个用户突然断开，将无法收回一个开始的MessageItem，他们的声音正在被发布，即使MessageItem现在是无效的。NodeConfigurations提供设置来管理MessageItem过期：
- NodeConfiguration.persistItems：如果MessageItem不再需要在它发布后立即提供给迟来的用户，设置NodeConfiguration的persistItems值为false。 服务器然后会不存储MessageItems。
- NodeConfiguration.userDeendentItems：如果MessageItem只有在相关用户在房间里时有效，设置一个node的NodeConfiguration.userDependentItems为true，一旦该用户断开连接，自动收回该node上的用户发布的任何项目，。其他订阅了的用户将接收到CollectionNodeEvent.ITEM_RETRACT 事件，显示该用户的MessageItems被移除。
- NodeConfiguration.sessionDependentItems：如果MessageItem是只在当时的房间是活动的才有效，一旦房间是空的，自动收回，请设置为true。
由于简单itemID存储规则，开发人员可能会为他们的共享模型，挑选需要的itemID战略。支持三种NodeConfiguration.itemStorageSchemes。设置NodeConfiguration的itemStorageScheme为以下之一：
- NodeConfiguration.STORAGE_SCHEME_SINGLE_ITEM:一个"单独MessageItem"模式
在大多数node，一个常见的模式是：只记得node最后一条发布的消息（例如日志中的文字）。在这种情况下，应用程序只需要选择一个itemID，所有的发布者都用它来写，它将会被后来的发布而覆盖。
- NodeConfiguration.STORAGE_SCHEME_QUEUE: 列队项目
聊天，添加剂名单等，都需要一个存储模式：以后每项添加到队列项目，存储在服务器上。客户在发布的时候不需要itemID，因为它将自动在服务器上生成，方式类似于数据库表中的自动递增的主键。
- NodeConfiguration.STORAGE_SCHEME_MANUAL: 关联数组或哈希表
如果客户有能力建造自己的唯一的itemIDs的MessageItem，并希望使用此作为关联数组或散列表，然后服务器将使用任何itemIDs发布。
3.1.5.2 MessageItem存储
NodeConfiguration.persistItems决定信息是否存储在服务器上，以便迟来的用户接收。但是，它通常的情况是，一些MessageItem的不需要储存，以捕捉到共享模型全部的状态。例如，用户在一个共享日志上工作，就像在来回发送MessageItems中全部的文本内容，所以实际上我们只需要最后的一个MessageItem，就可以知道日志的全部内容。
为了解决这个问题，MessageItems存储在服务器上，根据其itemID作为关联数组或哈希表。发布一个MessageItem带一个已经储存在node上的itemID，取代服务器上现有的MessageItem。在某些情况下，用户不应该被允许修改另一个发布者发布的项目（例如，聊天消息）。设置NodeConfiguration.modifyAnyItem为false，将确保用户只可以替换在服务器上自已的MessageItems的node。唯一的例外是，一个所有者用户总是可以修改其他用户的项目。
使用node*.retractItem*，存储的MessageItems可能会被删除，受与发布相同的权限规则支配。
共享模型往往需要能够表达是否当前用户和在房间里的其他用户完全取决于最新。如果一个node已被配置，在其 NodeConfiguration中persistItems就被设置为true，该node将MessageItems存储在服务器上，允许迟来的用户接收他们，然后同步到当前的状态。一旦它建立，collection node的isSynchronized为flase，这意味着它尚从该服务器上取得所有详细资料。
当一个迟来的用户订阅一个collection node，用户收到所有node和 NodeConfigurations，用户角色和存储的MessageItems，才可以发布或修改任何collection node的任何方面。当从服务器上收集这些信息，collection node API将触发早期事件，来传达“追赶”状态（所有同时还拥有isSynchronized 为flase）这些事件包括：
- CollectionNodeEvent.NODE_RECEIVE
- CollectionNodeEvent.ITEM_RECEIVE
- CollectionNodeEvent.USER_ROLE_CHANGE
这些事件跟随CollectionNodeEvent.SYNCHRONIZATION_CHANGE事件指示用户现在”up to state”与 rest of the users之后。
消息的基本单位是MessageItem，描述为com.adobe.rtc.messaging.MessagItem。
MessageItem是任何通过node发布命令的有效负荷。发布者通过 CollectionNode*.publishItem发布Items，通过侦听CollectionNodeEvent.ITEM_RECEIVE事件来接收MessageItems。一个MessageItem可能包含一个body：所需的负荷数据类型以及其他信息元数据，一旦它发布了，发布者的userId包含在里面，等等。
提示：item可以是一个单一字符串或数字，也可以是一个分层次的复杂类。 参考发送复杂的items作为消息的ComplexObjectTransfer例子。
发布一个item到一个node，意味着其它订阅了这个 collection node的用户，他的accessModel （访问级别）高于或者等于这个node提供的NodeConfiguration，那么他就可以接收到消息。私人消息的话就需要指定recipientID，并且它的NodeConfiguration中的allowPrivateMessages要设置为true。
One of the AFCS’s basic tenets is that every messaging call made by any client requires permissions
validation. A user role is a numerical expression of a user’s permission’s “level” for a given room element.
Elements of a room include all of the elements in our three level hierarchy:
The room itself (sometimes referred to the “root” user role)
A collection node
A node within a collection node
Messaging and Permissions
Cocomo Developer Guide MessageItems 27
User roles for a user cascade down from the room level to its collection nodes and on down to its
individual nodes. For example, a user may be a viewer for the room at large but is designated as the note
taker for a specific note pod. In this case, the note pod’s collection node can be set to have role value for
that user which is higher than the user’s overall role within the room (such as UserRoles.PUBLISHER).
Other users for the pod’s collection nodes and nodes would just inherit their role from the room.
A node’s NodeConfiguration has two specific settings which intersect with user roles: accessModel
and publishModel. Respectively, these values express the minimum user role required to subscribe and
publish to that node. This allows hosts to lower or raise the role requirements for node users to perform
publish and subscribe actions. Most of the shared Model and collaborative classes have API’s for changing
both the publishModel and accessModel.
The default user roles are enumerated on the class com.adobe.rtc.messaging.UserRoles and
consist of the following:
UserRoles.VIEWER: This is the default NodeConfiguration value for accessModel which allows
subscribing to but not publishing messages.
UserRoles.PUBLISHER: This is the default NodeConfiguration value for publishModel which
allows publishing and subscribing, but does not allow configuration.
UserRoles.OWNER: This is the role typically provided to the host or moderator. Users with this role can
publish, subscribe, add and remove both collection nodes and nodes, configure nodes, and set user
roles.
UserRoles.OWNER is the highest role possible, is able to both publish and subscribe to any node, as well
as being the only users who may create and delete nodes and collection nodes, and modify user roles and
NodeConfigurations. The owner is usually the who can add new collection nodes or new functionality
to a room.
While NodeConfiguration settings for permissions often stay static, user roles are by nature dynamic -
they are first assigned as a user is validated and enters the room. Subsequent changes to user roles on
collection nodes and nodes typically occur as a host user grants higher (or lower) role values to users as
the result of the situation at hand.
Tip: The SDK’s CustomRoster example demonstrates how to manipulate user roles.
NodeConfigurations 是node配置的基础。每个node都有一个NodeConfigurations ，通常是默认设置。NodeConfigurations 代表com.adobe.rtc.messaging.NodeConfiguration 类，用在CollectionNode API的方法中。
NodeConfigurations通常是静态的。虽然他们只设立了节点创建时间，他们也可以动态修改。在两种情况下，重要的是要注意，只有ollection node的所有都者才可以添加，删除，或在在一个node上设置NodeConfigurations。
提示：获取更详细的情况请参考AFCS API：com.adobe.rtc.messaging.NodeConfiguration和com.adobe.rtc.sharedModel.
AFCS的共享模型的逻辑目的地被称为：CollectionNodes and Nodes。因此，Adobe的RTC房间基本上由三个层级组成：房间它自已、它的CollectionNodes（相当于容器） 、CollectionNodes的 Nodes。
3.1.2.1 CollectionNodes
在AFCS房间中Collection nodes是主要的层级。总的来说，各个共享模型（例如：chat容器或者UserManager），在房间根中表现为一个collection node。任何共享模型类有可能实例化和管理它自已的collection nodes。同样地在AFCS API参考中描述的，开发者有他们的共享模型使用的主要类是com.adobe.rtc.sharedModel.CollectionNode。注意，只有房间的所有者才能添加新的collection nodes到房间或者修改现存的。
3.1.2.2 Nodes
顾名思义，collection nodes被细分为一组Node。每个collection nodes包含了多个Node。这些MessageItems可以被储存在服务器上。在Room Console（房间控制台）中你可以查看所有collection nodes，它们的nodes，和message items 。控制台提供了直观的界面添加、删除、修改这些项目。这些透明的数据，方便了调试。
正像一个collection node映射到一个共享模型，一个node 大致映射到一组在该模型中的API，具有相同的权限和存储。例如，聊天容器，可有一node，所有用户可以发布和访问（即公共聊天），但也需要可以发送私人信息。在实践中，它可能像用户只发送一个消息给房间的所有者。在这种情况下，您将创建一个单独的node，任何人都可以发布，但只房主可以访问。对这种信息的权限进行验证两次：一次是在客户端框架，一次在服务端。
Nodes 有以下功能：
- 它们支持NodeConfigurations。这是描述node设置：消息的权限和储存策略。
- 它们允许设置用户角色。
- 它们可能发布、订阅和在服务端储存MessageItems，依照它们的NodeConfigurations。迟来的用户可以接收到任何储存的消息，在collection node表明已同步后。
建立一个共享模型可以完成前面提到的职责，我们需要提供一个做法：
- 为消息建立一个逻辑目的地
例如，一个chat容器想要从其它用户的相应的chat容器发布和接收消息，但是不是从whiteboard(白板)或者note(日志)容器过来的消息。
- 提供许可设置，描述哪个角色可以发布和接收消息
例如，默认，任何人都可以发布聊天消息，但是只有发布者角色的用户才可以在白板上绘画。相反，房间的所有者可以决定，在协作过程中，降低使用白板所需的角色。
- 管理关于目的地的用户角色
类似前面，一个所有者可能希望提升或者降低指定的用户的角色，要么做为整个房间或者特定的组件。
- 定义消息的储存策略
不是所有的用户都是在同一时间登录的。一个新用户加入时，一个聊天谈话可能已经举行了一个小时了。为了让用户聊天有一个正确的共享模型，用户必须接收从他登录之前已经发送的所有消息。一个共享模型，必须定义是否会被存储，以及如何存储，以便处理迟到者。当它被建立，共享模型需要能够告诉它什么时候同步了，这意味着它已收到所有储存的消息，并跟上房间的当前状态。直到共享模型同步后，它可能不希望接受任何命令来改变其状态。
开发者通过建立和扩展一个共享模型（shared model）来建立自定义应用程序。在MVC设计视图中，一个模型的职责包括：
- 展现一个应用程序的状态（这里指组件的状态）
- 提供API来查询和修改状态
- 当状态改变时通过侦听器发出通知
在AFCS中，在“模型”这一概念是增强的“共享模型”的概念。一个共享模型添加 以下的职责：
- 它实行的是当前用户的许可使用特定的API。例如，共享模型必须知道用户是否有权在白板上绘画，或者向其他人发送聊天信息，并必须通知任何听众应用户的权限变化
- 当通过API呼叫改变它的状态，一个共享模型将通过产生的一个消息发布到服务器，传达潜在的改变。它并不立即反映它的状态。
- 当服务路由传入信息到共享模型中，它解释为消息，更新其状态以反映任何变化，并通知了任何地方接收者改变。
图 12 Shared model design pattern
图12展示了基本的流程。从controller中调用一个方法，传递消息到服务器，从服务器返回一个message事件。从这个意义上讲，当前（本地）用户收到的这种变化，一个远程用户也以相同的方式收到：它必须并从服务器往返，以便有效更新状态。处理所有共享的状态更新，这样的方式简化了RTC的应用程序的设计。
