总部位于瑞士 Paudex 的雀巢 Nespresso SA 公司最近宣布,他们名为“NesOA”的 SOA 项目只用了 6 个月就成功完成了第一阶段! Optaros 和 MuleSource 帮助定义和实现了这个名为“Nespresso 开发架构(或 NesOA)”的新型中间件架构。
根据 MuleSource 的新闻稿件和发布的案例研究的说法:
雀巢 Nespresso SA 在超过 50 个国家直接向它的客户销售产品,并在世界各主要城市经营超过 117 家享有声誉的专卖店。[……] 为了支撑增长极快的新的在线渠道,Nespresso 寻求购买能支撑这些新渠道和扩充现有渠道的新型架构和集成方法。Nespresso 雇佣了 Optaros 和 MuleSource 来帮助公司的架构团队定义和实现一种新型的中间架构,它被称为“Nespresso 开发架构(或 NesOA)”。
我们有幸联系到了 Nespresso 的企业架构师 Joel Schmitt,并向他询问了该项目的一些情况。
InfoQ:Nespresso 的企业架构师 Joel Schmitt 在新闻稿中这样说:“我们致力于开源的方法,包括 MuleSource 的 Mule ESB,因为遵守开放标准是未来扩展性和增长的关键。”就这个言论而言,关于开源和开放标准所提供的好处可能存在一些模糊,它们二者都有其优点,但又未必互补。如果要和大量渠道进行集成,那么支持最新 WS-* 标准或 Web 标准(互操作端点是 RESTful 的情况下)的 ESB 就显得非常重要了。这个解决方案支持的互操作级别是什么,所支持的传输和消息传输是什么?
JOEL:尽管在谈到开放标准时,开源通常引领了革新,但是二者之间的确没有完全重叠在一起。例如,Mule ESB 并不依赖 JBI 标准,但我们还是使用了它。开源和开放标准是战略的一部分,因为二者都保证了厂商独立性,简化了与各类系统及不同集成模式的集成。至于端点方面,我们准备同时支持 WS-* 和 RESTful 端点,而且 Mule/JBoss 如今都提供这种灵活性。有些集成需求是关于服务的,有些的重点是资源,有些则侧重于消息——我们打算把它们全部都搞定。
InfoQ:为了使各种渠道都发挥作用,你们采用了什么策略?考虑到“雀巢 Nespresso SA 在超过 50 个国家直接向它的客户销售产品,并在世界各主要城市经营超过 117 家享有声誉的专卖店。”,能够使所有这些渠道都发挥作用的渠道实施策略是什么?
JOEL:一个标准的集成平台并不意味着只有一个中心实例,我们对不同部署模型采取的是开放态度(Mule ESB 让我们得以实现一个相当分布的模型);此外,假使 ESB 不仅允许基于服务创建公司标准,而且允许创建它们的自定义门面(facade)(在一定限制之下……),这将使参与各方的集成工作量最小。
InfoQ:这个项目有何特点使之不同于一个“让我们使用某某 ESB 来集成我们的遗留应用”项目?例如,该项目涉及的业务流程分析和为提高效率而进行的流程再造工作量是多少?你们打算重用多少服务?不同团队(如果有的话)如何开发最终可能被重用的服务?
JOEL:遗留应用已被集成起来(打算在每个项目之上建立一个新的公司服务层)并尽量能被下一个项目重用。NesOA 是一个对 Nespresso 中间件进行平台再造的程序,包括了业务分析 / 建模和实现方面。
InfoQ:在定义、设计、开发、部署和治理这些服务时采用了什么方法论?是否存在正式的流程?实现策略是什么?在实现被提名完工之时,经历了多长时间?
JOEL:NesOA 程序是于 2 年前由几个实验项目启动的。当然,它没有采用“大爆炸式”的方法,而是基于由业务方管理的项目集合,采用演变式、中间件平台再造的方法。每个项目都有其功能性和非功能性需求、约束和变更。
InfoQ:鉴于最近关于“SOA 已死”的言论,根据你从这个项目中获得的经验,你能说说有哪些成功的关键因素或学到的教训,是那些有类似项目的其他公司可以 / 应该借鉴的?
JOEL:NesOA 与其说是 SOA,不如说更像是“开放架构”。我们使用来自 SOA 的工具和技术,但并非是 SOA 激进派。况且“SOA 已死”并不意味着企业架构、分布式系统、面向服务和应用集成都完蛋了。它们都依然存在于大型公司的 IT 之中——这就是它的全部含义。完蛋的可能是那种为了面向服务而面向服务的巨型架构再造项目。
考虑到最近的经济形势,SOA(不管你说它是死还是活)是否会成为企业节约成本和提高业务效率的根源呢?NesOA 项目可能给寻找面向服务和架构的合适搭配提供了一些线索。
查看英文原文: Optaros and MuleSource Help Nespresso With Next-Generation SOA Solution
评论