Oracle SOA Suit Medicator and OSB

For the purpose of Medicator and OSB (Oracle Service Bus), the concept of decoupling polymorphism is very similar from the architecture design pattern. By proxy agent, the implementation of a real service is hidden, so that the service-dependent application relies only on the service interface, and routing the past service behind the interface, it can be more convenient to maintain and modify. Professional terminology loosely-coupling Services.
Service Decoupling design principles:
Service input parameters, the less the better, only enter the necessary parameters. Too many parameters, as well as common parameters, will only make the service more difficult to maintain. For example, credit rate service, better parameters are limited to individual information, and other such as trading amount, the type of goods, etc. is best not added to the input parameters.
Service output parameters, but also the less the better, do not too much to expose unnecessary internal data outside the surface.
Reduce the dependency between service. Service can be synthesized between services, but this combination tries not to have a combination of business.
The implementation of the service does not refer to share Global Data
Try adding asynchronous message to decouple the dependency. Request and response do not need to be done at the same time is a better approach.
Service generally should not be stateful, the client should not rely on service status and design functionality. Stateful service is generally used in two cases, 1 is the result of the query, and the total number returned is more than the number of each fetch. 2 is to have multiple interactions between the client and service.
For the management of stateful service, the better practice is to remove the state management to the service, using Medicator or OSB. Client-->facade (Session mgmnt)-->native statemgmnt
Application scenarios for Medicator and OSB:
Medicator is part of the service component, and OSB is another independent application outside of the service componet, unlike OSB.
Medicator:
* When there are multiple service component in a service, use Medicator for routing.
* Verify the message of SCA. Service Component Assemblies.
* SCA Internal data type, format conversion
* Use message content to determine the selected component
OSB: A standalone JVM relative to SCA
The disadvantage is that there will be extra response time, Client-to-OSB--and SCA vs Client--> SCA
The advantage is to have all internal service, or external Non-sca service, unified suite, easy to use and manage
Because client code is not directly referenced to the target service code, it is easy to maintain at runtime
As a service portal, OSB can adjust the load balance of request to avoid the sudden collapse of a real service by a massive request.
Key features of Oracle Service bus:
Message Flow:
The invoker message first arrives at the proxy Server
Then enter into input Pipeline, do the format, Validation, Logging, enrich and other operations.
Then enter routing Step to decide which business service to execute the request
Finally, the selected business service calls the real service to respond.
Response information must also go through format, Logging, enrich and other operations before reaching Invoker.
Service Endpoint vitalization:
* Hide Real service behind business service, configure business service protocal, allow Invoker to access real service with a variety of protocal
* Added a load balancing policy
* Add retry policy, timeout policy, etc.
Monitoring:
Provides very powerful functionality to generate logging, alert, or report for all failed responses.

Oracle SOA Suit medicator and OSB