【IT168 分析评论】
SOA监管是一个复杂的主题。与SOA监管有关的事情非常繁杂,令人头疼。有技术元素,如注册库或存储库、策略管理、策略实施代理、安全性提供者、服务虚拟化,以及看似无穷无尽的其他技术列表;但还存在非技术元素,如组织结构、激励模型和监管流程。因此就出现了我们的问题——SOA监管有着如此之多的元素,我应该在何时、何处开始?如何入手?
我做的是产品营销,所以,您应该期待看到关于应选用哪种技术的答案,无论我提到了哪种产品,都应假设我准备告诉您这就是正确的产品。毕竟,这就是大多数产品营销人员的做法,对吗?好吧,一会儿我就掀开我这种产品的盖头来,现在是目标明确的过程。
有两件事需要先说明。第一,SOA监管需要的是多种人员、流程和技术的协同努力。如果仅关注一个方面,忽略其他方面,那么就只能得到一个不完整的监管解决方案。第二,对于何时、何处、如何应用监管这一问题不存在错误答案。
让我们从“何时”开始。简单的答案是:无论何时开始应用监管,都不会太早或太迟。然而,与尽早开始监管相比,较晚开始监管的机会成本很高。理论上来讲,一旦有了一个服务,就应该开始应用监管。遗憾的是,通常事实并非如此。大多会等到出现问题,且其SOA引入了过多的混乱而非解决业务问题时。一旦它成为问题,再去纠正方向、应用监管,成本就要远远高出在SOA计划中较早开始监管的成本。因而,不应等到遇到麻烦才开始在组织中实施监管。如果腿上有伤,您会等到无法走路时才去看医生吗?
接下来是“何处”。SOA监管应深入组织,跨越IT和业务的边界。许多人错误地将SOA监管与监管服务联系在一起。这并不完全正确。您需要监管所构建的服务,包括功能和业务服务,但也应为BPM流程应用监管,因为BPM流程很可能称为SOA工件的消费者,此外其自身也有可能会作为服务公开。最终,尝试管理整个项目时,在各个独立资产的级别上进行监管可能有些过分,还应在项目级别上应用监管。
最后就是“如何”。要讨论这个问题,就要花一些时间思索要考虑多少个方面,这样我将在某些入口点使之保持高级别。启动SOA监管计划的方法有许多种。可以归结为您的麻烦在何处;您希望得到怎样的结果。示例如下:
上面只是关于可选入手方式的一些例子,但这些例子都是面向技术的。之前我提到过,监管不仅仅是技术。通常情况下,尝试所有这些选项对于组织结构和流程而言是必须的。这实际上也应该就是您的起点。如若没有定义正确的组织结构和流程,技术方面的价值就会受限,因为不了解它们所应用的是怎样的结构。换句话说,技术因素应作为一种途径,在流程和其他因素(如愿景、架构方向等)中提供可靠性和响应性。
以上内容显然并非SOA监管必要任务的详尽列表,SOA监管是一个广博复杂的主题。底线就是:您需要识别出最大的麻烦或需求在哪里,并从那里入手。您的SOA监管框架随后就可以随着SOA的发展演进而演进了。
作者简介:
Mike Stamback在BEA已工作多年时间,他在WebLogic和AquaLogic产品系列的多个产品的开发和营销过程中扮演了多面手的角色。如今,他主要负责WorkSpace 360、SOA Governance和SOA Security and Management等产品的产品策略和定位。
| 第1页: 第1页 |