SOA/Web Service Pagination

Question

В SOA мы не должны создавать или удерживать состояние (или конструировать зависимости) между клиентом и сервером. Это понятно. Но какие шаблоны могут соблюдаться в случае, когда клиент хочет использовать службу в режиме реального времени, которая может возвращать число строк с открытым концом?

Веб-приложения, аналогичные SOA, но разрешающие состояние (сеансы), решили это с разбивкой по страницам. Для разбиения на страницы требуется (в большинстве случаев, особенно с SQL), что сервер хранит данные и что клиент запрашивает данные в кусках.

Если мы рассмотрим сценарии, похожие на страницы, для веб-сервисов, какие шаблоны будут следовать этим, это все равно позволит придерживаться принципов SOA (или как можно ближе).

Некоторые правила для мыслителей: 1) Снятые с помощью базы данных SQL (поэтому нет понятия числа строк в выбранном наборе) 2) Важно, чтобы не пропустить строку или дублировать строку в установить во пагинации 3) Данные могут быть вставлены и удалено в любое время в базу данных других клиентами 4) Там нет необходимости рассматривать набор данных живых (обновление-состояние) набор данных

Лично я считаю, что 1 и 2 выше уже засекретили наше решение, сдерживая пространство решения с требованиями.

Мое предлагаемое решение будет иметь данные (насколько это выбрано), которые будут храниться в хранилище/кеш-память, доступном только для чтения, где ему может быть назначен номер строки в результирующем наборе и разрешить разбиение на страницы в этом снимке данных. У меня была бы инфраструктура для хранения снимков (серверов, внешних кэшей, memcached или ehcache - это должно масштабироваться довольно велико). Результатом такого запроса будет идентификатор моментального снимка, и клиенты могут извлекать данные из моментального снимка с помощью API-интерфейса моментальных снимков (веб-служб) и идентификатора моментального снимка. Результаты будут обрабатываться только в режиме «только для чтения», только для х записей в то время, когда x было чем-то разумным.

Конкурирующие мысли и идеи, критические замечания или похвалы были бы весьма признательны.

Answer 1

Paginated results в веб-сервисе на самом деле довольно легко достичь.

Все, что вам нужно сделать, это добавить два параметра к вызову веб-службы: размер страницы, номер страницы.

Размер страницы - количество результатов для включения в страницу. Номер страницы - это номер страницы, которую вы ищете.

Затем ваш веб-сервис возвращается в базу данных (или кеш), возвращает результаты, определяет, какие результаты соответствуют заданной странице, и возвращают только те результаты.

Затем клиент должен сделать один запрос на страницу результатов, которые они хотят получить от службы.

Answer 2

Что вы предлагаете с memcached, также будет работать с таблицей кеширования. Первый вызов службы (1) INSERT приведет к тому, что в таблицу кэширования с идентификатором моментальной копии (2) верните первую страницу из таблицы кеширования и идентификатора моментального снимка. Последующие вызовы будут возвращать страницы на основе размера страницы и номера страницы, запрашивая таблицу кеширования с помощью идентификатора моментального снимка.

Я думаю, что это также можно оптимизировать, используя таблицу кэширования в памяти, но это зависит от того, поддерживает ли ваша база данных INSERT-INTO из таблицы дисков в таблицу в памяти. Однако это может усложниться в кластерной среде.

Такой кэш по своей природе является состоятельным, если вы сохраняете клиентскую копию между запросами, будь то хранение в объекте сеанса, таблице базы данных или хранилище данных memcached. Однако, учитывая требования, у вас нет выбора, кроме как кэшировать результаты в той или иной форме, за исключением того, что вы рискуете получить возможность вернуть удаленные или не имеющие большого значения записи в качестве законных результатов.

Answer 3

SOA не предназначен для таких низкоуровневых функций.

SOA предназначен для склеивания бизнес-областей, а не интерфейсов к бэкэндам. Не потому, что ваше приложение обращается к заднему концу с помощью веб-служб, у вас есть приложение «SOA». Это не имеет смысла, поскольку SOA не имеет смысла в контексте одной изолированной системы.

С этой точки зрения, тогда ясно, что в SOA вызывающий абонент не должен был знать о таблицах SQL, которые вы разбиваете на страницы, это деталь реализации, которую должна скрывать SOA. С другой стороны, сервер не должен знать о состоянии клиента, поскольку он должен быть агностическим для деталей клиентов, чтобы быть действительно открытым.

Итак, просто поймите, что разбиение на страницы не является SOA. Сделайте все, что хотите, просто поймите, что веб-сервис, который вы используете для разбивки на страницы, является внутренним артефактом вашего приложения, а не для внешних клиентов в SOA-шине. Также помните, что это не может быть транзакцией, согласующейся с состоянием на сервере. Вероятно, проблема заключается в том, что у вас есть только один уровень обслуживания для пользовательского интерфейса приложения и шины SOA, вам нужно их разделить.

Использование этого веб-сервиса в SOA-шине было бы плохо. Я не могу быть последовательным, так как пользователь разбивается на страницы, и по мере того как другие приложения зависают, они становятся привязанными к конкретному SQL.

... тогда вы могли бы предоставить прямой SQL-доступ к таблице для всего, что имеет значение.

SOA предназначен для деловых сообщений между системами, а не для приклеивания интерфейса приложения к серверу.

Answer 4

Такая же проблема решена с использованием подхода Navision.

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

Это возвращает страницу $ предельного элемента, которые начинаются от переданного идентификатора

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

заказанного ид ASC

Navision использовать ключ (каждый элемент имеет ключ), но в MySQL идентификатор автоинкремента лучше.

В этом случае пагинации предназначен для обработки больших наборов результатов, а не для внешнего интерфейса пагинации ...

Answer 5

Я не уверен, что SOA представляет интерес здесь. Проблема, с которой вы сталкиваетесь, связана с разбиением на страницы ваших API. Я укажу вам, как твиттер обрабатывает их разбиение на страницы. Dev.twitter.com/rest/public/timelines