Czym tak naprawdę jest Java EE? [Zamknięte]

Java EE ma wokół siebie ten „tajemniczy całun” dla młodszych programistów Java - taki, który próbuję podnieść od dłuższego czasu z niewielkim sukcesem.

Zamieszanie wynika z:

• Wydaje się, że Java EE jest zarówno biblioteką, jak i platformą - istnieje wiele sposobów „uzyskania” biblioteki Java EE, zazwyczaj z czegoś takiego jak pobranie pakietu Oracle Java EE SDK. Jednak biblioteka Java EE nie będzie działać ani kompilować, chyba że kod jest uruchamiany na serwerze aplikacji Java EE (takim jak JBoss, GlassFish, Tomcat itp.) Lub ma do niego dostęp. Czemu? Czy biblioteki nie mogą działać poza środowiskiem serwera aplikacji? Dlaczego potrzebuję czegoś masywnego jako JBoss tylko do skompilowania prostego kodu do wysłania e-maila?

• Dlaczego biblioteki Java EE nie są „standardowe” i są dołączane do zwykłego pobierania maszyny JVM i / lub zestawu SDK?

• Dlaczego jest tak wiele ofert Java EE, skoro tak naprawdę są tylko dwie główne odmiany standardowej Java (Oracle JVM / SDK | OpenJDK JVM / JDK)?

• Co można zrobić z Java EE, czego nie można zrobić ze standardową Javą?

• Co można zrobić ze standardową Javą, czego nie można zrobić z Java EE?

• Kiedy programista decyduje, że „potrzebuje” Java EE?

• Kiedy programista decyduje, że nie potrzebuje Java EE?

• Dlaczego wersja biblioteki Java EE nie jest zsynchronizowana ze standardowymi wydaniami bibliotek Java (Java EE 6 kontra Java 7)?

Dzięki za pomoc w usunięciu baty!

Dlaczego biblioteki nie mogą działać poza środowiskiem serwera aplikacji?

Właściwie mogą. Większość bibliotek może być bezpośrednio używana samodzielnie (w Javie SE) lub dołączona do pliku .war (prawie zawsze jest to Tomcat). Niektóre części Java EE, takie jak JPA, mają wyraźne sekcje w swoich specyfikacjach, które mówią, jak powinny działać i być używane w Java SE.

Jeśli już, chodzi nie tyle o samo środowisko serwera aplikacji, ile o obecność wszystkich innych bibliotek i łączący je kod integracji.

Z tego powodu adnotacje będą skanowane tylko raz dla wszystkich klas, a nie każdej biblioteki (EJB, JPA itp.), Która będzie skanować w kółko. Również z tego powodu adnotacje CDI można zastosować do fasoli EJB, a menedżerów jednostek JPA można do nich wstrzyknąć.

Dlaczego potrzebuję czegoś masywnego jako JBoss tylko do skompilowania prostego kodu do wysłania e-maila?

Jest kilka rzeczy nieprawidłowych w tym pytaniu:

1. Do kompilacji potrzebujesz tylko jar API, który ma mniej niż 1 MB dla profilu internetowego i nieco ponad 1 MB dla pełnego profilu.
2. Do biegania potrzebujesz oczywiście implementacji, ale „masowość” to zawyżanie rzeczy. Na przykład OpenJDK ma około 75 MB, a TomEE (implementacja profilu internetowego zawierająca obsługę poczty) ma tylko 25 MB. Nawet GlassFish (implementacja pełnego profilu) ma tylko 53 MB.
3. Mail działa doskonale z Java SE (a tym samym z Tomcat), a także przy użyciu samodzielnych mail.jar i Activation.jar .

Dlaczego biblioteki Java EE nie są „standardowe” i są dołączane do zwykłego pobierania maszyny JVM i / lub zestawu SDK?

Java EE była w pewnym sensie jedną z pierwszych prób podzielenia i tak już ogromnego JDK na porcje, które są łatwiejsze do zarządzania i pobierania. Ludzie już narzekają, że klasy graficzne (AWT, Swing) i aplety są wewnątrz środowiska JRE, podczas gdy jedyne, co robią, to uruchamianie niektórych poleceń na serwerze bezgłowym. Czy chcesz również uwzględnić wszystkie biblioteki Java EE w standardowym JDK?

