SOA、远程通信 相关概念
1 远程调用方式的系统间通信
远程调用方式就是尽可能地使系统间的通信和系统内一样，让使用者感觉到调用远程和调用本地一样，但其实并没有办法做到完全透明，例如远程调用带来的网络问题，超时问题，序列化反序列化、调试等问题。
远程调用方式总的来说是一个Client/Server的结构，Consumer （Client）<--> Producer（Server）。远程调用方式，即广义上的RPC。
1.1 RMI
RMI（Remote Method Invocation，远程方法调用）是Java的一组拥护开发分布式应用程序的API，是用Java在JDK1.1中实现的，它大大增强了Java开发分布式应用的能力。Java作为一种风靡一时的网络开发语言，其巨大的威力就体现在它强大的开发分布式网络应用的能力上，而RMI就是开发百分之百纯Java的网络分布式应用系统的核心解决方案之一。其实它可以被看作是RPC的Java版本。
RMI是传递可序列化的java对象，只能用在java虚拟机上，绑定语言，客户端和服务端都必须是java。原理：
除了Java自带的RMI实现，Spring http Invoker是对Java RMI的另一种实现，但是Spring http Invoker传输基于http协议。
1.2 狭义RPC
RPC（Remote Procedure Call Protocol）——远程过程调用协议。
RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息的到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。
根据实现方式的不同，有多种 RPC模式和执行。基本原理如图：
RPC可以是跨平台跨语言的，例如，用JAVA写的客户端，应该能够调用用C语言提供的过程。不能跨语言的RMI和Spring http Invoker可以看作是一种特殊的RPC。
1.3 Web Service
WebService是一种跨语言的系统间的交互标准。在这个标准中，对外提供功能的一方以http的方式提供服务，该服务采用WSDL（Web Service Description Language）描述，在这个文件中描述服务所使用的协议、所期望的参数、返回的参数格式等。调用端和服务端通过SOAP（Simple Object Access Protocol）方式进行交互。
JWS（Java Web Service）是指与webservice相关的Java EE技术。目前JWS的规范主要有：
JAX-WS : Java API for XML-Based Web Services
JAX-RS : Java API for RESTful Web Services
在 JAX-WS中，一个远程调用可以转换为一个基于XML的协议，例如SOAP，在使用JAX-WS过程中，开发者不需要编写任何生成和处理SOAP消息的代码。JAX-WS的运行时实现会将这些API的调用转换成为对应的SOAP消息。基本原理：
JAX-RS是JAVA EE6 引入的一个新技术。 JAX-RS即Java API for RESTful Web Services，是一个Java 编程语言的应用程序接口，支持按照表述性状态转移（REST）架构风格创建Web服务。JAX-RS使用了Java SE5引入的Java标注来简化Web服务的客户端和服务端的开发和部署。AX-RS提供了一些标注将一个资源类，一个POJO Java类，封装为Web资源。
支持JAX-WS服务规范的框架有：CXF，Axis，Xfile等；支持JAX-RS服务规范的框架有：Jersey、RESTEasy、Restlet等。
2 消息中间件（MOM）方式的系统间通信
消息队列（MQ）是一种应用程序对应用程序的通信方法。应用程序通过写和检索出入列队的针对应用程序的数据（消息）来通信，而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。能够帮助搭建企业服务总线(ESB)的基础传输层。
JMS即Java消息服务（Java Message Service）应用程序接口是一个Java平台中关于面向消息中间件的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。JMS是Java平台上有关面向消息中间件的技术规范。多数情况下jms是三方系统交互（Consumer <- Broker -> Producer）
原理图：
3 SOA
3.1 为什么需要SOA
当应用获得用户的认可后，会不断发展。以豆瓣为例，早期豆瓣网只有书评功能，随着对豆瓣的认可，发展出豆瓣社区，豆瓣音乐等功能，这些功能各有特色，但是又有很多公共的业务逻辑系统；随着用户越来越多，系统访问量和数据量上涨，服务器需要采用分工的方式服务用户。
第一个现象是系统多元化带来的问题，可采用对共用逻辑的部分进行抽象的方法，形成多个按领域划分的共用业务逻辑系统；第二个现象是系统访问量和数据量上涨带来的问题，采用拆分系统的方式来解决。
在构建了共用业务逻辑系统和拆分业务系统后，最明显的问题就是系统之间如何交互。如果不控制，会出现多个系统之间存在多种交互方式：Hessian、RMI、WebService等；同步、异步都会出现。这将导致开发人员学习和工作带来挑战。
3.2 SOA是什么
对于上面的问题，很容易想到解决方法是：统一交互的方式。实现该目标的一个思想是：SOA。
SOA全称是面向服务架构，它强调系统之间以标准的服务方式进行交互，各系统可以采用不同的语言、不同的框架来实现，交互则全部通过服务的方式进行。
3.3 SOA平台需要面对的挑战
服务多级调用带来的延迟
当一项功能调用服务A，服务A又调用服务B，服务B又调用服务C，就会带来大幅度的延迟。
调试/跟踪困难
例如，当调用服务A，服务A报错时，调用者通常会找服务A的开发人员来解决。服务A的开发人员查问题，有可能认为是服务B报错，服务B的开发人员又去查，有认为是网络的问题等等。
更高的安全/监测要求
在未拆分之前，对系统的安全和监测只要在一个系统上做即可。在拆分后，必须要求每个系统上都有相应的安全控制和监测。
QoS的支持
每个服务提供者能支撑的访问量是有限的，因此应尽可能采取一系列的措施来保障QoS，例如：流量控制、机器资源分配等。
高可用和高度可伸缩
依赖管理
由于服务众多，服务之间的依赖关系也要管理起来。
现有应用移植
移植的功能越多，花费的时间越多。
综上所述，一个SOA应用，至少要包含以下几个功能点：
统一的服务交互方式
提供调试/跟踪的支持
依赖管理
高性能及高可用。
在实现SOA时，可参考的标准或概念有SCA、ESB等，同事业界也有一些实现了SCA和ESB的框架。国内的Dubbo，也是一种SOA实现方案。
ESB原理图：
