SOA，现在进行时(摘抄自袁红岗Blog)
(分析的很透彻，至少我还看的懂，没有被抛弃的很远，特别喜欢那种由浅入深的文章和数据，也推荐给大家看看)
SOA现在正热得"烫手"。
对于SOA，目前我听到有两种说法：一种讲它是"颠覆性的革命架构"，一种是"谨慎观望"。但无疑，SOA最近几年发展得非常快，各主要软件厂商纷纷高调跟进，关于SOA的报道可以说是不绝于耳。对"SOA热"，程序员们有的兴奋和期待，有的则感到困惑，最近我在金蝶中间件于广州、上海等城市举行的"Java俱乐部"上和程序员们交流时，他们或是以一种朝圣者的表情说："以前面向对象的技术过时了，SOA时代来了"，或者一再恳切地追问我："SOA到底是什么？作用是什么？"
那么，SOA是什么?到底能解决什么问题、解决得怎样?我们和客户都准备好了吗?我给出的答案是"Just Processing，SOA-现在进行中"。
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可能应用于两个场景：第一种是业务互通互联；第二种是封闭交易系统，即将元数据和业务逻辑抽离，形成可复用。举个例子，在第一种场景中，当不同企业之间的业务需要相互调用，这时就可能采用SOA技术；在第二种场景中，在企业内部需要将系统进行迁移时，利用SOA技术定义的原有数据和业务流程，可以很快完成。
无疑，SOA是一个伟大的思想，它试图定义一个大家（各种软件厂商）都"认"的、都"遵循"的法则，大家都使用这样的方法来进行互联互通，从而实现无界限的联通，以及服务组件库的继承和复用，解放无效和重复劳动。打一个不那么恰当的比喻，就像人类的语言一样。SOA或许就像《圣经》中那个著名的"通天塔"的故事：人们用同一种语言交流产生的威力是如此之大，以至于他们在巴比伦几乎要修成一个"通天塔"，直达上帝所在的天庭。
但是，在SOA应用的两个场景中，现存的问题同样也是明显的：
第一种场景：业务互联互通，就是应用系统互联。业务互联，与其说是技术问题，不如讲是业务问题，例如ERP、CRM的异步整合，数据层面整合都不能很好将两个系统整合，SOA仅仅是一种实现工具之一，整合效果并不会好不到那里去。我们可以说，在没有其他选项之前，SOA是一种最"不坏"的方式，但它并不能解决所有的问题，实际上EAI的牵涉面很广，而我们知道，有些问题并不是单纯靠技术就能解决的。
第二种场景：封闭交易系统，缺点是性能慢，而且基于Web Services的交易没有形成明确的规范。使用XML作信息交互比较慢是大家都承认的，性能问题将对SOA的发展造在一定的阻力。同时SOA规范本身没有完善，比如Transaction规范还在不断完善，而且Web Service多年来收效甚微。总的来说，SOA现在还处在一个发展阶段，很多标准还在制定，不同厂商间还存在不兼容的现象，因此SOA还不能说已经是一个成熟的技术，还需要时间的检验，还在"进行中"。当然，金蝶中间件作为JCP组织成员，也会推动SOA规范在J2EE平台上的实现。
中国用户的现实选择之惑
在憧憬SOA技术可能带来的前景之余，我们不得不回过头来冷静地说：SOA和我们大家的共同客户――中国企业还有距离。
中国信息化进程与欧美不同，大量的基础业务系统还没建立起来，整合需求并不如想象的那么大。从我们对客户的了解，发现很少有客户有SOA的需求。简单地总结就是，互通无基础，以新建系统为主，需求并不强烈。而欧美市场大量业务系统已建立起来需要整合，从这个角度讲，SOA是适用于他们的。同时，在成功案例极少的前提下，SOA还处于培育期，新建封闭交易系统使用SOA技术还是有一定风险的。
一项新技术需要市场的消化，大型企业出于保护企业投资，不会轻易地转移到新的技术平台；而即使像J2EE这样成熟的技术经过了这么多年的发展，也不敢说占有统治地位的市场份额。SOA还需要整个IT界的用户和供应商共同促进。
中国信息化需要什么样的技术架构、能够接受什么样的成本价位？这不仅仅是我们的客户需要考虑，我们软件厂商要比客户考虑得更清楚、更进一步。在这个充满变数的激烈竞争市场，只有冷静务实才能生存、发展。
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的主要构成是怎么样的？
Soap的设计目标是：简单性 和 兼容性 。
SOAP协议构成方式，包括四个部分：
SOAP封装(envelop)：SOAP信封规范对计算机间传递的数据如何封装定义了具体的规则。这包括应用特定的数据，如要调用的方法名，方法参数和返回值；还包括谁将处理封装内容，失败时如何编码错误消息等信息。
SOAP编码规则（encoding rules）：为了交换数据，计算机必须在编码特定数据类型的规则上达成一致，SOAP也有自己的一套编码数据类型的约定。大部分约定都基于W3C XML Schema规范 。
SOAP RPC表示(RPC representation)：SOAP为双向消息接发定义了一个简单的协定来进行远程过程调用和响应，这使得客户端应用可以指定远程方法名，获取任意多个参数并接受来自服务器的响应。
SOAP绑定（binding）：提供了更底层协议传输SOAP封套的一套通用机制。
下面我们要重点关注的内容是：
1>.soap协议的封装：
2>.soap协议的Rpc表示。（具体与Http协议绑定实现）
Soap的封装方式
SOAP消息是一个XML文档，包括一个必需的SOAP封装(SOAP-ENV：Envelope)，一
个可选的SOAP头(SOAP-ENV：Head)和一个必需的SOAP体(SOAP-ENV：Body)。
一个简单的Soap封装的例子
A．XML文件
<?xml version="1.0" encoding='UTF-8' ?>
<Hello>
<sayHelloTo>
<name>John</name>
</sayHelloTo>
</Hello>
B． Soap封装后的XML文件
<?xml version='1.0' encoding='UTF-8'?> §XML声明
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/
§解析：名字空间声明，防止多个XML文件组合时发生标签名字的冲突
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
§解析：声明了XML模式实例的名字空间
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
§解析：另外一个名字空间声明，它定义了XML Schema名字空间，这个名字空间下
的元素用来指定xsi:type 属性的值（如xsd:string）
<SOAP-ENV:Header>
</SOAP-ENV:Header>
§解析：简单的存放一些指令，提供给接收消息的SOAP处理器。可选项在这里可以去除掉
<SOAP-ENV:Body>
§解析：SOAP主体用来存放实际数据或消息的有效负载，从而提供给最终的接受者使用或处理。
<ns1:sayHelloTo
xmlns:ns1="Hello"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<name xsi:type="xsd:string">John</name>
</ns1:sayHelloTo>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Soap的Rpc表示（与Http协议绑定）
C． Soap协议绑定Http协议生成的请求
POST http://www.SmartHello.com/HelloApplication HTTP/1.1
§解析：代码表明这是一个遵循HTTP 1.1规范的POST请求，POST的目标是http://www.SmartHello.com/HelloApplication
Content-Type: text/xml; charset="utf-8"
§解析：在HTTP消息中包含SOAP实体时，内容类型必须是text/xml
Content-Length: 587
§解析：指明了POST请求有效载荷的长度
SOAPAction: "http://www.SmartHello.com/HelloApplication#sayHelloTo"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Header>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<ns1:sayHelloTo
xmlns:ns1="Hello"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<name xsi:type="xsd:string">John</name>
</ns1:sayHelloTo>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
D．Soap协议绑定Http协议生成的响应
l 生成正确的信息
HTTP/1.0 200 OK
§解析：在HTTP协议中，200应答状态代码表示“一切正常”。如果在处理SOAP消息(Header区或者Body区)的时候出现了任何错误，则返回的状态代码将是500。在HTTP中，500状态代码表示“internal server error”。此时，上述SOAP应答的第一行代码将是:HTTP 500 Internal Server Error
Content-Type: text/xml; charset="utf-8"
Content-Length: 615
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="
http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="
http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:sayHelloToResponse
xmlns:ns1="Hello"
SOAP-ENV:encodingStyle="
http://schemas.xmlsoap.org/soap/encoding/">
<return xsi:type="xsd:string">Hello John, How are
you doing?</return>
</ns1:sayHelloToResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
l 生成出错的信息 （处理必要的头出错）
HTTP/1.1 500 Internal Server Error
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
§解析：fault表示相应的错误元素
<faultcode>SOAP-ENV:MustUnderstand</faultcode>
§解析：faultcode元素给软件提供了一个识别此错误的算法机制。SOAP定义一些SOAP faultcode描述基本的SOAP错误
<faultstring>SOAP Must Understand Error</faultstring>
§解析：SOAP错误元素必须有faultstring子元素，并且它应该提供一些错误本质的解释信息。
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
l 生成出错的信息 （处理处理Body出错）
HTTP/1.1 500 Internal Server Error
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring>Server Error</faultstring>
<detail>
§解析：detail元素用来携带与Body元素有关的应用程序所要的错误信息。如果Body元素的内容不能被成功的处理，则必须包含detail子元素。Fault元素中没有detail元素表示这个错误与Body元素的处理无关。在有错误的时候，这可以用来区分Body元素有没有被正确的处理。
<e:myfaultdetails xmlns:e="Some-URI">
<message>
My application didn't work
</message>
<errorcode>
1001
</errorcode>
</e:myfaultdetails>
</detail>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Soap如何实现与Http协议的绑定？
服务器怎样解释这个请求-URI是与实现相关的，但是许多实现中可能用它来映射到一个类或者一个对象。
一个SOAP请求也必须用SOAPMethodName HTTP头来指明将被调用的方法。简单地讲，SOAPMethodName头是被URI指定范围的应用相关的方法名，它是用#符作为分隔符将方法名与URI分割开：
SOAPMethodName: urn:strings-com:IString#reverse
这个头表明方法名是reverse，范围URI是urn:strings-com:Istring。
简单的说，一个SOAP请求的HTTP体是一个XML文档，它包含方法中[in]和[in,out]参数的值。这些值被编码成为一个显著的调用元素的子元素，这个调用元素具有SOAPMethodName HTTP头的方法名和名域URI。调用元素必须出现在标准的SOAP <Envelope>和<Body>元素内（后面会更多讨论这两个元素）。
下面是一个最简单的SOAP方法请求：
POST /string_server/Object17 HTTP/1.1
Host: 209.110.197.2
Content-Type: text/xml
Content-Length: 152
SOAPMethodName: urn:strings-com:IString#reverse
§解析：SOAPMethodName头必须与<Body>下的第一个子元素相匹配，否则调用将被拒绝
<Envelope>
<Body>
<m:reverse xmlns:m=''urn:strings-com:IString''>
<theString>Hello, World</theString>
</m:reverse>
</Body>
</Envelope>
SOAP响应的格式类似于请求格式。下面是对前面的SOAP请求的SOAP响应：
200 OK
Content-Type: text/xml
Content-Length: 162
<Envelope>
<Body>
<m:reverseResponse xmlns:m=''urn:strings-com:IString''>
§解析：这个元素的名字与请求的调用元素的名字相同，但以Response后缀来连接。
<result>dlroW ,olleH</result>
</m:reverseResponse>
</Body>
</Envelope>
这里响应元素被命名为reverseResponse，它是方法名紧跟Response后缀。要注意的是这里是没有SOAPMethodName HTTP头的。这个头只在请求消息中需要，在响应消息中并不需要。
Apache Soap的编程语法
A．搭建Apache Soap工作环境
1． 下载需要的jar包
2． 配置环境变量
（配置到Apache Tomcat 运行环境，配置到系统classpath便于通过命令行编译运行Soap控制台）
3． 实现Soap运行环境
B． 部署一个简单的Apache Soap实例
通过两种方式部署Soap服务
通过具体代码看看Soap服务的实现。
C．Apache Soap更近一步的知识可以参考Apache Soap的Api，以及Axis的相关内容
----------------------------------------------------------------------------------
什么是Web Service
新一篇: Soap技术总结
Web service到底是什么；在什么情况下你应该使用Web service。
分布式应用程序和浏览器
研究一下当前的应用程序开发，你会发现一个绝对的倾向：人们开始偏爱基于浏览器的瘦客户应用程序。这当然不是因为瘦客户能够提供更好的用户界面，而是因为它能够避免花在桌面应用程序发布上的高成本。发布桌面应用程序成本很高，一半是因为应用程序安装和配置的问题，另一半是因为客户和服务器之间通信的问题。
传统的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进行通信，不论两个程序的平台和编程语言是什么。
什么是Web Service
对这个问题，我们至少有两种答案。从表面上看，Web service 就是一个应用程序，它向外界暴露出一个能够通过Web进行调用的API。这就是说，你能够用编程的方法通过Web来调用这个应用程序。我们把调用这个Web service 的应用程序叫做客户。例如，你想创建一个Web service ，它的作用是返回当前的天气情况。那么你可已建立一个ASP页面，它接受邮政编码作为查询字符串，然后返回一个由逗号隔开的字符串，包含了当前的气温和天气。要调用这个ASP页面，客户端需要发送下面的这个HTTP GET请求：
http://host.company.com/weather.asp?zipcode=20171
返回的数据就应该是这样：
21,晴
这个ASP页面就应该可以算作是Web service 了。因为它基于HTTP GET请求，暴露出了一个可以通过Web调用的API。当然，Web service 还有更多的东西。
下面是对Web service 更精确的解释： 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平台的这三个技术。
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类型。你用的工具可能已经自动帮你完成了这个转换，但你很可能会根据你的需要修改一下转换过程。在第二章中，我们将深入XSD，学习怎样转换自定义的数据类型(例如类)到XSD的类型。
SOAP
Web service建好以后，你或者其他人就会去调用它。简单对象访问协议(SOAP)提供了标准的RPC方法来调用Web service。实际上，SOAP在这里有点用词不当：它意味着下面的Web service是以对象的方式表示的，但事实并不一定如此：你完全可以把你的Web service写成一系列的C函数，并仍然使用SOAP进行调用。SOAP规范定义了SOAP消息的格式，以及怎样通过HTTP协议来使用SOAP。SOAP也是基于XML和XSD的，XML是SOAP的数据编码方式。第三章我们会讨论SOAP，并结识SOAP消息的各种元素。
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的代码。
什么是SOAP?
1.SOAP也被称作XMLP，为两个程序交换信息提供了一种标准的工作机制。在各类机构之间通过电子方式相互协作的情况下完全有必要为此制定相应的标准。
交换信息可以采用很多方法，比如电子邮件、即时聊天和远程过程调用（RPC）等。电子邮件和聊天消息通常不具备计算机友好性。计算机可以读取电子邮件报头，但是其类型内容却无法得到计算机这个"硅脑袋"的理解。即时聊天和RPC也面临同样的尴尬情况：计算机倒是可读可人又没法读了。
计算机确实知道如何理解XML。SOAP描述了把消息捆绑为XML的工作方式。它还说明了发送消息的发送方、消息的内容和地址以及发送消息的时间。这也是为什么把SOAP叫做一种协议的原因。SOAP并没有同电子邮件协议（SMTP）、RPC（套接字和IDL）或者Web协议（HTTP）截然分开。SOAP要利用这些系统作为消息的起点。
2.SOAP是Web Service的基本通信协议。因为SOAP与DCOM和CORBA在概念上有相同之处，所以很多人在问："SOAP是怎样激活对象的？"或"SOAP在使用什么命名服务（Naming Service）？"。或许在执行SOAP的过程当中会用到这些，但这些并不在SOAP规范要考虑的范畴之内。SOAP只是定义SOAP消息的XML格式（XML Format），如果你用一对SOAP标记（SOAP Elements）把XML文档括起来，那么这个就是一个SOAP消息，这不是很简单吗？
3.SOAP规范还定义了怎样用XML来描述程序数据（Program Data）,怎样执行RPC（Remote Procedure Call）。这些可选的规范是为了构建RPC-style的应用程序（客户端SOAP消息包含函数名和在函数中用到的参数，而服务器端SOAP消息包含执行函数之后的结果）。大多数SOAP解决方案都支持RPC-style应用程序，因为很多程序员已对DCOM或CORBA熟悉。SOAP还支持Document-style应用程序（SOAP消息只包含XML文本信息）。Document-style应用程序有很好的灵活性，所以很多用RPC很难构建的Web Service用这种方式构建。
1.最后SOAP规范还定义了HTTP消息是怎样传输SOAP消息的。这并不代表SOAP只能用HTTP来作为传输协议，MSMQ、SMTP、TCP/IP都可以做SOAP的传输协议。
很多大公司根据SOAP规范，都开发出了自己的SOAP解决方案。这些解决方案都是相对于某种语言。比如说Microsoft SOAP toolkit2.0把COM函数转换成SOAP消息，而Apache toolkit把JAVA函数转换成SOAP消息。这样难免带来一些兼容性问题。
现在SOAP的很多另人瞩目的特性已成为现实（SOAP已经运行于不同的硬件和软件平台），而且有70多个解决方案。之所以SOAP被人们所爱戴，是因为SOAP比其他同类技术（CORBA、DCE）简单易用。
安全性对于应用程序来说是很重要的。那么SOAP的安全性如何呢？对于把HTTP作为传输协议的SOAP来说是没有问题的，因为HTTP协议已经有很好的安全构架。那么用其他传输协议会出现安全问题吗？不是的，你不必担心，因为已经有这方面的规范了（http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-security.asp）。
2.簡易物件存取協定
SOA，现在进行时(摘抄自袁红岗Blog)
(分析的很透彻，至少我还看的懂，没有被抛弃的很远，特别喜欢那种由浅入深的文章和数据，也推荐给大家看看)
SOA现在正热得"烫手"。
对于SOA，目前我听到有两种说法：一种讲它是"颠覆性的革命架构"，一种是"谨慎观望"。但无疑，SOA最近几年发展得非常快，各主要软件厂商纷纷高调跟进，关于SOA的报道可以说是不绝于耳。对"SOA热"，程序员们有的兴奋和期待，有的则感到困惑，最近我在金蝶中间件于广州、上海等城市举行的"Java俱乐部"上和程序员们交流时，他们或是以一种朝圣者的表情说："以前面向对象的技术过时了，SOA时代来了"，或者一再恳切地追问我："SOA到底是什么？作用是什么？"
那么，SOA是什么?到底能解决什么问题、解决得怎样?我们和客户都准备好了吗?我给出的答案是"Just Processing，SOA-现在进行中"。
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可能应用于两个场景：第一种是业务互通互联；第二种是封闭交易系统，即将元数据和业务逻辑抽离，形成可复用。举个例子，在第一种场景中，当不同企业之间的业务需要相互调用，这时就可能采用SOA技术；在第二种场景中，在企业内部需要将系统进行迁移时，利用SOA技术定义的原有数据和业务流程，可以很快完成。
无疑，SOA是一个伟大的思想，它试图定义一个大家（各种软件厂商）都"认"的、都"遵循"的法则，大家都使用这样的方法来进行互联互通，从而实现无界限的联通，以及服务组件库的继承和复用，解放无效和重复劳动。打一个不那么恰当的比喻，就像人类的语言一样。SOA或许就像《圣经》中那个著名的"通天塔"的故事：人们用同一种语言交流产生的威力是如此之大，以至于他们在巴比伦几乎要修成一个"通天塔"，直达上帝所在的天庭。
但是，在SOA应用的两个场景中，现存的问题同样也是明显的：
第一种场景：业务互联互通，就是应用系统互联。业务互联，与其说是技术问题，不如讲是业务问题，例如ERP、CRM的异步整合，数据层面整合都不能很好将两个系统整合，SOA仅仅是一种实现工具之一，整合效果并不会好不到那里去。我们可以说，在没有其他选项之前，SOA是一种最"不坏"的方式，但它并不能解决所有的问题，实际上EAI的牵涉面很广，而我们知道，有些问题并不是单纯靠技术就能解决的。
第二种场景：封闭交易系统，缺点是性能慢，而且基于Web Services的交易没有形成明确的规范。使用XML作信息交互比较慢是大家都承认的，性能问题将对SOA的发展造在一定的阻力。同时SOA规范本身没有完善，比如Transaction规范还在不断完善，而且Web Service多年来收效甚微。总的来说，SOA现在还处在一个发展阶段，很多标准还在制定，不同厂商间还存在不兼容的现象，因此SOA还不能说已经是一个成熟的技术，还需要时间的检验，还在"进行中"。当然，金蝶中间件作为JCP组织成员，也会推动SOA规范在J2EE平台上的实现。
中国用户的现实选择之惑
在憧憬SOA技术可能带来的前景之余，我们不得不回过头来冷静地说：SOA和我们大家的共同客户――中国企业还有距离。
中国信息化进程与欧美不同，大量的基础业务系统还没建立起来，整合需求并不如想象的那么大。从我们对客户的了解，发现很少有客户有SOA的需求。简单地总结就是，互通无基础，以新建系统为主，需求并不强烈。而欧美市场大量业务系统已建立起来需要整合，从这个角度讲，SOA是适用于他们的。同时，在成功案例极少的前提下，SOA还处于培育期，新建封闭交易系统使用SOA技术还是有一定风险的。
一项新技术需要市场的消化，大型企业出于保护企业投资，不会轻易地转移到新的技术平台；而即使像J2EE这样成熟的技术经过了这么多年的发展，也不敢说占有统治地位的市场份额。SOA还需要整个IT界的用户和供应商共同促进。
中国信息化需要什么样的技术架构、能够接受什么样的成本价位？这不仅仅是我们的客户需要考虑，我们软件厂商要比客户考虑得更清楚、更进一步。在这个充满变数的激烈竞争市场，只有冷静务实才能生存、发展。
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的主要构成是怎么样的？
Soap的设计目标是：简单性 和 兼容性 。
SOAP协议构成方式，包括四个部分：
SOAP封装(envelop)：SOAP信封规范对计算机间传递的数据如何封装定义了具体的规则。这包括应用特定的数据，如要调用的方法名，方法参数和返回值；还包括谁将处理封装内容，失败时如何编码错误消息等信息。
SOAP编码规则（encoding rules）：为了交换数据，计算机必须在编码特定数据类型的规则上达成一致，SOAP也有自己的一套编码数据类型的约定。大部分约定都基于W3C XML Schema规范 。
SOAP RPC表示(RPC representation)：SOAP为双向消息接发定义了一个简单的协定来进行远程过程调用和响应，这使得客户端应用可以指定远程方法名，获取任意多个参数并接受来自服务器的响应。
SOAP绑定（binding）：提供了更底层协议传输SOAP封套的一套通用机制。
下面我们要重点关注的内容是：
1>.soap协议的封装：
2>.soap协议的Rpc表示。（具体与Http协议绑定实现）
Soap的封装方式
SOAP消息是一个XML文档，包括一个必需的SOAP封装(SOAP-ENV：Envelope)，一
个可选的SOAP头(SOAP-ENV：Head)和一个必需的SOAP体(SOAP-ENV：Body)。
一个简单的Soap封装的例子
A．XML文件
<?xml version="1.0" encoding='UTF-8' ?>
<Hello>
<sayHelloTo>
<name>John</name>
</sayHelloTo>
</Hello>
B． Soap封装后的XML文件
<?xml version='1.0' encoding='UTF-8'?> §XML声明
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/
§解析：名字空间声明，防止多个XML文件组合时发生标签名字的冲突
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
§解析：声明了XML模式实例的名字空间
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
§解析：另外一个名字空间声明，它定义了XML Schema名字空间，这个名字空间下
的元素用来指定xsi:type 属性的值（如xsd:string）
<SOAP-ENV:Header>
</SOAP-ENV:Header>
§解析：简单的存放一些指令，提供给接收消息的SOAP处理器。可选项在这里可以去除掉
<SOAP-ENV:Body>
§解析：SOAP主体用来存放实际数据或消息的有效负载，从而提供给最终的接受者使用或处理。
<ns1:sayHelloTo
xmlns:ns1="Hello"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<name xsi:type="xsd:string">John</name>
</ns1:sayHelloTo>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Soap的Rpc表示（与Http协议绑定）
C． Soap协议绑定Http协议生成的请求
POST http://www.SmartHello.com/HelloApplication HTTP/1.1
§解析：代码表明这是一个遵循HTTP 1.1规范的POST请求，POST的目标是http://www.SmartHello.com/HelloApplication
Content-Type: text/xml; charset="utf-8"
§解析：在HTTP消息中包含SOAP实体时，内容类型必须是text/xml
Content-Length: 587
§解析：指明了POST请求有效载荷的长度
SOAPAction: "http://www.SmartHello.com/HelloApplication#sayHelloTo"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Header>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<ns1:sayHelloTo
xmlns:ns1="Hello"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<name xsi:type="xsd:string">John</name>
</ns1:sayHelloTo>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
D．Soap协议绑定Http协议生成的响应
l 生成正确的信息
HTTP/1.0 200 OK
§解析：在HTTP协议中，200应答状态代码表示“一切正常”。如果在处理SOAP消息(Header区或者Body区)的时候出现了任何错误，则返回的状态代码将是500。在HTTP中，500状态代码表示“internal server error”。此时，上述SOAP应答的第一行代码将是:HTTP 500 Internal Server Error
Content-Type: text/xml; charset="utf-8"
Content-Length: 615
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="
http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="
http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:sayHelloToResponse
xmlns:ns1="Hello"
SOAP-ENV:encodingStyle="
http://schemas.xmlsoap.org/soap/encoding/">
<return xsi:type="xsd:string">Hello John, How are
you doing?</return>
</ns1:sayHelloToResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
l 生成出错的信息 （处理必要的头出错）
HTTP/1.1 500 Internal Server Error
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
§解析：fault表示相应的错误元素
<faultcode>SOAP-ENV:MustUnderstand</faultcode>
§解析：faultcode元素给软件提供了一个识别此错误的算法机制。SOAP定义一些SOAP faultcode描述基本的SOAP错误
<faultstring>SOAP Must Understand Error</faultstring>
§解析：SOAP错误元素必须有faultstring子元素，并且它应该提供一些错误本质的解释信息。
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
l 生成出错的信息 （处理处理Body出错）
HTTP/1.1 500 Internal Server Error
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring>Server Error</faultstring>
<detail>
§解析：detail元素用来携带与Body元素有关的应用程序所要的错误信息。如果Body元素的内容不能被成功的处理，则必须包含detail子元素。Fault元素中没有detail元素表示这个错误与Body元素的处理无关。在有错误的时候，这可以用来区分Body元素有没有被正确的处理。
<e:myfaultdetails xmlns:e="Some-URI">
<message>
My application didn't work
</message>
<errorcode>
1001
</errorcode>
</e:myfaultdetails>
</detail>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Soap如何实现与Http协议的绑定？
服务器怎样解释这个请求-URI是与实现相关的，但是许多实现中可能用它来映射到一个类或者一个对象。
一个SOAP请求也必须用SOAPMethodName HTTP头来指明将被调用的方法。简单地讲，SOAPMethodName头是被URI指定范围的应用相关的方法名，它是用#符作为分隔符将方法名与URI分割开：
SOAPMethodName: urn:strings-com:IString#reverse
这个头表明方法名是reverse，范围URI是urn:strings-com:Istring。
简单的说，一个SOAP请求的HTTP体是一个XML文档，它包含方法中[in]和[in,out]参数的值。这些值被编码成为一个显著的调用元素的子元素，这个调用元素具有SOAPMethodName HTTP头的方法名和名域URI。调用元素必须出现在标准的SOAP <Envelope>和<Body>元素内（后面会更多讨论这两个元素）。
下面是一个最简单的SOAP方法请求：
POST /string_server/Object17 HTTP/1.1
Host: 209.110.197.2
Content-Type: text/xml
Content-Length: 152
SOAPMethodName: urn:strings-com:IString#reverse
§解析：SOAPMethodName头必须与<Body>下的第一个子元素相匹配，否则调用将被拒绝
<Envelope>
<Body>
<m:reverse xmlns:m=''urn:strings-com:IString''>
<theString>Hello, World</theString>
</m:reverse>
</Body>
</Envelope>
SOAP响应的格式类似于请求格式。下面是对前面的SOAP请求的SOAP响应：
200 OK
Content-Type: text/xml
Content-Length: 162
<Envelope>
<Body>
<m:reverseResponse xmlns:m=''urn:strings-com:IString''>
§解析：这个元素的名字与请求的调用元素的名字相同，但以Response后缀来连接。
<result>dlroW ,olleH</result>
</m:reverseResponse>
</Body>
</Envelope>
这里响应元素被命名为reverseResponse，它是方法名紧跟Response后缀。要注意的是这里是没有SOAPMethodName HTTP头的。这个头只在请求消息中需要，在响应消息中并不需要。
Apache Soap的编程语法
A．搭建Apache Soap工作环境
1． 下载需要的jar包
2． 配置环境变量
（配置到Apache Tomcat 运行环境，配置到系统classpath便于通过命令行编译运行Soap控制台）
3． 实现Soap运行环境
B． 部署一个简单的Apache Soap实例
通过两种方式部署Soap服务
通过具体代码看看Soap服务的实现。
C．Apache Soap更近一步的知识可以参考Apache Soap的Api，以及Axis的相关内容
----------------------------------------------------------------------------------
什么是Web Service
新一篇: Soap技术总结
Web service到底是什么；在什么情况下你应该使用Web service。
分布式应用程序和浏览器
研究一下当前的应用程序开发，你会发现一个绝对的倾向：人们开始偏爱基于浏览器的瘦客户应用程序。这当然不是因为瘦客户能够提供更好的用户界面，而是因为它能够避免花在桌面应用程序发布上的高成本。发布桌面应用程序成本很高，一半是因为应用程序安装和配置的问题，另一半是因为客户和服务器之间通信的问题。
传统的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进行通信，不论两个程序的平台和编程语言是什么。
什么是Web Service
对这个问题，我们至少有两种答案。从表面上看，Web service 就是一个应用程序，它向外界暴露出一个能够通过Web进行调用的API。这就是说，你能够用编程的方法通过Web来调用这个应用程序。我们把调用这个Web service 的应用程序叫做客户。例如，你想创建一个Web service ，它的作用是返回当前的天气情况。那么你可已建立一个ASP页面，它接受邮政编码作为查询字符串，然后返回一个由逗号隔开的字符串，包含了当前的气温和天气。要调用这个ASP页面，客户端需要发送下面的这个HTTP GET请求：
http://host.company.com/weather.asp?zipcode=20171
返回的数据就应该是这样：
21,晴
这个ASP页面就应该可以算作是Web service 了。因为它基于HTTP GET请求，暴露出了一个可以通过Web调用的API。当然，Web service 还有更多的东西。
下面是对Web service 更精确的解释： 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平台的这三个技术。
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类型。你用的工具可能已经自动帮你完成了这个转换，但你很可能会根据你的需要修改一下转换过程。在第二章中，我们将深入XSD，学习怎样转换自定义的数据类型(例如类)到XSD的类型。
SOAP
Web service建好以后，你或者其他人就会去调用它。简单对象访问协议(SOAP)提供了标准的RPC方法来调用Web service。实际上，SOAP在这里有点用词不当：它意味着下面的Web service是以对象的方式表示的，但事实并不一定如此：你完全可以把你的Web service写成一系列的C函数，并仍然使用SOAP进行调用。SOAP规范定义了SOAP消息的格式，以及怎样通过HTTP协议来使用SOAP。SOAP也是基于XML和XSD的，XML是SOAP的数据编码方式。第三章我们会讨论SOAP，并结识SOAP消息的各种元素。
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的代码。
什么是SOAP?
1.SOAP也被称作XMLP，为两个程序交换信息提供了一种标准的工作机制。在各类机构之间通过电子方式相互协作的情况下完全有必要为此制定相应的标准。
交换信息可以采用很多方法，比如电子邮件、即时聊天和远程过程调用（RPC）等。电子邮件和聊天消息通常不具备计算机友好性。计算机可以读取电子邮件报头，但是其类型内容却无法得到计算机这个"硅脑袋"的理解。即时聊天和RPC也面临同样的尴尬情况：计算机倒是可读可人又没法读了。
计算机确实知道如何理解XML。SOAP描述了把消息捆绑为XML的工作方式。它还说明了发送消息的发送方、消息的内容和地址以及发送消息的时间。这也是为什么把SOAP叫做一种协议的原因。SOAP并没有同电子邮件协议（SMTP）、RPC（套接字和IDL）或者Web协议（HTTP）截然分开。SOAP要利用这些系统作为消息的起点。
2.SOAP是Web Service的基本通信协议。因为SOAP与DCOM和CORBA在概念上有相同之处，所以很多人在问："SOAP是怎样激活对象的？"或"SOAP在使用什么命名服务（Naming Service）？"。或许在执行SOAP的过程当中会用到这些，但这些并不在SOAP规范要考虑的范畴之内。SOAP只是定义SOAP消息的XML格式（XML Format），如果你用一对SOAP标记（SOAP Elements）把XML文档括起来，那么这个就是一个SOAP消息，这不是很简单吗？
3.SOAP规范还定义了怎样用XML来描述程序数据（Program Data）,怎样执行RPC（Remote Procedure Call）。这些可选的规范是为了构建RPC-style的应用程序（客户端SOAP消息包含函数名和在函数中用到的参数，而服务器端SOAP消息包含执行函数之后的结果）。大多数SOAP解决方案都支持RPC-style应用程序，因为很多程序员已对DCOM或CORBA熟悉。SOAP还支持Document-style应用程序（SOAP消息只包含XML文本信息）。Document-style应用程序有很好的灵活性，所以很多用RPC很难构建的Web Service用这种方式构建。
1.最后SOAP规范还定义了HTTP消息是怎样传输SOAP消息的。这并不代表SOAP只能用HTTP来作为传输协议，MSMQ、SMTP、TCP/IP都可以做SOAP的传输协议。
很多大公司根据SOAP规范，都开发出了自己的SOAP解决方案。这些解决方案都是相对于某种语言。比如说Microsoft SOAP toolkit2.0把COM函数转换成SOAP消息，而Apache toolkit把JAVA函数转换成SOAP消息。这样难免带来一些兼容性问题。
现在SOAP的很多另人瞩目的特性已成为现实（SOAP已经运行于不同的硬件和软件平台），而且有70多个解决方案。之所以SOAP被人们所爱戴，是因为SOAP比其他同类技术（CORBA、DCE）简单易用。
安全性对于应用程序来说是很重要的。那么SOAP的安全性如何呢？对于把HTTP作为传输协议的SOAP来说是没有问题的，因为HTTP协议已经有很好的安全构架。那么用其他传输协议会出现安全问题吗？不是的，你不必担心，因为已经有这方面的规范了（http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-security.asp）。
2.簡易物件存取協定