Wraz z ostatecznym wydaniem obsługi modułowości będziemy mieli tylko małe podstawowe środowisko JRE z wieloma rzeczami, które można oddzielnie zainstalować jako pakiety. Być może pewnego dnia wiele lub nawet wszystkie klasy, które teraz tworzą Java EE, będą również takim pakietem. Czas pokaże.

Dlaczego jest tak wiele ofert Java EE, skoro tak naprawdę są tylko dwie główne odmiany standardowej Java (Oracle JVM / SDK | OpenJDK JVM / JDK)?

Istnieje więcej niż tylko dwie odmiany Java SE. Jest przynajmniej IBM JDK, poprzedni BEA (JRocket, który jest łączony z Oracle / Sun z powodu przejęcia), różne inne implementacje open source i mnóstwo implementacji do użytku wbudowanego.

Powodem, dla którego Java SE i EE są specyfikacjami, jest to, że wielu dostawców i organizacji może je wdrożyć, a tym samym sprzyja konkurencji i zmniejsza ryzyko uzależnienia od dostawcy.

Nie inaczej jest w przypadku kompilatorów C i C ++, w przypadku których masz wiele konkurencyjnych ofert, a wszystkie są zgodne ze standardem C ++.

Dlaczego wersja biblioteki Java EE nie jest zsynchronizowana ze standardowymi wydaniami bibliotek Java (Java EE 6 kontra Java 7)

Java EE jest oparta na Javie SE, więc pozostaje w tyle. Wersje jednak odpowiadają. Java EE 5 wymaga Java SE 5. Java EE 6 wymaga Java SE 6 i tak dalej. Tyle, że głównie wtedy, gdy Java SE X jest aktualna, Java EE X-1 jest aktualna.

Oto kilka szybkich odpowiedzi na Twoje pytania ...

• Dlaczego biblioteki JavaEE nie mogą działać bez serwera aplikacji? Usługi świadczone przez JavaEE (transakcje zarządzane przez kontener, wstrzykiwanie zależności zarządzanych przez kontener, usługa timera, itp.) Nieodłącznie obejmują serwery aplikacji zgodne z JavaEE (na przykład: GlassFish, JBoss, WebSphere itp.). Dlatego biblioteki JavaEE są bezcelowe bez takiego kontenera. „ Dlaczego potrzebuję czegoś tak masywnego jak JBoss tylko do skompilowania prostego kodu do wysłania e-maila? ” Nie. Istnieją sposoby na wysłanie wiadomości e-mail bez JavaEE ... Ale jeśli chcesz to zrobić w sposób JavaEE, potrzebujesz kontenera JavaEE.

• Dlaczego biblioteki JavaEE nie są dołączane do pobierania JavaSE? Z tego samego powodu, dla którego nie uwzględniono wielu bibliotek: byłaby to przesada. Skoro nie możesz nawet używać bibliotek JavaEE bez serwera aplikacji, po co je dołączać? JavaEE należy pobrać wtedy, gdy programista instaluje serwer aplikacji i decyduje się na użycie JavaEE.

• Dlaczego jest tak wiele ofert JavaEE? Czy naprawdę jest „ tak wiele ” ofert JavaEE? Jeśli tak, wymień niektóre z nich. Dokładniej, uważam, że istnieje wiele implementacji tych samych interfejsów API .

• Co można zrobić z JavaEE, czego nie można zrobić bez standardowej Javy? Wiele. Nie można polegać na serwerze aplikacji w zarządzaniu transakcjami lub kontekstami trwałości bez JavaEE. Nie można zezwolić serwerowi aplikacji na zarządzanie wstrzykiwaniem zależności EJB bez JavaEE. Nie możesz korzystać z usługi zegara zarządzanego przez aplikację bez JavaEE. Odpowiedź na to pytanie powinna sprawić, że odpowiedź na pierwsze pytanie będzie dość jasna ... Większość usług świadczonych przez JavaEE wymaga kontenera JavaEE.

• Co możesz zrobić z JavaSE, czego nie możesz zrobić z JavaEE? Um ... nie wiem.

• Kiedy programista decyduje, że potrzebuje JavaEE? To pytanie jest całkowicie subiektywne ... Ale jeśli potrzebujesz którejkolwiek z usług dostarczanych przez JavaEE, zaczynasz o tym myśleć. Jeśli nie wiesz, czym jest JavaEE ... prawdopodobnie go nie potrzebujesz.

• Kiedy programista decyduje, że nie potrzebuje JavaEE? Zobacz poprzednią odpowiedź.

