W przypadku projektu obliczeń rozproszonych rozpoczynającego się dzisiaj, w którym nie ma starszych komponentów, czy są jakieś dobre powody, aby zajrzeć do CORBA?
Szczerze mówiąc, nie jestem pewien, czy kiedykolwiek miały jakieś dobre powody - to okropna technologia. Mówię tutaj jako były programista CORBA.
2
Powodem było to, że kiedy CORBA pojawiła się po raz pierwszy, nie było realnej alternatywy (chyba że można było DCOM lub DCE).
skaffman
@skaffman Były alternatywy - na przykład TIBCO.
Jasne, ale to było równie brzydkie, nie wspominając o drogich.
skaffman
3
@Skaffman Żartujesz! TIBCO Rendezvous był / jest co najmniej 10 razy łatwiejszy w użyciu niż CORBA. Jeśli chodzi o koszty, to wydaje mi się, że mogą sobie na to pozwolić IB, którzy używają tych rzeczy. A przynajmniej mogli wtedy.
Odpowiedzi:
46
Nadal istnieją sytuacje, w których CORBA może być dobrą odpowiedzią:
gdy budujesz system rozproszony obejmujący wiele języków programowania i wiele platform,
gdy Twój system wymaga przesyłania złożonych struktur danych ... a SOAP tego nie wycina,
kiedy masz wysokie współczynniki przesyłania wiadomości ... a HTTP tego nie ogranicza lub
kiedy musisz współdziałać z istniejącymi klientami i / lub usługami CORBA.
Ale mówiąc to, istnieją alternatywy, które robią to, co robi CORBA, tylko lepiej ... a przynajmniej tak twierdzą. Na przykład ICE firmy ZeroC
EDYTUJ @fnieto dzwoni, aby powiedzieć (lub zasugerować), że ICE nie jest darmowy, ale TAO jest.
Jest to niedokładne i mylące .
ICE jest oprogramowaniem na licencji GPL i jest dostępne do bezpłatnego pobrania. Musisz zapłacić za ICE tylko wtedy, gdy Ty / Twoja firma nie jesteście przygotowani do przestrzegania warunków GPL. (Lub jeśli potrzebujesz wsparcia.)
Jako przykład alternatywy dla CORBA użyłem ICE . TAO to CORBA. Autorzy ICE przedstawiają wiarygodne argumenty, dlaczego mogą uzyskać lepszą wydajność, nie będąc zgodnymi z CORBA.
TAO nie jest bynajmniej jedyną darmową / otwartą implementacją CORBA. Przychodzą mi na myśl 3 inne.
Wadą ICE jest brak współdziałania ze stosami oprogramowania pośredniego CORBA, ale z mojego doświadczenia wynika, że współdziałanie różnych implementacji CORBA również może być problematyczne. (Być może sytuacja się poprawiła w tej dziedzinie ... ale nie wykonałem żadnej pracy CORBA od ~ 2002 roku, więc jestem trochę poza zasięgiem.)
Odnośnie punktu 1 - spodziewałem się, że CORBA i Web Services będą mniej więcej równoważne z punktu widzenia wielu platform i języków. Każdy będzie miał słabe punkty, których nie obejmują, ale ogólnie nie widzę dużej różnicy. W przypadku tego scenariusza innego niż starszy nie widzę, że jest to problem.
djna
@djna: ale weź pod uwagę, że dzisiejsza aplikacja, która nie jest starsza, jest starszą aplikacją jutra. Korzystanie z wielojęzycznej / wieloplatformowej technologii oprogramowania pośredniego może dziś pomóc w integracji z następną generacją aplikacji korporacyjnych za 5–10 lat.
Stephen C
@Stephen. Jedynym problemem z ICE jest cena, TAO jest bezpłatne.
fnieto - Fernando Nieto
3
Dobrze powiedziane. Rzeczywiście, Java jest najbardziej rzucającą się w oczy darmową implementacją CORBA. A fakt, że J2EE narzuca IIOP jako swój transport, oznacza, że CORBA jest obecnie prawdopodobnie bardziej wszechobecna i „aktualna” niż kiedykolwiek.
user207421
33
Z istniejących odpowiedzi wynika, że jest to temat prawie religijny. Na CORBĘ można spojrzeć tak samo, jak na półpustą / w połowie pełną szklankę: z jednej strony CORBA jest przestarzałym cruftem, z drugiej strony jest stosunkowo stabilna z kilkoma dostępnymi implementacjami i „diabłem, którego znasz”.
W mojej pracy widzę CORBA wdrażaną w systemach wbudowanych, systemach czasu rzeczywistego (CORBA ma rozszerzenia RT) i tym podobnych. Nie ma wielu alternatyw AFAIK.
Kolejną „zaletą” CORBA jest dostępność kilku wysokiej jakości implementacji open source, np. TAO, MICO, JacORB, itp., Z różnymi modelami licencjonowania i wsparcia. Nadal dostępne są również wersje komercyjne.
W odniesieniu do „większości” aplikacji CORBA wdrażanych w Javie - z mojego doświadczenia tak nie jest. Podczas gdy mapowanie języka CORBA na Javę jest jednym z najprzyjemniejszych (co może nie mówić wiele), Java ma już bardzo ładny model obliczeń rozproszonych, który oferuje bogactwo poza CORBA, a aplikacje całkowicie Java używają go bardziej niż CORBA. Zdecydowana większość rozwoju CORBA, jaką widziałem, dotyczy C ++ (co jest również najgorszym mapowaniem języka).
Wreszcie, CORBA oferuje ustandaryzowane asynchroniczne wywołania po stronie klienta w postaci AMI, ale nigdy nie oferowała asynchronicznej obsługi po stronie serwera. TAO oferuje niestandardową implementację po stronie serwera o nazwie AMH.
Uważam, że Corba została w pewnym sensie ożywiona oryginalną specyfikacją EJB, ponieważ EJB można łatwo przekształcić w fasolę CORBA przez odrobinę konfiguracji. Podejrzewam, że większość wdrożeń Corby została faktycznie zaimplementowana w Javie.
Jeśli chodzi o popularność, to myślę, że przez kilka dziesięcioleci mogą pozostać zaawansowane rozwiązania, ale dla większości ludzi Corba nie żyje.
Jest wiele bardzo seksownych sposobów na zrobienie tego samego (z wyjątkiem wyżej wymienionego high-endu).
Przetwarzanie w chmurze (usługi internetowe, skalowalne przetwarzanie, luźne połączenie, kolejkowanie).
Usługi REST (lite usług internetowych).
Usługi SOAP (ciężkie usługi sieciowe).
Grid / Cluster computing (kolejkowanie, redukcja map i podobne)
Oczywiście zależy to od typu serwera i rozważanej komunikacji międzyprocesowej. Myślę, że Stephen C i Chris Cleeland bardzo dobrze opisują pozytywy Corby.
Nasza aplikacja używa CORBA (Orbix) od ponad 10 lat, więc teraz jest jej spuścizną. A jak to jest napisane, CORBA to dobra technologia. Jednak gdybym zaczynał od nowa, prawdopodobnie nie użyłbym CORBA:
Jest to skomplikowane i tylko niewielka liczba osób w mojej organizacji wie o tym bardzo dobrze, w wyniku czego wszystkie trudne problemy spadają na nich do rozwiązania.
Rekrutacja personelu może być problemem. CORBA po prostu nie jest już fajna i nie robi się fajniejsza Chociaż w Irlandii programiści C ++ są też trochę szczupli.
Większość firm konsultingowych chce używać usług internetowych do prac integracyjnych, więc jeśli chcesz, aby integrację przeprowadziły strony trzecie, prawdopodobnie i tak będziesz potrzebować interfejsu API usług internetowych.
Teraz, w zależności od rodzaju komunikacji, który chciałem, prawdopodobnie rozważyłbym:
bufory protokołów dla wielu małych wiadomości (wiem, że musiałbym zapewnić transport)
usług internetowych dla mniejszej liczby dużych wiadomości
Opiera się to bardziej na znalezieniu personelu i wiedzy specjalistycznej, wsparciu stron trzecich i wykorzystaniu bibliotek open source, niż na technicznej jakości CORBA, której używam na co dzień i jest mocna, choć trochę uciążliwa.
@iain: dobre punkty. CORBA nie jest łatwa w użyciu, nawet w Javie, gdzie większość pracowałem nad CORBA. Rzeczy POA / BOA są trudne do ogarnięcia.
Stephen C
3
Tak, w szczególności sprawa POA jest trudniejsza niż powinna
m.in.
2
Dzięki standaryzacji mapowania języka IDL do C ++ 11 nauka i używanie CORBA jest znacznie łatwiejsze. Mapowanie języka jest proste i ponownie wykorzystuje tyle, ile może z STL. Nadal musisz nauczyć się POA, ale to naprawdę nie jest trudne.
Johnny Willemsen
13
CORBA jest z pewnością staroświecka, ale zapewnia również pewne funkcje wysokiego poziomu po wyjęciu z pudełka (patrz tutaj ). Ta funkcjonalność mogłaby zostać wykonana przy użyciu nowoczesnych usług internetowych, ale prawdopodobnie nie w standardowy sposób i nie bez dużej ilości dodatkowej pracy.
Jednak w przypadku 99% usług rozproszonych CORBA jest niepożądana. Jest brzydki, złożony i trudny w użyciu.
Biorąc pod uwagę ten ostatni punkt, właśnie dlatego ludzie wymyślili mydło / ws- *. Co jest teraz również brzydkie i złożone.
leeeroy
Mydło nie jest takie brzydkie, gdy pracujesz z frameworkami, które wykonują za Ciebie większość zakulisowych działań.
arg20
Jakie alternatywy proponujesz?
schoetbi
5
@ arg20 - To trochę tak, jakby powiedzieć, że mydło nie jest takie brzydkie, jeśli go nie widać :-)
Stephen C
12
Jedna rzecz, o której nikt tutaj nie wspomniał, to OTWARTE, OTWARTE STANDARDY. Ze wszystkich istniejących technologii (z wyjątkiem SOAP) jest to jedyny prawdziwy otwarty standard białej księgi. Standard nie jest zależny od technologii jednej organizacji. RMI (Sun / Oracle), DCOM (obecnie nieistniejący - Microsoft). Jest całkowicie neutralny pod względem dostawcy i języka. Z wyjątkiem SOAP, żadna z innych technologii DOS (Distributed Object Technology) nie jest
Jestem architektem oprogramowania i regularnie muszę wybierać, który DOS powinien być używany w projekcie systemu. Gdyby nie wojna religijna, której za każdym razem stawiam, byłaby to MAMA lub CORBA.
Spójrz na to w ten sposób, gdyby była tak martwa, żadna z sieci 3 / 4G nie działałaby. 3GPP jest całkowicie zgodne ze specyfikacją CORBA. Europejski system satelitarny jest w całości określony przez CORBA. Zapytaj siebie, dlaczego? To dlatego, że muszą być oparte na architekturach neutralnych dla dostawców i języków!
Eee ... w przeszłości brałem udział w opracowywaniu standardów OMG i mogę powiedzieć, że procesy nie zawsze były tak otwarte i przejrzyste, jak można by oczekiwać. A OMG historycznie trzymał się z daleka od kwestii zgodności ... nie żeby IETF czy W3C radziły sobie w tym znacznie lepiej.
Stephen C
1+ @Selvyn Szukałem tych informacji
Tony Shih
@Selvyn, Michi Henning przedstawia całkiem przekonujący argument przeciwny, że otwartość OMG jest systemową przyczyną jego problemów - queue.acm.org/detail.cfm?id=1142044 . Dobra lektura.
półbezpieczne
9
Powiedziałbym, że obecny poziom dojrzałości usług sieciowych (w tym REST) oraz w świecie Java EJB (które mogą nawet używać CORBA pod osłonami) pokrywają to, co jest potrzebne dla rozproszonych systemów korporacyjnych.
Radziłbym, aby jeden aspekt, któremu należy się uważnie przyjrzeć, to stopień asynchronicznej interakcji, którego potrzebujesz w swoim systemie rozproszonym. Postuluję, że każdy system rozproszony o nietrywialnej skali wymaga asynchronicznej komunikacji, a wybrana infrastruktura powinna obsługiwać przetwarzanie asynchroniczne, zwykle oznacza to kolejki.
Nie jest to sprzeczne z korzystaniem z usług sieciowych (lub rzeczywiście CORBA), ale wskazuje na aspekt wyboru produktu, który może zostać przeoczony na początku ekscytacji związanej z rozpoczęciem przetwarzania rozproszonego
Odpowiedzi:
Nadal istnieją sytuacje, w których CORBA może być dobrą odpowiedzią:
Ale mówiąc to, istnieją alternatywy, które robią to, co robi CORBA, tylko lepiej ... a przynajmniej tak twierdzą. Na przykład ICE firmy ZeroC
EDYTUJ @fnieto dzwoni, aby powiedzieć (lub zasugerować), że ICE nie jest darmowy, ale TAO jest.
Jest to niedokładne i mylące .
Wadą ICE jest brak współdziałania ze stosami oprogramowania pośredniego CORBA, ale z mojego doświadczenia wynika, że współdziałanie różnych implementacji CORBA również może być problematyczne. (Być może sytuacja się poprawiła w tej dziedzinie ... ale nie wykonałem żadnej pracy CORBA od ~ 2002 roku, więc jestem trochę poza zasięgiem.)
źródło
Z istniejących odpowiedzi wynika, że jest to temat prawie religijny. Na CORBĘ można spojrzeć tak samo, jak na półpustą / w połowie pełną szklankę: z jednej strony CORBA jest przestarzałym cruftem, z drugiej strony jest stosunkowo stabilna z kilkoma dostępnymi implementacjami i „diabłem, którego znasz”.
W mojej pracy widzę CORBA wdrażaną w systemach wbudowanych, systemach czasu rzeczywistego (CORBA ma rozszerzenia RT) i tym podobnych. Nie ma wielu alternatyw AFAIK.
Kolejną „zaletą” CORBA jest dostępność kilku wysokiej jakości implementacji open source, np. TAO, MICO, JacORB, itp., Z różnymi modelami licencjonowania i wsparcia. Nadal dostępne są również wersje komercyjne.
W odniesieniu do „większości” aplikacji CORBA wdrażanych w Javie - z mojego doświadczenia tak nie jest. Podczas gdy mapowanie języka CORBA na Javę jest jednym z najprzyjemniejszych (co może nie mówić wiele), Java ma już bardzo ładny model obliczeń rozproszonych, który oferuje bogactwo poza CORBA, a aplikacje całkowicie Java używają go bardziej niż CORBA. Zdecydowana większość rozwoju CORBA, jaką widziałem, dotyczy C ++ (co jest również najgorszym mapowaniem języka).
Wreszcie, CORBA oferuje ustandaryzowane asynchroniczne wywołania po stronie klienta w postaci AMI, ale nigdy nie oferowała asynchronicznej obsługi po stronie serwera. TAO oferuje niestandardową implementację po stronie serwera o nazwie AMH.
źródło
Uważam, że Corba została w pewnym sensie ożywiona oryginalną specyfikacją EJB, ponieważ EJB można łatwo przekształcić w fasolę CORBA przez odrobinę konfiguracji. Podejrzewam, że większość wdrożeń Corby została faktycznie zaimplementowana w Javie.
Jeśli chodzi o popularność, to myślę, że przez kilka dziesięcioleci mogą pozostać zaawansowane rozwiązania, ale dla większości ludzi Corba nie żyje.
Jest wiele bardzo seksownych sposobów na zrobienie tego samego (z wyjątkiem wyżej wymienionego high-endu).
Ale oczywiście Twój przebieg może się różnić.
źródło
Oczywiście zależy to od typu serwera i rozważanej komunikacji międzyprocesowej. Myślę, że Stephen C i Chris Cleeland bardzo dobrze opisują pozytywy Corby.
Nasza aplikacja używa CORBA (Orbix) od ponad 10 lat, więc teraz jest jej spuścizną. A jak to jest napisane, CORBA to dobra technologia. Jednak gdybym zaczynał od nowa, prawdopodobnie nie użyłbym CORBA:
Teraz, w zależności od rodzaju komunikacji, który chciałem, prawdopodobnie rozważyłbym:
Opiera się to bardziej na znalezieniu personelu i wiedzy specjalistycznej, wsparciu stron trzecich i wykorzystaniu bibliotek open source, niż na technicznej jakości CORBA, której używam na co dzień i jest mocna, choć trochę uciążliwa.
źródło
CORBA jest z pewnością staroświecka, ale zapewnia również pewne funkcje wysokiego poziomu po wyjęciu z pudełka (patrz tutaj ). Ta funkcjonalność mogłaby zostać wykonana przy użyciu nowoczesnych usług internetowych, ale prawdopodobnie nie w standardowy sposób i nie bez dużej ilości dodatkowej pracy.
Jednak w przypadku 99% usług rozproszonych CORBA jest niepożądana. Jest brzydki, złożony i trudny w użyciu.
źródło
Jedna rzecz, o której nikt tutaj nie wspomniał, to OTWARTE, OTWARTE STANDARDY. Ze wszystkich istniejących technologii (z wyjątkiem SOAP) jest to jedyny prawdziwy otwarty standard białej księgi. Standard nie jest zależny od technologii jednej organizacji. RMI (Sun / Oracle), DCOM (obecnie nieistniejący - Microsoft). Jest całkowicie neutralny pod względem dostawcy i języka. Z wyjątkiem SOAP, żadna z innych technologii DOS (Distributed Object Technology) nie jest
Jestem architektem oprogramowania i regularnie muszę wybierać, który DOS powinien być używany w projekcie systemu. Gdyby nie wojna religijna, której za każdym razem stawiam, byłaby to MAMA lub CORBA.
Spójrz na to w ten sposób, gdyby była tak martwa, żadna z sieci 3 / 4G nie działałaby. 3GPP jest całkowicie zgodne ze specyfikacją CORBA. Europejski system satelitarny jest w całości określony przez CORBA. Zapytaj siebie, dlaczego? To dlatego, że muszą być oparte na architekturach neutralnych dla dostawców i języków!
źródło
Powiedziałbym, że obecny poziom dojrzałości usług sieciowych (w tym REST) oraz w świecie Java EJB (które mogą nawet używać CORBA pod osłonami) pokrywają to, co jest potrzebne dla rozproszonych systemów korporacyjnych.
Radziłbym, aby jeden aspekt, któremu należy się uważnie przyjrzeć, to stopień asynchronicznej interakcji, którego potrzebujesz w swoim systemie rozproszonym. Postuluję, że każdy system rozproszony o nietrywialnej skali wymaga asynchronicznej komunikacji, a wybrana infrastruktura powinna obsługiwać przetwarzanie asynchroniczne, zwykle oznacza to kolejki.
Nie jest to sprzeczne z korzystaniem z usług sieciowych (lub rzeczywiście CORBA), ale wskazuje na aspekt wyboru produktu, który może zostać przeoczony na początku ekscytacji związanej z rozpoczęciem przetwarzania rozproszonego
źródło