Integracja: Java kontra .Net

Czas konieczny do stworzenia systemu

Czas implementacji rozwiązań jest jednym z istotnych czynników wpływających na długookresowe koszty związane z wyborem konkretnej platformy. W przypadku J2EE programista ma do dyspozycji kilka mechanizmów, które nie są bezpośrednio dostępne w przypadku Microsoft .Net: automatyczne zarządzanie trwałym stanem (persistent state management) oferowane przez komponenty entity beans, co znacząco przyspiesza proces tworzenia aplikacji i umożliwia uniezależnienie się od dostawcy bazy danych, interfejs JCA (Java Connector Architecture) pozwala na rozszerzenie funkcjonalności projektu o komunikację z innymi systemami (np. SAP R/3, Siebel) bez konieczności modyfikowania istniejącego oprogramowania. W implementacji J2EE brakuje jednak rozwiązań umożliwiających wykorzystanie architektury klastrowej czy buforowania (niezbędne mechanizmy są dostępne w konkretnych implementacjach, decydując się jednak na ich wykorzystanie, należy się liczyć ze zmniejszeniem przenośności stworzonego kodu; zostaną one prawdopodobnie uwzględnione w kolejnych standardach J2EE).

Z kolei platforma Microsoft .Net umożliwia programistom łatwe tworzenie interfejsu użytkownika (również w przypadku aplikacji WWW), udostępniając wiele komponentów. Ponadto interfejs aplikacji webowej nie jest uzależniony od urządzenia wykorzystywanego przez klienta (ASP .Net pozwala na tworzenia stron WWW w HTML, WML czy XML). Mechanizm komunikacji asynchronicznej z komponentami przy wykorzystaniu Queued Components jest bogatszy i bardziej elastyczny niż występujący w J2EE mechanizm MDB (Message Driven Beans). Microsoft starał się jak najbardziej uprościć mechanizmy programowania, rezygnując np. z wykorzystania obiektów serwerowych zapamiętujących stan sesji (stateful) czy upraszczając mechanizmy transakcji. Nie oznacza to, że nie można korzystać z wyżej wymienionych mechanizmów, tworząc aplikacje na platformę Microsoft .Net - jest to możliwe, jednak nieco bardziej, niż w przypadku technologii J2EE, czasochłonne; dodatkowym minusem jest często w takim przypadku konieczność rezygnacji z wykorzystania udogodnień platformy Microsoftu (tworzenie kodu niezarządzanego przez .Net).

Mimo różnic funkcjonalnych udostępnianych przez obie platformy oraz trudności w bezpośrednim porównaniu czasu koniecznego do stworzenia podobnego systemu przy wykorzystaniu platform J2EE i Microsoft .Net, wydaje się, że ich możliwości w tym zakresie są zbliżone. O wyborze przez organizację konkretnej platformy powinny więc decydować inne względy.

Niezależność od dostawcy rozwiązania

W przypadku J2EE mamy do czynienia ze specyfikacją mającą wiele implementacji komercyjnych (np. implementacje firm IBM, HP, Oracle, iPlanet, Borland) oraz niekomercyjnych (JBoss, Jonas, Enhydra). Pieczę nad rozwojem specyfikacji sprawuje firma Sun Microsystems. Odbywa się to jednak przy aktywnej współpracy ze wszystkimi liczącymi się na rynku dostawcami oprogramowania (poza Microsoftem) w ramach Java Community Process, nie powinno być zatem obaw o próbę dominacji ze strony Suna. Implementacje dostarczane przez poszczególnych dostawców nie są w pełni przenośne, jednak ocenia się, że przeniesienie oprogramowania między różnymi implementacjami J2EE nie wymaga zmiany więcej niż 10% kodu.

Zupełnie inne podejście reprezentuje Microsoft, który jest dostawcą systemu operacyjnego, zestawu interfejsów programistycznych oraz wielu dodatkowych produktów współpracujących z technologią Microsoft .Net. Dzięki temu możliwa jest integracja z systemami dostarczonymi przez Microsoft, jednak integracja systemu z rozwiązaniami firm trzecich może niejednokrotnie nastręczać trudności. Organizacja decydująca się na zastosowanie technologii Microsoft .Net skazuje się na podporządkowanie decyzjom marketingowym i technologicznym podejmowanym przez Microsoft, co może mieć różne następstwa w przyszłości.

Niektóre z mechanizmów związanych z technologią Microsoft .Net zostały objęte standaryzacją i udokumentowane (CLR, język pośredni MSIL, protokół SOAP). Umożliwiło to podjęcie prób mających na celu powstanie alternatywnych implementacji platformy .Net w środowisku Linux/Unix (projekt Mono). Mimo to dostępność większości mechanizmów koniecznych do budowy rzeczywistych systemów jest zależna od produktów i narzędzi dostarczanych przez Microsoft. Objęte standaryzacją mechanizmy umożliwiają współpracę i integrację rozwiązań dostarczanych przez firmy trzecie z produktami Microsoftu, jednak nie pozwalają na pełne uniezależnienie się od firmy z Redmond jako dostawcy systemu i narzędzi.


TOP 200