SOA/Web Service Pagination

Question

W SOA nie powinniśmy budować ani wstrzymywać stanu (ani projektować zależności) między klientem a serwerem. Jest to zrozumiałe. Ale jakie wzorce można zastosować w przypadku, gdy klient chce skorzystać z usługi czasu rzeczywistego, która może zwrócić otwartą liczbę "wierszy"?

Aplikacje internetowe, podobnie jak w SOA, ale pozwalające na stan (sesje) rozwiązały to przy pomocy paginacji. Paginacja wymaga (w większości przypadków, szczególnie w przypadku SQL), że serwer przechowuje dane i że klient żąda danych w porcjach.

Jeśli zastanowimy się nad scenariuszem podobnym do paginacji dla usług sieciowych, jakie wzorce podążałyby za nimi, nadal możliwe byłoby przestrzeganie zasad SOA (lub jak najbliżej).

Niektóre zasady myślicieli: 1) poparte bazy danych SQL (w związku z tym nie ma pojęcia z wielu wierszy w wybranej zestawie) 2) Ważne jest, aby nie pominąć wiersz lub powielić wiersz w ustawić podczas paginacji 3) dane można wprowadzać i usuwać w dowolnym momencie do bazy danych przez innych klientów 4) nie istnieje potrzeba rozważenia zestaw danych na żywo (update-stanie) zestaw danych

Osobiście uważam, że 1 i 2 powyżej już przeliterują nasze rozwiązanie, ograniczając przestrzeń rozwiązania z wymaganiami.

Proponowane przeze mnie rozwiązanie zawiera dane (w takim zakresie, w jakim jest zaznaczone) przechowywane w pamięci podręcznej/pamięci podręcznej tylko do odczytu, gdzie można przypisać numer wiersza w zestawie wyników i zezwolić na stronicowanie w tej migawce danych. Posiadałbym infrastrukturę do przechowywania migawek (serwerów, zewnętrznych pamięci podręcznych, memcached lub ehcache - to musi być dość duże). Wynikiem takiego zapytania byłby identyfikator migawki, a klienci mogliby pobrać dane z migawki za pomocą snapshot API (usług internetowych) i identyfikatora migawki. Wyniki będą przetwarzane w trybie tylko do odczytu, do przodu dla rekordów X w czasie, gdy x jest czymś rozsądnym.

Radzenie sobie ze swoimi myślami i pomysłami, krytyka lub pochwała.

Answer 1

Pseudonimy w usłudze sieciowej są w rzeczywistości dość łatwe do osiągnięcia.

Wszystko, co musisz zrobić, to dodać dwa parametry do połączenia serwisowego: Rozmiar strony, Numer strony.

Rozmiar strony to liczba wyników do uwzględnienia na stronie. Numer strony jest numerem strony wyników, której szukasz.

Twoja usługa sieciowa następnie wraca do bazy danych (lub pamięci podręcznej), wyświetla wyniki, określa, które wyniki pasują do żądanej strony, i zwraca tylko te wyniki.

Klient musi następnie wysłać jedno żądanie na stronę wyników, które chce uzyskać z usługi.

Answer 2

To, co proponujesz z memcached, będzie działało również z tabelą buforowania. Pierwsze zgłoszenie serwisowe: (1) WSTAW wyniki do tabeli buforowania z identyfikatorem migawki (2) zwraca pierwszą stronę z tabeli buforowania i identyfikator migawki. Kolejne wywołania będą zwracać strony na podstawie rozmiaru strony i numeru strony, wysyłając zapytanie do tabeli buforowania za pomocą identyfikatora migawki.

Myślę, że można to również zoptymalizować za pomocą tabeli buforowania w pamięci, ale zależy to od tego, czy baza danych obsługuje INSERT-INTO z tabeli dyskowej do tabeli w pamięci. To może się jednak skomplikować w środowisku klastrowym.

Taka pamięć podręczna jest z natury istotna, jeśli zachowuje się specyficzną dla klienta kopię między żądaniami, niezależnie od tego, czy pamięć jest w obiekcie sesji, w tabeli bazy danych, czy w pamięci memcached. Biorąc pod uwagę wymagania, nie masz wyboru, musisz tylko buforować wyniki w takiej czy innej formie, z tą różnicą, że ryzykujesz możliwość usunięcia skasowanych lub już nieistniejących rekordów jako uzasadnionych wyników.

Answer 3

Architektura SOA nie jest przeznaczona do tak niskiego poziomu funkcjonalności.

Architektura SOA przeznaczona jest do łączenia obszarów biznesowych, a nie frontendów z backendami. Nie dlatego, że aplikacja rozmawia z zapleczem za pomocą usług sieciowych, masz aplikację "SOA". To nie ma sensu, ponieważ SOA nie ma znaczenia w kontekście 1 izolowanego systemu.

Z tego punktu widzenia jasne jest, że w SOA osoba dzwoniąca nie powinna wiedzieć o tabeli SQL, którą się stroni, jest to szczegół implementacji, który SOA powinna ukrywać. Z drugiej strony serwer nie powinien wiedzieć o stanie klienta, ponieważ powinien on być agnostyczny względem szczegółów klientów, aby być naprawdę otwartym.

Po prostu zrozum, że paginacja nie jest SOA. Rób tak, jak chcesz, po prostu zrozum, że usługa sieciowa, której używasz do tworzenia stronicowania, jest wewnętrznym artefaktem twojej aplikacji, a nie jest używana do zewnętrznych klientów w magistrali SOA. Pamiętaj również, że nie może to być transakcja zgodna z bieżącym stanem na serwerze. Prawdopodobnie problem polega na tym, że masz tylko jedną warstwę usługi dla interfejsu aplikacji i magistrali SOA, musisz je rozdzielić.

Korzystanie z tego serwisu w autobusie SOA byłoby złe. Nie mogę być konsekwentny, ponieważ strona jest paginowana, a inne aplikacje się z nią wiążą, stają się powiązane z konkretnym SQL.

... równie dobrze możesz przyznać bezpośredni dostęp SQL do tabeli we wszystkich istotnych sprawach.

Architektura SOA służy do przesyłania komunikatów biznesowych między systemami, a nie do nakładania aplikacji na serwer.

Answer 4

Ten sam problem rozwiązany przy użyciu metody Navision.

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

to powrót stronę elementu $ limit, który rozpoczyna się od przekazanym id

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

zamówionej przez ID ASC

Navision użyć klawisza (każdy element ma klucz), ale w MySQL identyfikator autoinkrementacji jest lepszy.

W tym przypadku paginacji jest przeznaczony do obsługi dużych zestawów wyników, a nie na paginacji frontend ...

Answer 5

Nie jestem pewien, czy SOA ma obaw tutaj. Wydaje się, że masz problem z dzieleniem na strony swoich interfejsów API. Wskażę ci, jak twitter obsługuje paginację dev.twitter.com/rest/public/timelines