Ganesh的方法包括了以下几个要点：

　　眼观全局。SOA不是关于集成或者是引入一种新技术来简化现有系统的连接。而是关于：

　　...精简企业的部件并且使它们易于理解和连接...所以始终应当谨记简洁性，并且不要把它与权宜之计搞混了，那是指的阻力最少的道路和。而精简可能需要付出努力。

　　理解数据。服务互操作性需要用于交互的“语义”数据模型。Ganesh指出所谓规范的数据模型通常层次较高且对于实践应用来说过于抽象。作为代替，他建议将企业数据划分为几个逻辑域并为各个域定义字典。

　　所有暴露它们的逻辑域的服务都应该当使用这些定义，而来自其它域的服务消费者有责任理解这些定义。由跨这些域的服务组合起来的流程应当在类似的数据元素之间执行它们自己的映射。这不象听起来这么恐怖，因为只有一个域所管理的数据元素只有一部分子集会通过服务接口暴露出去...不要尝试[构建]一个单一的规范数据模型。那只是徒劳之举，根本不要启动。

　　选择正确的中间件。在Ganesh看来，大部分情况下，HTTP是SOA实现最合适的中间件。他建议，除了必须需要的情况下，避免使用消息队列并指出基于HTTP的数据库备份的通信模型通常能提供更简单的解决方案。

　　HTTP是一个十分通用的协议，可用作你的SOA项目的逻辑基础设施的元素。ESB，服务目录以及其它的“治理”组件通常只在管理它们自身所引入的复杂性时才需要。用简单的web服务器群和数据库群所能做到的会让你惊叹，同时还能始终保持简单和明了。

　　选择正确的服务实现手段。Ganesh认为基于SOAP的web服务很大程度上是“供应商提供”的宣传，并推荐尽量予以避免。他建议使用REST来代替：

　　REST实际上是实现SOA的有效方式，它通常可以以极低的成本和复杂性来交付解决方案。采用REST的困难所在是找到用这种方式思考的优秀人员。

　　选择正确的数据合约定义。 谈到领域模型的正式定义时，Ganesh建议道“标准”的XML方式是重量级的比较笨拙。相反，他建议好好看一下JSON模式提案

　　在许多高级语言比如Java当中，已经有现成的JSON模式的库可用。应该能够可以以极低的复杂性，如XML一样严格的定义数据合约...避免XML的那些繁文缛节，由JSON开始，并且融合日趋成熟的JSON模式。你会发现这些与REST结合起来会工作得非常棒。

　　解决SOA简洁性的悖论。 尽管SOA背后的主要驱动因素是精简企业架构，按照Ganesh的说法，典型的SOA实现的现实是，因使用重量级方案而导致集成了复杂性，又通过引入工具来管理这一复杂性。

　　当然，如果你有官僚的倾向，你可以沐浴在高预算与大团队的声望中，并且可以基于你所交付的服务和流程和数量发表胜利的宣言。但如果你真的想成功交付SOA(例如，让你的业务更加灵活并且以一种可持续的低成本来运营)，而这一路上不用烧钱的话，你得务必看看我上面列的这些烦人的，没什么印象的，甚至是不合潮流的方案和技术。让那些大卖主好好歇歇吧。你不需要买技术(除了你所拥有的web服务器和数据库)。你也当然不需要买任何复杂的技术，而这正是那些供应商要倾售给你的。
 

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。