安全

　　每个想要连接到集成层的应用需要声明自己，通过使用WEB服务安全用户名令牌(WS-Security UsernameToken) (身份认证)的方式。 对我们暴露出来的大多数服务那已经足够，在极少数案例中，这种应用必须具有明确的许可(授权)。

　　不是说内部使用(只有在我们收到某个外部客户的请求时)就是可信的，我们要求消息头部和载荷的某个部分具有署名。

　　转换

　　假设不是所有的应用都连接到框架'说同样的语言'(如以前的博客中所提到的)，明显有数据模型转换的需求——我们最常被使用的特性之一。一个不太普通的是分裂特性，它使得一个大的消息被划分成为一些小的部分成为可能。

　　数据存储

　　最后一些特性对已经提到的那些更具有支持的作用。我们提供使用于测试和bug查找会话中的日志功能，以及在需要存储整个消息时的持久化功能。后者经常与再发送结合起来使用(这对上面描述的有保证的交付特性而言是必须的)，但也在审计的需求中使用。

　　结论

　　这些特性的大多数从我们框架的第一个版本就一直伴随着，并且经历时间考验证明了它们的通用性质。在一些案例中我们不得不做一些改动，即使现在也有一两个特性我们可能在未来用不同的方式实现。还有一系列的额外的特性，但已经非常少，这被我看作是在这里我们已经有了完美结束的标记。

　　这就是第四篇;下一次我将谈论一些我们提供给我们项目团队的，更多特定范围内的成果。