Dlaczego nie ma języka zorientowanego na usługi?

Edytować:

Aby uniknąć dalszych nieporozumień: nie mówię o usługach internetowych i tym podobnych. Mówię o wewnętrznej strukturze aplikacji, nie chodzi o to, jak komputery się komunikują. Chodzi o języki programowania, kompilatory i sposób rozszerzenia paradygmatu programowania imperatywnego.

Oryginalny:

W dziedzinie programowania imperatywnego w ciągu ostatnich 20 lat (lub więcej) widzieliśmy dwa paradygmaty: obiektowy (OO) i zorientowany na usługi (SO) aka. oparty na komponentach (CB).

Oba paradygmaty rozszerzają paradygmat programowania imperatywnego, wprowadzając własne pojęcie modułów. OO nazywa je obiektami (i klasami) i pozwala im łączyć zarówno dane (pola), jak i procedury (metody) razem. SO odróżnia natomiast dane (rekordy, komponenty, ...) od kodu (komponenty, usługi).

Jednak tylko OO ma języki programowania, które natywnie obsługują jego paradygmat: Smalltalk, C ++, Java i wszystkie inne kompatybilne z JVM, C # i wszystkie inne kompatybilne z .NET, Python itp.

SO nie ma takiego języka ojczystego. Występuje tylko w językach proceduralnych lub językach OO: COM / DCOM (binarny, C, C ++), CORBA, EJB, Spring, Guice (wszystkie Java), ...

Te frameworki SO wyraźnie cierpią z powodu braku obsługi ich rodzimych języków.

• Zaczynają używać klas OO do reprezentowania usług i rekordów. Prowadzi to do projektów, w których istnieje wyraźne rozróżnienie między klasami, które mają tylko metody (usługi), a tymi, które mają tylko pola (rekordy). Dziedziczenie między usługami lub rekordami jest następnie symulowane przez dziedziczenie klas. Technicznie rzecz biorąc, nie jest tak ściśle przestrzegany, ale ogólnie programiści powinni tworzyć klasy, aby grały tylko jedną z dwóch ról.
• Używają dodatkowych, zewnętrznych języków do reprezentowania brakujących części: IDL, konfiguracje XML, Adnotacje w kodzie Java, a nawet osadzone DSL jak w Guice. Jest to szczególnie potrzebne, ale nie tylko, ponieważ skład usług nie jest częścią samego kodu usługi. W OO obiekty tworzą inne obiekty, więc nie ma potrzeby takich udogodnień, ale w przypadku SO istnieje to, że usługi nie tworzą ani nie konfigurują innych usług.
• Ustanawiają efekt wewnętrznej platformy na szczycie OO (wczesny EJB, CORBA), w którym programista musi napisać cały kod potrzebny do „sterowania” SO. Klasy stanowią tylko część charakteru usługi, a wiele klas musi być napisanych, aby razem utworzyć usługę. Cała ta płyta kotła jest konieczna, ponieważ nie ma kompilatora SO, który zrobiłby to dla programisty. To jest tak, jak niektórzy ludzie robili to w C dla OO, gdy nie było C ++. Po prostu przekazujesz rekord, który przechowuje dane obiektu jako pierwszy parametr do procedury, która jest metodą. W języku OO parametr ten jest niejawny, a kompilator generuje cały kod, który jest nam potrzebny do funkcji wirtualnych itp. W przypadku SO wyraźnie go brakuje.
• Szczególnie nowsze frameworki intensywnie wykorzystują AOP lub introspekcję, aby dodać brakujące części do języka OO. Nie zapewnia to niezbędnej ekspresji językowej, ale pozwala uniknąć kodu platformy kotła opisanego w poprzednim punkcie.
• Niektóre frameworki używają generowania kodu do generowania kodu płyty kotła. Źródłem informacji są pliki konfiguracyjne w formacie XML lub adnotacje w kodzie OO.

Nie wszystkie zjawiska, o których wspomniałem powyżej, można przypisać SO, ale mam nadzieję, że wyraźnie pokazuje, że istnieje potrzeba języka SO. Skoro ten paradygmat jest tak popularny: dlaczego go nie ma? A może są takie akademickie, ale przynajmniej branża ich nie używa.

Ponieważ <5% kodu faktycznie definiuje usługę, a ja argumentowałbym znacznie mniej czasu. Po zdefiniowaniu interfejsu jest on w dużej mierze wykonany. Resztę czasu spędza się w OO (lub alternatywach), aby wszystko działało .

Mówiąc najprościej, nie jest wielką wygraną stworzenie specjalistycznego języka dla tego małego fragmentu problemu. Jeśli już, posiadanie dwóch języków (jednego dla usługi i jednego dla implementacji / konsumpcji) wymaga jedynie większej złożoności integracji.

[edytuj w celu wyjaśnienia PO, że jest to wewnętrzny układ aplikacji, a nie granica aplikacji]:

Głównym celem takiego układu usługi jest posiadanie cienkich punktów styku między usługami. Mój pierwotny powód nadal utrzymuje (imo) i dodaję do tej odpowiedzi fakt, że stosunkowo niewiele problemów dobrze pasuje do wewnętrznej struktury aplikacji opartej na usługach. Więc nie tylko rozwiązujesz niewielki fragment problemu, ale ogólnie mniejszy odsetek problemów.

