SOA实践秘诀

注:本文为转载。

在服务导向架构(SOA)底下,我们的目标是将所有具备价值的IT 资源,不论是旧的或新的,通通都能够透过Web Services的包装,成为可以随取即用的IT资产。

这样一来,利用专为Web Services所设计的商业流程管理(BPM;Business Process Management)工具,便可将各种服务快速汇整,开发出组合式应用,达到「整合即开发」。此外,透过那些对于Web Services 充分支持的应用服务器,以及相关的开发环境下所开发出的新应用,先天上就会是Web Services-ready。

从此以后,所有在这种环境下所开发出来的应用单元,几年后不至于再沦为新的legacy 系统,因为我们在开发的时候便已经把它们的未来准备妥当,也同样符合「整合即开发」的概念。

本周,我们接着探讨应用平台,特别是其所提供的各项基础设施服务,以及对于建置与部署SOA架构所产生的重大影响。开发Web Services的进入门坎固然低,但真正的挑战在于如何确保这些Web Services能够经年累月稳健的执行下去,并且能顾及安全上的要求。

毕竟,当Web Services愈来愈普遍的扮演IT中的建材角色,却无法同时经得起24x7 关键性任务的挑战时,后果自然不是当初导入 SOA 所想要的。这样的需求,自然会让我们联想至应用服务器,以及于其上所衍生的各项专门的应用领域。实际上,安全性、稳定性、可用性、延展性,和效能方面的要求,一直是应用服务器这类型新一代的中介软件(middleware)在设计时,便必须考虑在内的关键指标。

几年导入下来的经验,加上许许多多的成功案例,提供了非常可靠的验证。另有数家应用服务器厂商,早在两年前便开始积极提供各项Web Services相关科技的支持。因此,选择能担当大任的应用服务器作为Web Services宿主,在逻辑上,将会是很自然的延续与延伸。
先前提到,由应用服务器衍生出来的数据、应用整合平台,可透过数种策略,将既有系统重新包装为Web Services;而业务流程设计/管控 (BPM)、讯息格式转换,讯息和服务路由等基本功能,则进一步的提供SOA上不可或缺的基础服务。

整体而言,这样的信息整合平台在 SOA 的世界扮演的是服务提供者 (Web Services provider) 的角色;而服务消费者 (Web Services consumer)则是交给 Portal 平台来扮演。因为portal可将后端的作业流程、服务,数据等,一一加以汇整,再根据前端浏览器具的不同,以及个人化的设定,将信息提供给终端的使用者。从Portal软件开发的趋势来看,Portal在IT中所扮演的角色,正逐渐从早年作为内容管理的门户,逐步迈向process portal之路。

在Web Services的安控方面,最直接的作法,固然是可以将权限控管等安全相关的逻辑直接写死在Web Services 的应用里,但这种将安控逻辑内嵌在多支程序中的作法,将成为未来在更新、维护和管理上令人头疼的问题。比较理想的方式,是透过可横跨整个平台的安控机制,集中拟定各项与Web Services相关的安控设定。

这就与流程控管、服务路由,以及负载平衡相同,如果可以经由平台提供设定与控管的功能,而不是在应用软件(AP)的层级进行,将在整体维护及整合双方面,产生极大的帮助。

此外,在Web Services的营运方面,几个比较新的领域还包括了Web services 的管理、效能水平监测 (SLA;Service-Level Agreement)、业务流程监控 (BAM;Business Activity Monitoring),以及Web services 讯息拦截和转运等。现阶段,已有多家厂商开始在这些领域中进行愈来愈多的着墨。

正因为应用平台提供了多项 SOA 需要的加值功能,许多分析师都一致看好几个主要的应用平台厂商,在未来将囊括大半的SOA市场。此外,由于应用服务器与相关科技,已经在许多企业中具有相当程度的导入经验,所以若从技能与基础设施共享,以及IT资产集中化等潮流与角度审视,以应用平台作为迈向SOA的基础环境自是最逻辑的选择。 (zdnet)

你可能感兴趣的:(应用服务器,Web,浏览器,SOA,平台,安全相关)