Czy dziedzictwo CORBA?

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?

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 .

1. 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.)
2. 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.
3. 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.)

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)

Ale oczywiście Twój przebieg może się różnić.

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.

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.

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!

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