注明:本帖作为学习之帖,难免有误解!
先来段百度百科的介绍:
面向服务的体系结构,是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

OASIS(一个SOA标准组织)给予出的SOA定义“SOA是一个范式,用于组织和利用可能处于不同所有权范围控制下的分布式系统。”
维基百科给出的SOA定义“面向服务的体系结构(Service-oriented architecture)是构造分布式系统的应用程序的方法。它将应用程序功能作为服务发送给最终用户或者其他服务。它采用开放标准、与软件资源进行交互并采用表示的标准方式。”。
要准确全面理解SOA,首先必须理解SOA的核心要素:

SOA的目标就是实现灵活可变的IT系统。要达到灵活性,通过三个途径来解决:标准化封装、复用、松耦合可编排。
互操作(标准化封装)、复用、松耦合等SOA技术的内在机制,也是中间件技术和产品的本质特征。
标准化封装(互操作性)
传 统软件架构,因为封装的技术和平台依赖性,一直没有彻底解决互操作问题。互联网前所未有的开放性意味着各节点可能采用不同的组件、平台技术,对技术细节进 行了私有化的约束,构件模型和架构没有统一标准,从而导致架构平台自身在组件描述、发布、发现、调用、互操作协议及数据传输等方面呈现出巨大的异构性。各 种不良技术约束的结果是软件系统跨互联网进行交互变得困难重重,最终导致了跨企业/部门的业务集成和重组难以灵活快速的进行。
在软件的互操作方面,传统中间件只是实现了访问互操作,即通过标准化的API实现了同类系统之间的调用互操作,而连接互操作还是依赖于特定的访问协议,如JAVA使用RMI,CORBA使用IIOP等。而SOA通过标准的、支持Internet、与操作系统无关的SOAP协议实现了连接互操作。而且,服务的封装是采用XML协议,具有自解析和自定义的特性,这样,基于SOA的中间件还可以实现语义互操作。
SOA要实现互操作,就是通过一系列的标准族,来实现访问、连接和语义等各种层面的互操作。
个人总结:
SOA在互联网与日俱进的今天得到了广泛应用。
单举特列说,今天的APP应用、各大开放平台提供的服务(接口服务)、各大电商平台提供的接入服务等,具体如安卓/IOS应用,
微信公众,各大云平台服务,云服务器等。
总之,我理解为能够提供专一服务/多服务的网络数据,通过这些单一服务,能够再次组装成一个完整的不同应用。举一个简单
例子:SOA服务商A提供轮胎,B提供车架,C提供其它零件,那么D服务商可以根据自己的需要和爱好组装各种不同的车子。
不知道我的理解准确不,哈哈。组件化开发应用服务,让应用管理更方便,更新更省心,开发更便捷。
下面说说我深刻的理解:
AB:开发短信服务1.0.0版本。
ABC:开发邮件系统1.0.0版本。
ABCD:开发XX商城系统,通过hppt://open.sms.xxx.cn/send调用【AB】的短信服务,轻松完成了手机号验证;又通过http://open.mail.xxx.cn/send
调用了【ABC】的邮件系统完成了用户的密码找回。哈哈,时间和效率比【ABCD】一个人开发划算很多,而且在技术上也大大降低了风险和难度。
情景2:
AB:更新短信服务2.0.0,同时推出了邮件系统1.0.0 。
ABC:更新邮件系统2.0.0,同时推出了云盘存储服务1.0.0 。
ABCD:更新商城,调用【AB】的升级版短信服务,也调用【ABC】的升级版邮件系统,为了节省自身服务器空间,接通了【ABC】的云存储服务。自己同时还
开发了商城的部分新应用。
这样AB有更加专业的短信服务平台,ABC对邮件系统精益求精,ABCD的商城应用在多服务支持下稳定、安全的运行着。不仅时间上节省,费用自然也节省,最大的
好处就是技术上更为成熟、精进。当然,这是最大的好处。那么,坏处也同样存在,就是一旦AB短信服务停止或终止服务,会影响到ABCD的商城正常运作;相比ABC,
就要承担更大的风险,如果ABC一旦终止服务,那么就严重影响了商城运作甚至瘫痪。所以,有利有弊,不过像这样的服务提供商不止一家,可以有个备用,以防万一。
慢慢地,开发久了,觉着程序只是开发的一部分,数据和数据结构才是应用的核心部分。有句话说得好:一个完整的应用是20%的开发加上80%的维护。高级
程序员都是用命令或脚本维护应用的。