SOA 执行障碍解答

SOA 试图让 IT 能更快和业务同步，在规划上以朝向提供弹性的业务服务为目标。这是无庸置疑的。但在SOA执行方面，正如近几年来导入J2EE 架构和应用服务器，每当 IT 转型进入新的架构，跌跌撞撞的情形总是难以避免。

从CIO到负责规划的架构师，需要和业务单位和策略伙伴间有充分的沟通。CIO必须要认识到，SOA 的建立会是一个为期数年的承诺，基础建设需要按部就班打起来，资助的模式也必须在 IT 和各个业务单位间建立，来陆续支持基础建设及各项业务服务的开发。

而 SOA 的到来，对于架构师和开发人员在观念上和思维上所需调适的幅度，事实上并不亚于前几个时代的IT 架构间的差异。事前规划过于轻率、architect 脑中仍残留先前 IT 世代的余毒、开发人员在实作上对新科技缺乏掌握度、与使用单位沟通不足都会是SOA实施所必须要面对的问题。

在规划建置业务服务方面，和在过去的 IT 架构之下相比，IT 和业务单位的互动幅度会需要更多。此沟通工作的执行，甚至会需要一种新的角色，在技术与业务间扮演桥梁的任务。

有些架构师或许可以胜任这项工作。但姑且不论是兼职或专职，此项工作的负责人，除了 对 SOA 的认知之外，最重要的是要能不厌其烦地将业务单位的需求，与技术人员充分沟通，进而规划出较为完善而有价值的业务服务(或者说 “business API”)。

在另一方面，技术单位必须培养具备设计 “business API” 的新技能。对开发人员来说，转型到 SOA 所需要作的调适，幅度或许不如从 structural programming 到 OOP，历经「顿悟」般的转变;但对于习于使用 function call和组件等较为紧密结合(tightly-coupled) 的方式进行应用整合的 architect 和开发人员来说，改成从业务的角度来思考、设计 AP，且能充分掌握松散藕合 (loosely-coupled) 的设计法则，仍是一项新的挑战。国外一些开始导入 SOA 的企业CIO也纷纷意识到，设计“business API” 的技能，需要开始导入和培训。

如我们先前所讨论的，松散藕合的原则，是 Web 服务和 SOA 承袭自第一代 Web(即 Web 1.0)的主要精髓，也是 Web 之所以能有今天，其背后最重要的关键因素。

要设计出业务导向的服务，开发人员在规划 Web 服务接口和 XML 的颗粒大小(应囊括哪些字段和内容)等问题时，可以把要规划的接口单元想象成一个个的页面(不管是网页的形式，或者client-server 的 GUI 画面，或主机的终端画面皆可)，其提供了一项项申办、查询、订购…的功能。

如何透过和业务单位 and/or 策略伙伴充分沟通(视该项 Web 服务要服务的对象)，从业务和续发展的弹性等角度出发，然后逐渐讨论、描绘出 XML 文件的各项字段，将会是规划业务服务的过程中，需要好好构思的一项重要工作。

来源:IT专家网社区

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友