Języki funkcjonalne są bardzo zorientowane na usługi. Zamiast tworzyć na nich obiekty i wywoływać funkcje, tworzysz funkcje i przekazujesz do nich wiadomości. Erlang jest doskonałym przykładem tej techniki, ponieważ nawet poza funkcjonalnymi aspektami języka ma wbudowaną komunikację między procesami, a nawet między maszynami, wbudowaną w jej podstawową strukturę, która umożliwia wysyłanie wiadomości do zdalnego procesu, tak jakby był to proces lokalny .

Inne języki, takie jak Scala, Clojure i F #, również zapewniają semantykę „zorientowaną na usługi”. Problemem nie jest to, że ich nie ma, to, że ludność się ich boi, więc nie są tak popularne.

Orientacja na usługi była / jest architektoniczną odpowiedzią na problemy z integracją. Idealna integracja to kompleksowe rozwiązanie, które pasuje do każdego istniejącego języka, produktu, urządzenia, zasobu w celu uzyskania większego obrazu.

Nie ma potrzeby wprowadzania nowego języka, ponieważ sam problem polega na posiadaniu zbyt wielu języków , co powoduje wysokie koszty interoperacyjności.

Wprowadzono jednak jeden rodzaj języka - język definicji usługi internetowej. WSDL to metajęzyk SOA (i istnieje inny opuszczony dla REST o nazwie WADL)

Odwrócę pytanie i zapytam „jak wyglądałby język SO?”

Jak powstałyby te umowy między modułami?
Jak wykona się podstawowa mechanika działania?

Usługi zorientowane na usługi są własnością aplikacji, niekoniecznie używanego języka. Usługa jest konstrukcją, która opiera się na funkcji. Ta funkcja jest konstrukcją opartą na mechanice języka programowania w celu przetłumaczenia operacji na instrukcje wykonywalne przez maszynę.

BPEL jest możliwym przykładem języka SO, ale ma bardzo wysoki poziom i polega na dostępności modułów do jego wykorzystania. Te moduły są z kolei napisane w językach innych niż BPEL, aby można było wykonywać pracę (czyli przetłumaczoną na język maszynowy).

Świetne Q i dało mi dobrą refleksję.

Dam odpowiedź na moje pytanie, aby zobaczyć, ile osób się zgadza i nie zgadza.

Niektóre możliwości:

• Wydaje się, że trudno jest zbudować język SO. Głównie z powodu oddzielenia realizacji usług i ich składu. Jest kilka rozwiązań akademickich, o których słyszałem na uniwersytecie (bez odniesienia, przepraszam), ale nie wydaje się, aby znalazły się w branży. Ale liczę to jako wymówkę, a nie prawdziwy powód. Języki i kompilatory OO są również dość trudne do wdrożenia, ale od dawna istnieją rozwiązania na rynku.

• Programiści używają języków OO do SO, ponieważ nie rozumieją OO i używają go w niewłaściwy sposób. Mówię źle, ponieważ istnieją dwie podstawowe koncepcje w OO, które są sprzeczne z SO:

  1. Funkcjonalność trafia do klasy, w której znajdują się dane, nad którymi pracują. Kod i dane są sprzężone razem w tym samym module. To nie jest styl OO, aby mieć osobne klasy, które działają na danych innych klas. To podejście Züllighofena oparte na narzędziach i materiałach (WAM), które pasuje do paradygmatu SO.

  2. Obiekty tworzą inne obiekty i tworzą sieci obiektów. Mogą tworzyć hierarchie lub dowolne złożone relacje. Usługi zawsze tworzą płaskie sieci złożone z zewnątrz. Usługi mają zwykle tylko jedną instancję (Singleton), podczas gdy obiekty są tworzone instancyjnie tak często, jak istnienie, które reprezentują. Rekordy w SO nie są połączone w sieci.

• Niektóre funkcje OO wyglądają podobnie do SO lub mogą być użyte do ułatwienia tego, co jest potrzebne do SO, więc przydaje się użycie języka OO.

  1. Zasada inwersji zależności w OO jest podobna do sposobu, w jaki usługi składają się na zewnątrz.

  2. Obiekty Singleton są jak usługi, fabryki obiektów są jak lokalizatory usług.

  3. OO ma również interfejsy podobne do interfejsów serwisowych.

  4. Dziedziczenie klas może być podobne (tak samo?) Jak dziedziczenie usług i zapisów.

• OO i SO są przydatne w przypadku różnego rodzaju problemów. Dlatego w każdej aplikacji kuszące jest użycie paradygmatu tu lub tam. Posiadanie osobnego języka utrudniłoby przełączanie się między nimi w ramach tego samego programu.

• SO to nie tylko paradygmat programowania, ale także zachowanie programu: usługi sieciowe, składniki systemu operacyjnego itp. Są SO, ale niekoniecznie muszą być napisane w języku SO. Tego rodzaju „elementy binarne” są bardzo naturalne i odnoszą sukcesy. Ale to coś innego: to sposób, w jaki programy komunikują się ze sobą, a nie sposób, w jaki program komunikuje się wewnętrznie. Myślę, że ludzie często to mieszają.