SOA/Web Service Pagination

Question

En SOA no deberíamos crear o mantener el estado (o el diseño de dependencias) entre el cliente y el servidor. Esto es entendido Pero, ¿qué patrones se pueden seguir en el caso de que un cliente quiera consumir un servicio en tiempo real que pueda devolver un número abierto de 'filas'?

Las aplicaciones web, similares a SOA pero que permiten estados (sesiones), han resuelto esto con la paginación. La paginación requiere (en la mayoría de los casos, especialmente con SQL) que el servidor contenga los datos y que el cliente solicite los datos en fragmentos.

Si consideráramos escenarios de paginación para servicios web, ¿qué patrones seguirían que permitieran adherirse a los principios de SOA (o lo más cerca posible)?

Algunas reglas para los pensadores: 1) Con el respaldo de una base de datos SQL (por lo tanto, no existe el concepto de un número de fila en un conjunto de selección) 2) Es importante no saltarse una fila o duplicar una fila en una establecido durante la paginación 3) los datos pueden ser insertados y eliminados en cualquier momento en la base de datos de otros clientes 4) no hay necesidad de considerar el conjunto de datos de un vivo() conjunto de datos update-poder

en lo personal, creo que 1 y 2 arriba ya deletrean nuestra solución al restringir el espacio de la solución con los requisitos.

Mi solución propuesta tendría los datos (tanto como se seleccionen) almacenados en un almacén/caché de solo lectura donde se le puede asignar un número de fila dentro del conjunto de resultados y permitir que la paginación ocurra en esta instantánea de datos. Tendría una infraestructura para almacenar instantáneas (servidores, cachés externos, memcached o ehcache, esto debe escalar bastante). El resultado de dicha consulta sería una ID de instantánea y los clientes podrían recuperar los datos de la instantánea utilizando una API de instantánea (servicios web) y la identificación de la instantánea. Los resultados se procesarían de manera solo de lectura, solo para reenvío para x registros en un momento donde x era algo razonable.

Pensamientos e ideas en conflicto, críticas o elogios serían muy apreciados.

Answer 1

Los resultados paginados en un servicio web son en realidad bastante fáciles de lograr.

Todo lo que tiene que hacer es agregar dos parámetros a la llamada al servicio web: Tamaño de página, Número de página.

El tamaño de página es el número de resultados para incluir en una página. Número de página es el número de página de resultados que está buscando.

Su servicio web vuelve a la base de datos (o caché), recupera los resultados, determina qué resultados se ajustan a la página solicitada y devuelve solo esos resultados.

El cliente tiene que hacer una sola solicitud por página de resultados que desea del servicio.

Answer 2

Lo que proponga con memcached también funcionará con una tabla de almacenamiento en caché. La primera llamada de servicio sería (1) INSERTAR resultados EN LA tabla de almacenamiento en caché con una ID de instantánea (2) devolver la primera página de la tabla de almacenamiento en caché y la ID de la instantánea. Las llamadas posteriores devolverían páginas según el tamaño de página y el número de página al consultar la tabla de almacenamiento en caché utilizando la identificación de la instantánea.

Creo que esto también podría optimizarse utilizando una tabla de almacenamiento en memoria caché en la memoria, pero eso depende de si su base de datos es compatible con INSERT-INTO desde una tabla de discos a una tabla en memoria. Sin embargo, eso podría complicarse en un entorno agrupado.

Dicha memoria caché es explícita por naturaleza si está reteniendo una copia específica del cliente entre las solicitudes, ya sea que el almacenamiento esté en un objeto de sesión, una tabla de base de datos o un almacén de datos memcached. Sin embargo, dados los requisitos, no tiene más remedio que guardar en caché los resultados de una forma u otra, excepto que corre el riesgo de que los registros eliminados o que ya no son relevantes como resultados legítimos.

Answer 3

SOA no está diseñado para tal funcionalidad de bajo nivel.

SOA está destinado a unir áreas de negocio, no interfaces a back-end. No porque su aplicación se dirija a la parte de atrás usando servicios web, usted tiene una aplicación "SOA". Esto no tiene sentido ya que SOA no tiene sentido en el contexto de 1 sistema aislado.

Desde ese punto de vista, está claro que, en SOA, la persona que llama no debería haber sabido acerca de la tabla SQL que está paginando, eso es un detalle de implementación que SOA debería ocultar. Por otro lado, el servidor no debe saber sobre el estado del cliente, porque debe ser independiente de los detalles de los clientes, para ser realmente abierto.

Entonces, entienda que la paginación no es SOA. Haga lo que desee, simplemente entienda que el servicio web que está utilizando para paginar es un artefacto interno de su aplicación, que no debe usarse para clientes externos en un bus SOA. También recuerde que no puede ser una transacción consistente con el estado fuera del servidor. Probablemente el problema es que solo tiene una capa de servicio para la interfaz de usuario de la aplicación y el bus SOA, debe separarlos.

Usar este servicio web en un bus SOA sería malo. No puedo ser coherente a medida que el usuario pagina y, a medida que otras aplicaciones dependen de él, se vincula al SQL específico.

... entonces también podría haber otorgado acceso SQL directo a la tabla por todo lo que importa.

SOA es para mensajes de negocios entre sistemas, no para pegar el frontend de una aplicación al back-end.

Answer 4

Mismo problema, resuelto usando el enfoque de Navision.

$ws->getList($first_record_id, $limit) 

Este devolver una página de elemento de $ límite que se inician desde el el id pasado

select * from collection where collection.id > $first_record_id ASC limit $limit 

clasificadas por ASC Identificación

Navision utilizar la tecla (cada elemento tiene una llave), pero en MySQL una identificación autoincrement es mejor.

En este caso la paginación está destinado para manejar grandes conjuntos de resultados y no por una interfaz de paginación ...

Answer 5

No estoy seguro de si SOA es de interés aquí. El problema que tienes parece ser al paginar tus API. Le indicaré cómo Twitter maneja su paginación dev.twitter.com/rest/public/timelines