利用企业服务总线进行物联网数据处理

### 利用企业服务总线进行物联网数据处理 #### 1. 引言 物联网（IoT）是通过互联网等知名网络相互连接的多个物理设备或嵌入式小工具的集合。这些设备在访问和服务其客户端时，需要遵循相同的准则。在不同设备之间的互操作性、数据处理的集中协调以及资源利用等方面，存在着诸多挑战。 例如，开发人员在处理应用程序时，会产生大量新的、快速变化的数据类型，包括结构化、半结构化、非结构化和多态数据。处理这些不同类型的数据是一项具有挑战性的任务。如果一个应用程序只需要处理其中一种数据类型，也会在识别数据类型和格式时产生很多歧义。 企业服务总线（ESB）是一种软件框架，它在通用和共享平台上提供多种服务集成。ESB还支持多种数据格式和类型，有助于任何服务识别其格式。它还引入了企业集成模式（EIP），当需要处理多种类型的数据时，可以使用ESB来实现当前的解决方案。 近年来，对近场通信（NFC）、传感器网络等技术的开发兴趣大幅增加。随着物联网在当今世界的日益普及，将不同设备发送的数据高效处理并与物联网平台融合变得至关重要。主要任务是提供一个集成平台，帮助处理数据及其格式。在许多应用中，即使是最轻微的延迟也可能会带来问题，而使用ESB可以有效地提高数据传输效率。 #### 2. 企业服务总线 企业服务总线（ESB）本质上是一种架构，是一套用于在类似总线的基础设施上集成多个应用程序的原则和规则。有各种ESB产品，它们都能让用户构建这种类型的架构，但实现方式和提供的功能有所不同。 ESB架构的核心概念是在各种应用程序之间插入一个通信总线，使所有应用程序都能与总线进行通信。这样可以减少系统之间的耦合，使它们在总线上无需相互依赖或了解对方就能进行通信。ESB概念的提出是为了取代点对点集成，因为点对点集成随着时间的推移变得难以管理且脆弱。点对点集成会导致自定义集成代码分散在各个应用程序中，没有集中的方式进行跟踪或故障排除，这种情况常被称为“意大利面条代码”，并且它无法扩展，因为会在应用程序之间产生紧密的依赖关系。 ESB的主要职责包括： - 控制和监控服务之间消息交换的路由。 - 解决通信服务组件之间的争用问题。 - 控制服务的版本管理和部署。 - 管理冗余服务的使用。 - 提供消息和事件排队与排序、安全或异常处理、事件处理、数据转换和映射、确保良好的通信服务质量以及协议转换等服务。 #### 3. 集成核心原则 将ESB架构映射到五个集成核心原则： |原则|说明| | ---- | ---- | |服务集成|将许多现有的细粒度组件组合成一个更高阶的复合服务，以实现适当的服务粒度，促进基本组件的可管理性和重用。| |协议转换|在标准数据格式和ESB每个连接器所需的特定数据格式之间进行数据转换。标准（或规范）数据格式大大简化了大型ESB实施中与转换相关的要求，因为其中有许多提供者和消费者，各自具有不同的数据格式和定义。例如，在CSV、Cobol与JSON或SOAP/XML之间进行格式转换。| |合并传输|在多种格式（如JMS、JDBC和HTTP）之间进行传输协议协商。| |中介|解释不同的接口，原因包括：（a）合并不同的服务版本，以与现有服务兼容；（b）支持底层服务组件的多通道实现。可能会同时涉及多个接口，以使用标准格式（如SOAP/XML）处理同一组件。| |非功能一致性|包括在处理服务时应用的安全和监控策略的一致性。此外，可以通过插入多个服务实例到ESB来实现可扩展性和可用性，提高吞吐量（从可扩展性角度）并消除单点故障（SPOFs），这也是实现可用性的主要目标。| #### 4. 服务建模与实现 ##### 4.1 建模如何改进面向服务的架构 面向服务的架构（SOA）的强大之处在于它能够通过业务流程的重用和集成来实现业务的敏捷性。SOA通过两种方式实现这一点：（a）鼓励围绕可重用的服务组织解决方案，这些服务封装了与实现分离的功能能力；（b）提供管理功能能力之间耦合的方法。 建模可以缩小当今业务需求与基于服务部署的解决方案之间的差距。SOA在服务中对数据处理的抽象级别进行建模，使人们能够专注于业务目标，以实现高可重用性和可用性。这种开发方法可用于在Java（J2EE）或IBM CICS等平台上实现SOA的可扩展性、可重用性和可用性等特性，有助于满足业务功能和非功能目标的敏捷性要求。 “面向服务的架构（SOA）”这个术语有多种含义。从业者通常用它来定义一种架构风格，并描述一种使基于该架构风格构建的IT系统能够运行的通用基础设施。这些以技术为重点的观点很有用，但仅靠它们是不够的。 为了发挥其潜力，基于SOA的IT基础设施（或SOA）需要与业务相关，即由业务驱动并为支持业务而实施。SOA解决方案需要以与它们所满足的业务需求相关的方式进行设计。如果业务需求被记录在多个描述Web服务集合的XML文档中，这将很难实现。 我们需要一种方法来规范业务需求并提高抽象级别，使SOA更接近业务服务，以及这些服务如何满足业务的目标和目的。这样，部署的解决方案就能与预期的业务价值相联系。同时，我们需要一种方法将业务关注点与支持它们的SOA平台隔离开来。 这些目标可以通过建模和模型驱动开发（MDD）来实现。模型使我们能够抽象掉实现细节，专注于驱动架构选择的问题。在一定程度上，我们所描述的方法将SOA的一个基本原则应用于SOA解决方案的开发：松散耦合和关注点分离。在这里，我们将业务分析师和IT人员的职责和任务清晰地分开。 通常，业务分析师关注的是实现业务愿景所需的业务运营和组织要求。他们通常不涉及（或没有足够的技能来处理）IT方面的问题，如内聚性和耦合性、重用性、安全性、分布性、数据完整性、持久性、故障恢复、并发性等。此外，业务流程建模工具通常不具备解决这些问题的必要能力，即使具备，它们也不太可能成为业务分析师有效的