|
Wstęp
|
Współczesne przedsiębiorstwa, aby się rozwijać, muszą poszerzać zakres swych usług, obniżać ich koszty
i zapewniać wygodny dostęp do nich dla klientów, pracowników i dostawców. W typowej systuacji aplikacje
realizujące te usługi muszą łączyć istniejące systemy informacyjne przedsiębiorstwa z nową funkcjonalnością
biznesową, której odbiorcą jest liczna rzesza klientów. Wspomniane usługi muszą charakeryzować się:
- Wysoką dostępnością, aby zaspokoić potrzeby współczesnego globalnego środowiska
prowadzenia biznesu
- Bezpieczeństwem, aby chronić prywatne dane użytkowników i dane przedsiębiorstwa
- Niezawodnością i skalowalnością, aby zapewnić, że transakcje są przetwarzane
w sposób kontrolowany
Dla programisty stającego przed zadaniem stworzenia takiej aplikacji powyższe wymagania mogą stanowić
nie lada wyzwanie. Autentykacja i kontrola uprawnień użytkowników systemu, transakcyjność wykonywanych
operacji, komunikacja między różnymi modułami systemu (często rozproszonymi), zarządzanie dostępem
do trwałych archiwów danych - to tylko niektóre z mechanizmów, które należy zaimplementować. Ponieważ
są to skomplikowane zadania programistyczne, a wraz rozwojem elektronicznego biznesu pojawiało się coraz
większe zapotrzebowanie na aplikacje spełniające te wszystkie wymogi, powstała idea stworzenia czegoś,
co teraz określa się terminem middleware.
Podejście to bazuje na pomyśle, żeby stworzyć warstwę oprogramowania rezydującą ponad systemem operacyjnym,
odpowiedzialną za implementację zestawu mechanizmów, protokołów i interfejsów programistycznych, które
są nieodzowne dla stworzenia zaawansowanego systemu informatycznego dla współczesnego przedsiębiorstwa
prowadzącego działalność w sieci.
Istnienie takiej warstwy umożliwiłoby twórcy systemu pracę na wyższym poziomie abstrakcji i
skupienie się na oprogramowaniu logiki aplikacji, bez angażowania się w skomplikowane mechanizmy
niskopoziomowe. Już na pierwszy rzut oka widać wynikające z tego korzyści:
- Uniknięcie ryzyka popełnienia błedów programistycznych w krytycznych mechanizmach systemu
- Szybsze, tańsze i łatwiejsze projektowanie, programowanie, wdrażanie i utrzymanie aplikacji
- Szansa na polepszenie jakości oprogramowania dzięki specjalizacji w tworzeniu middleware
- Lepsza skalowalność i łatwiejsza integracja systemów dzięki standaryzacji interfejsów
Platforma J2EE firmy Sun Microsystems pozwala na zrealizowanie tych wszystkich założeń.
Ponieważ rozwinięcie
akronimu (Java 2 Enterprise Edition) nieuchronnie nasuwa na myśl pytanie o związek J2EE z językiem Java,
jeszcze przed opisem tej platformy zobaczmy, jak przebiegała ewolucja od powstania Javy do powstania J2EE.
- Pojawia się JDK; firma Sun jeszcze nie myśli o technologiach middleware
- Java okazuje się dobrym jezykiem oprogramowania strony serwera systemów działających w
architekturze klient-serwer; powstają usługi nazw, katalogowe, zapewniania transakcyjności, pojawia się pierwsza
specyfikacja EJB; problem - specyfikacje są słabo skorelowane, jest wiele niespójności i dwuznacznosci;
różne wersje interfejsów pojawiają się niezależnie, brak między nimi zgodności; brak referencyjnej
implementacji interfejsów programistycznych (API)
- Nowa koncepcja Sun'a - podział na 3 platformy (uporządkowane od najmniejszej):
- j2me (java 2 platform micro edition) - bardzo ograniczona, dla urządzeń typu palmtopy i zegarki
- j2se (java 2 platform standard edition) - JDK; grafika, I/O, itd.
- j2ee (java 2 platform enterprise edition) - pełna platforma do tworzenia zaawansowanych
aplikacji działających na serwerze
|
|
Co to jest platforma?
|
J2EE jest platformą dla złożonych, wielowarstowych, rozproszonych, wydajnych i skalowalnych aplikacji.
Co to jednak znaczy platforma? J2EE to nie sprzęt komputerowy, ani żadne konkretne oprogramowanie.
Jest to zbiór specyfikacji dotyczących powiązanych ze sobą technologii, które razem mają zapewnić dobrą
realizację zadań wymienionych we wstępie. W szczególności wiele z nich określa wymagania odnośnie
implementowanych interfejsów programistycznych. Rolę systemu zgodnego z J2EE można przedstawić w analogii
do zadań systemu operacyjnego, który ma umożliwić procesom korzystanie z zasobów komputerowych
i zarządzać ich działaniem w sposób wydajny i bezpieczny. System operacyjny odpowiada za stworzenie procesom
abstrakcji sprzętu, natomiast oprogramowanie spełniające standardy J2EE pozwala programiście abstrahować
od implementacji podstawowych usług, np. uwierzytelniania, komunikacji w rozproszonym środowisku, czy
transakcyjności. Dzięki temu programista może skupić się wyłącznie na logice biznesowej tworzonego
oprogramowania.
Fakt, że J2EE jest tylko zbiorem specyfikacji i nie narzuca żadnej konkretnej implementacji, prowadzi
do otwartości systemów opartych na tej platformie i pozwala wybierać pomiędzy różnymi dostawcami
oprogramowania zgodnego z J2EE.
|
|
J2EE od wewnątrz
|
Za skrótem J2EE kryje się wielka liczba pojęć, technologii, wymagań, ograniczeń i narzędzi. W styczniu
tego roku ukazał się Proposed Final Draft specyfikacji - Java 2 Platform Enterprise Edition
Specification w wersji 1.3. Jednak J2EE to nie tylko specyfikacja komponentowego modelu aplikacji
rozproszonej. Na J2EE składają się cztery elementy:
| J2EE Platform | | specyfikacja platformy |
| J2EE Compatibility Test Suite | | zbiór testów umożliwiających weryfikację
zgodności ze specyfikacją konkretnej implementacji J2EE |
| J2EE Reference Implementation | | dostarczona przez twórcę specyfikacji, firmę Sun
Microsystems, wzorcowa implementacja specyfikacji |
| J2EE Blueprints | | zbiór wskazówek, preferowanych rozwiązań, wzorców projektowych wraz z
propozycją konkretnego modelu rozproszonej, skalowalnej aplikacji |
W dalszej części skupimy się na pierwszym z tych elementów.
|
| Najważniejsze koncepcje |
Wielowarstwowość aplikacji
Aplikacje J2EE są logicznie podzielone na warstwy. Każda warstwa odpowiada za inny zakres funkcjonalności
systemu i może zawierać wiele komponentów. Najczęściej pod terminem "wielowarstwowy" (ang.
multi-tiered) rozumie się 3 warstwy. Granice pomiędzy warstwami są oczywiście logiczne i mogą być
ustanowione przez różne maszyny, procesy, bądź przedsiębiorstwa.
Wspomniany model 3-warstwowy pasuje do wzorca MVC (Model, View, controller), gdzie w kolejnych warstwach
rezydują:
| Warstwa prezentacji (View) |
aplikacje w Javie, aplety, serwlety, strony JSP |
| Warstwa logiki biznesowej (controller) |
komponenty EJB |
| Warstwa danych (Model) |
bazy danych, Enterprise Information Systems |
Zaletą takiego podejścia jest możliwość podzielenia aplikacji na niezależne części, z których każda
obejmuje oprogramowanie odpowiadające za konkretny fragment funkcjonalność całego systemu i może być
rozwijana równolegle z pozostałymi. Żeby
tworzone niezależnie komponenty oprogramowania chciały ze sobą współgrać, muszą pomiędzy nimi istnieć
dobrze zdefiniowane interfejsy, a to właśnie daje platforma J2EE.
Komponentowy model programownia
Programowanie z wykorzystaniem komponentów realizuje dobrze znany sposób atakowania większych problemów
określany jako "dziel i zwyciężaj". Komponent to kawałek kodu implementujący pewien zbiór interfejsów.
Jest to fragment logiki programu, który sam nie stanowi aplikacji - nie może działać samodzielnie, a jest
raczej 'klockiem', który można złożyć z innymi, aby powstała pełna aplikacja. Ideą stojącą za programowaniem
komponentowym jest powtórne wykorzystanie kodu. Korzyści płynące z tworzenia aplikacji za pomocą komponentów
to z pewnością:
- szybka konstrukcja oprogramowania
- mniejsze ryzyko popełnienia błędów programistycznych
- ułatwienie dla projektantów systemu, którzy mogą tworzyć modele o wyższym stopniu abstrakcji traktując
komponenty jako 'czarne skrzynki'
- wyższa jakość tworzonych aplikacji dzięki tworzeniu dobrze udokumentowanym, wyspecjalizowanym komponentom
dostarczanym przez niezależnych producentów
Aby można było tworzyć oprogramowanie bazujące na komponentach potrzebne są:
- IDE - np. Borland JBuilder, Symantec Visual Cafe, Forte
- kontener - czyli otoczka, w której działają komponenty. Kontener zapewnia środowisko wykonania
oraz standardowe usługi, z których korzystają komponenty (np. dynamiczne tworzenie i kasowanie komponentów,
zarządzanie transakcjami i zewnętrznymi zasobami, autoryzacja użytkowników). Dzięki istnieniu kontenerów
programista komponentów nie musi się zajmować tymi funkcjami. Pomiędzy komponentami a kontenerami również
zdefiniowany jest odpowiedni intefejs programistyczny.
- Serwer aplikacyjny - w nim są umieszczone kontenery
- Narzędzia do instalacji komponentów i ich konfiguracji
Menadżer zasobów
Dostęp do zewnętrznych zasobów danych organizowany jest wokół koncepcji tzw. menadżerów zasobów (ang.
resource manager), która jest uogólnieniem idei stojącej za JDBC, czy JNDI. Serwer aplikacyjny
korzysta z usług odpowiedniego sterownika, który, ipmlementując odpowiedni protokół komunikacyjny,
umożliwia dostęp do zasobów konkretnego systemu przechowywania i archiwizacji danych (EIS). Specyfikacja
J2EE connector architecture 1.0 opisuje ten standard.
Podział na role
Specyfikacja J2EE zakłada ścisły podział ról w obrębie procesu tworzenia aplikacji, co jest naturalną
konsekwencją przyjęcia wielowarstwowego modelu opartego na komponentach.
| J2EE Product Provider |
dostawca platformy programowej zgodnej ze specyfikacją J2EE |
| Application Component Provider |
programista tworzący komponenty |
| Application Assembler |
osoba odpowiedzialna za przygotowanie pliku EAR z dostarczonych komponentów |
| Deployer |
osoba wdrażająca aplikację |
| Administrator |
administrator aplikacji J2EE |
|
|
Dlaczego w Javie?
|
Dlaczego to właśnie Java została wybrana jako język programowania aplikacji na platformę J2EE?
- Jest znana bardzo wielu programistom na świecie
- Jest przenośna
- Ma mocny system typów, co znacznie podnosi niezawodność tworzonego oprogramowania
- Jest dobrym językiem do programowania obiektowego, a cechy tego sposobu programowania
(powtórne wykorzystanie kodu, dziedziczenie, oddzielenie interfejsu od implementacji, obsługa sytuacji
wyjątkowych, komunikacja między oddzielnymi obiektami poprzez wysyłanie komunikatów) doskonale pasują
do modelu aplikacji dla platformy J2EE
- W momencie powstawania pierwszej specyfikacji J2EE było już opracowanych wiele API
właśnie dla Javy
|
|
Najważniejsze technologie
|
|
W tym punkcie przedstawione będą technologie wykorzystywane w systemach zgodnych z J2EE, które realizują założenia
opisane w punkcie J2EE od wewnątrz/Najważniejsze koncepcje.
|
| Podział ogólny |
Architektura J2EE opiera się na wielu technologiach, które można podzielić na 3 podstawowe kategorie:
- technologie komponentowe
Platforma J2EE wspiera następujące komponenty: aplikacje kliencke, applety, komponenty WWW (serwlety i
strony JSP) oraz komponenty EJB.
Ze względu na miejsce wykonania kodu komponentów można je podzielić na:
- komponenty strony klienta (applety i aplikacje w Javie)
- komponenty strony serwera (pozostałe)
Ze wzlgędu na charakter wykonywanych zadań można dokonać podziału na:
- komponenty odpowiedzialne za interakcję z użytkownikiem (wszystkie oprócz EJB)
- komponenty odpowiedzialne za logikę biznesową, stosujące skomplikowane algorytmy i przeprowadzające
transakcje na dużych wolumenach (EJB)
Dla appletów oraz normalnych programów w Javie do wykonania potrzebna jest wirtualna maszyna Javy. W
odróżnieniu od nich komponenty WWW i komponenty EJB potrzebują czegoś więcej. Środowiskiem pracy dla
tych komponentów są kontenery, które oddzielają je od klientów, jak również od zewnętrznych zasobów. Tego
rodzaju pośrednictwo jest niezbędne do umożliwienia wykonywania kontenerowi jego zadań, a więc zarządzania
transakcjami, zewnętrznymi zasobami, cyklem życia poszczególnych komponentów, dostępem do systemu oraz
autoryzacją jego użytkowników. Kontenery implementowane są jako niezależne podsystemy w serwerze aplikacji,
który stanowi jądro systemu zgodnego z J2EE. Serwer aplikacji wykonuje ogromną liczbę różnych zadań, których
celem jest realizacja wszystkich wymagań stawianych zaawansowanym aplikacjom sieciowym (niezawodność,
odporność na błędy, transakcyjność, bezpieczeństwo, wielodostępność, wydajność, load-balancing, itp.).
- komunikacja
Ponieważ aplikacje tworzone na platformę J2EE są zwykle rozproszone, muszą być dostarczone odpowiednie
protokoły zapewniające komunikację między poszczególnymi elementami systemu.
- HTTP, HTTPS - typowym klientem systemu J2EE jest przeglądarka WWW
- JDBC, JNDI - dostęp do baz danych
- RMI/RMI-IIOP - dostęp do komponentów EJB, które są dystrybuowalne
- usługi
Ze względu na to, że aplikacje J2EE często muszą integrować wiele źródeł informacji (bazy danych,
systemy typu ERP, CRM, inne aplikacje isntniejące w firmie), serwer aplikacyjny musi oferować jednolity
sposób dostępu do tych zasobów. Tego typu usługi definiuje specyfikacja J2EE Connector Architecture 1.0.
|
| Interfejsy programowe |
Aby aplikacje zbudowane w modelu J2EE mogły działać zgodnie z podanymi wytycznymi, potrzebnych jest
wiele interfejsów programowych (API). Dostawca systemu zgodnego z J2EE zapewnia ich implementację, a twórca
komponentów musi ich przestrzegać, co wiąże się także z pewnymi ograniczeniami, np. pisząc komponenty EJB
nie można korzystać z bibliotek natywnych, tworzyć i synchronizować wątków, korzystać z dostępu do plików
poprzez bibliotekę java.io, ani korzystać z obiektów klasy ServerSocket. Kilka z tych interfejsów występuje
już w J2SE (Java 2 Platform Standard Edition).
Poniżej znajdują się krótkie opisy interfejsów, o których jest mowa w specyfikacjie J2EE 1.3.
| Java IDL API |
Java IDL pozwala na tworzenie aplikacji obiektowych komunikujących się przez CORBA. |
| JDBC Core API |
JDBC jest protokołem dostępu do relacyjnych baz danych. |
| RMI-IIOP API |
Protokół RMI pozwala na komunikację międzyprocesową. RMI-IIOP jest jego przenośnym rozszerzeniem bazującym
na protokole IIOP (Internet Inter-ORB Protocol), używanym przez aplikacje wykorzystujące standard CORBA.
|
| JNDI API |
JNDI pozwala na zlokalizowanie komponentu lub innego zasobu w sieci. |
| JDBC 2.0 Extension |
Ten interfejs programistyczny zawiera wsparcie dla operacji na zbiorach krotek, nazywania połączeń
z wykorzystaniem JNDI, zarządzania pulą połączeń i obsługi rozproszonych transakcji. |
| EJB 2.0 |
Standard EJB definiuje sposób pisania komponentów strony serwera i ustanawia standardowy interfejs
pomiędzy komponentami i serwerem aplikacyjnym.
|
| Servlets 2.3 |
Specyfikacja Servlets 2.3 definiuje zasady programowania serwletów. |
| JSP 1.2 |
Specyfikacja Java Server Pages określa zasady budowania komponentów WWW bazujących na
osadzaniu kodu języka Java w dokumentach HTML. |
| JMS 1.0 |
Java Messaging Service pozwala na asynchroniczną komunikację pomiędzy rozproszonymi obiektami. |
| JTA 1.0 |
Specyfikacje Java Transaction API i Java Transaction Service oferują komponentom niezawodne
usługi transakcyjne. |
| JavaMail 1.2 |
JavaMail pozwala na wysyłanie poczty elektronicznej z poziomu aplikacji napisanej w Javie
w sposób niezależny od platformy oraz używanych protokołów dostarczania poczty. JavaMail jest
interfejsem zależnym od JAF. |
| JAF 1.0 |
Specyfikacja Java Beans Activation Framework określa zadania tego interfejsu jako: określanie typu
dowolnych danych, enkapsulacja dostępu do danych, pobieranie zestawu operacji możliwych do wykonania
na określonym typie danych.
|
| JAXP 1.1 |
Java API for XML Parsing obsługuje interfejsy SAX i DOM parserów XML, jak również
wspiera obsługę procesorów transformacji XSLT. |
| Connector 1.0 |
Ten interfejs pozwala na integrację aplikacji J2EE z różnymi systemami EIS. |
| JAAS 1.0 |
Za pomocą Java Authentication and Authorization Service można przeprowadzić autentykację
użytkowników i kontrolować ich prawa dostępu do aplikacji. Wykorzystywany jest do tego mechanizm
podobny do PAM (Pluggable Authentication Modules). |
Intuicje odnośnie opisanych mechanizmów w architekturze J2EE dobrze wspomaga poniższy
obrazek
|
|
Schemat procesu tworzenia aplikacji na platformę J2EE
|
Aplikacje zgodne ze specyfikacją J2EE są odpowiednio pakowane do pliku typu EAR (Enterprise
Archive). Plik taki ma dobrze określoną strukturę, a jego zawartość opisywana jest przez deskryptor
pliku EAR. Pojedynczy plik EAR jest samodzielnym, zamkniętym pakietem, który stanowi kompletną aplikację
gotową do uruchomienia na dowolnym systemie zgodnym z J2EE.
Plik EAR zwykle składa się z kilku modułów, które zawierają komponenty. Podobnie jak plik EAR jest
opisany przez własny deskryptor (zwany deskryptorem aplikacji), tak zawartość każdego modułu
jest opisana jego deskryptorem. Każdy moduł może dać się samodzielnie uruchomić, nie jest do tego potrzebny
kontekst ani deskryptor aplikacji.
W typowym przypadku aplikacja J2EE składa się z następujących modułów:
- Modułów EJB w postaci archiwów JAR (Java Archive), które zawierają komponenty EJB (sesyjne, trwałe oraz
komunikacyjne) razem z właściwym deskryptorem. Specyfikacja EJB 2.0 określa strukturę i zawartość takiego
modułu.
- Modułów WWW w postaci archiwów WAR (Web Archive), które zawierają serwlety, JSP, strony HTML i inne
zasoby WWW razem z właściwym deskryptorem. Specyfikacja Servlets 2.3 określa strukturę i zawartość
takiego modułu.
- Modułów adapterów zasobów w postaci plików RAR (Resource Archive)
Rozwój typowej aplikacji J2EE odbywa się według następującego schematu postępowania:
- Implementacja poszczególnych komponentów: serwletów, stron JSP, komponentów EJB
- Spakowanie komponentów w odpowiednie moduły i utworzenie dla nich deskryptorów
- Spakowanie modułów komponentowych do jednego pliku EAR i utworzenie dla niego deskryptora
aplikacji, co razem daje kompletny program na platformę J2EE
- Instalacja aplikacji w postaci pliku EAR w serwerze aplikacji
- Uruchomienie aplikacji za pomocą narzędzia (deployment tool) dostarczonego przez
producenta serwera aplikacji, na co składa się
- odczytanie deskryptora aplikacji, co daje informacje o zawartych modułach
- odczytanie deskryptora każdego modułu
- instalacja poszczególnych komponentów w odpowiednich kontenerach
- Dopasowanie przez administratora systemu wszystkich paramtrów aplikacji (polityka
bezpieczeństwa, zachowanie transakcyjne systemu) do istniejącego środowiska IT
Wszystkie wspomniane deskryptory zapisane są w odpowiednim dialekcie języka XML.
Oto przykładowy deskryptor aplikacji
Widać na nim, że aplikacja składa się z jednego modułu WWW (petstoreadmin.war) oraz jednego modułu
EJB (petstoreadminEjb.jar).
|
|
Istniejące implementacje
|
- Bea Weblogic Server
- HP Bluestone Total-e-Server
- iPlanet Application Server
- IBM Websphere Application Server
- IONA iPortal Application Server
- Oracle 9i Application Server
- Macromedia JRun Server
- SilverStream Application Server
- Sybase EAServer
- TogetherSoft ControlCenter
- Trifork Enterprise Application Server
- Ars Digita Community System
- Borland AppServer
- Java 2 SDK, Enterprise Edition
|
|
Aktualna wersja specyfikacji
|
|
Aktualna specyfikacja J2EE ma numer 1.3.
|
|
Kierunki rozwoju
|
Biorąc pod uwagę, że celem sformułowania specyfikacji J2EE jest stworzenie pełnego środowiska dla
wykonywania rozproszonych aplikacji, widać, że jest jeszcze wiele do zrobienia. Autorzy specyfikacji
wskazują aktualnie na następujące kierunki rozwoju:
- Większe wsparcie dla technologii XML (XML Data Binding API), tym bardziej, że aktualnie
do określania struktury dokumentu wykorzystywany jest tylko DTD, a nie ma możliwości użycia XML Schema
- Prace nad rozwojem SPI (Service Provider API), czyli interfejsem dla producentów EIS
(Enterprise Information System) przeznaczonym do pisania odpowiednich sterowników. Pierwszy krok w
tym kierunku został już poczyniony w postaci J2EE Connector Architecture
- Ujednolicenie zarządzania systemami opartymi na J2EE. Przyszła specyfikacja ma zawierać
opis tzw. Management APIs, czyli standardowych interfejsów do zarządzania aplikacjami oraz serwerem
aplikacyjnym
- Prace nad protokołem JNLP (Java Network Launch Protocol) definiującym mechanizm
wdrożenia aplikacji napisanej w Javie na serwerze i uruchomienia jej z poziomu klienta
- Rozwój JDBC Rowsets, czyli standardowego sposobu przesyłania danych pochodzących z tabel
pomiędzy zdalnymi komponentami rozproszonej aplikacji J2EE
- Opracowanie lepszych interfejsów programistycznych do zapewniania bezpieczeństwa
|
|
Konkurencyjne rozwiązania
|
Rozwiązania konkurencyjne dla J2EE opracowywane są także przez firmę Microsoft. Na samym początku trzeba
już jednak wskazać podstawową różnicę w podejściu Sun'a i Microsoftu do tego problemu. J2EE jest
specyfikacją, czyli sformułowaniem zestawu warunków, które muszą być spełnione przez każdą implementację,
podczas gdy Microsoft oferuje gotowe rozwiązania w postaci własnych aplikacji.
Propozycje Microsoftu to:
- Windowsw NT + DCOM + MS Message Queue + MS Transaction Server + MS Wolfpack +
MS SQL Server + IIS + ASP + MS Management Console (starsze rozwiązanie)
- .Net (nowe rozwiązanie)
Oczywistą konsekwencją zdecydowania się na rozwiązanie Microsoftu jest automatyczna rezygnacja z możliwości
wyboru pomiędzy dostawcami elementów platformy.
Ze względu na brak praktycznego doświadczenia pozwalającego na dokonane porównania J2EE z Microsoft.Net
pozwolę sobie zacytować kilka fragmentów z artykułu "J2EE vs. Microsoft.NET A comparison of building XML-based
web services", Chad Vawter and Ed Roman June 2001.
"The shared vision between both J2EE and .NET is that there is an incredible amount of 'plumbing' that goes into building web services, such as XML interoperability, load-balancing, and transactions. Rather than writing all that plumbing yourself, you can write an application that runs within a container that provides those tricky services for you."
"Microsoft.NET offers language-independence and language-interoperability. This is one of the most intriguing and fundamental aspects of the .NET platform. A single .NET component can be written, for example, partially in VB.NET, the .NET version of Visual Basic, and C#, Microsoft's new object-oriented programming language."
"J2EE offers several features that accelerate time-to-market which are not found in .NET. For example, state management services enable developers to write less code and not worry about managing state, resulting in a higher degree of rapid application development."
"Microsoft.NET offers a variety of time-to-market features not found in J2EE as well. Most notably, ASP.NET is independent of client device, and allows for user interfaces to be rendered to alternative user interfaces without rewriting code. Microsoft also offers Queued Components which are superior to MessageDriven Beans. It should be noted here that Microsoft has tried to simplify server-side programming greatly by removing support for features found in traditional enterprise applications, such as stateful servers and simple transactions. If developers need to go outside this box, their code must be made to be non-managed and reside outside the .NET Framework rather than take advantage of it. Microsoft also provides business process management and E-Commerce capabilities, which are available in some J2EE implementations but not all."
"In conclusion, we feel the ability to achieve rapid application development offered by both J2EE and .NET is definitely not equal. It is, however, comparable."
".NET provides a fairly complete solution from a single vendor--Microsoft. This solution may lack some of the higher end features that J2EE solutions offer, but in general, the complete web services vision that Microsoft will be providing is equal in scope to that of a larger J2EE vendor."
"Arguments supporting both platforms
- Regardless of which platform you pick, new developers will need to be trained (Java training for J2EE, OO training for .NET)
- You can build web services today using both platforms
- Both platforms offer a low system cost, such as jBoss/Linux/Cobalt for J2EE, or Windows/Win32 hardware for .NET.
- Both platforms offer a single-vendor solution.
- The scalability of both solutions are theoretically unlimited.
Arguments for .NET and against J2EE
- .NET has Microsoft's A-team marketing it
- .NET released their web services story before J2EE did, and thus has some mind-share
- .NET has a better story for shared context today than J2EE
- .NET has an awesome tool story with Visual Studio.NET
- .NET has a simpler programming model, enabling rank-and-file developers to be productive without shooting themselves in the foot
- .NET gives you language neutrality when developing new eBusiness applications, whereas J2EE makes you treat other languages as separate applications
- .NET benefits from being strongly interweaved with the underlying operating system
Arguments for J2EE and against .NET
- J2EE is being marketed by an entire industry
- J2EE is a proven platform, with a few new web services APIs. .NET is a rewrite and introduces risk as with any first-generation
technology
- Only J2EE lets you deploy web services today
- Existing J2EE code will translate into a J2EE web services system without major rewrites. Not true for Windows DNA code
ported to .NET.
- .NET web services are not interoperable with current industry standards. Their BizTalk framework has proprietary SOAP
extensions and does not support ebXML.
- J2EE is a more advanced programming model, appropriate for well-trained developers who want to build more advanced object
models and take advantage of performance features
- J2EE lets you take advantage of existing hardware you may have
- J2EE gives you platform neutrality, including Windows. You also get good (but not free) portability. This isolates you from
heterogeneous deployment environments.
- J2EE has a better legacy integration story through the Java Connector Architecture (JCA)
- J2EE lets you use any operating system you prefer, such as Windows, UNIX, or mainframe. Developers can use the
environment they are most productive in.
- J2EE lets you use Java, which is better than C# due to market-share and maturity. According to Gartner, there are 2.5
million Java developers. IDC predicts this will grow to 4 million by 2003. 78% universities teach Java, and 50% of universities
require Java.
- We would not want to use any language other than C# or Java for development of new mission-critical solutions, such as a
hacked object-oriented version of C, VB, or COBOL.
- We are finding most ISVs and consulting companies going with J2EE because they cannot control their customers' target
platforms. We believe this application availability will result in J2EE beginning to dominate more and more as time goes on.
In conclusion, while both platforms will have their own market-share, we feel most customers will reap greater wins with J2EE.
We feel the advantages outweigh those offered by Microsoft.NET. That is our preferred architecture, and we stand behind it."
|
|
Adresy w sieci
|
Poniżej zamieściłem kilka adresów, których odwiedzenie szczerze polecam. Informacje tam zawarte były
dla mnie nieocenioną pomocą przy zapoznawaniu się z platformą J2EE oraz pisaniu tego artykułu.
|
|
