没有找到合适的文档，希望了解的细致一点，谢谢

尽管SOA背后并没有什么新概念，但人人都在谈论着SOA。在进行软件服务（software services）的定义时所采用的接口与实现分离的思想，是早已在J2EE、CORBA、COM及DCE中得到充分检验的。

用Web服务实现SOA的主要优点在于：Web服务是广泛普及的、简单的和平台中立的。

Web服务与SOA的组合，提供了一种快速集成方案，它关注被共享的数据与可重用服务（而不是专有的集成产品），因此能够更快更轻松地确保IT投入与企业战略的一致。

一个常见的集成难题是：如何定义和应用“用于满足信息需求与数据转换”的业务规则（及技术规则），并处理好速度、互操作性、可移植性及灵活性间的权衡。
该难题出现在许多场合，包括：
• 在各个数据库系统间转换数据库表示
• 转换系统间传递的消息（和文件）
• 将数据从公共格式转换为某系统使用的一种内部格式
• 在各个业务应用间转换业务文档
• 转换用于B2B集成的业务文档
通常的解决方案是，用企业服务总线（Enterprise Service Bus，ESB）模式定义一个可重用的技术服务（technical service）。ESB（如图4-9）接收来自服务请求者的信息请求（比如“获取所有关于Fred在ABC银行的账户信息”），并根据描述“已知数据服务（就是以返回数据为主要职责的服务）可提供哪些信息”的元数据将信息返回。这个例子也说明了可重用技术服务（比如一个ESB）可以构建在Web服务平台之上，而不需内置于Web服务平台之中。

摘自《Understanding SOA with Web Services中文版》

能否给偶发一份： hopeshared@tom.com

感激不尽

就快出版了，敬请期待！

　　Web Service是就现在而言最适合实现SOA的一些技术的集合，事实上最近SOA的火爆在很大程度上归功于Web Service标准的成熟和应用的普及为广泛的实现SOA架构提供了基础。下面让我们看看Web Service中的各种协议是如何互相工作来满足SOA所需的特点的：

　　 独立的功能实体：通过UDDI的目录查找，我们可以动态改变一个服务的提供方而无需影响客户端的应用程序配置。所有的访问都通过SOAP访问进行，只要WSDL接口封装良好，外界客户端是根本没有办法直接访问服务器端的数据的。

　　 大数据量低频率访问：通过使用WSDL和基于文本(Literal)的SOAP请求，我们可以实现能一次性接收大量数据的接口。这里需要着重指出的是SOAP请求分文本方式和远程调用(RPC)两种方式，正如上文已经提到的，采用远程调用方式的SOAP请求并不符合这点要求。但是令人遗憾的是现有的大多数SOAP请求采用的仍然是远程调用(RPC)方式，在某些平台上，例如IBM WebSphere的早期版本，甚至没有提供文本方式的SOAP支持。

　　 基于文本的消息传递：Web Service所有的通讯是通过SOAP进行的，而SOAP是基于XML的，不同版本之间可以使用不同的DTD或者XML Schema加以辨别和区分。因此只需要我们为不同的版本提供不同的处理就可以轻松实现版本控制的目标。

以下是引用admin在2006-4-14 23:34:00的发言： 面向服务的架构（service-oriented architecture，SOA）是一种设计方式，它指导着业务服务（business services）在其生命周期（从构思开始，直至停止使用）中包括创建和使用的方方面面。SOA也是一种定义和提供IT基础设施（IT infrastructure）的方式，它允许不同应用相互交换数据、并参与业务流程（business processes），无论它们各自背后使用的是何种操作系统或采用了何种编程语言。 >>>>在商业信息系统建设领域，SOA已经成为一种引发信息系统建设，整合方法论变革的技术了，如 admin 所说的，这种方法论在 IBM 集中体现为 SOMA 等“自顶向下，自底向上，中间向外”服务建模过程，从业务组件层的集成，到消息中间件层的集成，在到面向流程的柔性化自动化智能化集成。当然，SOA本身则不仅仅局限于这种组织（政府，企业）信息系统，同样适合诸如普适计算环境下，如微软的upnp, sun的ｊｉｎｉ，都可以看成是ｓｏａ的一个实现。因此，本质上，ｓｏａ是一种分布式计算架构。在各个情景下都有技术实现，在面电子业务领域影响最大，所以最火，技术实现方案如ｗｅｂ　ｓｅｒｖｉｃｅ，　ｃｏｂｒａ等。 尽管SOA背后并没有什么新概念，但人人都在谈论着SOA。在进行软件服务（software services）的定义时所采用的接口与实现分离的思想，是早已在J2EE、CORBA、COM及DCE中得到充分检验的。 ＞＞＞＞＞＞赞～　︿＿︿ 用Web服务实现SOA的主要优点在于：Web服务是广泛普及的、简单的和平台中立的。 ＞＞＞＞传统的组件模型可谓多矣，但是要么和语言相关如Ｊ２ＥＥ，．ＮＥＴ，要么和平台相关如“烤吧”。只有ＷＳ是独立于平台和语言的。从而特别适合于异构遗留系统的集成。 Web服务与SOA的组合，提供了一种快速集成方案，它关注被共享的数据与可重用服务（而不是专有的集成产品），因此能够更快更轻松地确保IT投入与企业战略的一致。 〉〉〉〉〉〉向ＩＢＭ，ＢＥＡ都提供了非常ｎｂ的几乎一条龙的工具来支持。 一个常见的集成难题是：如何定义和应用“用于满足信息需求与数据转换”的业务规则（及技术规则），并处理好速度、互操作性、可移植性及灵活性间的权衡。 该难题出现在许多场合，包括： • 在各个数据库系统间转换数据库表示 • 转换系统间传递的消息（和文件） 〉〉〉〉〉〉消息的路由功能 • 将数据从公共格式转换为某系统使用的一种内部格式 〉〉〉〉〉〉消息的格式转换功能 • 在各个业务应用间转换业务文档 • 转换用于B2B集成的业务文档 〉〉〉〉〉〉还有消息的内容的改变等都可以在ＥＳＢ组件里头做。 通常的解决方案是，用企业服务总线（Enterprise Service Bus，ESB）模式定义一个可重用的技术服务（technical service）。ESB（如图4-9）接收来自服务请求者的信息请求（比如“获取所有关于Fred在ABC银行的账户信息”），并根据描述“已知数据服务（就是以返回数据为主要职责的服务）可提供哪些信息”的元数据将信息返回。这个例子也说明了可重用技术服务（比如一个ESB）可以构建在Web服务平台之上，而不需内置于Web服务平台之中。 〉〉〉〉〉〉〉据我的理解，ｅｓｂ作用体现在开发一些消息处理的组件，来对消息的格式和内容进行转换和路由。因此仅仅ｅｓｂ本身可以实现硬的业务流程自动化。当然，一个有良好界面的柔性包含业务流程智能还是需要强大业务流程管理系统来支持的。但是如果系统中组件都是ＷＳ组件的话，我想是不是可以直接用流程引擎转起来呢？呵呵～～︿＿︿ 摘自《Understanding SOA with Web Services中文版》