SOA / пагинация веб-сервисов

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

, упорядоченного по идентификатору ASC

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

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

Answer 4

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

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

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

Answer 5

Постраничных результатов в веб-службе на самом деле довольно легко достичь.

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

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

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

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