应用与企业架构
原文链接: https://www.nv5geospatialsoftware.com/Learn/Blogs/Blog-Details/apps-and-enterprise-architectures
21839 评价本文:
暂无评分
应用与企业架构
匿名作者 2013年4月18日，星期四
在地理空间情报领域，近期关于应用、应用商店乃至应用商城的讨论层出不穷。话题涉及应用的创建者、管理者与部署者，应用开发者的报酬机制，以及终端用户如何获取应用。我不禁思考，从软件或系统工程师的视角来看，应用究竟应该是何种形态。
让我们将地理空间情报应用定义为：用于执行地理空间数据可视化、处理或分析的基于网络或移动端的应用程序。去年，我与同事 Pat Collins 曾撰文探讨过应用的构成（参见《应用——名称背后的内涵？》与《应用的解剖……或“冰山一角”》）。我们在文中讨论了应用的组成部分，并指出应用往往比表面看来更为复杂。这里讨论的应用，是指那些依赖于用户界面之外数据与服务的类型。Pat 和我曾以银行应用和咖啡店定位器为例——它们看似简单，实则依赖众多服务（如地图服务和 GPS），而这些服务并非运行应用的设备或系统本地所提供。许多地理空间情报应用也属于此类。
访问和消费基于网络的数据与服务的能力，已成为衡量软件的新标准。许多组织正积极开发企业级的地理空间软件与服务，因为相比管理众多分散的桌面实例，这类解决方案更易于管控。此类架构还能在数据共享、处理流程共享和工作流协同方面提升效率。由于其分布式特性，这些解决方案非常适合云端部署。
图 1 展示了一个可能用于部署地理空间情报应用的概念性企业架构。前端客户端负责提供用户体验或用户界面——这通常被用户视为“应用”本身。这些客户端可以设计得很简单，例如提供基于按钮的界面，让用户在无需理解构建答案所需的数据和处理流程的情况下，就能获得诸如“我可以在哪里降落这架直升机？”等问题的答案。客户端也可以提供功能强大的用户界面，允许用户对可用数据执行复杂搜索，并明确控制地理处理函数的每个参数设置。
中间件负责协调客户端与服务器上运行的服务之间的通信。为了保持客户端的简洁与轻量，中间件可承载业务逻辑，这些逻辑决定了地理处理函数适用的源数据和参数。有些人将中间件视为粘合应用程序并确保其正常运行的“胶水”。中间件并非总是必需，部分客户端应用或功能可以绕过中间件，直接连接服务器上运行的网络服务。
在服务器上运行的网络服务，才是复杂应用背后真正的“主力军”。这些服务可包括处理服务、影像服务、数据服务、地图服务、GPS 服务等。它们无需全部运行在同一台服务器上即可协同工作，实际情况通常也确实如此。尽管这看起来相当复杂，但终端用户对此并无所觉——这也正是应用显得如此简单、甚至有些“欺骗性”的原因之一。
标准化对于这类基于服务的架构的成功至关重要。REST 和 HTTP 等标准定义了各组件之间如何通信。而 WCS 和 WMS 等标准则规定了数据如何在组件间被请求和提供。
基于服务的企业架构非常理想，适合开发一系列应用，从而将地理空间情报能力交付给从野外部署的士兵和急救人员，到在华盛顿特区环线内工作的资深影像分析师等各类用户。这种架构的一个关键优势在于资源共享能力，例如数据和处理服务。想象一个场景：一小套地理处理服务通过多种客户端界面为众多不同的用户提供服务。根据个体用户的需求，有些客户端界面可能极其简单，而另一些则相当复杂。用户体验着不同的应用，但驱动这些应用的却是相同的服务。这正是目前关于应用讨论中，我认为尚未被广泛涉及的部分。我正在绘制一些支持单一服务对应多客户端模型的系统示意图。下周我将带着这些内容回来。同时，如果您对企业架构的哪些方面最感兴趣或希望进一步探讨，请随时告知。