• Dlaczego wersja biblioteki JavaEE nie jest zsynchronizowana z wersją JavaSE? Dobre pytanie. Nie będę udawać, że wiem, jak na to odpowiedzieć ... Ale przypuszczam, że odpowiedź brzmi: „ponieważ nie są zsynchronizowane”.

Z lotu ptaka Java EE to platforma, czyli coś, na czym możemy budować.

Patrząc z bardziej technicznej perspektywy, standard Java Enterprise Edition definiuje zestaw interfejsów API powszechnie używanych do tworzenia aplikacji korporacyjnych. Te interfejsy API są implementowane przez serwery aplikacji - i tak, różne serwery aplikacji mogą korzystać z różnych implementacji API Java EE.

Jednak biblioteka java ee nie będzie działać ani kompilować, chyba że kod jest uruchamiany na serwerze aplikacji Java EE (takim jak JBoss, GlassFish, Tomcat itp.) Lub ma do niego dostęp.

Kompilujesz w oparciu o interfejsy API Java EE, więc potrzebujesz tych interfejsów API tylko w czasie kompilacji. W czasie wykonywania będziesz również potrzebować implementacji tych API, tj. Serwera aplikacji.

Dlaczego potrzebuję czegoś masywnego jako JBoss tylko do skompilowania prostego kodu do wysłania e-maila?

Ty nie. Jeśli jednak chcesz używać API Java EE do wysyłania poczty, będziesz potrzebować implementacji tego API w czasie wykonywania. Może to być dostarczone przez serwer aplikacji lub przez autonomiczną bibliotekę, którą dodajesz do ścieżki klas.

Dlaczego biblioteki Java EE nie są „standardowe” i są dołączane do zwykłego pobierania maszyny JVM i / lub zestawu SDK?

Ponieważ tylko interfejsy API są znormalizowane, a nie implementacje.

Dlaczego jest tak wiele ofert Java EE

Ponieważ ludzie nie zgadzają się co do właściwego sposobu implementacji niektórych funkcji. Ponieważ różni dostawcy konkurują o udział w rynku.

Co można zrobić z Java EE, czego nie można zrobić ze standardową Javą?

Ponieważ implementacje Java EE są zbudowane przy użyciu „standardowej Java”: nic. Jednak wykorzystanie istniejących bibliotek może zaoszczędzić wiele wysiłku w przypadku rozwiązywania typowych problemów przedsiębiorstwa, a użycie standardowego interfejsu API może zapobiec uzależnieniu od dostawcy.

Co można zrobić ze standardową Javą, czego nie można zrobić z Java EE?

Nic, ponieważ Java EE zawiera Java SE.

Kiedy programista decyduje, że „potrzebuje” Java EE? Kiedy programista decyduje, że nie potrzebuje Java EE?

Ogólnie rzecz biorąc, interfejsy API Java EE rozwiązują typowe, powtarzające się problemy w komputerach korporacyjnych. Jeśli masz takie problemy, zwykle warto zastosować standardowe rozwiązania - ale jeśli masz inne problemy, mogą być wymagane inne rozwiązania. Na przykład, jeśli chcesz rozmawiać z relacyjną bazą danych, powinieneś rozważyć użycie JPA. Ale jeśli nie potrzebujesz relacyjnej bazy danych, JPA ci nie pomoże.

Co to jest Java EE?

Zacznijmy od definicji kanoniczności na wiki:

Java Platform, Enterprise Edition lub Java EE to platforma obliczeniowa Java klasy korporacyjnej firmy Oracle. Platforma zapewnia interfejs API i środowisko wykonawcze do tworzenia i uruchamiania oprogramowania dla przedsiębiorstw, w tym usług sieciowych i internetowych oraz innych wielowarstwowych, skalowalnych, niezawodnych i bezpiecznych aplikacji sieciowych na dużą skalę.

Głównym punktem jest to, że Java EE jest platformą zapewniającą API, a nie jakąś konkretną bibliotekę.

Czego potrzeba do Java EE?

Głównym zakresem Java EE są aplikacje sieciowe, w przeciwieństwie do Java SE zorientowanych na tworzenie aplikacji desktopowych z prostą obsługą sieci. To jest główna różnica między nimi. Skalowalność, przesyłanie wiadomości, transakcje, obsługa baz danych dla każdej aplikacji ... potrzeba tego wszystkiego wzrosła wraz z ewolucją sieci. Oczywiście wiele gotowych rozwiązań, które dostarcza Java SE jest przydatnych przy tworzeniu sieci, więc Java EE rozszerza Java SE.

