Ostatnie dni sierpnia schodzą mi bardzo pracowicie nad projektem, jaki tworzę w C#. Jest to projekt aplikacji opartej na koncepcji distributed systems, czyli za polską Wikipedią system "obliczeń rozproszonych" (choć bardziej sensownie byłoby to chyba nazwą system rozproszony). Aplikację, jak i dok...

Witam, Nazywam się Piotr Sowa i fascynuje mnie programowanie rozproszone. Przedstawiam program HopfieldSimpulator :). Symulator jest niedokończony w ramach trwającego konkursu. Postanowiłem podejść do sprawy tak, że zamieszczam projekt bez interfejsu graficznego. Nagrodą dla osoby, która ulepszy projekt będzie obserwowanie pracy sieci Hopfielda w ujęciu pamięci asocjacyjnej pracującej w czasie rzeczywistym :). Wszystkiego dobrego Piotr Sowa, MCAD

Task-based API w .NET 4.0 (część I) października 1, 2009 22:34 by Marek Kalinowski Pierwszą okazję do zetknięcia się ze zmianami w API dotyczącym wielowątkowości miałem przy okazji udostępnionej prezentacji Daniela Motha z konferencji PDC2008 (http://channel9.msdn.com/pdc2008/TL26/). Podstawowym argumentem mającym mówić za wprowadzeniem (i używaniem) nowego API jest konieczność dostosowania się deweloperów do zmian w architekturze procesorów – czasy "darmowego" przyrostu wydajności bezpowrotnie minęły, o...

Pod tym enigmatycznym nieco tytułem kryje się notka na temat problemu wymuszania różnego rodzaju zachowania po drugiej stronie łącza między dwoma systemami. O co chodzi? Wyobraźmy sobie dwie aplikację. Pierwsza z nich, nazwana przeze mnie umownie Klientem, chce do drugiej aplikacji (nazywanej dalej Serwerem) przekazać zachowanie. Nie dane, ale zachowanie.

W jaki sposób pokonać ograniczenia standardowego protokołu inwentarza usług, nie łamiąc przy tym zgodności ze standardami? Wzorzec Canonical Protocol zaleca wykorzystania jednego, standardowego, protokołu do komunikacji między usługami w ramach jednego inwentarza. Domyślnie oczywiście, protokołem tym są jakiegoś rodzaju usługi webowe (Basic WS, WS-*, REST), jednak nie jest to twarde wymaganie. Niezależnie od wyboru standardowego protokołu, mogą zdarzyć się sytuacje, kiedy jest on z jakichś przyczyn ni...

Konferencja WPC09 trwa w tej chwili w najlepsze, czego namacalnym dowodem jest ogłoszenie m.in. sposobu licencjonowania i cennika Windows Azure. Microsoftowe podejście do usług w chmurach ogłoszone ostatniej jesieni nabiera w związku z tym jak najbardziej konkretnego wymiaru. Jak można się było spodziewać, kwestia płatności w przypadku tak złożonej grupy produktów jest dość skomplikowana i uwzględnia takie czynniki, jak czas przetwarzania, transfer wejściowy i wyjściowy, przestrzeń dyskową, transakcje (w...

W jaki sposób infrastruktura przechowująca stan usług może być skalowana i zabezpieczona przed awarią? Odpowiedzią na to pytania jest wzorzec Service Grid. Jego nazwa może być nieco myląca. Nie ma on bowiem nic wspólnego z gridami oraz raczej niewiele z usługami w klasycznym pojęciu SOA. Service Grid jest nazwą dla podejścia, w którym wiele instancji infrastruktury przechowującej stan usług jest równolegle aktywnych (zwykle na wilu fizycznych maszynach). Instancje te współdzielą między sobą informacje d...

W jaki sposób rozwiązanie oparte o usługi może dostarczyć interaktywny interfejs użytkownika? Rozwiązaniem jest specjalna usługa Mediatora, która jest umieszczana pomiędzy kodem interfejsu użytkownika, a rzeczywistą usługą dostarczającą funkcjonalności biznesowej. Mediator jest odpowiedzialny za dostarczanie użytkownikowi informacji o stanie zainicjowanego przez niego procesu oraz o wszelkich zdarzeniach występujących w trakcie jego działania. Mediator może być zrealizowany na dwa sposoby: jako sp...

W jaki sposób usługa bezstanowa może brać udział w interakcjach wymagających przechowywania stanu? Rozwiązaniem (jednym z wielu możliwych) jest przesyłanie informacji o stanie w wymienianych przez usługę komunikatach. Tradycyjne rozwiązanie problemu polega na przechowywaniu stanu w instancji usługi. Jego słabą stroną jest blokowanie zasobów serwera (głównie pamięci) przez tymczasowo nieaktywne instancji usługi czekające na dalszy ciąg interakcji. Jeśli nie możemy zrezygnować z przechowywania stanu ...

To właściwie dwa wzorce: Capability Composition oraz Capability Recomposition. Pierwszy z nich rozwiązuje problem usługi, która w celu wykonania swojego zadania potrzebueje logiki, która nie mieści się w jej zakresie odpowiedzialności. Aby problem rozwiązać, można poszerzyć zakres odpowiedzialności usługi, jednak prowadzi to do duplikacji logiki. Innym, lepszym i poprawnym, rozwiązaniem jest włączenie wywołania innej usługi jako elementu realizacji logiki tej pierwszej. Właściwie wydaje się to zup...