本文探讨了面向服务的体系结构(SOA)项目中的可视化技术，包括建立业务视角、业务与IT的一致性、中间件可视化、解决方案实现及管理和监视等方面。
正如老话所说的，一幅图胜过千言万语。在面向服务的体系结构（service-oriented architecture，SOA）项目的几乎每个阶段中，参与人员无论扮演什么角色，都要面临着“表明”其预期意图的挑战。换句话说，我们这些参与 SOA 的人希望找到适当的方法来可视化我们正在开发的系统的各个方面。
当然，在理想的情况下，我们使用某种级别的抽象来使得掌握预期的解决方案变得很容易。在更好的情况下，我们只需以任何方式重用作为我们在项目中的角色的一部分来开发的抽象。存在一些常用的技巧和技术可帮助您“可视化 SOA”，我们将在本文中探索其中一些技巧和技术。
近来，一切都从业务开始，业务也（通常）是任何 IT 项目投资的来源。业务还是在 IT 方面所做的任何事情的最终客户。那么，如果 SOA 是答案，您将从何处着手呢？在您开始确定可能需要哪些服务、可能接受哪些业务流程和如何将现有的系统集成到解决方案中之前，获取业务视图无疑是有帮助的。因此，这就是我们的可视化技术分析开始的地方。
通常，我们在 IBM® 鼓励客户使用一种称为组件业务建模的技术，从而创建他们的核心业务组件的可视化模型。该活动的结果之一是企业中所有核心业务组件的可视化表示形式，这些组件按能力和可靠性级别 (Competency and Accountability Level) 排序，如图 1 所示。
如上所示的组件图（针对一家虚构的汽车租赁公司而创建）还支持确定哪些领域迫切需要改进，以及哪些领域能够保证最佳的投资回报。类似如此的关系图对于可视化业务大有裨益，并且可用于在人员团队之间轻松交流“问题空间”。
面向服务的核心原则之一在于促进业务与 IT 之间的更紧密一致性。简而言之，您采用某个组件图，并使用诸如 IBM WebSphere® Business Modeler 等工具来开始对相关核心业务流程建模。这不仅为您提供了另一种形式的可视化，而且还使用了底层的正式技术模型。这样做的优点在于，您可以将该模型转换为不同的形式，从而直接有助于解决方案的创建，您将在下面进一步看到这一点。
图 2. WebSphere Business Modeler 中建模的业务流程
然而，首先也是最重要的是，业务流程模型允许您使用拖放工具，可视化地对流程进行描述和分解，直至达到服务概念开始表现出来的详细程度。
图 3. WebSphere Business Modeler 中的流程分解
在我们将这幅图片深入到 IT 世界之前，我们需要首先查看一下底层的基础。
项目中存在一个必须在其中定义 SOA 解决方案技术基础的阶段。这包括诸如企业服务总线（Enterprise Service Bus，ESB）等体系结构组件，以及诸如应用程序服务器和消息引擎等技术组件和产品。而且——您可能已经猜到了——使用可视化是该工作的关键方面。
在最高级别，您可以使用模式来帮助定义环境中存在的组件的范围和术语。例如，IBM 提供了用于电子商务的模式，图 4 显示了那些模式的示例。
然后，图 4 所示的模式视图发展为系统的特定方面的更具体图片。最终，您将向该图片中添加产品，以表明它们如何帮助构建基础，如图 5 所示。
在大多数情况下，这些虚拟化是相对简单的关系图，通常将它们插入 PowerPoint® 演示文稿。由于它们本质上只是图片，因此不会直接使用它们来生成代码（举例而言）或任何其他 IT 相关的构件，但是它们对于传达和记录任何 SOA 解决方案的基础极为重要。
为了将该信息转换为仍然能够可视化地进行构建的正式和标准化的模型，我们将求助于 UML 和 IBM Rational® Software Architect（或 Rational Software Modeler）。此工具使您能够可视化地创建整个解决方案的已开发模型；例如，包含拓扑的关系图、逻辑体系结构、系统上下文、用例，以及最终的类和交互关系图。
使用 UML 和 Rational 工具使您能够在某个可发展为具体模型和实现的抽象级别上构建解决方案。同样地，它提供了有关解决方案的每个部分的视图和透视图。
您可能以为，您已经准备好离开图片和关系图并开始编写代码了。您大概是对的。在您开发的几乎任何解决方案中都将存在自定义代码，而且并非一切都可以在抽象模型的基础上自动生成。但是您仍然可以尝试对系统的某些部分使用可视化开发：使用 IBM WebSphere Integration Developer 将业务流程实现为采用 WS-BPEL 语言来描述的服务编排。
类似地，您可以使用不同的工具来可视化地定义在企业服务总线中执行的中介流，具体使用什么工具将取决于特定的产品。图 8 是为 WebSphere ESB 构建的中介流的示例，同样使用了 WebSphere Integration Developer。
在使用 WebSphere Process Server 或 WebSphere ESB 时，您可以利用服务组件体系结构（Service Component Architecture，SCA），该体系结构提供了可视化的组件组装（同样是使用 WebSphere Integration Developer）。这允许您定义组件及其接口之间的依赖项和关系，以及定义协议绑定，这些协议绑定支持 SCA 模块与外部使用者和提供者之间的连接。
而且，还存在对所有这一切的若干好处：
- 可以更快地开发解决方案，因为可以使用拖放操作来聚合和开发服务及其他组件。
- 与将一切定义在 (Java) 代码中或定义为某个文档中的文本相比较，可以更快地做出更改。
- 更容易进行有关解决方案的交流，因为与阅读代码和/或文本相比，图片更容易领会。
上述要点不仅适用于实现阶段，而且适用于已经提到的解决方案创建的所有方面。
到目前为止，您已在该过程中的每一步使用了可视化和抽象——而且该过程在部署解决方案之后后并未结束。存在两个应用监视和管理的主要级别，即业务级别和 IT 级别。
在业务级别，您可以使用诸如 WebSphere Business Monitor 等环境来捕获运行环境中发生的相关事件，将这些事件与预定义的关键性能指标相关联，并以能够集成各种来源的信息的仪表板形式可视化这些事件。
图 10. WebSphere Business Monitor 仪表板
您在本文的示例中看到的可视化信息大部分是静态的。它们代表系统的快照视图，虽然各个地方也存在有限的支持来使得这些视图更加动态；例如，使用 Powerpoint 自定义动画和动画 GIF 文件。此外，上面所示的所有视图都是二维的。
要创建系统的动态和三维视图，我们可以向虚拟世界寻求帮助。在这样的世界——其中最常见的是 Second Life——中，您不仅可以显示运动的事物，而且还可以使用您自身的虚拟表示形式来从不同的角度实际查看这些事物，您只需在它们周围走动或飞行。您可以利用这些功能来创建真实 IT 解决方案部署的虚拟表示形式。
IBM 开发了一个有关如何完成此类虚拟表示形式的示例。该示例使用的应用程序从真实系统接收事件（部分地使用了公共事件基础设施），并使用一个允许控制某个位置的虚拟元素的 API 来将事件发送到 Second Life。这样，您就可以通过在虚拟世界中在真实系统周围走动并从某个角度进行查看，从而观察真实系统的实际结构和行为。
图 12. Second Life 中使用 DataPower 和其他产品的基于 ESB 的系统
最终，可以使用该环境来做的工作不仅只是观察某个系统。虚拟世界中的化身可以采取操作并将操作发送到真实世界中，并且可以直接将操作应用于真实系统。这使得 IT 操作员能够（可视化地）在他或她的数据中心周围飞行，并根据需要启动和停止组件，密切注意警报，对警报做出反应等等。把这看作是交互式仪表板的未来版本吧！
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
