2011-03-18 4 views
0

Sur le plan architectural, comment pouvez-vous consolider les données provenant de plusieurs services OData/WCF sans sacrifier les performances? J'expose un contexte EF sur le service et souhaite de la flexibilité dans quel (s) objet (s) interroger.Gestion de plusieurs services OData/WCF

Supposons qu'un utilisateur initie une requête nécessitant de contacter x nombre de services OData distincts s'exécutant sur des serveurs distincts répartis dans le monde entier. Au fur et à mesure que x augmente, je pense que le temps nécessaire pour recevoir les résultats augmentera aussi. Est-ce que quelqu'un sait comment améliorer les performances via la mise en cache ou une base de données centrale temporaire, etc.?

Actuellement, je consolide les données dans une base de données SQL en contactant tous les services OData à des intervalles planifiés et en initiant des requêtes sur cette base de données centrale. Je cherche une solution meilleure et plus légère, si possible.

Merci d'avance.

Répondre

1

Est-il possible d'exposer une sorte de service Web de couches spécifique aux types de requêtes exécutées? Je ne sais pas si vous parlez d'une application ici.

Pour réduire les temps de latence, vous pouvez demander des données de ces services disparates de manière asynchrone (vous pouvez donc effectuer plusieurs appels simultanément). Cela aidera à gérer votre inquiétude sur le nombre de services en augmentation. Pour éviter cette complexité de code côté client, utilisez ce nouveau service de superposition.

Si la performance devient un problème, supprimez ce service de couche, mais gardez les appels simultanés aux services côté client.

Si vous ne pouvez pas effectuer les actions simultanément parce qu'il y a une chaîne logique de données entre les services ou quoi que ce soit, j'ai peur qu'il y ait beaucoup pour vous aider à les consolider. vous suggérez - collectez et cachez les données vous-même.

Mise à jour: juste pour clarifier, oui ce serait simplement un autre service qui parle à tous les services séparés pour vous, votre client/application utilisera simplement ce service. Le service lui-même peut encapsuler les appels simultanés et la mise en cache des résultats selon vos besoins. Parce que c'est pour le reporting je serais d'accord avec l'idée de cache pour de gros morceaux de données si l'âge des données ou la possibilité d'être légèrement obsolète n'est pas un problème, ou si les données sont en grande partie statiques par nature.

+0

Par service de couche, vous voulez dire essentiellement un seul service qui agit comme une passerelle vers plusieurs, n'est-ce pas? Ça marcherait. Je peux interroger de manière asynchrone pour de petits lots de données, puis pour des lots plus volumineux, peut-être construire de manière asynchrone un cache pendant le chargement de la page à l'avance, puis interroger ce cache? Il va être un site web asp.net pour l'interrogation/génération de rapports. –