En SOA, nous ne devrions pas construire ou détenir des états (ou concevoir des dépendances) entre client et serveur. Ceci est compris. Mais quels schémas peuvent être suivis dans le cas où un client souhaite consommer un service en temps réel pouvant renvoyer un nombre ouvert de «lignes» à la fin.
Les applications Web, similaires à la SOA mais permettant à l'état (sessions) l'ont résolu avec une pagination. La pagination nécessite (dans la plupart des cas, en particulier avec SQL) que le serveur détient les données et que le client demande les données en morceaux.
Si nous recherchons des scénarios de type pagination pour les services Web, quels schémas ces suivants permettraient toujours de respecter les principes de la SOA (ou aussi près que possible).
Certaines règles pour les penseurs: 1) Sontéré par une base de données SQL (il n'y a donc aucun concept de numéro de ligne dans un ensemble de sélection) 2) Il est important de ne pas sauter une ligne ou dupliquer une ligne dans un ensemble pendant la pagination 3) Les données peuvent être insérées et supprimées à tout moment dans la base de données par d'autres clients. 4) Il n'est pas nécessaire de prendre en compte le jeu de données A Live (mise à jour)
Personnellement, je pense que 1 et 2 ci-dessus épelez déjà notre solution en contraintenant l'espace de la solution avec les exigences.
Ma solution proposée aurait les données (autant que sélectionnées) être stockées dans un magasin / un cache en lecture seule, où il se peut avoir attribué un numéro de ligne dans le jeu de résultats et permettre à la pagination de se produire sur cette instantanée de données. J'aurais une infrastructure pour stocker des instantanés (serveurs, caches externes, memcached ou ehcache - cela doit être assez grand). Le résultat d'une telle requête serait un identifiant d'instantané et des clients pourraient récupérer les données de l'instantané à l'aide d'un API Snapshot (Services Web) et de l'ID d'instantané. Les résultats seraient traités dans une manière en lecture seule pour les enregistrements X à la fois où X était quelque chose de raisonnable.
Les pensées et idées concurrentes, critiques ou apolades seraient grandement appréciées.
5 Réponses :
Les résultats paginées dans un service Web sont en fait assez facile à atteindre.
Tout ce que vous avez à faire est d'ajouter deux paramètres à l'appel du service Web: Taille de la page, numéro de page.
La taille de la page est le nombre de résultats à inclure dans une page. Le numéro de page est le numéro de la page des résultats que vous recherchez.
Votre service Web redevient ensuite à la base de données (ou au cache), redevez les résultats, les chiffres sur les résultats correspondant à la page demandée et ne renvoient que ces résultats.
Le client doit alors faire une seule demande par page de résultats souhaité à partir du service.
Merci - mais ne répond pas aux exigences. Retour à la base de données ne fournit pas de résultats cohérents, des données peuvent être ajoutées, supprimées ou modifiées entre les appels qui rend la cohérence difficile. Vous pouvez ignorer des lignes de cette manière car les données ont été supprimées ci-dessus. Si les critères de tri ne sont pas uniques, vous ne pouvez pas également garantir la séquence. N'oubliez pas que je cherche un motif que je peux appliquer globalement qui résout également ces problèmes. Bien essayé quand même.
Ce que vous proposez avec Memcached fonctionnera également avec une table de mise en cache. Le premier appel de service (1) (1) insérer des résultats dans la table de mise en cache avec un identifiant d'instantané (2) renvoie la première page de la table de cache et de l'identifiant d'instantané. Les appels ultérieurs retourneraient des pages basées sur la taille de la page et le numéro de page en interrogeant la table de mise en cache à l'aide de l'ID d'instantané.
Je dois penser que cela pourrait également être optimisé en utilisant une table de mise en cache en mémoire, mais qui dépend de la question de savoir si votre base de données prend en charge l'insertion dans une table de disque à une table en mémoire. Cela pourrait bien être compliqué dans un environnement en cluster.
Un tel cache est indiqué par sa nature même si vous conservez une copie spécifique au client entre les demandes, si le stockage est dans un objet de session, une table de base de données ou un magasin de données MEMCACHED. Compte tenu des exigences, vous n'avez pas d'autre choix que de mettre en cache des résultats dans une forme ou une autre, sauf que vous risquez de renvoyer des enregistrements supprimés ou non pertinents comme des résultats légitimes.
SOA n'est pas destiné à une fonctionnalité aussi basse.
SOA est destiné à coller ensemble les zones d'affaires, pas de jaillies à la brajoute. Non pas parce que votre application parle à l'arrière-plan à l'aide de Webservices, vous disposez d'une application "SOA". Cela n'a pas de sens puisque la SOA n'a pas de sens dans le contexte de 1 système isolé.
À partir de ce point de vue, il est alors clair que, en SOA, l'appelant n'aurait pas dû savoir sur la table SQL que vous paginez, c'est un détail de mise en œuvre que SOA devrait cacher. D'autre part, le serveur ne devrait pas savoir sur l'état du client, car il devrait être agnostique aux détails des clients, d'être vraiment ouvert.
Alors, comprend juste que la pagination n'est pas SOA. Faites comme vous le souhaitez, il suffit de comprendre que le service Web que vous utilisez pour paginer est un artefact interne de votre application, de ne pas être utilisé pour des clients externes dans un bus SOA. N'oubliez pas non plus que cela ne peut pas être une transaction cohérente avec l'état de sortie du serveur. Le problème est probablement que vous n'avez qu'une seule couche de service pour l'interface utilisateur de l'application et le bus SOA, vous devez les séparer.
Utiliser ce Webservice dans un bus SOA serait mauvais. Je ne peux pas être cohérent car l'utilisateur fait paginé et que d'autres applications se suspendent, elles sont liées à la SQL spécifique.
... alors vous aurez peut-être aussi bien accordé un accès direct SQL à la table pour tout ce qui compte.
SOA est destiné aux messages d'entreprise entre les systèmes, à ne pas coller la frontale d'une application au backend.
J'apprécierais un commentaire dans le vote au bas. Si c'était à cause de mon écriture, je suis vraiment désolé, toujours un commentaire aidera. Si cela était plutôt parce que vous croyez que la pagination est correcte dans la SOA, s'il vous plaît vérifier à nouveau, ce n'est pas le cas. Je suggère: blogs.msdn.com/b/rogerwolterblog /Rarchive/2006/04/20/580353.A SPX
Même problème, résolu à l'aide de l'approche de Navision.
select * from collection where collection.id > $first_record_id ASC limit $limit
Je ne sais pas si la SOA est préoccupante ici. Le problème que vous avez semble être avec la pagination de vos API. Je vais vous signaler comment Twitter gère leur pagination dev.Twitter.com/res/public/timéline
Je vais vous indiquer comment Twitter gère leur pagination. Cela pourrait vous aider à vous dev.Twitter.com/res/public/timelines