这
方式不是那么宏大而感到担心
复杂性让新手感受深刻
但结果才是最终能让所有人留下印象Ganesh
思路方法包括了以下几个要点:眼观全局
SOA不是有关集成或者是引入种新技术来简化现有系统连接而是有关:...精简企业
部件并且使它们易于理解和连接...所以始终应当谨记简洁性并且不要把它和权宜的计搞混了那是指阻力最少道路和而精简可能需要付出努力理解数据
服务互操作性需要用于交互“语义”数据模型Ganesh指出所谓规范标准数据模型通常层次较高且对于实战应用来说过于抽象作为代替他建议将企业数据划分为几个逻辑域并为各个域定义字典所有暴露它们
逻辑域服务都应该当使用这些定义而来自其它域服务消费者有责任理解这些定义由跨这些域服务组合起来流程应当在类似数据元素的间执行它们自己映射这不象听起来这么恐怖只有个域所管理数据元素只有部分子集会通过服务接口暴露出去...不要尝试[构建]个单规范标准数据模型那只是徒劳的举根本不要启动选择正确
中间件在Ganesh看来大部分情况下HTTP是SOA实现最合适中间件他建议除了必须需要情况下避免使用消息队列并指出基于HTTP数据库备份通信模型通常能提供更简单解决方案HTTP是
个十分通用协议可用作你SOA项目逻辑基础设施元素ESB服务目录以及其它“治理”组件通常只在管理它们自身所引入复杂性时才需要用简单web服务器群和数据库群所能做到会让你惊叹同时还能始终保持简单和明了选择正确
服务实现手段Ganesh认为基于SOAPweb服务很大程度上是“供应商提供”宣传并推荐尽量予以避免他建议使用REST来代替:REST实际上是实现SOA
有效方式它通常可以以极低成本和复杂性来交付解决方案采用REST困难所在是找到用这种方式研究优秀人员选择正确
数据合约定义 谈到领域模型正式定义时Ganesh建议道“标准”XML方式是重量级比较笨拙相反他建议好好看下JSON模式提案在许多高级语言比如Java当中
已经有现成JSON模式库可用应该能够可以以极低复杂性如XML样严格定义数据合约...避免XML那些繁文缛节由JSON开始并且融合日趋成熟JSON模式你会发现这些和REST结合起来会工作得非常棒解决SOA简洁性
悖论 尽管SOA背后主要驱动原因是精简企业架构按照Ganesh说法典型SOA实现现实是因使用重量级方案而导致集成了复杂性又通过引入工具来管理这复杂性当然
如果你有官僚倾向你可以沐浴在高预算和大团队(Team)声望中并且可以基于你所交付服务和流程和数量发表胜利宣言但如果你真想成功交付SOA(例如让你业务更加灵活并且以种可持续低成本来运营)而这路上不用烧钱话你得务必看看我上面列这些烦人没什么印象甚至是不合潮流方案和技术让那些大卖主好好歇歇吧你不需要买技术(除了你所拥有web服务器和数据库)你也当然不需要买任何复杂技术而这正是那些供应商要倾售给你
最新评论