Dlaczego potrzebujemy serwerów aplikacji, aby uruchomić nasz kod?

Dlaczego potrzebujemy systemów operacyjnych? Ponieważ jest wiele bolesnej pracy ze sprzętem, którą musimy wykonać, aby stworzyć nawet najprostszą aplikację. A bez systemu operacyjnego musisz to robić wielokrotnie. Zbyt uproszczony system operacyjny to tylko kontener programistyczny, który zapewnia nam globalny kontekst do uruchamiania naszych aplikacji.

Tym właśnie są serwery aplikacji. Pozwalają nam uruchamiać nasze aplikacje w ich kontekście i zapewniają nam wiele funkcji wysokiego poziomu, które są potrzebne dla aplikacji sieciowych o dużym obciążeniu w przedsiębiorstwach. I nie chcemy pisać własnych rowerów, aby rozwiązać ten problem, chcemy napisać kod, który zaspokoi nasze potrzeby biznesowe.

Innym przykładem może być JVM dla języka Java.

Dlaczego Java EE nie zawiera wbudowanego serwera aplikacji?

Trudno mi powiedzieć. Myślę, że zrobiono to dla większej elastyczności. Java EE mówi, co powinni zrobić, decydują, jak to zrobić.

Dlaczego JVM nie zawiera Java EE?

Ponieważ kierowali się do różnych sektorów rynku. Java EE ma wiele funkcji, które nie są potrzebne na zwykłych komputerach stacjonarnych.

Dlaczego jest tak wiele ofert Java EE?

Ponieważ Java EE opisuje tylko zachowanie. Każdy może to wdrożyć.

Co można zrobić z Java EE, czego nie można zrobić z Java SE?

Podbić internet. Naprawdę trudno jest zrobić z apletami i gniazdami Java SE :)

Co można zrobić z Java SE, czego nie można zrobić z Java EE?

Jak wspomniano powyżej, Java EE rozszerza Java SE, więc dzięki Java EE powinieneś być w stanie zrobić wszystko, co jest dostępne dla Java SE.

Kiedy programista decyduje, że „potrzebuje” Java EE?

Gdy potrzebują mocy Java EE. Wszystko, co zostało wymienione powyżej.

Kiedy programista decyduje, że nie potrzebuje Java EE?

Kiedy piszą zwykłą aplikację konsolową lub komputerową.

Dlaczego wersje Java SE i Java EE nie są synchronizowane?

Java zawsze miała problemy z nazewnictwem i wersjonowaniem swoich technologii. Więc ta sytuacja nie jest wyjątkiem.

Java EE to koncepcja kontenera.
Kontener to kontekst wykonania, w którym będzie działać Twoja aplikacja i który zapewni ostatni zestaw usług. Każdy rodzaj usługi jest określony przez specyfikację o nazwie JSR. Na przykład JSR 907, JTA (Java transaction Api), które zapewniają standardowy sposób zarządzania rozproszonymi transakcjami na różnych zasobach.
Generalnie istnieje wiele różnych implementacji dla danego JSR, implementacja, z której będziesz korzystać, zależy od dostawcy kontenera, ale tak naprawdę nie masz nic przeciwko temu, ponieważ masz pewność, że zachowanie jest zgodne z predefiniowanym kontraktem: JSR API.
Aby skorzystać z Java EE, musisz uruchomić aplikację w kontenerze. Dwa główne to EJB i kontener serwletów, które są obecne na każdym serwerze aplikacji z certyfikatem Java EE.

Celem tego wszystkiego jest zdefiniowanie standardowego środowiska wykonawczego, aby umożliwić spakowanie aplikacji tylko z niezbędnymi elementami, id.est. Twój interes. Pozwala uniknąć polegania na nieznanym i różnym zestawie bibliotek innych firm, które w przeciwnym razie musiałbyś spakować i dostarczyć wraz z aplikacją, a które mogą być źródłem konfliktów z innymi aplikacjami na serwerze. W Java EE wiesz, że wszystkie standardowe wymagania niefunkcjonalne, takie jak bezpieczeństwo, transakcje, skalowalność, zdalne wywołanie i wiele innych, zostaną dostarczone przez kontener (podzielone na czynniki dla wszystkich działających w nim aplikacji) i po prostu musisz oprzeć swoją pracę na nim.