【TechTarget中国原创】ZapThink的不断变化,发布的集成化成本曲线,从2002年一直到今天,引发了ZapThink设计师的广泛讨论,讨论的核心是,当业务需求改变时,建立在传统中间件基础上的集成有可能导致不可预知的成本,如果用面向服务架构(SOA)来解决集成化问题,成本的浮动则相对平缓。实施SOA意味着寻求改变,由此引发的争论一直不断,成本总是有的,但是一个灵活的设计师能够减缓IT集成成本的上下浮动。
到2008年底,虽然ZapThink一再警告大家不要在SOA中率先采取ESB方法,但是,迫于供应商的压力,大多数机构还是首先采用了ESB方法,即“SOA平台”方法实施SOA。正如我们在ZapFlash所提到的,使用ESB实施SOA是有可能的,并且许多机构都是这样做的——但是最佳的方法是把ESB看做是服务中介物而不是集成中间件,在集成成本曲线这个环境下采用这个方法,当要求增加时,ESB做为集成中间件的这种做法就会导致成本的突增,由此降低了SOA的净成本,只有机构在SOA中首先实施架构方法,机构才有可能实现其收益。
用于中间件的中间件
目前市场上出现了这样一种趋势,一些机构试图缩减以平台为中心的SOA实施,但是他们很快遇到了麻烦。因为当今企业的规模,没有一个单一的平台能够满足整个机构SOA基础设施的所有需求。因此,我们必须就不同的业务部分实施不一样的平台——即那些分析人士所说的“SOA域”(读者不要把此命题和ZapThink 2004年提出的服务域弄混,这种服务域是在业务为中心的理念下提出的)。相反,SOA关注SOA平台以及操作这个平台的服务。因此,对SOA措施的缩减需要不同SOA域间的互操作,这样我们就会遇到许多SOA域之间互操作和合作问题。
这里隐藏着SOA平台为中心方法的最大问题:因为这种方法依赖于集成中间件,因此那些SOA试图解决的中间件问题也势必会影响到这种方法的实施,即灵活性的缺乏以及集成成本的不断增加。从根本上说,你需要更多的中间件运行SOA中的ESB,以确保这些域可以相互协作,完成互操作。现在可以用这种方式实施这种方法了,但是,如果不能实现业务灵活性或者节省成本,那么还干嘛费力采用这种方式呢?
更有趣的是,Forrester Research公司Mike Gilpin提醒我们要对这个问题做更进一步的思考。虽然他的研究进行的紧锣密鼓,似乎是天衣无缝,但是结论却不完整。自从企业有了SOA平台策略之后,他的观点就变得不完整了,当这些企业开始缩减SOA措施时,它们需要的更多SOA域之间的互操作和合作,而这样就需要更多的中间件,而Gilpin却没有看到这点,这就是归谬法:如果你认为SOA的实施依赖的是SOA平台策略,那么最终你的中间件就需要中间件了,这样就会最先降低SOA给架构带来的收益。因此,SOA不应该依赖SOA平台策略。
果断地采用无ESB SOA
ZapFlash没必要知道,为什么我们从架构角度而不是以集成为中心的角度来看待SOA。之前我们在ZapFlashes中探讨过这个话题。我们认为没必要迫于供应商的压力而采用SOA平台方法。我们也解释过架构驱动的基础设施,也谈过中间物形式,阐释过对松耦合的意义,并且关注业务服务抽取的建设和维护。