WCF z Taskami niezależymi od requestow do serwisu.

Szukam sensownego rozwiazania dla takiej logiki w WCF:
Użytkownik w Web aplikacji w .net core tworzy requesta o zawarcie transakcj biznesowej (zakup/sprzedarz po okreslonej cenie) , ten request jest wysyłany do WCF, tam zapisywany w mongo i wrzucany na kolejkę.

Do transakcji dochodzi gdy w kolejce znajdują się conajmiej 2 zlecenia o pasujących cenach ale przecidnych typach (kupie/sprzedam).

WCF ma przyjmować zlecenia i dobierać je w pary i tu mam problem jak to zorganizować.

Mam taki pomysł:

• publiczna metoda serwisu przyjmuje zlecenia i wrzuca to na kolejke/liste
  -w konstruktorze serwisu tworze singletona który w nieskonczonej petli co iles sekund wywoluje metode szukajacej pasujacych zleceń w kolejce.

Podejrzewam ze to niezbyt eleganckie rozwiazanie. Mogli byście mnie na kierowac jak lepiej to rozwiazać?

Dzieki

Empek napisał(a):

Szukam sensownego rozwiazania dla takiej logiki w WCF:
Użytkownik w Web aplikacji w .net core tworzy requesta o zawarcie transakcj biznesowej (zakup/sprzedarz po okreslonej cenie) , ten request jest wysyłany do WCF, tam zapisywany w mongo i wrzucany na kolejkę.

Do transakcji dochodzi gdy w kolejce znajdują się conajmiej 2 zlecenia o pasujących cenach ale przecidnych typach (kupie/sprzedam).

WCF ma przyjmować zlecenia i dobierać je w pary i tu mam problem jak to zorganizować.

Mam taki pomysł:

• publiczna metoda serwisu przyjmuje zlecenia i wrzuca to na kolejke/liste
  -w konstruktorze serwisu tworze singletona który w nieskonczonej petli co iles sekund wywoluje metode szukajacej pasujacych zleceń w kolejce.

Podejrzewam ze to niezbyt eleganckie rozwiazanie. Mogli byście mnie na kierowac jak lepiej to rozwiazać?

Dzieki

Do kawy postudiuj "arkusz zleceń" (per towar/papier) o jakim jest mowa w maklerce.

Może jestem w tej chwili jakoś myślowo ograniczony, ale nie wyobrażam sobie bez statycznych struktur - ty mówisz o czymś czysto dynamicznym.

Cena graniczna, ilość proponowana do transakcji, być może limit czasowy, spotkanie jednej transakcji z czterema z drugiej strony ... to się robi za skomplikowane dla algorytmy "dynamicznego"

PS. Kolejka jak ją powszechnie rozumiemy nie jest strukturą do powtarzalnego przetwarzania tych samych danych (przez nawracającą pętlę). Jeśli czegoś nie wiem, proszę o korektę.
Jest owszem "jakieś" miejsce na kolejkę, wrzutka np sprzedaży na kolejkę (i tu kończy się czysta kolejka) **jednorazowo ** powoduje odpalenie algorytmu, który się wyżywa w **puli ** zleceń przeciwnych (tak, pula, to lepsze słowo niż kolejka!)

PPS. kolejna myśl: dziel i rządź: odetnij się myślowo od WCF, dalsze etapy nie mają nic do tego.

Dzieki @ AnyKtokolwiek.
Dałes mi do myślenia. Chodź samo parowanie zleceń odbywało by się w singelton'ie, to TAK było by to procesowanie dynamicznie przez algorytm. Ale szczerze mówiąc nie mam pomyslu jak to inaczej zrobic. Ale przyjrze sie jak działa ten 'arkusz zleceń' .
Co do kolejki, to myślałem dokładnie o Queue bo bedzie miało znaczenie kolejność przyjęcia zlecenia przez serwis a w miedzyczasie chciałem odpytac API w procesie walidacji a nie chciałem zeby czas odpowiedzi miał wpływ na ta kolejność. Potem chciałem to zlecenie opakowac w inną strukture i przechowywać może na liscie lub słowniku list. Nie przemyślałem tego jeszcze.

PPS. kolejna myśl: dziel i rządź: odetnij się myślowo od WCF, dalsze etapy nie mają nic do tego.

Sugerujesz rozbicie tego na 2 projekty?

Dzieki za rady, rozkminiam dopiero jak to wszystko dziala.

Kolejka to jest coś, co musisz przetwarzać po kolei. Ty nie chcesz tego robić, Ty chcesz mieć dostęp do całej kolekcji zleceń. A nawet wydaje mi się, że do dwóch kolekcji - jednej na zlecenia sprzedaży, a drugiej na zlecenia kupna.

1. Spisz sobie zasady kojarzenia zleceń w pary.
2. Na tej podstawie napisz testy.
3. Napisz algorytm kojarzący zlecenia w pary (na wejściu kolekcje zleceń obu rodzajów).
4. Potem zastanów się jak ten algorytm wywoływać cyklicznie. (Może jakiś Quartz.NET czy inny tego typu scheduler.)