Medicator和OSB (Oracle Service Bus)存在的目的，从架构的设计模式上看，和解耦多态等理念非常的相似。 通过Proxy代理的方式，把真正某个Service的实现进行隐藏，让依赖于Service的应用只依赖Service接口，而在接口后面 Routing过去的Service，可以更方便的维护和修改。专业的术语Loosely-Coupling Services.
Service解耦设计原则：
Service的输入参数，越少越好，只输入必要的参数。过多的参数，以及通用的参数只会让Service更加难以维护。比如Credit Rate的Service，比较好的参数就只限定在Individual信息，而其他比如交易的Amount, 货物的Type等就最好不加入到输入参数里面。
Service的输出参数，也是越少越好，不要过多的把不必要的内部数据暴露在外面。
减少Service之间的依赖关系。Service之间可以互相组合成新的Service，但是这个组合尽量不要有业务上的组合。
Service里面的实现不要引用Share Global Data
尽量加入asynchronous message来解耦dependency. Request和Response不需要在同时完成是比较好的方法。
Service一般情况下不应该是有状态的，Client不应该依赖Service的状态而设计Functionality。 有状态的Service一般用在两种情况， 1是查询结果，返回的总数量多于每次获取的数量。2是Client和Service之间要有多次交互。
对于有状态的Service的管理，比较好的实践就是把State Management移除到service外面，用Medicator或者是OSB来实现。 Client-->Facade(Session Mgmnt)-->Native StateMgmnt
Medicator和OSB的应用场景：
Medicator是Service Component的一部分，和OSB不同，OSB是另外一个独立的应用在Service Componet之外。
Medicator：
* 一个Service里面有多个Service Component的时候，采用Medicator进行Routing.
* 校验SCA的Message. Service Component Assemblies.
* SCA内部数据类型，格式转换
* 通过Message Content来判断选择指定的Component
OSB: 相对SCA来说是独立的JVM
缺点是会有多余的响应时间， Client --> OSB --> SCA vs Client -- > SCA
优点是让所有公司内部Service，或者外部的Non-SCA service，都统一Suite，方便使用和管理
由于Client Code不是直接引用到目标Service Code，所以在Runtime很方便进行维护
OSB作为一个Service入口可以调节Request的负载均衡，避免真正的Service突然被海量Request给挤垮
Oracle Service Bus的主要功能：
Message Flow:
invoker的message首先到达的是Proxy Server
然后进入到Input Pipeline, 进行Format, Validation, Logging, Enrich等操作。
之后进入到Routing Step，用来决定由哪个Business Service来执行这个Request
最后，被选中的Business Service调用真正的Service来响应。
Response的信息同样要经过Format, Logging, Enrich等操作才到达Invoker.
Service Endpoint Vitalization：
* 把真正的Service隐藏在Business Service后面 ，配置Business Service的Protocal，让invoker可以采用各种不同的Protocal访问真正Service
* 添加了负载均衡的策略
* 添加Retry的策略，超时策略等
Monitoring:
提供非常强大的功能为所有失败的响应生成Logging, Alert或者是Report.