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)