How to use adjust the service connectivity logic of the stock quote scenario, to make the solution more flexible.
A mediation flow encapsulates service connectivity logic, that is invoked when a message is received by the ESB. A mediation flow helps you to reuse existing services and applications.
Initially, the financial services company that provides the stock quotes has a business requirement for two levels of service: premium and standard. In addition, the business has only two Web services that can provide the relevant business services. Therefore, version 1.0 of the stock quote mediation flow assumes that there will be only two service endpoints, and that the endpoint addresses are known when the mediation flow is created. The flow is dynamic in the sense that the precise service endpoint is selected at runtime, based upon the customer subscription level. However, the flow could be made more dynamic, and more flexible, by removing the service addresses from the mediation flow and storing them elsewhere.
As the financial services company grows it finds that it has a requirement for greater flexibility, and wants to make use of new Web services as they become available, without deploying modules to the runtime. By storing service endpoint addresses in a database, the administrator can manage the use of Web services by making changes to one database, rather than having to redeploy a changed EAR file, perhaps to multiple machines.
Over a period of time the financial services company finds it has a business requirement to use services from other companies, so that it can cater for particular geographical or linguistic areas. The financial services company, therefore, decides to store all the service endpoint addresses it uses in a registry. The mediation flow can then extract the service that is most suitable for the customer. This requires adding service endpoint details to a registry, and setting up a query of the registry from the mediation flow, (using the Endpoint Lookup mediation primitive).