Temat: SOA - EDA - CEP ???

moze temat troche przysechł ale jako wieloletni fan biztalka ... to nie moge postawic rownania soa = biztalk czy soa = webservice...

bo to tylko technologie ktore mozna wykorzystac w podejsciu SOA...
i tak nie zaleznie od tego jaka technologie wykorzystamy czy to MS BTS czy IBM WS czy BEA jeżeli nie zrobimy tego z głową (podejsciem do problemu) to mimo że dane technologie ładnie wspierają SOA to co otrzymamy moze wcale nie byc SOA.

Temat: SOA - EDA - CEP ???

Dopiero teraz odkopałem ową dyskusję, a szkoda... jest bardzo ciekawa :)

Dla mnie jednak istotną rzeczą w architekturze zorientowanej na usługi jest redundancja (że tak to ujmę). Jeśli Ty nie chcesz dla mnie czegoś zrobić, to poszukam kogoś innego. WS-I kładzie duży nacisk na serwisy odkrywkowe, wiążą się one również z pewnymi technologiami. Wydaje mi się że dla biznesu byłoby lepszą sprawą utożsamianie SOA z XML Web Services i konkretnymi standardami (nie mówię o technologiach - technologię każdy wybiera sam), wtedy informatyzacja na serio mogłaby iść do przodu. Każda aplikacja posiadałaby zdolność do działania usługowego, która była ustandaryzowana i wszystkim żyłoby się lepiej.

Co do traktowania i nie traktowania jako usługę - dla mnie ważna jest zdolność do opisania siebie w celu wymienienia informacji z serwisem odkrywkowym. Jeśli baza danych to potrafi, to OK, zgadzam się, możemy ją traktować jako usługę, jeśli nie - wydaje mi się że nie jest to zgodne z filozofią SOA.

Temat: SOA - EDA - CEP ???

Wojciech Obst:
Dla mnie jednak istotną rzeczą w architekturze zorientowanej na usługi jest redundancja (że tak to ujmę). Jeśli Ty nie chcesz dla mnie czegoś zrobić, to poszukam kogoś innego. WS-I kładzie duży nacisk na serwisy odkrywkowe, wiążą się one również z pewnymi technologiami.

Hm... pewnie tak, jednak czym innym jest system składający się z dziesiątek i setek usług, nawet redundantnych a co innego to klasyczna nasza krajowa sytuacja w rodzaju kilka lub kilkanaście dedykowanych aplikacji gdzie o redundancji nie ma mowy z przyczyn ekonomicznych.

Wydaje mi się że dla biznesu byłoby lepszą sprawą utożsamianie SOA z XML Web Services i konkretnymi standardami (nie mówię o technologiach - technologię każdy wybiera sam), wtedy informatyzacja na serio mogłaby iść do przodu. Każda aplikacja posiadałaby zdolność do działania usługowego, która była ustandaryzowana i wszystkim żyłoby się lepiej.

Poza WS mamy COM+, SOAP, ... znam sytuacje w których doskonałym narzędziem (opisywanym także na InfoQ) jest serwer pocztowy SMTP/POP3 za pośrednictwem którego wymieniane są asynchronicznie komunikaty pomiędzy aplikacjami, doskonały sposób na komunikację gdzie nie ma zbytnich rygorów czasowych.

Co do traktowania i nie traktowania jako usługę - dla mnie ważna jest zdolność do opisania siebie w celu wymienienia informacji z serwisem odkrywkowym. Jeśli baza danych to potrafi, to OK, zgadzam się, możemy ją traktować jako usługę, jeśli nie - wydaje mi się że nie jest to zgodne z filozofią SOA.

Samoopisywanie się to chyba cecha interfejsu a nie usługi jako takiej. Ważniejsze jest moim zdaniem właściwe "dobieranie" usług projektując statyczny system.

Co do usług i ich "odkrywania" to mam sprawdzoną metodę: tworze model dziedziny i wyszukuje gęsto powiązane skupiska klas. Po analizie możliwe jest wyodrębnienie quasiniezależnych obszarów cechujących się jedną kompetencją w modelu dziedziny. Każdy taki obszar następnie traktuje jak "kandydata na niezależny komponent" zgodnie z zasadą ról i odpowiedzialności. Np. z reguły system FK odpowiada za zarządzanie danymi kontrahentów itp...

W efekcie powstaje architektura, gdzie fasada jest jakiś system BPM (worflow, documentflow itp.) lub Intranet zaś pozostałe systemy dedykowane są podłączone do tej fasady. Powstaje coś w rodzaju takiego rozproszonego MVC gdzie mamy jeden Widok oraz pary dziedzinowe Model-Controler. Każda taka Para to usułga we wzorcu SOA.