ARCHITEKTURY KOMPONENTOWE: OGRANICZENIA I ALTERNATYWY

Projektowanie oparte na komponentach jest stosunkowo nowe i nadal jest przedmiotem ożywionych dyskusji, w tym poważnej debaty na temat względnych zalet CORBA i DCOM. Względne zalety i wady często wynikają z różnych podejść przyjętych przez ich wynalazców: DCOM pochodzi ze stajni firmy Microsoft i, między innymi, daje znaczną moc klientom z systemem Windows. Aby podać tylko jeden przykład, DCOM garbage collection korzysta z prawa do niszczenia obiektów, gdy nie ma już do nich odniesień żaden klient. Z drugiej strony, CORBA zachowuje prawo serwera do utrzymywania tych obiektów, zapewniając w ten sposób lepszą skalowalność, ale wymagając napisania specjalistycznych rozwiązań dla każdej aplikacji. Nowy uczestnik, Enterprise Java, jest wyraźnie bardzo ważnym rozwiązaniem dla wymagań dotyczących  handlu elektronicznego i, w porównaniu z większością alternatyw, oferuje wygodne „proste” podejście. Jest to również, przynajmniej w zasadzie, w pełni otwarte rozwiązanie: niezależnie od konkretnego środowiska sprzętowego i programowego, na którym działa, wirtualna maszyna Java zapewnia programiście spójne środowisko programistyczne. Niestety, może to również stanowić problem: ponieważ kod maszyny wirtualnej musi zostać przetłumaczony na „prawdziwy” kod dla „prawdziwej” używanej maszyny, występują nieuniknione spadki wydajności, w szczególności szybkość. Z tego powodu deweloperzy w branżach, w których wymagane są procesy wymagające intensywnych transakcji, na przykład bankowość detaliczna, które generalnie zastrzegają ocenę, czy korporacyjna Java zapewni odpowiednie rozwiązanie. Inny problem pojawia się w przypadku starszego kodu: jak powiedzieliśmy, poprzez Java Native Interface (JNI) można zintegrować się z innymi językami, ale mogą pojawić się trudności z definicjami obiektów, które muszą być zakodowane w JAVA. Kontrastuje to z CORBA, która jest po prostu specyfikacją, pozwala na kodowanie obiektów w dowolnym języku, pod warunkiem, że istnieje funkcja biblioteki ORB. To dopiero początek, aby móc komentować bezpieczeństwo architektur komponentów. Można się martwić o moc, jaką DCOM daje klientom. Twierdzono również, że bezpieczeństwo CORBA jest nadal raczej szarą strefą. Mechanizmy bezpieczeństwa Javy powinny skorzystać na podejściu piaskownicy, chociaż należy zauważyć, że kod inny niż Java, połączony przez JNI, zachowa swoje własne luki. To powiedziawszy, zgodnie z naszą dyktaturą podaną w części 3.2 dotyczącą konieczności opracowania prostych operacyjnie procedur bezpieczeństwa, prawdopodobnie prawdą jest, że wszystkie omówione przez nas rozwiązania komponentowe ułatwią programistom ocenę bezpieczeństwa ich kodu niż dostępne wcześniej dla nich opcje. Na koniec powinniśmy zauważyć, że żadna z architektur nie została zaprojektowana z myślą o aplikacjach działających w czasie rzeczywistym, takich jak ciągłe przesyłanie strumieniowe wideo. Na razie nie jest to pilny wymóg, ale głupotą byłoby polegać na tym, by tak było przez dłuższy czas.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *