SOA: Dlaczego nie używać serwerów internetowych Erlang/OTP jako usług?

Question

Po przeczytaniu strony Service Oriented Architecture Principles i odpowiedniej Wikipedii article pomyślałem: platformę Erlang/OTP można uznać za platformę SOA i można na niej budować aplikacje SOA.

Jedyną rzeczą jest to, że Service Contract dla każdej usługi w takim systemie jest bardzo specyficzny: aby wywołać usługę w Erlang/OTP, warstwa Orchestrating będzie musiała wykonywać połączenia za pośrednictwem komunikatów Erlang lub wywołań do serwera gen_server (zależy od implementacja).

To nie pozwala na wykonywanie żadnych połączeń z usługami poza zasięgiem platformy Erlang/OTP.

Co jednak zrobić, jeśli spróbujemy zbudować każdą usługę, przenosząc wszystkie funkcje usługi do serwera sieciowego Erlang, takiego jak Mochiweb i zasadniczo zmieniając interfejs każdej usługi z serwera_głównego: wywołanie XML?

Umożliwi to komponowanie różnych aplikacji ze standardowych "klocków" z uniwersalnymi umowami serwisowymi opartymi na WSDL.

Co więcej, takie podejście pozwoli nam nadal korzystać z usług nadzorców OTP i innych funkcji OTP, ponieważ taka Usługa nadal będzie aplikacją OTP.

Pytanie brzmi: Czy uważasz, że budowanie aplikacji o architekturze opartej na architekturze usługowej przy użyciu serwerów internetowych OTP (Mochiweb) jako usług to dobry pomysł? Czy dodatkowa warstwa przetwarzania XML może zniszczyć wszystkie zalety takiego podejścia?

Answer 1

Głównym powodem tego nie robi to dlatego, że można ograniczyć się do protokołu SOA. Erlang implementuje protokół IP z kilkoma dodanymi punktami (monitorami). Chociaż możesz to zrobić, zastanawiam się, czy byłoby warto.

W zasadzie Erlang ma już wszystko oprzyrządowania dla idei SOA ale bez wszystkich nadąć z SOAP i WSDL :)

Answer 2

SOA może być stosowany do wielu technologii wykonania, a nie tylko SOAPy Web Services i odkryłem, że zawsze było to korzystne. Na przykład można modelować widoki bazy danych i procedury składowane jako usługi. Możesz modelować interfejsy API Java, które są usługami. itp

Teraz dotarcie do rzeczywistych pytań:

Więc pytanie brzmi: Czy uważasz, że budowanie aplikację z usługą Oriented Architecture podejścia za pomocą OTP serwerów internetowych (Mochiweb) jako Usługi to dobry pomysł?

Nie. Wszyscy odchodzą od SOAP w kierunku REST; jednak budowanie aplikacji o architekturze zorientowanej na usługi przy użyciu serwerów internetowych OTP (Mochiweb) jako usług RESTful może być dobrym pomysłem.

Czy dodatkowa warstwa przetwarzania XML może zniszczyć wszystkie zalety takiego podejścia?

Zależy od tego, jaki jest Twój cel. Jeśli właśnie dodajesz warstwę XML, ponieważ uważasz, że jest to "Właściwa rzecz do zrobienia ™", zawsze będziesz mieć problemy z warstwą XML, ponieważ będzie to rozwiązanie szukające problemu do rozwiązania. Jeśli Twoim celem jest odłączyć technologii wdrażania serwera od implementacji klienta, poprzez tworzenie powszechnie rozumianych reprezentacji dla twoich jednostek, to warta jest dodatkowa warstwa przetwarzania XML (lub JSON lub cokolwiek jest najbardziej odpowiednia).

Answer 3

To jest nasza główna aplikacja z Erlang: serwisy internetowe. Zwykle używamy Yaws Appmods, a article here może Ci wiele pokazać, jak to się robi. Erlang jest dobrą platformą dla architektury SOA, ponieważ:

1. Kod zwolniony z efektu Side Effect jest bardzo łatwy w pisaniu i testowaniu.
2. Izolacja: Procesy w Erlang pomagają odizolować każde zgłoszenie serwisowe w czysty sposób.
3. Większość bibliotek Erlang takich jak mochiweb, misultin i Chicago Boss zostało zbudowanych od podstaw w celu obsługi systemów SOA napisanych w Erlang.

To świetny pomysł, aby zastosować własną aplikację OTP za którąkolwiek z tych platform. Innym ważnym powodem, dla którego erlang nadaje się do SOA, jest redundancja. Systemy SOA muszą być zainstalowane. Jeśli zgłoszenie serwisowe nie powiedzie się, zostanie ono ponownie przetestowane na innej ścieżce (która, rzecz jasna, na warstwie fizycznej, będzie obsługiwana przez inną maszynę, na której została rozpowszechniona aplikacja OTP).

Daj szansę, świetny pomysł: