Optaros和MuleSource帮助Nespresso打造下一代SOA解决方案

Optaros和MuleSource帮助Nespresso打造下一代SOA解决方案

总部位于瑞士Paudex的雀巢Nespresso SA公司最近宣布，他们名为“NesOA”的SOA项目只用了6个月就成功完成了第一阶段！Optaros和MuleSource帮助定义和实现了这个名为“Nespresso开发架构（或NesOA）”的新型中间件架构。

根据MuleSource的新闻稿件和发布的案例研究的说法：

雀巢Nespresso
SA在超过50个国家直接向它的客户销售产品，并在世界各主要城市经营超过117家享有声誉的专卖店。[……]为了支撑增长极快的新的在线渠
道，Nespresso寻求购买能支撑这些新渠道和扩充现有渠道的新型架构和集成方法。Nespresso雇佣了Optaros和MuleSource来
帮助公司的架构团队定义和实现一种新型的中间架构，它被称为“Nespresso开发架构（或NesOA）”。
我们有幸联系到了Nespresso的企业架构师Joel Schmitt，并向他询问了该项目的一些情况。

：Nespresso的企业架构师Joel Schmitt在新闻稿中这样说：“我们致力于开源的方法，包括MuleSource的Mule ESB，因为遵守开放标准是未来扩展性和增长的关键。”

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