SOA和组合应用软件程序
组合应用程序软件与面向服务(SOA)的解决方案共享了大量普遍的东西……
选择一个开发技术栈
将一个能够工作的技术栈放在一起来建立和维护组合的应用程序软件也许没有你想象中的那么恐怖和困难。就像现在大多湖的软件项目一样,至少有三个派系可以供你选择,他们是:微软,Java以及开源软件。在这篇文章中,我将使用微软的体系作为参考:
- 用户界面——网络表单以及扩展的应用程序标记语言(XAML)
- Web服务——ASMX以及窗口通信基础(WCF)
- 数据库——ActiveX数据对象(ADO)
- 工作流——工作流基础(WF)以及BizTalk
- 开发环境——Visual Studio.NET
需要注意的是,1)我们并没有足够的空间来详细描述如何部署这些技术,2)在每一个层上Java和开源软件也都有相应的支持的技术。
为好性能而设计
就像我在前面提到的,对于管理员来说,将组合的应用程序软件看作绩效的杀手,认为他们接触的系统都会降低生产率这件事是在自然不过的事情了。但是,这没有必要成为例子。下面有三个简单的步骤你可以采纳,从而保证你的应用程序软件的速度。
1.使用索引或者其他的优化过的查询——举例来说,如果你的组合的应用程序软件向财务系统发出了呼叫,想要找到过去的财务信息以及其他的一些信息,你一定要确保调用的服务是使用了索引或者是其他由底层应用程序提供的和性能相关的技术。
2.让用户决定何时找回数据——很多过于热情的程序开发人员给他们的组合的应用程序软件设计了这样的结构:当用户接口初始化装载的时候,应用程序将获得所有的可能的数据。但是,这将会严重的影响多系统的绩效,而且是非常没有必要的。举例而言,假设用户并没有想要或者并不需要看到一个已有记录的跨库数据,他将精力放在一个单一系统包含的数据当中。为什么要让用户决定何时以及是否去查询次要的和第三等的应用程序呢?
3.不要允许非法的审前调查——一个一定能够让应用程序软件(无论是组合的还是其他的)陷入困境的方法就是让用户拥有不受限制的查询权利。而在部署组合的解决方案当中这样做将会特别的危险。因为可怜的查询保护将会在同一时刻破坏多个数据仓。强迫用户将精力集中在主要的应用程序的记录当中然后在使用记录中的关键信息从而获得其他数据仓的数据的方式会比不受限制的查询要好得多。
安全的捣浆糊
安全是组合应用程序软件的开发人员以及管理人员经常(也是有理由的)十分关心的问题。对未经授权的访问(甚至更坏的,改写)次要的系统感到恐怖是非常正常的事情。谢天谢地,你可以通过很多的方法来减轻你的风险。
只发表只读权限的应用程序软件——这是大多数程序开发人员正常采用的第一步。尽管他并没有消除未经授权访问的潜在可能性,但是这样做的确阻止了不想要的数据修改的可能性。
依赖主要系统的安全模式——一个典型的组合应用程序软件是从一个主系统中出发的。例如,在这个例子中,组合的应用程序软件应该是从一个带有CRM包的客户记录的一个实例出发的。你可以假设如果用户正在从CRM包中阅读客户记录的信息,他们应该能够看到相关的财务以及次要系统当中能够提供的其他信息。
使用简单的安全仓库——如果你有时间,金钱以及纪律的话,这样做应该是最有效率的技术来在所有的底层系统中确保一致的安全政策的方法了。这也是一种理想的组合应用程序软件的支持方式。
结论
组合应用程序软件与面向服务的解决方案共享了大量普遍的东西,包括概念合和技术两个方面。实际上,组成服务的应用理所当然地取得了组合的资格。术语“组合应用“某些时候与具体的应用特性(如联合用户接口)相联系;尽管如此,以前对比组合设计和面向服务的原则的证据表明,组合和面向服务应用的协同是不可否认的。我们只需要提醒我们自己面型服务的设计的基本的颂歌就是服务必须是具有内在的组合性。
TechTarget独家授权文章,严禁转载
- 本文关键词:

