目前为止，已经讨论了关于开发活动的目标与挑战，但现在更多的关注于集成框架本身，以及它给那些使用它的程序带来了什么。

一旦一个参与方(可能是服务消费者或者服务提供方)连接到我们的框架，它能直接从我们提供的丰富的开箱即用的函数中获得好处。这些“通用特性”正是我们期待从一个(逻辑的)ESB获得的东西，它们部分的基于扩展的企业服务总线模式。

由于我们的项目是敏捷驱动的，特性仅在它们被需要的时候开发。有时候，经过设计和开发阶段，我们发现了一个更好的处理方法，有时候猜想到一个特性可能会发生的问题，会被以一种完全不同的，超越我们处理范围的方法解决。但最终我们成功的实现了大约20个特性，可以粗略的被分为五种类型：路由，健壮性，安全性，转换和数据存储。

路由

我们一个主要的目标是将消息从A传送到B，但不需要A知道现在B存在于哪里。为了做到这一点，我们对WEB服务地址(WS-Addressing)标准做了扩展使用。我们框架中的一个组件，路由服务，使用消息头部的信息去决定下一跳(hop)是什么(在这个案例中hop是另一个框架组件)。大多数时间里，一个消息在它进入集成层的时候被交付到后方，我们称之为简单路由。

然而，一旦需要执行一些特殊的动作时(比如像数据模型转换)，消息会绕道到达某个不与外部世界联系的框架组件。我们将其归类为中间服务，它们对周围情况不知——这意味着它们没有任何线索，任何关于它们被调用的这个上下文的线索。消息继续它的路径所必须用到的信息，同样也是地址头部的一部分，这使之成为高级路由。

一种特殊类型的高级路由是分发，它通过以最基础的形式使用WEB服务通知(WS-Notification)， 使得将一个消息在同一时间发送给数个订阅者成为可能。最后优先级路由是一个确保一个消息在其它消息之前的特性，这么说吧——当处理一个柜台边客户等待的服务，同时又有大量的负载正在处理，这个时候它是非常有用的。

健壮性

在投递消息的时候没有错误，或者至少能在它发生的时候处理那个情况(异常管理)，显然这是极其重要的。当我们接收到一个消息时的第一件事情就是检查它是否符合我们实施的工业的和设计的标准(技术验证)。有时候消费者/发布者不想等待(函数式的)回答，但仍然想获得消息是否在技术上有效的信息，那种情形下我们给他发送一个说明那一点的响应(技术验收)。

我们有两个特性处理最大负载：限流保证了集成层只接收它可以处理的那些，而缓存保证了我们不会淹没于连接的应用。与第二个类似的是延迟交付，用在我们预先知道后台不可及的时候。

但目前这些类型特性中最重要的是担保交付。我们试验了双向的变化(使用服务可靠消息传递WS-RM)但最终选定了单向的实现，这意味着在我们发送消息之前我们首先是存储它，如果我们收到一个HTTP错误代码我们会再次发送它。

最后(实际上至少因为它很难被使用)具有对发送消息的句法校验是可能的。但正如我们喜欢遵循的波斯托定律(Postel’s law也称作健壮性法则)，我们感到消费者有责任确保消息首先是有效的(你能够想象从我们的观点来说这需要一些推销)。唯一的例外就是载荷被框架改变的时候。

安全

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

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

转换

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

数据存储

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

结论

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