Managing multiple OData / WCF services

Architecturally speaking how could you co开发者_运维百科nsolidate data coming from multiple OData / WCF services without sacrificing performance? I am exposing an EF context over the service and want flexibility in what object(s) to query.

Say a user initiates a query that requires contacting x number of seperate OData services running on seperate servers distributed across the world. As x increases, I think the time it takes to receive the results will increase, too.

Does anyone know of ways to either improve performance through caching or some temporary central database, etc?

Currently I am consolidating data in one SQL database by contacting all the OData services on scheduled intervals, and initiating queries against this central database. I'm looking for a better and more lightweight solution, if possible.

Thanks in advance.

Is it possible to expose a sort of layering web service specific to the types of queries run? Not sure if you are talking about an application here.

To reduce latency times you could ask for data from these disparate services asynchronously (so you can do multiple calls concurrently). This will help handle your concern over the number of services increasing. To avoid this code complexity at the client side, use this new layering service.

If performance becomes an issue, remove this layering service, but keep the concurrent calls to the services on the client side.

If you cannot perform the actions concurrently because there is a logical chain of data being sent between the services or whatever, then I'm afraid there is much to help you consolidate them - other than changes those services yourself or do as you suggest - collect and cache the data yourself.

Update: just to clarify, yes it would simply be another service that talks to all the separated services for you, your client / application will simply then use this one service. The service itself can encapsulate concurrent calls and result caching as per your requirements. Because it is for reporting I would agree with the caching idea for big chunks of data if the age of the data or the possibility of being slightly out of date is not an issue, or if the data is largely static by nature anyway.