应用解构
原文链接: https://www.nv5geospatialsoftware.com/Learn/Blogs/Blog-Details/apps-deconstructed
22608 评价此文章:
暂无评分
应用解构
匿名作者 2013年4月25日，星期四
上周，我讨论了部署地理空间情报应用的系统架构可能是什么样子（阅读应用与企业架构博客）。本周，我想重新审视这个话题，重点探讨构成一个复杂地理空间情报应用的组件。我将地理空间情报应用定义为用于执行地理空间数据可视化、处理或分析的基于网络或移动应用程序。下图展示了我尝试描述的应用组件及其在企业架构中的可能表示方式。
在此图中，应用用户显示在左侧，参与应用开发的开发人员显示在底部。应用使用的中间件、网络服务和数据显示在图表的中央部分，并托管在云端。此图的要点在于表明一个应用不仅仅是单一的软件。在设备或网络客户端界面上运行并在浏览器中显示的软件是一个更大的、相互关联系统的一部分。大多数复杂的应用都由多个软件组件构成。
让我们以图中的应用B为例。假设这是一个用户从应用商店下载到移动设备上的通视分析应用。当此应用运行时，它期望通过互联网（或云端）连接到特定的应用中间件，该中间件将访问图像、地图和分析服务以产生所需结果。通视分析应用最初呈现一张地图，用户可在其上选择感兴趣区域。中间件调用图像服务以定位相关格式正确的图像，然后调用通视分析服务。结果返回到运行在移动设备上的应用界面或客户端。如果追踪应用C和应用D的连线，你会发现它们的构建方式类似。我包含了应用A来说明应用直接连接到网络服务而无需任何中间件的情况。
构成应用的各个组件可能并非由同一开发人员或组织编写。一些组织可能只提供被多个应用使用的服务，例如地图服务。其他组织则可能利用这些服务来创建客户端和中间件，从而构建健壮的应用。这些不同的组件可能不在同一台服务器上，甚至不属于同一网络。标准的使用是这些分布式应用成功的关键。
在这类应用中，服务承担了大部分"繁重工作"。编写良好的服务可以在各种应用中使用，无论是交互式的还是自动化的。开发人员可以创建一组服务，以多种方式部署，满足广泛的用户需求。注意在图中，每个服务都是多个应用的组件。在我的通视分析示例中，支持交互式应用中通视分析的分析服务，也可以作为自动化流程的一部分，用于在所有图像入库时生成通视分析结果。
我对这种单一服务通过多种应用满足多种需求的模型所蕴含的可能性感到兴奋。我也好奇这些服务将如何从源代码控制到部署到企业环境中进行管理。