一、SOA到底是什么?作用是什么_soa是什么意思
有了它，才能释放soa的最大价值
因此，esb成为厂商在soa(面向服务的架构)竞争中的焦点
作为近两年软件领域最热门的词汇之一，soa(serviceoriented，面向服务的架构)的概念以及soa带来的好处，正在被用户逐步接受
gartner的数据表明，到2007年，全球将有70%以上的大企业会将他们的应用转到soa
但是目前cio们最关心的是，如何才能真正实现基于soa的应用?在近一段时期，多家软件厂商如ibm、sun、bea、oracle等都加大了对esb(enterpriseservicebus，企业服务总线)产品的投入力度，并声称自己的soa解决方案因此而更加完善，esb成为厂商在soa竞争中的焦点
esb成为一种新的诱惑esb是传统中间件技术与xml、web服务等技术结合的产物
esb提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素
业内对esb的定义是:它是由中间件技术实现并支持soa的一组基础架构，支持异构环境中的服务、消息以及基于事件的交互，并且具有适当的服务级别和可管理性
这样的定义稍显抽象，简单地说，esb就是试图将应用服务器上的多种逻辑层面迁移到总线以及连接点上，从而降低企业内部信息共享的成本
ibmwebsphere软件全球副总裁sandycarter女士介绍说，“企业服务总线是soa中的消息框架-即消息相互交换和通信的方式，是业界标准与客户消息框架的整合
”esb产品的共有特性包括:连接异构的mom(microsoftoperationsmanager)、利用web服务描述语言接口封装mom协议，以及在mom传输层上传送简单对象应用协议(soap)传输流的能力
大多数esb产品支持在分布式应用之间通过中间层如集成代理实现直接对等沟通
esb的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的通信与整合
从功能上看，esb提供了事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标准接口
在电信领域:esb能够在全方位支持电信行业oss(运营支撑系统)的应用整合概念，是理想的电信级应用软件承载平台
在电力领域:esb能够全方位支持电力行业ems的数据整合概念，是理想的系统数据交换平台
在金融领域:esb能够在全方位支持银企间业务处理平台的流程整合概念，是理想的b2b交易支撑平台
为soa挑起大旗对于soa的概念，不同的软件提供商有不同的定义方式
很多用户也都是从不同的视角来理解soa，从程序员的角度，soa是一种全新的开发技术，新的组件模型，比如说webservice;从架构设计师的角度，soa就是一种新的设计模式，方法学;从业务分析人员的角度，soa就是基于标准的业务应用服务
soa不仅是web服务，如何让业务服务最大限度地复用才是soa的核心价值
esb为分散服务提供了交互、组合和治理的基础架构
有了它，才能释放soa的最大价值
我们可以这样来理解，esb就是在soa架构中实现服务间智能化集成与管理的中介
而它与soa的关系是:esb是逻辑上与soa所遵循的基本原则保持一致的服务集成基础架构，它提供了服务管理的方法和在分布式异构环境中进行服务交互的功能
可以这样说，esb是特定环境下(soa架构中)实施eai(enterpriseapplicationintegration，企业应用集成)的方式
iona公司大中国区总裁薛志勇表示，采用iona公司的esb产品artix作为soa的切入点，将可以使企业以最小的投入将已有系统纳入soa架构
薛志勇称，目前esb是soa集成中最普遍采用的方法，传统的eai和平台厂商是以“服务器”为中心、以“hub”为形式的解决方案，这种方法虽然解决了信息孤岛问题，但投资大，见效慢，而且也不灵活
因为esb是传统中间件技术与xml、web服务等技术结合的产物，对企业而言，采用esb中间件系统作为企业级信息系统整合方案中的中枢技术，可以无须添加任何软硬件设备，就可把过去、现有和未来的it系统整合在企业级的信息应用框架下，并且能为企业提供实时、大容量的信息通信和实时控制、管理和分配消息传递的能力
目前，除了iona、tibco等专业的esb公司外，soa的两大领导厂商ibm和bea也加入了esb的阵营
forrester公司分析师mikegilpin说:“尽管人们还不十分确定如何构建出一个完整的soa，但他们已经知道要解决集成问题，而esb正好能帮助他们解决该问题
”国内cio对soa早已听了很多
soa的理念和他们所面临诸多挑战，soa的开放性和灵活性，给了cio一个选择它的理由
然而，不菲的平台迁移成本以及缺少成功案例的佐证,都让cio难下决心
cio不但要考虑必须对现有产品进行集成以支持soa的使用场景
还必须考虑如何构建面向未来的soa应用
esb的出现和应用恰好为这个难题提供了一个解决之道
甲骨文公司在去年将esb产品内嵌在其业务流程管理产品中，今年就推出了独立的esb产品
bea推出了aqualogicservicebus等来加强esb的产品线
ibm在原有wbimessagebroker、was6sibus这些集成产品之外，又推出了独立的websphereesb产品
而传统的eai厂商tibco和webmethods也宣布了各自的esb产品
bea公司中国区技术经理刘汩春认为:“soa的‘服务’必须是可组装编排、可快速注册发布、质量可监控、生命周期可管理的
这样soa才能在整个it范围内实现服务治理和优化，从而直接推动业务的优化
而从简单的服务重用框架到soa演进的过程中，esb就是其中最重要的催化剂之一
”esb的兴起让soa的渐进之路可以走得更开放和平稳，而esb也代表了中间件产品本身的进化方向，从应用领域而言，由于esb是基于开放的web服务而来，在soa的发展过程中，esb已经当仁不让地挑起大旗
esb开源之路开源软件市场这几年的发展也早就显示出极其旺盛的生命力
linux服务器、开源数据库、开源应用软件等产品的市场份额都已有了很大提高
开源软件已成为政府机构和企业用户节约成本的一种有效手段
随着java应用服务器迅速成为一种大众化商品，企业中间件也朝着开源的方向跟进
近两年，已出现了许多极其成熟的企业服务总线实施项目
sun在javaone大会上发布了自己的免费esb
这个名为java开放式企业服务总线的项目将放在java
net上进行，第一个版本有望在今年夏末交付
sun还计划把来自这个社区项目的代码包装成商用产品
sun的应用程序以及开发者平台的市场副总经理joekeller说，openesb将会基于java商业集成1
0规范
还提供了使用开源代码的java系统应用程序服务器
“这将是一个推动整个世界商业的应用程序服务器，”keller说
而在sun对esb开源前，iona科技公司就公开了celtix的源代码，这是采用gnulgpl许可证的javaesb，从而启动了objectweb社区在esb方面的工作
iona方面声称，celtix将支持java商业智能(jbi)规范，该规范为跨应用集成明确规定了标准化的对象容器
目前市场上已经有大量bea、ibm以及sun等大制造商生产的esb产品
而objectweb在上星期也接收到了法国it服务公司bull的源代码捐赠来加速它esb产品发展
随着开源项目的这股趋势，这个领域的所有供应商都在观望哪个esb会获得成功
idc的副总裁dennisbyron说:“拿ibm举例，如果不管什么原因objectweb占据了市场!
二、初步理解一下：SOA, SOAP, Web Service, WSDL等
什么是soa、soap?
soa到底是什么？
soa（service-oriented architecture）的定义是面向服务的架构，就是说将软件按照功能设计成一个个服务，这些服务用标准的方式定义接口、并通过标准的协议进行调用。 soa所定义的接口和调用方式是独立于编程语言和运行平台的，广义上讲soa可以基于不同的底层技术实现，比如corba和web services。但corba由于过于复杂和臃肿已很少使用，所以目前所说的soa绝大多数是基于web services技术实现。在web services的实现方式下，soa服务的接口用xml进行定义。
在soa架构下，软件开发从业务流程分析开始，使用组件化业务建模的方法识别和分析各种业务模型，将各种实践融入其中，在这个基础上建立用例，用例直接产 生bpel，这些bpel则可以被融入一个服务整合框架中，其描述了各种服务的信息，从而把esb上的各个模块统一起来，形成一个巨大的服务仓。
将中间层再进行抽离，在中间层作一个跨技术架构的元数据和业务逻辑，使之成为跨技术架构的、可长期继承、并不断积累的企业业务库和最宝贵的信息资产，也就 是面向服务的组件库，而且这个服务组件库也可以被其它企业复用，且不依赖于任何一种技术架构。夸张一点说，如果所有软件企业都使用soa架构，那么世界软 件业将会发生彻底的改变。显然，这样一个框架不是一种产品，也不仅仅是一种技术，而是一种解决问题的方法论。
soa可能应用于两个场景：第一种是业务互通互联；第二种是封闭交易系统，即将元数据和业务逻辑抽离，形成可复用。举个例子，在第一种场景中，当不同企业 之间的业务需要相互调用，这时就可能采用soa技术；在第二种场景中，在企业内部需要将系统进行迁移时，利用soa技术定义的原有数据和业务流程，可以很 快完成。
soa并不是一个新事物，it组织已经成功建立并实施soa应用软件很多年了，bea、ibm、等厂商看到了它的价值，纷纷跟进。soa的目标在于让it 变得更有弹性，以更快地响应业务单位的需求，实现实时企业（real-time enterprise，这是gartner为soa描述的愿景目标）。而bea的cio rhonda早在2001年6月就提出要将bea的it基础架构转变为soa，并且从对整个企业架构的控制能力、提升开发效率、加快开发速度、降低在客户 化和人员技能的投入等方面取得了不错的成绩。
soa是在计算环境下设计、开发、应用、管理分散的逻辑（服务）单元的一种规范。这个定义决定了soa的广泛性。soa要求开发者从服务集成的角度来设计 应用软件，即使这么做的利益不会马上显现。soa要求开发者超越应用软件来思考，并考虑复用现有的服务，或者检查如何让服务被重复利用。soa鼓励使用可 替代的技术和方法（例如消息机制），通过把服务联系在一起而非编写新代码来构架应用。经过适当构架后，这种消息机制的应用允许公司仅通过调整原有服务模式 而非被迫进行大规模新的应用代码的开发，使得在商业环境许可的时间内对变化的市场条件做出快速的响应。
soa也不仅仅是一种开发的方法论--它还包含管理。例如，应用soa后，管理者可以方便的管理这些搭建在服务平台上的企业应用，而不是管理单一的应用模 块。其原理是，通过分析服务之间的相互调用，soa使得公司管理人员方便的拿到什么时候、什么原因、哪些商业逻辑被执行的数据信息，这样就帮助了企业管理 人员或应用架构师迭代地优化他们的企业业务流程、应用系统。
soa的一个中心思想就是使得企业应用摆脱面向技术的解决方案的束缚，轻松应对企业商业服务变化、发展的需要。企业环境中单个应用程序是无法包容业务用户 的（各种）需求的，即使是一个大型的erp解决方案，仍然不能满足这个需求在不断膨胀、变化的缺口，对市场快速做出反应，商业用户只能通过不断开发新应 用、扩展现有应用程序来艰难的支撑其现有的业务需求。通过将注意力放在服务上，应用程序能够集中起来提供更加丰富、目的性更强的商业流程。其结果就是，基 于soa的企业应用系统通常会更加真实地反映出与业务模型的结合。服务是从业务流程的角度来看待技术的--这是从上向下看的。这种角度同一般的从可用技术 所驱动的商业视角是相反的。服务的优势很清楚：它们会同业务流程结合在一起，因此能够更加精确地表示业务模型、更好地支持业务流程。相反我们可以看到以应 用程序为中心的企业应用模型迫使业务用户将其能力局限为应用程序的能力。
企业流程（enterprise process）是流经企业框架的空气，它赋予业务模型里的组件以生命，并更加清晰地定义了它们之间的关系。流程定义了同业务模型进行交互操作的专门方 法。例如，会计可能是企业服务系统的一个组件--但是将发票寄给客户却是一个业务流程。服务被定义用来支持业务流程，因而贯穿整个流程始终的是：各种服务 组件在流程和逻辑实现过程中的装配操作。理解业务流程是定制服务的关键所在。
有利于企业业务的集成传统的应用集成方法（点对点集成、企业消息总线或中间件的集成（eai）、基于业务流程的集成）都很复杂、昂贵，并且不灵活。这些集 成方法难于快速适应基于企业现代业务变化不断产生的需求。基于面向服务架构 (soa) 的应用开发和集成可以很好的解决其中的许多问题。
soa 描述了一套完善的开发模式来帮助客户端应用连接到服务上。这些模式定制了系列机制用于描述服务、通知及发现服务、与服务进行通信。
不同于传统的应用集成方法，在 soa 中，围绕服务的所有模式都是以基于标准的技术实现的。大部分的通信中间件系统，如 rpc、corba、dcom、ejb 和 rmi，也同样如此。可是它们的实现都不是很完美的，在权衡交互性以及标准定制的可接受性方面总是存在问题。soa 试图排除这些缺陷。因为几乎所有的通信中间件系统都有固定的处理模式，如rpc 的功能、corba 的对象等等。然而，服务既可以定义为功能，又可同时对外定义为对象、应用等等。这使得 soa 可适应于任何现有系统，并使得系统在集成时不必刻意遵循任何特殊定制。
soa 帮助企业信息系统迁移到"leave-and-layer"架构之上，这意味着在不用对现有的企业系统做修改的前提下，系统可对外提供 web 服务接口，这是因为它们已经被可以提供 web 服务接口的应用层做了一层封装，所以在不用修改现有系统架构的情况下，soa 可以将系统和应用迅速转换为服务。soa 不仅覆盖来自于打包应用、定制应用和遗留系统中的信息，而且还覆盖来自于如安全、内容管理、搜索等 it 架构中的功能和数据。因为基于 soa 的应用能很容易地从这些基础服务架构中添加功能，所以基于soa的应用能更快地应对市场变化，为使企业业务部门设计开发出新的功能应用。
soap是什么？
soap 是simple object access protocol（简单对象访问协议）的缩写。
soap是一个用于分布式环境的、轻量级的、基于xml进行信息交换的通信协议.
对于soap的理解：
第一步理解：soap＝http＋xml
第二步理解：soap把xml的使用代码化为请求和响应参数编码模式，并用http作传输。
soap是把成熟的基于http的web技术与xml的灵活性和可扩展性组合在了一起。
第三步理解：具体地讲，一个soap实现可以简单地看作遵循soap编码规则的http请求和响应。
注意：soap 是一个协议，与编程语言无关。实际上，许多语言已经开始支持 soap，如：java，c，c＋＋以及javascript。
soap的起源？soap解决的问题？
soap最初由微软发起研究，用以解决mts/com资源消耗大，不够轻巧等问题，后逐渐被ibm等巨头接纳并加入研究，现已提交w3c，成为web service应用传输标准。soap技术主要用于实现大量异构程序和平台之间的互操作性，从而使存在的应用能够被广泛的用户所访问。
soap意思是简单对象访问协议（simple object access protocol）。的确如它的名字一样，soap是很简单的。它是一个基于xml的协议，允许程序组件和应用程序彼此使用一种标准的internet协 议--http来通讯。soap是一种独立的平台，它不依赖程序语言，它是简单的，弹性的，很容易扩展的。目前，应用程序能够彼此使用一种基于dcom和 corba技术的远程过程调用（rpc）来进行相互通讯，但http不被设计为这个目的。rpc在internet上应用是非常困难的，它们会出现许多兼 容性和安全性的问题，因为防火墙和代理服务器通常都会阻断（block）这些类型的流量。应用程序之间最好的通讯方式是通过http协议，因为http是 支持所有internet浏览器和服务器的。基于这个目的，soap协议被创建出来。
soap（simple object access protocol ）简单对象访问协议是在分散或分布式的环境中交换信息的简单的协议，是一个基于xml的协议，它包括四个部分：soap封装(envelop)，封装定义 了一个描述消息中的内容是什么，是谁发送的，谁应当接受并处理它以及如何处理它们的框架；soap编码规则（encoding rules），用于表示应用程序需要使用的数据类型的实例; soap rpc表示(rpc representation)，表示远程过程调用和应答的协定;soap绑定（binding），使用底层协议交换信息。
虽然这四个部分都作为soap的一部分，作为一个整体定义的，但他们在功能上是相交的、彼此独立的。特别的，信封和编码规则是被定义在不同的xml命名空间(namespace)中，这样使得定义更加简单。
什么是cxf？
apache cxf = celtix + xfire，apache cxf 的前身叫 apache celtixfire，现在已经正式更名为 apache cxf 了，以下简称为 cxf。cxf 继承了 celtix 和 xfire 两大开源项目的精华，提供了对 jax-ws 全面的支持，并且提供了多种 binding 、databinding、transport 以及各种 format 的支持，并且可以根据实际项目的需要，采用代码优先（code first）或者 wsdl 优先（wsdl first）来轻松地实现 web services 的发布和使用。目前它仍只是 apache 的一个孵化项目。
apache cxf 是一个开源的 services 框架，cxf 帮助您利用 frontend 编程 api 来构建和开发 services ，像 jax-ws 。这些 services 可以支持多种协议，比如：soap、xml/http、restful http 或者 corba ，并且可以在多种传输协议上运行，比如：http、jms 或者 jbi，cxf 大大简化了 services 的创建，同时它继承了 xfire 传统，一样可以天然地和 spring 进行无缝集成。
cxf 包含了大量的功能特性，但是主要集中在以下几个方面：
支持 web services 标准：cxf 支持多种 web services 标准，包含 soap、basic profile、ws-addressing、ws-policy、ws-reliablemessaging 和 ws-security。
frontends：cxf 支持多种“frontend”编程模型，cxf 实现了 jax-ws api （遵循 jax-ws 2.0 tck 版本），它也包含一个“simple frontend”允许客户端和 endpoint 的创建，而不需要 annotation 注解。cxf 既支持 wsdl 优先开发，也支持从 java 的代码优先开发模式。
容易 使用： cxf 设计得更加直观与容易使用。有大量简单的 api 用来快速地构建代码优先的 services，各种 maven 的插件也使集成更加容易，支持 jax-ws api ，支持 spring 2.0 更加简化的 xml 配置方式，等等。
支持二进制和遗留协议：cxf 的设计是一种可插拨的架构，既可以支持 xml ，也可以支持非 xml 的类型绑定，比如：json 和 corba。
我们来利用cxf创建一个简单的webservice吧。
首先cxf 所需要的包：更具网站说明以下的包都是必须的，但是在我的实际项目中红色部分的包并没有用到。
大家可更具自己需求来添加适应的包。
cxf.jar
commons-logging.jar
geronimo-activation.jar (or the sun equivalent)//
geronimo-annotation.jar (or the sun equivalent)//
geronimo-javamail.jar (or the sun equivalent)//
neethi.jar
jaxb-api.jar
jaxb-impl.jar
stax-api.jar//
xmlschema.jar
wstx-asl.jar
xml-resolver.jar
分布式应用程序和浏览器
研究一下当前的应用程序开发，你会发现一个绝对的倾向：人们开始偏爱基于浏览器的瘦客户应用程序。这当然不是因为瘦客户能够提供更好的用户界面，而是因为 它能够避免花在桌面应用程序发布上的高成本。发布桌面应用程序成本很高，一半是因为应用程序安装和配置的问题，另一半是因为客户和服务器之间通信的问题。
传统的windows富客户应用程序使用dcom来与服务器进行通信和调用远程对象。配置好dcom使其在一个大型的网络中正常工作将是一个极富挑战性的 工作，同时也是许多it工程师的噩梦。事实上，许多it工程师宁愿忍受浏览器所带来的功能限制，也不愿在局域网上去运行一个dcom。在我看来，结果就是 一个发布容易，但开发难度大而且用户界面极其受限的应用程序。极端的说，就是你花了更多的资金和时间，却开发出从用户看来功能更弱的应用程序。不信？问问 你的会计师对新的基于浏览器的会计软件有什么想法：绝大多数商用程序用户希望使用更加友好的windows用户界面。
关于客户端与服务器的通信问题，一个完美的解决方法是使用http协议来通信。这是因为任何运行web浏览器的机器都在使用http协议。同时，当前许多防火墙也配置为只允许http连接。
许多商用程序还面临另一个问题，那就是与其他程序的互操作性。如果所有的应用程序都是使用com或.net语言写的，并且都运行在windows平台上， 那就天下太平了。然而，事实上大多数商业数据仍然在大型主机上以非关系文件(vsam)的形式存放，并由cobol语言编写的大型机程序访问。而且，目前 还有很多商用程序继续在使用c++、java、visual basic和其他各种各样的语言编写。现在，除了最简单的程序之外，所有的应用程序都需要与运行在其他异构平台上的应用程序集成并进行数据交换。这样的任 务通常都是由特殊的方法，如文件传输和分析，消息队列，还有仅适用于某些情况的的api，如ibm的"高级程序到程序交流(appc)"等来完成的。在以 前，没有一个应用程序通信标准，是独立于平台、组建模型和编程语言的。只有通过web service，客户端和服务器才能够自由的用http进行通信，不论两个程序的平台和编程语言是什么。
什么是webservice?
web services是建立可互操作的分布式应用程序的新平台。作为一个windows程序员，你可能已经用com或dcom建立过基于组件的分布式应用程序。com是一个非常好的组件技术，但是我们也很容易举出com并不能满足要求的情况。
web service平台是一套标准，它定义了应用程序如何在web上实现互操作性。你可以用任何你喜欢的语言，在任何你喜欢的平台上写web service ，只要我们可以通过web service标准对这些服务进行查询和访问。
web service平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型系统。要实现互操作性，web service平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。在传统的分布式系统中，基于界面 (interface)的平台提供了一些方法来描述界面、方法和参数（译注：如com和cobar中的idl语言）。同样的，web service平台也必须提供一种标准来描述web service，让客户可以得到足够的信息来调用这个web service。最后，我们还必须有一种方法来对这个web service进行远程调用。这种方法实际是一种远程过程调用协议(rpc)。为了达到互操作性，这种rpc协议还必须与平台和编程语言无关。
web service 是一种新的web应用程序分支，他们是自包含、自描述、模块化的应用，可以发布、定位、通过web调用。web service可以执行从简单的请求到复杂商务处理的任何功能。一旦部署以后，其他web service应用程序可以发现并调用它部署的服务。
web service是一种应用程序，它可以使用标准的互联网协议，像超文本传输协议(http)和xml，将功能纲领性地体现在互联网和企业内部网上。可将web服务视作web上的组件编程。
1 历史
web广泛用到的技术：
◆tcp/ip：通用网络协议，被各种设备使用
◆html：通用用户界面，可以使用html标签显示数据
◆java：写一次可以在任何地方运行的通用编程语言
◆xml ：通用数据表达语言，在web上传送机构化数据的容易方法
他们的特点是其开放性，跨平台性，开放性正是web services的基础。
2 web发展的趋势
内容更动态化
◆带宽bandwidth更便宜，易于获得
◆存储器storage更便宜，更易获得
◆普遍式计算变得更加重要：大量的设备，例如移动电话，页面，电脑，pc，已经在internet上变得普遍，平台变得更多元化，象xml这样的跨平台技术变得更重要
3 web services扮演什么角色？
上述的这些趋势意味着，更加智能的处理，操作和汇总内容变得十分重要。让我们看看按照web services角度所预示的四个趋势：
◆内容更加动态：一个web service必须能合并从多个不同源来的内容，可以包括股票，天气，新闻等，在传统环境中的内容，如存货水平，购物订单或者目录信息等，都从后端系统而来
◆带宽更加便宜：web services可以分发各种类型的内容（音频，视频流等）
◆存储更便宜: web services必须能聪明地处理大量数据，意味着要使用数据库，ldap目录，缓冲，和负载平衡软件等技术保持可扩展能力
◆普遍式计算更重要：web services不能要求客户使用某一版本的windows的传统浏览器，必须支持各种设备，平台，浏览器类型，各种内容类型。
4 两种重要技术
要达到这样的目标，web services要使用两种技术：
◆xml xml是在web上传送结构化数据的伟大方式，web services要以一种可靠的自动的方式操作数据，html不会满足要求，而xml可以使web services十分方便的处理数据，它的内容与表示的分离十分理想
◆soap soap使用xml消息调用远程方法，这样web services可以通过http协议的post和get方法与远程机器交互，而且，soap更加健壮和灵活易用。
其他象uddi和wsdl技术与xml和soap技术紧密结合用于服务发现。</span>
组成web service平台的这三个技术。
xml和xsd
可扩展的标记语言(xml)是web service平台中表示数据的基本格式。除了易于建立和易于分析外，xml主要的优点在于它既是平台无关的，又是厂商无关的。无关性是比技术优越性更重要的：软件厂商是不会选择一个由竞争对手所发明的技术的。
xml解决了数据表示的问题，但它没有定义一套标准的数据类型，更没有说怎么去扩展这套数据类型。例如，整形数到底代表什么？16位，32位，还是 64位？这些细节对实现互操作性都是很重要的。w3c制定的xml schema(xsd)就是专门解决这个问题的一套标准。它定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。web service平台就是用xsd来作为其数据类型系统的。当你用某种语言(如vb.net或c#)来构造一个web service时，为了符合web service标准，所有你使用的数据类型都必须被转换为xsd类型。你用的工具可能已经自动帮你完成了这个转换，但你很可能会根据你的需要修改一下转换 过程。
wsdl
你会怎样向别人介绍你的web service有什么功能，以及每个函数调用时的参数呢？你可能会自己写一套文档，你甚至可能会口头上告诉需要使用你的web service的人。这些非正式的方法至少都有一个严重的问题：当程序员坐到电脑前，想要使用你的web service的时候，他们的工具(如visual studio)无法给他们提供任何帮助，因为这些工具根本就不了解你的web service。解决方法是：用机器能阅读的方式提供一个正式的描述文档。web service描述语言(wsdl)就是这样一个基于xml的语言，用于描述web service及其函数、参数和返回值。因为是基于xml的，所以wsdl既是机器可阅读的，又是人可阅读的，这将是一个很大的好处。一些最新的开发工具 既能根据你的web service生成wsdl文档，又能导入wsdl文档，生成调用相应web service的代码。
三、SOA在汽车行业的应用和前景
面向服务架构（soa）是一个典型的从it／互联网行业引入到 汽车 的软件技术，现在 汽车 行业围绕soa有很多讨论和实践，主要集中于soa本身的概念和在智能 汽车 中的实际应用，有些观点把soa捧得很高，认为soa是一劳永逸的方案，用了soa就可以具备和特斯拉一较高下的软件能力，也有人觉得soa比较虚，上了soa用户也没什么直接的体验，不见得能多卖几辆车。毫无疑问，新技术的引入总是伴随着争议，主要还是专业背景的不同，站在 汽车 电子，通信或者电气工程师的角度去看待一个软件问题，总会有各种怀疑，也有很多与soa无关的需求和问题，想让soa来解决，这些都跨专业的理解偏差。而 汽车 软件，毕竟还是软件，不是信号、电子或芯片，很多疑问还得回到软件的领域，才能正确理解soa的概念以及它能解决的问题。
智能 汽车 到底需不需要soa？这里需要先看一下智能驾驶时代的 汽车 架构和 汽车 软件的实际需求：
传统的整车架构，尤其是电子和电气部分，主要就是分布式ecu，嵌入式软件和现场总线级别的通信网络，传统的eea很大程度上是一套硬件集成方案（当然复杂度比手机高出几个量级），如果没有特斯拉，可能这套成熟的体系还能用上很多年，没有人考虑过把it行业的软硬件架构直接套用到 汽车 上，但现在这事被特斯拉做成了，而且类似 科技 公司背景的入局者和模仿者越来越多，各类 汽车 软件也大幅增加。对于传统oem，根据自己的专业背景，在这一轮技术升级中，基本都能看到域控制器、新型传感器、车载以太网、操作系统、app和各种算法等新技术，但如何把它们有效地集成在一起，做成用户体验卓越的智能产品，还能保证成本可控，是一个比较大的挑战。新硬件好学，拆来看看，大概也能明白对手怎么做的，但是软件和代码，还有基于这些软件的运维方式和盈利模式，对于传统 汽车 行业来说，是所谓的虚拟经济和“灵魂”，既看不太懂也有内部变革的阻力。所以oem需要的是在现有eea基础上，想办法把这些五花八门的新技术用更快更有效的方式集成到一起，而且采用成本和风险可控的迭代方式，而不是推倒现有架构和供应链重来。这个目标从软件的角度来看，其实就是要求oem要具备整车软件的集成能力。
但大型系统软件的集成正是传统eea缺失的能力，因为现有零部件都是软硬件耦合的，传统车内嵌入式软件的集成基本是零部件和can网络调通即可，由于can是基于广播的，所以各个零部件软件之间实际并没有直接对接。而随着新的非嵌入式的软件越来越多进入到车内，相互之间会通过基于以太网的软件接口(api)来直接传输数据，api调用和can信号广播完全是两回事，api设计是软件问题不是通信问题，同时新的 汽车 软件会有独立的生命周期线，为了保证让大量的新软件能通过以太网络在一起协同工作，oem必须引入全新的独立于硬件的大型软件集成能力，相当于需要一套单独的整车软件架构。
这套软件架构的基本作用是：
能集成整车各个ecu、dcu(域控制器)、zcu(区域控制器)、分布式网关/中央网关等的软件，而软件集成最重要的环节就是，设计一套统一的软件接口和数据传输格式，当然还有安全、性能等一系列规范。有了这套整车软件集成方案，oem才能让各个供应商或服务商的软件按事先约定好的统一标准来传输数据。否则就会演变成各供应商自行定义接口名称和参数，输出各式各样的数据，安全标准也不一致，最终还得由oem来适配和对接，成百上千的新软件集成到车内，接口联调和适配的复杂度和工作量是oem无法承受的，这会比can矩阵设计高出几个量级。
那么现在 汽车 行业选择了面向服务架构(soa)来作为 汽车 的整车软件架构，主要是为了解决各个零部件间的数据交换和通信。这个方向对不对？我们可以从it行业设计soa的初衷来分析。
广义的面向服务架构，或者广义的“服务”本身，是从单机软件到网络软件都一直存在的最基本的概念。传统 汽车 的ecu嵌入式软件，都算是单机软件，功能界面数据处理基本都在同一个硬件上，没有前台界面+后台服务的概念，但在it/软件行业，从局域网到广域网、互联网、物联网等，软件早已完成了分层架构，从最早局域网软件的client/server(c/s)架构，到web时代的b/s架构，最近十几年又迭代出soa、微服务、无服务架构等等，服务这个概念始终存在且保持进化，贯穿了整个软件发展。简单来讲，软件的复杂业务代码都是运行在所谓的“服务器”上，这些服务器都是远程部署在机房的高性能计算机，运行在这些服务器上的软件被统称为“后台服务”，而运行在用户终端上的，比如pc、手机或智能硬件的软件，都叫做“前台界面”，其实就是 汽车 行业经常提的hmi。这种把交互界面和业务模块(算法)分离的主要原因是终端算力有限，同时为了避免重复开发可共用的复杂模块，才把这类模块都放到后台服务器上去做成“服务”来共享使用。
所以 汽车 软件从嵌入式逐步升级为大型系统软件的趋势下，只要有网络，那么基于服务的架构是不可避免的。高算力平台或域控制器就是车内的服务器，这些服务器把各种 汽车 零部件的控制权以软件接口的方式，提供给车内或车外以太网的其他软件使用。
但狭义上的soa (service-oriented architecture), 尤其是 汽车 行业目前多从ibm借鉴的那套soa和企业总线理念，是不是必须的呢？并不是，而且ibm的soa解决方案已经是过时的技术了，原因有很多，总的来说，和商业软件公司的没落有关系。
上面讲了面向服务架构的来龙去脉，就比较容易澄清soa的用处，面向服务架构是在it行业软硬件运行环境都很成熟的基础上出现的架构，用于软件模块之间分层，对于部分公用的，消耗计算资源的代码，被抽象成服务，单独运行在专门的服务器上，被其他软件模块共享使用。十几年前soa的提出显然没有考虑过 汽车 行业现在还需要先实现车载以太网通信，域控制器和操作系统升级的情况。 如果说it行业搞soa是从0到1，那么 汽车 行业搞soa就是从-1到0，再从0到1 ，因为还得先解决硬件升级的问题，-1到0就是oem先得补齐的硬件功课（当然自动驾驶或者座舱应用本来也需要升级这些硬件），这里面又涉及到成本和长期roi，以及传统oem如何看待soa的价值问题。 从整车成本的角度来看 ，soa会给oem每次新车换代节省一定比例的零部件开发费，但是在使用了soa的第二代车开始才会节省，而第一代使用soa的 汽车 ，又要升级网络又要引入中间件，各种新增成本，oem未必能买单，所以如果对软件架构的长期价值理解不清楚，这个总账算起来很有难度。 而从技术上看 ，oem其实需要在短时间内同时完成通信网络升级、硬件升级、软件升级(生态建立,盈利模式)的三步走，这三步可能在其他行业都经历了十年以上的时间，所以 汽车 行业面临的挑战要复杂不少。
soa本身能解决哪些问题，不能解决哪些问题，到底能带来什么好处？
soa的范围包括：
soa最重要的作用：
soa能保证车内和车外所有使用以太网通信的软件采用同一套数据格式进行数据交换，避免大量的软件接口适配和数据不兼容，给oem和供应商双方都省去大量的集成成本。长期来看，soa会是未来 汽车 开放平台的基础，如果有一天特斯拉开放和苹果类似的应用商店，面向服务架构必然是最底层的技术基础。
soa不包含：
另外oem需要的软硬件解耦能力，须由操作系统和soa中间件开发商共同提供，操作系统可以通过驱动模型、硬件抽象和设备树等方式把常用的标准零部件转成系统接口，但各oem的零部件很多都是非标准化的，操作系统并没自带这些零部件系统接口，所以还需要soa这样的架构来补充这部分零部件的协议转化和为应用层提供api。
在实际soa项目落地过程中，会有各种车载网络和硬件的限制条件，尤其是soa整体性能问题，会牵涉到车内现有网络和ecu的性能和负载瓶颈，需要oem和零部件厂商共同解决，都是有不小的挑战。另外soa虽然是后台架构，但也会被质疑能带来什么用户体验，这涉及到应用层开发，确实需要一些新的app或新场景来验证soa的作用。
汽车 行业的工程师多年来习惯了先找行业标准，工具，然后才是研发，制造，最后再用标准来测试验证的闭环，这套流程是典型的制造行业的模式，凡事都得先看看有没有行业标准和成熟工具，上下游各公司都用同一套标准，最后以最小的成本和最低的风险把 汽车 造出来，流程很稳定，但这种思维模式会让工程师过分依赖标准和工具，失去真正的研发和创新能力，尤其是整车架构中很多标准和协议都是欧美日定义的，大量的资金都投给了国外的工具商和外资tier-1，给到工程团队的研发费用反而很少。现在这套闭环被特斯拉带头用更先进的理念和技术打破了，还造出了跨代领先的产品，证明了开源软件在车内的可行性。而且新的智能软件并不像硬件或者嵌入式软件需要那么多规范，传统 汽车 软件开发类似于做填空题，题干都被固定了，我们只能做最没有技术含量的部分，而智能软件都是根据用户需求自行开发，更像是写作文，就一个题目，剩下的自由发挥。这个变化对于新一代智能 汽车 或者新一代的 汽车 软件供应商，都是研发能力升级的最佳机会，也有充分的商业动机去完成新一代核心软件和工具的国产化。
作者：
luke chen
快控 科技 ceo
