Service-Oriented Architecture，面向服务架构，SOA是一种架构模型，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理互联网纾的人为依赖性。SOA的几个关键特性：一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义适配器进行通讯，不涉及底层编程适配器和通讯模型。
这个定义很准确，可是却不能形象的让人们理解SOA的意义和作用。
谈到SOA，总是让人们感觉好象很神秘或者感觉到这是一个颠覆，颠覆了开发者的一些习惯性思维，特别是中小开发团队和个人开发者，有时候甚至无从下手。但是如果在团队里有一位精明的系统设计师和策划人员，开发者就会感觉到SOA实际上让开发的工作更加轻松愉快，整个系统更加清晰。
SOA的重点在于分离“服务”。当面向服务的思路还是很清晰的时候，最另人疑惑的是如何将系统功能打包为服务，或者将哪些功能打包为服务。
曾经，我的老板问我，将系统的功能都单独的一个个分离出来，例如上传，添加数据库记录，验证输入等，这样我们可以在开发其他产品时重新组合一下就可以了。可是，这样的感觉似乎更像是面向对象的结构，将一个单独的功能封装好重复利用。SOA，则是需要服务。
打个比方，现在在网上购物是件很轻松愉快的事情。整个购物的流程是这样的：购买者浏览网上购物的网站，然后下订单，之后网站会要求购买者银行付款并提供依据，如果是网络银行那就更方便些；卖家再查看到订单和购买者的支付依据后，会通过邮政或快递发送货物，货物通过航空、铁路或公路货运部门发送到购买者所在地，最后，又是邮政或快递公司将货物送到购买者手上。
在用户看来，网上购物是由网站购物网站提供的服务，实际上，在完整的购买过程中我们需要利用很多部门或单位提供的服务。
网站提供了直接面向客户，展示产品的服务，通过网站，用户看到了物品，和相关的信息；
之后，我们需要银行的转帐或汇款服务，这一点对于买卖双方当然都是非常重要的。
接下来分别是邮政和快递公司的服务，货运部门的服务。
每一个环节都相当的重要，可是它们之间却没有绝对的关系，各个部分都是独立的、分离的，都拥有自己的完善业务系统，不会互相依赖，其中任何一个环节不必去关心其他环节的具体操作问题，其中一个环节如果做出调整或出现问题，只要服务依然以相同形式存在，那么对于整个流程不会造成任何影响，当然，最坏的情况是某个环节瘫痪，也许多少会对整个流程造成影响，但是却不会影响另外的环节，并且我们可以想办法绕过瘫痪的环节，因此，整个流程中的各个环节是松散的，而将他们所提供的服务串联之后便可以为普通用户提供新的服务了。
在现实生活中，这样的应用非常多。人们都习以为常，但是运用到软件开发中却困难重重，就我个人来看，归咎原因主要还是开发者没有将服务明确，甚至有时候将面向服务变成了面向对象。
首先，需要搞清楚，面向服务开发，提供出的是服务，而不是应用本身。也就是说，一个应用或一个系统，它必须在具备独立和完善的功能才可以为别的应用或系统提供服务。例如一个新闻系统，提供一个新闻列表的WEB服务（这看上去就好象是RSS一样），但是如果说仅提供一个列表WEB服务，那么它不具备整套新闻系统的完整功能，那么就必须做另一个服务去给它管理新闻，这样的话，新闻列表的WEB服务就必须依赖两个地方，一是接收这个列表的WEB页，二是管理新闻的系统，如果任何一方出现变动，那么这个新闻列表将是无用的。因此，我们应该做一套完整的，既可以管理新闻，又可以阅读新闻的新闻系统，只后再向外提供新闻列表服务，这样，系统本身是独立的，就算提供的服务没有任何使用，系统本身也是正常运作着的。
在正确的分析好服务后，开发工作实际上就变得简单了。
如果你需要提供服务提供开发者，开发工作会变得很单纯，只需要考虑自己的应用，再提供一个公共的服务出来，你不必考虑你的内部设计会影响别人，包括数据库设计和运行环境和平台，开发者将有更自由的发挥空间，只需要确保服务方式保持不变就可以了。当然，你可以尽可能多的提供服务模式，这样，也就可以更多的适应各种不同的需求。
而对于需要应用服务的开发者来说更是省心不少，不必考虑太多，没必要知道它是怎么做到的，只要知道它能做什么，只需要了解服务提供者的服务模式，之后，至于怎么用就完全自由发挥，就好象组装你的家用电脑一样，你需要什么样硬件设备直接找提供商获得，至于硬盘和内存条要怎么做出来那就不需要了解了，组装好，插上电源，OK！
如果有选择的话，甚至你可以随时更换更优秀的设备。
在实际开发中，有很多SOA的架构是应用在一个系统平台下的，或是在一个产品体系中，这样看来，似乎可选择性并不是那么明显，也许一个由不同服务共同组合出来的新服务还是具有互相依赖的关系，但是它仍然具备面向服务开发的其他优点。面向服务开发可以让复杂个流程更加表面化，让团队中的分工更加清晰，这样，最起码就降低了维护成本。
如果SOA仅仅只是这样，可能不会这么引人注目。
设想一下，将来，互联网会看上去更加紧凑，各个从事软件开发或互联网服务的公司不再是产品的竞争，而是服务的竞争。用户不再是使用某一个产品，而是使用一系列服务，而这些服务是不同的公司提供的有机的，就如同我们现实生活中一样。一个小团队同样可以为他们的用户群提供非常强大的服务，因为这些不需要他们自己动手，只需要能为用户设计一套完整的服务流程。
而对用户来说，则更丰富的获得了信息、资源和服务，同样，也有了更多的选择。
SOA，更需要被应用到整个互联网而非只是局部的开发！
自互联网出现以来，信息孤岛是一直存在的一个问题，搜索引擎的出现改善了这样的问题。用户通过搜索关键子来获得互联网上的有用的信息，信息提供者的信息一旦被搜索引擎收录，那么它就将有机会被送到需要的用户眼前。现在GOOGLE、BAIDU等各大搜索引擎的功能越来越强大，似乎我们不必担心找不到信息，也不必担心自己发布的信息没人看见，但是这并不是真正的资源共享。这种方式相当的被动，这就好象是去逛街买东西一样，而企业与企业，网站与网站之间的资源共享更像是原料商、工厂、销售商之间的互相协作的关系。更何况，SOA所要共享的资源更加广泛，包括功能上的实现。
SOA这种构架的出现并不会降低搜索引擎的重要性。相反，它们之间的互相作用会对彼此都相当有利，例如，我们通过搜索引擎搜索到一个关于订购机票的网站，到此为止，我们就找到相关机票订购的信息，但如果这个网站同时拥有很丰富的服务项目，像酒店订房、货物托运、旅行手册等相关的服务，这样，用户就获得了更多更丰富的信息和功能，当然，目前类似的网站也已经很多，但是决大多数都是网站自己本身在维护这些服务，这样的话，服务的质量和信息的准确性都大打折扣。如果是几家比较专业的网站互相协作形成系统服务，就会好很多。
具体来说，SOA的实现是非常灵活的，可以采用多种方式。相对与其他开发结构来说，它更加的表面化，这也是SOA的最大的特点，当我们面向对象开发很熟练之后，开发者就会寻求一种让系统平台更加松散偶合的构架方式。互联网发展至今，用户的需求越来越高，各个系统平台也越来越复杂，开发者门通过面向对象的方式让自己的工作更加清晰，维护更加简便，同样的，我们也需要让一个系统平台的工作更加清晰。这也是SOA出现的原因。
WEBSERVICE是当前构建SOA最常用的技术之一。WEBSERVICE利用了HTTP协议，这样使得服务的提供和获取非常的简单，就像是一个很普通的请求与响应一样，当然，我们不可能像看网页一样那么直接的使用了。通过一些客户端脚本将WEBSERVICE提供的数据格式好以后提供给用户，同样的，客户端脚本将用户需要提交的数据格式好，然后便可以请求服务。另外，WEBSERVICE所用的XML格式的标记方式，使得我们的服务更容易让别人理解再加上WSDL的说明，就好象是银行门口张贴的业务介绍和流程介绍一样。服务提供者甚至都可以不用和服务使用者之间有过多的交流就可以正常的被运用起来（当然，开发者之间的交流是相当重要的）。
前面，讲到很多关于SOA的好处和概念，可是怎么实现呢？既然要松散偶合，既然要面向服务，当然，必须先明确你的服务。例如，我在公司的系统平台中负责了用户系统的开发，这时候，我的用户系统就需要提供服务给其他系统使用。最常见的当然就是登陆验证以及注册功能，同时还必须有获得用户信息的功能。这时候我就可以明确，我有3个服务是必须提供的，登陆验证服务、注册服务、获得用户信息的服务。OK，当明确这些服务后，剩下的时候和平时的开发几乎就没什么两样，只要我最终能提供一个WEBSERVICE可以实现这3个服务就可以了，至于我的用户系统内部是怎么工作的就与此无关了。同样的，其他系统也一样，它们只需要知道怎么利用我提供的服务去验证在它们那里登陆的用户，而用户的验证方法和用户的数据信息它们完全可以不必理会，当需要用户信息的时候在从我的服务这里获得就行了，就好象是我们在用118114查询电话一样，只要在我需要的时候我去找118114问就可以了，不必我也自己拿个本子收集记录下来。
SOA看起来好象很不寻常，不过仔细分析一下，好象比现实生活中的其他应用来说其实是简单了不少。我们一直都在生活中接受服务和提供服务，将这样的概念和方式转移到我们的软件开发中也就形成了SOA。