执行SOA--SOA实践指南
点击看大图
基本信息
- 作者： (美)Norbert Bieberstein [作译者介绍]
- 译者： 王海鹏
- 丛书名： SOA技术丛书
- 出版社：机械工业出版社
- ISBN：9787111266822
- 上架时间：2009-5-21
- 出版日期：2009 年5月
- 开本：16开
- 页码：179
- 版次：1-1
- 所属分类：
计算机 > 计算机网络 > Web Server > SOA/SOC(面向服务框架)
编辑推荐
在本书中，四位有经验的SOA实施者针对在最大、最复杂的SOA计划中的成功交付，分享了真实世界的、经过验证的实战指南。
本书紧承作者们的畅销书《Service—Orierlted Architecture Compass》，展示了如何克服成功实施SOA的关键障碍，并确定了针对所有方面的最佳实践，包括技术方面、组织机构方面和人员方面。本书关注的问题包括：引入服务原则，支持协作和信息过程共享；利用已有的技术资产和策略来集成服务；为新的工具选择正确的角色；文化、治理和架构方面的转变；为整个组织机构的生命周期带来更大的敏捷性，而不只是针对独立的项目。
本书对于每个力求在复杂环境中通过SOA来实现价值的企业架构师、技术经理和lT领导人来说。是一项必备的资源。
本书内容包括：
实现SOA治理。反映组织机构的战略和业务重点。
成功执行SOA项目：关于服务建模和设计的实践指南和经过验证的方法学。
利用可复用的资产：最大限度地利用SOA库。
让架构师能够选择正确的工具和产品，它们包含执行SOA方法进行服务设计和实现时所需的功能。
定义信息服务，以便让合适的人在合适的时间收到合适的信息。
集成SOA与Web 2.0，以及其他创新的产品和解决方案。
在SOA环境中提供高度可用的人员接口。
内容简介回到顶部↑
目录回到顶部↑
译者序
序
致谢
作者简介
对本书的评价
第1章 soa简介
1.1 soa回顾
1.2 要考虑的新问题
1.3 这本书有何不同
1.4 这本书写给谁
1.5 这本书包含哪些内容
1.6 developerworks的文章链接
1.7 参考资料
第2章 揭示好处
2.1 为什么业务部门应该关心soa
2.2 架构
2.3 聚焦业务架构
2.4 业务过程
2.5 业务组件
2.6 揭开面纱
序
致谢
作者简介
对本书的评价
第1章 soa简介
1.1 soa回顾
1.2 要考虑的新问题
1.3 这本书有何不同
1.4 这本书写给谁
1.5 这本书包含哪些内容
1.6 developerworks的文章链接
1.7 参考资料
第2章 揭示好处
2.1 为什么业务部门应该关心soa
2.2 架构
2.3 聚焦业务架构
2.4 业务过程
2.5 业务组件
2.6 揭开面纱
译者序回到顶部↑
几年前，为了尝试JDK 15中的并发包，我写了一个多线程的网页爬虫程序，利用线程池来抓取和分析页面。.
并发200个线程，每个线程从待爬URL队列中取得一个URL，取回网页，进行分析，找出其中的URL链接，再放入待爬队列。开发过程很正常，但在测试中遇到了问题。在爬了7万多个网页之后，程序开始越来越慢。凭感觉判断，有一些线程“死”掉了。
多线程的调试并不是件容易的事。这个问题很“难”再现。这不是普通意义上的难再现，它每次都会出现。但要跑到7万多URL时，才会出现。也就是说，再现这个问题的代价很大。我试过将线程池的大小退化到 1，想找出什么样的URL会导致线程死掉，但是行不通，因为速度太慢。当时的IDE也缺乏对多线程调试的一些支持。而且即便有支持，可能也不太适合这种情况。后来因为种种原因，那个程序就不了了之了。
这本书中SOA治理的思想给了我一些启发：我们需要关注服务执行的健康状况，包括服务执行的时间。例如，我们可以进行这样的改动：
在每个线程领取URL时，记录一个时间戳。在它完成这个URL处理时，再记录一个时间戳。再利用一个线程，对未完成的URL定时检查它的健康程度。如果在很长的一段时间内它还没完成，那么它就有问题。这样我们可以找到嫌疑URL。我们可以对这种URL单独测试，看看是否因为程序的原因，不能处理这样的URL。或者，我们可以把对应的线程任务杀掉，直接跳过这些有问题的URL。
如果您和我一样，是一名开发人员，学习一些SOA的思想是很有帮助的。我们可以在程序中设计一些机制，支持运营维护和故障分析，这正是SOA的一部分内容。..
IT运维部门需要SOA。业务部门需要SOA。企业高层需要SOA。设想一家经营固话业务的电信公司，通过兼并和重组，拿到了一个移动网络。公司最需要的是什么？就是SOA。
这个移动网络上跑着多少应用？多少中间件？多少数据库？多少操作系统？多少服务器？它们的使用状况如何？它们由谁提供技术支持？它们是什么配置和版本？它们有哪些参数可以调整？它们支持着怎样的业务流程？它们支持着怎样的业务数据模型？它们提供怎样的QoS？它们在安全性和可伸缩性方面存在哪些风险？
SOA参考框架帮助我们提出这些问题。提出问题比解决问题更重要，真的。企业应该认真考虑向SOA迁移。
参加本书翻译工作的人员除封面署名外还有：王海燕、李国安、周建鸣、范俊、张海洲、谢伟奇、林冀、钱立强、甘莉萍。在这本书的翻译过程中，我学到了很多，因此郑重地向大家推荐它。如果这本书对于您有所帮助，我将十分高兴。...
王海鹏
己丑年春日于上海
并发200个线程，每个线程从待爬URL队列中取得一个URL，取回网页，进行分析，找出其中的URL链接，再放入待爬队列。开发过程很正常，但在测试中遇到了问题。在爬了7万多个网页之后，程序开始越来越慢。凭感觉判断，有一些线程“死”掉了。
多线程的调试并不是件容易的事。这个问题很“难”再现。这不是普通意义上的难再现，它每次都会出现。但要跑到7万多URL时，才会出现。也就是说，再现这个问题的代价很大。我试过将线程池的大小退化到 1，想找出什么样的URL会导致线程死掉，但是行不通，因为速度太慢。当时的IDE也缺乏对多线程调试的一些支持。而且即便有支持，可能也不太适合这种情况。后来因为种种原因，那个程序就不了了之了。
这本书中SOA治理的思想给了我一些启发：我们需要关注服务执行的健康状况，包括服务执行的时间。例如，我们可以进行这样的改动：
在每个线程领取URL时，记录一个时间戳。在它完成这个URL处理时，再记录一个时间戳。再利用一个线程，对未完成的URL定时检查它的健康程度。如果在很长的一段时间内它还没完成，那么它就有问题。这样我们可以找到嫌疑URL。我们可以对这种URL单独测试，看看是否因为程序的原因，不能处理这样的URL。或者，我们可以把对应的线程任务杀掉，直接跳过这些有问题的URL。
如果您和我一样，是一名开发人员，学习一些SOA的思想是很有帮助的。我们可以在程序中设计一些机制，支持运营维护和故障分析，这正是SOA的一部分内容。..
IT运维部门需要SOA。业务部门需要SOA。企业高层需要SOA。设想一家经营固话业务的电信公司，通过兼并和重组，拿到了一个移动网络。公司最需要的是什么？就是SOA。
这个移动网络上跑着多少应用？多少中间件？多少数据库？多少操作系统？多少服务器？它们的使用状况如何？它们由谁提供技术支持？它们是什么配置和版本？它们有哪些参数可以调整？它们支持着怎样的业务流程？它们支持着怎样的业务数据模型？它们提供怎样的QoS？它们在安全性和可伸缩性方面存在哪些风险？
SOA参考框架帮助我们提出这些问题。提出问题比解决问题更重要，真的。企业应该认真考虑向SOA迁移。
参加本书翻译工作的人员除封面署名外还有：王海燕、李国安、周建鸣、范俊、张海洲、谢伟奇、林冀、钱立强、甘莉萍。在这本书的翻译过程中，我学到了很多，因此郑重地向大家推荐它。如果这本书对于您有所帮助，我将十分高兴。...
王海鹏
己丑年春日于上海
序言回到顶部↑
面向服务的架构（ServiceOriented Architecture, SOA）已经不是新东西了。实际上，随着技术成熟曲线的发展，它经历了一些紧缩和倒退，有了不少失败尝试的案例。为什么会这样？如果这个方面是如此紧迫，为什么一些人转向怀疑和公然反对？主要原因在于我们都没有理解这种转变的困难，在业务和IT基础设施方面，它都需要训练有素的人员、深刻的理解和积极的行动。在协作和跨团队的过程中，我们需要训练有素的人员，这样我们才能够进行更大范围的、关于组织结构的思考，而不只是个人的、局部的“快速修复”或局部应用。因此，许多计划尝试失败的原因是多种多样的：.
未能建立有效的治理，或者甚至未能意识到这种治理必须改变现状，通过交付共享的、有用的和有效的服务来获得持久的好处。
试图在组织机构的独立部门中引入服务的原则和方法，而没有大幅度地改变共享的文化和信息处理的过程。这种疏忽绝对会导致失败。
未能理解如何将有关服务的新思维与原有的技术资产和方向进行集成。
相信单项技术或工具将实现期望的结果。
相信速度来自敏捷，而敏捷则简单等同于“快速交付”独立的、互不相干的项目，没有考虑到组织机构范围的生命周期。这也被称为无结构的混沌。
在我看来，追求SOA的基本动机或理由在今天尤为普遍，超过以前任何时候。通过更快的速度和创新的业务模式来进行竞争的压力没有改变。对于企业、生态系统和供应链全球化的压力正在加剧。依赖于IT系统来扩张业务的需求持续增长，技术遍及商业和日常生活的方方面面。
在所有业务模式的转变中，许多扩张问题都来自于因特网所提供的途径和选择，因特网正变得越来越无所不在。因特网正在改变和演进。带宽不断增长，导致的网络效应正为新的公司和业务模式提供机会，同时也对已有的公司和业务模式形成破坏性的冲击。我们只要看看音乐行业中发生的例子（实际上是整个娱乐行业）。电信服务提供商（TSP）是典型的例子，其中行业的垂直集成和账单模式已经被基于IT的服务和设备的引入所击碎。两者的交集（娱乐业和TSP）变化更是戏剧性的，并且对消费电子、汽车等行业产生了影响。不断增长的选择和由此导致的全球供应链、供应源的转变对一切都产生了影响，从制造的产品，到知识产权，再到人才。没人能置身事外。
IT系统必须支持或引领这种潮流，否则，与之相联系的业务将在竞争中失败，沦为淘汰者。支持灵活性和规模伸缩的关键就在于面向服务的架构原则。前面曾提到，SOA中没有魔法。在很大程度上，它是古老的“模块化”和结构化分解概念的演进版本，强调在全球化的、开放的环境中更好地实现IT和业务的融合。但是，要在因特网上成功部署基于服务的架构，实现模块化和共享，真正支持全球化的业务，一些基本的规模伸缩问题以前还没有人尝试过。..
我对这个伸缩性问题的体验来自于在IBM中转变Rational。我曾经尝试利用SOA来影响Rational的业务和Rational的技术中文化和技术的演进。Jazz的方向和架构是这种策略转变的主要体现，这种策略不仅源自于基于因特网的架构，也源自于对开发工具和平台底层的业务和技术的重新思考。这让我们开始创造新的产品，从已有的产品演进，并利用新的业务模式（定价和打包）在交付客户价值方面的优点。正如本书所介绍的，这要求文化的转变，治理模型的转变，涉及组织机构、技术假定、信息架构、协作服务等。这要求我们重新思考软件开发的工作，将它建模为一系列的业务过程，这些业务过程需要建立起来，并通过动态的测量指标监控服务来实现报告，这些服务可以放在全球分布的内部网上。现在说我们已经将愿景变成现实还为时尚早，但我比以前任何时候更坚信，这样做是对的。
出于这种精神，我推荐您阅读这本书，进一步了解我们和客户在过去4年中各种基于SOA的工作经验所带来的好处。前一本书展示了舞台，带给我们许多关键的问题和思考。这一本书深入探讨了治理、服务管理，特别是生命周期的挑战等关键问题。它关注了我在一开始提到的许多失败原因。作者们经验丰富，而且提炼出了最佳实践，为实现成功的SOA转变提供了实际可行的、深思熟虑的路线图。好好享受这本书。毕竟，假如事情很容易，那么每个人都能做好！
Daniel Sabbah
GM, Rational Software
IBM Software Group
致谢
我们要感谢IBM的管理团队，允许我们花时间来编写这本书。所有在IBM写的书都得到了管理层的支持。我们感激这种支持，以及允许我们在编写本书时访问必需的资源。谢谢IBM Software Group和IBM Global Services的直接支持主管，特别是IBM全球咨询服务的总经理Robert LeBlanc。
我们要感谢IBM Press和Pearson Education的工作者，这些出版人和员工帮助完成市场方面的工作，并完成了这本书的出版工作。我们要感谢IBM Press的Tara Woodman和她的团队。我们要感谢Pearson Education的Greg Wiegand，他在选题阶段给予我们帮助。我们也要感谢Pearson Education的Katherine Bull，她是高级编辑，让我们著作能符合标准。我们要感谢开发编辑Ginny Bess Munroe和拷贝编辑Keith Cline，他们对可理解性提出建议，帮助我们更好地表达我们的想法。我们要感谢Sue Outterson，她提供了技术审读，指出了不一致的地方。我们也要感谢Pearson的产品和市场团队，他们的帮助让这本书变成现实。
我们还想感谢所有那些令人吃惊的才华横溢的人们，他们在IBM developerWorks (http://wwwibmcom/developerWorks)and IBM Redbooks (http://wwwibmcom/redbooks)上发表了大量的文章，让公众分享。在第5章“利用可复用的资产”为例，它包括了这些人的贡献：Alan Brown、Mikko Kontio、DrTracy Gardner、Larry Yusuf、John Lord、Eoin Lane、Clive Gee、John Medicke、 FengWei Chen、Margie Mago、Scott Linehan、Kevin Williams、John Ganci、Amit Acharya、Jonathan Adams、Paula Diaz de Eusebio、Gurdeep Rahi、Diane Strachan、Kanako Utsumi、Noritoshi Washio 和Grant Larsen。
最后，我们想感谢对本书的各章做出贡献的许多人。Clive Gee来自IBM UK，他在治理方面与客户合作了多年。他对什么有效、什么有意义的深刻见解，让我们的SOA治理和SOA组织部分的内容受益非浅。Randy langel来自IBM US，告诉了我们关于SOA治理的业务方面和SOA治理的子集方面的内容。Bruce Hawken来自IBM Australia，展示了他的洞见和专注，他让SOA治理成为现实并令人鼓舞。我们感谢他们3位对SOA治理部分的贡献。我们也要感谢DrAli Arsanjani，他是IBM杰出工程师，在过去数年中，与我们多次讨论了SOMA，我们在这个主题上获益良多。我们也要感谢Patrick Haren，IBM执行架构师，他的关键复查和建议让我们最终完成了第4章的工作。我们感谢Marc Fiammante，他是IBM杰出工程师，不管多忙，他总是抽出时间来，为我们提供急需的意见和指导。我们感谢Rosalind Radcliffe，来自IBM Tivoli的STSM，他为SOA架构的产品提供了关键的意见。我们感谢Sankar Singha，他是IBM高级架构师，他帮助我们将第6章的内容组织在一起。最后，我们要感谢Thomas Schaeck，他是IBM杰出工程师，参与开发了Lotus Quickr和WebSphere Portal Web 20。他在协作式解决方案方面提供了深刻见解，这种解决方案能够扩展基于SOA的IT在企业中的好处。...
未能建立有效的治理，或者甚至未能意识到这种治理必须改变现状，通过交付共享的、有用的和有效的服务来获得持久的好处。
试图在组织机构的独立部门中引入服务的原则和方法，而没有大幅度地改变共享的文化和信息处理的过程。这种疏忽绝对会导致失败。
未能理解如何将有关服务的新思维与原有的技术资产和方向进行集成。
相信单项技术或工具将实现期望的结果。
相信速度来自敏捷，而敏捷则简单等同于“快速交付”独立的、互不相干的项目，没有考虑到组织机构范围的生命周期。这也被称为无结构的混沌。
在我看来，追求SOA的基本动机或理由在今天尤为普遍，超过以前任何时候。通过更快的速度和创新的业务模式来进行竞争的压力没有改变。对于企业、生态系统和供应链全球化的压力正在加剧。依赖于IT系统来扩张业务的需求持续增长，技术遍及商业和日常生活的方方面面。
在所有业务模式的转变中，许多扩张问题都来自于因特网所提供的途径和选择，因特网正变得越来越无所不在。因特网正在改变和演进。带宽不断增长，导致的网络效应正为新的公司和业务模式提供机会，同时也对已有的公司和业务模式形成破坏性的冲击。我们只要看看音乐行业中发生的例子（实际上是整个娱乐行业）。电信服务提供商（TSP）是典型的例子，其中行业的垂直集成和账单模式已经被基于IT的服务和设备的引入所击碎。两者的交集（娱乐业和TSP）变化更是戏剧性的，并且对消费电子、汽车等行业产生了影响。不断增长的选择和由此导致的全球供应链、供应源的转变对一切都产生了影响，从制造的产品，到知识产权，再到人才。没人能置身事外。
IT系统必须支持或引领这种潮流，否则，与之相联系的业务将在竞争中失败，沦为淘汰者。支持灵活性和规模伸缩的关键就在于面向服务的架构原则。前面曾提到，SOA中没有魔法。在很大程度上，它是古老的“模块化”和结构化分解概念的演进版本，强调在全球化的、开放的环境中更好地实现IT和业务的融合。但是，要在因特网上成功部署基于服务的架构，实现模块化和共享，真正支持全球化的业务，一些基本的规模伸缩问题以前还没有人尝试过。..
我对这个伸缩性问题的体验来自于在IBM中转变Rational。我曾经尝试利用SOA来影响Rational的业务和Rational的技术中文化和技术的演进。Jazz的方向和架构是这种策略转变的主要体现，这种策略不仅源自于基于因特网的架构，也源自于对开发工具和平台底层的业务和技术的重新思考。这让我们开始创造新的产品，从已有的产品演进，并利用新的业务模式（定价和打包）在交付客户价值方面的优点。正如本书所介绍的，这要求文化的转变，治理模型的转变，涉及组织机构、技术假定、信息架构、协作服务等。这要求我们重新思考软件开发的工作，将它建模为一系列的业务过程，这些业务过程需要建立起来，并通过动态的测量指标监控服务来实现报告，这些服务可以放在全球分布的内部网上。现在说我们已经将愿景变成现实还为时尚早，但我比以前任何时候更坚信，这样做是对的。
出于这种精神，我推荐您阅读这本书，进一步了解我们和客户在过去4年中各种基于SOA的工作经验所带来的好处。前一本书展示了舞台，带给我们许多关键的问题和思考。这一本书深入探讨了治理、服务管理，特别是生命周期的挑战等关键问题。它关注了我在一开始提到的许多失败原因。作者们经验丰富，而且提炼出了最佳实践，为实现成功的SOA转变提供了实际可行的、深思熟虑的路线图。好好享受这本书。毕竟，假如事情很容易，那么每个人都能做好！
Daniel Sabbah
GM, Rational Software
IBM Software Group
致谢
我们要感谢IBM的管理团队，允许我们花时间来编写这本书。所有在IBM写的书都得到了管理层的支持。我们感激这种支持，以及允许我们在编写本书时访问必需的资源。谢谢IBM Software Group和IBM Global Services的直接支持主管，特别是IBM全球咨询服务的总经理Robert LeBlanc。
我们要感谢IBM Press和Pearson Education的工作者，这些出版人和员工帮助完成市场方面的工作，并完成了这本书的出版工作。我们要感谢IBM Press的Tara Woodman和她的团队。我们要感谢Pearson Education的Greg Wiegand，他在选题阶段给予我们帮助。我们也要感谢Pearson Education的Katherine Bull，她是高级编辑，让我们著作能符合标准。我们要感谢开发编辑Ginny Bess Munroe和拷贝编辑Keith Cline，他们对可理解性提出建议，帮助我们更好地表达我们的想法。我们要感谢Sue Outterson，她提供了技术审读，指出了不一致的地方。我们也要感谢Pearson的产品和市场团队，他们的帮助让这本书变成现实。
我们还想感谢所有那些令人吃惊的才华横溢的人们，他们在IBM developerWorks (http://wwwibmcom/developerWorks)and IBM Redbooks (http://wwwibmcom/redbooks)上发表了大量的文章，让公众分享。在第5章“利用可复用的资产”为例，它包括了这些人的贡献：Alan Brown、Mikko Kontio、DrTracy Gardner、Larry Yusuf、John Lord、Eoin Lane、Clive Gee、John Medicke、 FengWei Chen、Margie Mago、Scott Linehan、Kevin Williams、John Ganci、Amit Acharya、Jonathan Adams、Paula Diaz de Eusebio、Gurdeep Rahi、Diane Strachan、Kanako Utsumi、Noritoshi Washio 和Grant Larsen。
最后，我们想感谢对本书的各章做出贡献的许多人。Clive Gee来自IBM UK，他在治理方面与客户合作了多年。他对什么有效、什么有意义的深刻见解，让我们的SOA治理和SOA组织部分的内容受益非浅。Randy langel来自IBM US，告诉了我们关于SOA治理的业务方面和SOA治理的子集方面的内容。Bruce Hawken来自IBM Australia，展示了他的洞见和专注，他让SOA治理成为现实并令人鼓舞。我们感谢他们3位对SOA治理部分的贡献。我们也要感谢DrAli Arsanjani，他是IBM杰出工程师，在过去数年中，与我们多次讨论了SOMA，我们在这个主题上获益良多。我们也要感谢Patrick Haren，IBM执行架构师，他的关键复查和建议让我们最终完成了第4章的工作。我们感谢Marc Fiammante，他是IBM杰出工程师，不管多忙，他总是抽出时间来，为我们提供急需的意见和指导。我们感谢Rosalind Radcliffe，来自IBM Tivoli的STSM，他为SOA架构的产品提供了关键的意见。我们感谢Sankar Singha，他是IBM高级架构师，他帮助我们将第6章的内容组织在一起。最后，我们要感谢Thomas Schaeck，他是IBM杰出工程师，参与开发了Lotus Quickr和WebSphere Portal Web 20。他在协作式解决方案方面提供了深刻见解，这种解决方案能够扩展基于SOA的IT在企业中的好处。...
媒体评论回到顶部↑
SOA是一种架构风格选择。但是，实现SOA会带来一种雪崩效应，其中一些后果目前还没有发现。通向SOA的方法不只一种。我们必须在做中学，积累经验和最佳实践。这本书对应用SOA的后果提供了有价值的深刻见解。它基于经验，对完整的服务生命周期提供了方法、原则和指导。这本书是每个企业架构师必备的。.
Martin van den Berg
Lead Enterprise Architect
Sogeti Netherlands
现在许多关于面向服务的架构（SOA）的出版物只关注技术和工具。本书提供了更广阔的视图。针对SOA对业务的影响、SOA的治理和SOA架构师的方法，都分别提供了整章的内容。
一些精彩观点包括：
1SOA首先关注的是业务敏捷性，而非IT。
2SOA是一种架构风格，并不等同于Web服务这样的技术。..
3SOA的原则并不新，并不是和这个名词一起出现的。
我们需要更多类似这样的书籍！
ProfDrBernhard Humm
全面而实用的一本书。它深刻地描述了SOA治理，给出了服务的全面视图，从架构视图直到实际的实现，我觉得这一点对我很有价值。对于准备面对SOA中艰难部分的企业架构师来说，这本书是很有用的。关于如何实现资产复用、SOA中人员的方面、描述如何适用工具的那些章节，让这本书很值得一读，而且很实用。通过对其他材料的扩展引用，它也是为进一步阅读提供了向导。
Erik van Ommeren
Director of Innovation
Sogeti USA LLC / VINT
Washington DC, USA
“全面而实用的一本书。它深刻地描述了SOA治理，给出了服务的全面视图，从架构视图直到实际的实现，我觉得这一点对我很有价值。对于准备面对SOA中艰难部分的企业架构师来说，这本书是很有用的。关于如何实现资产复用、SOA中人员的方面、描述如何适用工具的那些章节，让这本书很值得一读，而且很实用。” ...
Erik van Ommeren, Director of Innovation, Sogeti USA LLC
Martin van den Berg
Lead Enterprise Architect
Sogeti Netherlands
现在许多关于面向服务的架构（SOA）的出版物只关注技术和工具。本书提供了更广阔的视图。针对SOA对业务的影响、SOA的治理和SOA架构师的方法，都分别提供了整章的内容。
一些精彩观点包括：
1SOA首先关注的是业务敏捷性，而非IT。
2SOA是一种架构风格，并不等同于Web服务这样的技术。..
3SOA的原则并不新，并不是和这个名词一起出现的。
我们需要更多类似这样的书籍！
ProfDrBernhard Humm
全面而实用的一本书。它深刻地描述了SOA治理，给出了服务的全面视图，从架构视图直到实际的实现，我觉得这一点对我很有价值。对于准备面对SOA中艰难部分的企业架构师来说，这本书是很有用的。关于如何实现资产复用、SOA中人员的方面、描述如何适用工具的那些章节，让这本书很值得一读，而且很实用。通过对其他材料的扩展引用，它也是为进一步阅读提供了向导。
Erik van Ommeren
Director of Innovation
Sogeti USA LLC / VINT
Washington DC, USA
“全面而实用的一本书。它深刻地描述了SOA治理，给出了服务的全面视图，从架构视图直到实际的实现，我觉得这一点对我很有价值。对于准备面对SOA中艰难部分的企业架构师来说，这本书是很有用的。关于如何实现资产复用、SOA中人员的方面、描述如何适用工具的那些章节，让这本书很值得一读，而且很实用。” ...
Erik van Ommeren, Director of Innovation, Sogeti USA LLC
加载中...
