Java EE gerçekten nedir? [kapalı]

Java EE'nin etrafında genç Java geliştiricileri için bu "gizemli örtü" var - bir süredir çok az bir başarı ile kendimi kaldırmaya çalışıyorum.

Karışıklık şunlardan kaynaklanır:

• Java EE hem bir kitaplık hem de bir platform gibi görünmektedir - Java EE kitaplığını "almanın" birden çok yolu vardır, tipik olarak Oracle'ın Java EE SDK indirmesi gibi bir şeyden. Ancak, kodunuz bir Java EE uygulama sunucusunda (JBoss, GlassFish, Tomcat, vb.) Çalıştırılmadıkça veya erişime sahip olmadıkça Java EE kitaplığı çalışmayacak veya derlenmeyecektir. Neden? Kitaplıklar, uygulama sunucusu ortamının dışında çalışamaz mı? Bir e-posta göndermek için basit bir kod derlemek için neden JBoss kadar büyük bir şeye ihtiyacım var?

• Java EE kitaplıkları neden "standart" değil ve normal JVM indirme ve / veya SDK'ya dahil edildi?

• Standart Java'nın gerçekten yalnızca iki ana çeşidi varken (Oracle JVM / SDK | OpenJDK JVM / JDK) neden bu kadar çok Java EE teklifi var?

• Java EE ile standart Java ile yapamayacakları neler yapılabilir?

• Standart Java ile Java EE ile yapamayacakları neler yapılabilir?

• Bir geliştirici, Java EE'ye "ihtiyaç duyduklarına" ne zaman karar verir?

• Bir geliştirici ne zaman Java EE'ye ihtiyaç duymadıklarına karar verir?

• Java EE kitaplığı sürümü neden standart Java kitaplığı sürümleriyle (Java EE 6 vs. Java 7) senkronize değil?

Kırbaçları temizlememe yardım ettiğin için teşekkürler!

Kitaplıklar neden uygulama sunucusu ortamının dışında çalışamıyor?

Aslında yapabilirler. Kütüphanelerin çoğu doğrudan bağımsız olarak kullanılabilir (Java SE'de) veya bir .war'a dahil edilebilir (pratikte neredeyse her zaman Tomcat budur). Java EE'nin JPA gibi bazı kısımları, kendi spesifikasyonlarında Java SE'de nasıl çalışması ve kullanılması gerektiğini anlatan açık bölümlere sahiptir.

Bir şey varsa, burada söz konusu olan bir uygulama sunucusu ortamı değil, diğer tüm kitaplıkların varlığı ve onları birleştiren entegrasyon kodu.

Bu nedenle, ek açıklamalar bu taramayı kendi başına yapan her kitaplık (EJB, JPA, vb.) Yerine tüm sınıflarınız için yalnızca bir kez taranacaktır. Ayrıca bu nedenle, CDI ek açıklamaları EJB çekirdeklerine uygulanabilir ve bunlara JPA varlık yöneticileri enjekte edilebilir.

Bir e-posta göndermek için basit bir kod derlemek için neden JBoss kadar büyük bir şeye ihtiyacım var?

Bu soruda yanlış olan birkaç şey var:

1. Derlemek için yalnızca Web Profili için 1MB'nin altında ve tam profil için 1MB'nin biraz üzerinde olan API kavanozuna ihtiyacınız vardır.
2. Çalıştırmak için tabii ki bir uygulamaya ihtiyacınız var, ancak "büyük" şeyler abartıyor. Örneğin OpenJDK yaklaşık 75MB'dir ve TomEE (posta desteği içeren bir Web Profili uygulaması) yalnızca 25MB'dir. GlassFish bile (Tam Profil uygulaması) yalnızca 53MB'dir.
3. Mail, Java SE'den (ve dolayısıyla Tomcat'ten) ve bağımsız mail.jar ve activation.jar kullanılarak mükemmel şekilde çalışır .

Java EE kitaplıkları neden "standart" değil ve normal JVM indirme ve / veya SDK'ya dahil edildi?

Java EE bir bakıma, zaten çok büyük olan JDK'yı yönetimi ve indirmesi daha kolay parçalara ayırmaya yönelik ilk girişimlerden biriydi. İnsanlar, grafiksel sınıfların (AWT, Swing) ve Applet'lerin, başsız bir sunucuda bazı komutları çalıştırmak olduğu zaman JRE'nin içinde olduğundan şikayet ediyorlar. Ve sonra tüm Java EE kitaplıklarını standart JDK'ya dahil etmek mi istiyorsunuz?

Modülerlik desteğinin nihai sürümüyle birlikte, paketler olarak ayrı ayrı kurulabilen birçok şeyin bulunduğu küçük bir temel JRE'ye sahip olacağız. Belki bir gün Java EE'yi oluşturan birçok veya hatta tüm sınıflar da böyle bir paket olacaktır. Zaman gösterecek.

Standart Java'nın gerçekten yalnızca iki ana çeşidi varken (Oracle JVM / SDK | OpenJDK JVM / JDK) neden bu kadar çok Java EE teklifi var?

Java SE'nin ikiden fazla çeşidi vardır. En azından IBM JDK, önceki BEA olanı (satın alma nedeniyle Oracle / Sun ile birleştirilen JRocket), çeşitli diğer açık kaynak uygulamaları ve yerleşik kullanım için bir dizi uygulama var.

Java SE ve EE'nin bir şartname olmasının nedeni, birçok satıcı ve kuruluşun bunu uygulayabilmesidir ve bu nedenle rekabeti teşvik eder ve satıcıya bağımlı kalma riskini azaltır.

C ++ standardına bağlı kalmanın yanı sıra birçok rakip teklifinizin olduğu C ve C ++ derleyicileriyle gerçekten farklı değil.

Java EE kitaplığı sürümü neden standart Java kitaplık sürümleriyle (Java EE 6 vs. Java 7) senkronize değil

Java EE, Java SE üzerine kurulur, bu yüzden geride kalır. Versiyonlar yine de örtüşüyor. Java EE 5, Java SE 5 gerektirir. Java EE 6, Java SE 6 vb. Gerektirir. Sadece Java SE X mevcut olduğunda, Java EE X-1 günceldir.

İşte sorularınıza hızlı bir şekilde oluşturulmuş birkaç cevap ...

• JavaEE kitaplıkları neden bir uygulama sunucusu olmadan çalışamaz? JavaEE tarafından sağlanan hizmetler (konteyner yönetimli işlemler, konteyner tarafından yönetilen bağımlılık enjeksiyonu, zamanlayıcı servisi, vb.) Doğası gereği JavaEE uyumlu Uygulama Sunucularını içerir (örneğin: GlassFish, JBoss, WebSphere, vb.). Bu nedenle, JavaEE kitaplıkları böyle bir kap olmadan hiçbir amaca hizmet etmez. " Bir e-posta göndermek için basit bir kod derlemek için neden JBoss kadar büyük bir şeye ihtiyacım var? " JavaEE olmadan e-posta göndermenin yolları vardır ... Ancak bunu JavaEE yöntemiyle yapmak istiyorsanız, bir JavaEE kapsayıcısına ihtiyacınız vardır.

• JavaEE kitaplıkları JavaSE indirmesine neden dahil değil? Pek çok kütüphanenin dahil edilmemesinin nedeni: aşırı olur. JavaEE kitaplıklarını bir uygulama sunucusu olmadan bile kullanamayacağınıza göre, neden onları dahil etmeye zahmet edesiniz? Bir geliştirici bir uygulama sunucusu yüklediğinde ve JavaEE kullanmaya karar verdiğinde JavaEE indirilmelidir.

• Neden bu kadar çok JavaEE teklifi var? Gerçekten " çok fazla " JavaEE teklifi var mı? Eğer öyleyse, lütfen bazılarını listeleyin. Daha doğrusu , aynı API'lerin birden çok uygulaması olduğuna inanıyorum .

• Standart Java olmadan yapamayacakları JavaEE ile neler yapılabilir? Çok. JavaEE olmadan işlemleri veya kalıcılık bağlamlarını yönetmek için bir uygulama sunucusuna güvenemezsiniz. Bir uygulama sunucusunun JavaEE olmadan EJB bağımlılık enjeksiyonunu yönetmesine izin veremezsiniz. JavaEE olmadan uygulama tarafından yönetilen bir zamanlayıcı hizmetini kullanamazsınız. Bu sorunun cevabı ilk sorunun cevabını oldukça açık hale getirmelidir ... JavaEE tarafından sağlanan hizmetlerin çoğu bir JavaEE konteyneri gerektirir.

• JavaEE ile yapamadığınız JavaSE ile neler yapabilirsiniz? Um ... bilmiyorum.

• Bir geliştirici JavaEE'ye ihtiyaç duyduklarına ne zaman karar verir ? Bu soru tamamen özneldir ... Ancak JavaEE tarafından sağlanan hizmetlerden herhangi birine ihtiyacınız olursa, düşünmeye başlarsınız. JavaEE'nin ne olduğunu bilmiyorsanız ... muhtemelen ihtiyacınız yoktur.

• Bir geliştirici JavaEE'ye ihtiyaçları olmadığına ne zaman karar verir? Önceki cevaba bakın.

• JavaEE kitaplığı sürümü neden JavaSE sürümüyle senkronize değil? İyi soru. Nasıl cevaplayacağımı biliyormuş gibi yapmayacağım ... Ama cevabın "çünkü senkronize olmadıkları için" olduğunu tahmin ediyorum.

Kuşbakışı bakıldığında, Java EE bir platformdur, yani üzerine inşa edebileceğimiz bir şeydir.

Daha teknik bir bakış açısıyla, Java Enterprise Edition standardı, kurumsal uygulamalar oluşturmak için yaygın olarak kullanılan bir dizi API'yi tanımlar. Bu API'ler, uygulama sunucuları tarafından uygulanır - ve evet, farklı uygulama sunucuları, Java EE API'lerinin farklı uygulamalarını kullanma özgürlüğüne sahiptir.

Ancak, kodunuz bir Java EE uygulama sunucusunda (JBoss, GlassFish, Tomcat, vb.) Çalıştırılmadıkça veya erişime sahip olmadıkça java ee kitaplığı çalışmayacak veya derlenmeyecektir.

Java EE API'lerine karşı derleme yaparsınız, bu nedenle bu API'lere yalnızca derleme zamanında ihtiyaç duyarsınız. Çalışma zamanında, bu API'lerin bir uygulamasına, yani bir uygulama sunucusuna da ihtiyacınız olacak.

Bir e-posta göndermek için basit bir kod derlemek için neden JBoss kadar büyük bir şeye ihtiyacım var?

Yapmıyorsun. Ancak, posta göndermek için Java EE API kullanmak isterseniz, çalışma zamanında bu API'nin uygulanmasına ihtiyacınız olacaktır. Bu, bir uygulama sunucusu tarafından veya sınıf yolunuza eklediğiniz bağımsız bir kitaplık tarafından sağlanabilir.

Java EE kitaplıkları neden "standart" değil ve normal JVM indirme ve / veya SDK'ya dahil edildi?

Çünkü uygulamalar değil, yalnızca API'ler standartlaştırılmıştır.

Neden bu kadar çok Java EE teklifi var?

Çünkü insanlar belirli özellikleri uygulamanın doğru yolu konusunda hemfikir değiller. Çünkü farklı satıcılar pazar payı için rekabet ediyor.

Java EE ile standart Java ile yapamayacakları neler yapılabilir?

Java EE uygulamaları "standart Java" ile oluşturulduğundan beri: Hiçbir şey. Bununla birlikte, tipik kurumsal sorunları çözüyorsanız, mevcut kitaplıklardan yararlanmak büyük bir çabadan tasarruf sağlayabilir ve standartlaştırılmış bir API kullanmak, satıcıya bağımlı kalmayı önleyebilir.

Standart Java ile Java EE ile yapamayacakları neler yapılabilir?

Hiçbir şey, çünkü Java EE, Java SE'yi içeriyor.

Bir geliştirici, Java EE'ye "ihtiyaç duyduklarına" ne zaman karar verir? Bir geliştirici ne zaman Java EE'ye ihtiyaç duymadıklarına karar verir?

Genel olarak konuşursak, Java EE API'leri kurumsal bilgi işlemdeki tipik, tekrar eden sorunları çözer. Bu tür sorunlarınız varsa, genellikle standart çözümleri kullanmak mantıklıdır - ancak farklı sorunlarınız varsa, farklı çözümler aranabilir. Örneğin, ilişkisel bir veritabanıyla konuşmanız gerekiyorsa, JPA kullanmayı düşünmelisiniz. Ancak ilişkisel bir veritabanına ihtiyacınız yoksa, JPA size yardımcı olmaz.

Java EE nedir?

Wiki'deki kanonisite tanımından başlayalım:

Java Platform, Enterprise Edition veya Java EE, Oracle'ın kurumsal Java bilgi işlem platformudur. Platform, ağ ve web hizmetleri ve diğer büyük ölçekli, çok katmanlı, ölçeklenebilir, güvenilir ve güvenli ağ uygulamaları dahil olmak üzere kurumsal yazılım geliştirmek ve çalıştırmak için bir API ve çalışma zamanı ortamı sağlar.

Buradaki ana nokta, Java EE'nin somut bir kitaplık değil, bir API sağlayan bir platform olmasıdır.

Java EE için neye ihtiyaç var?

Java EE'nin ana kapsamı, basit ağ desteği ile masaüstü uygulamaları geliştirmeye yönelik Java SE'den farklı olarak ağ tabanlı uygulamalardır. Bu, aralarındaki temel farktır. Ölçeklenebilirlik, mesajlaşma, işlem, her uygulama için DB desteği ... Ağın evrimi ile tüm bunlara olan ihtiyaç artmıştır. Elbette, Java SE'nin sağladığı birçok hazır çözüm ağ geliştirme için kullanışlıdır, bu nedenle Java EE, Java SE'yi genişletir.

Kodumuzu çalıştırmak için neden uygulama sunucularına ihtiyacımız var?

Neden işletim sistemlerine ihtiyacımız var? Çünkü en basit uygulamayı bile yapmamız gereken donanımla ilgili çok fazla zahmetli iş var. Ve işletim sistemi olmadan bunu tekrar tekrar yapmanız gerekir. Aşırı basitleştirilmiş işletim sistemi, uygulamalarımızı çalıştırmak için bize küresel bir bağlam sağlayan programatik bir kapsayıcıdır.

Ve uygulama sunucuları da budur. Uygulamalarımızı kendi bağlamlarında çalıştırmamıza izin verir ve bize kurumsal yüksek yüklü ağ uygulamaları için gerekli olan çok sayıda üst düzey işlevsellik sağlar. Ve bu sorunları çözmek için kendi bisikletlerimizi yazmak istemiyoruz, iş ihtiyaçlarımızı karşılayacak kodlar yazmak istiyoruz.

Buradaki başka bir örnek Java için JVM olabilir.

Java EE neden yerleşik uygulama sunucusu içermiyor?

Benim için söylemesi zor. Sanırım daha fazla esneklik için yapıldı. Java EE ne yapmaları gerektiğini söylüyor, nasıl yapacaklarına onlar karar veriyor.

JVM neden Java EE'yi içermiyor?

Çünkü farklı pazar sektörlerine yöneldiler. Java EE, normal masaüstü bilgisayarlar için gerekmeyen bir dizi işlevselliğe sahiptir.

Neden bu kadar çok Java EE teklifi var?

Çünkü Java EE yalnızca davranışı tanımlar. Herkes uygulayabilir.

Java SE ile yapamayacakları Java EE ile neler yapılabilir?

İnterneti fethetmek için. Java SE uygulamaları ve soketleri ile yapmak gerçekten zor :)

Java EE ile yapamayacakları Java SE ile ne yapılabilir?

Yukarıda belirtildiği gibi Java EE, Java SE'yi genişletir, bu nedenle Java EE ile Java SE için mevcut olan her şeyi yapabilmelisiniz.

Bir geliştirici, Java EE'ye "ihtiyaç duyduklarına" ne zaman karar verir?

Java EE'nin gücüne ihtiyaç duyduklarında. Yukarıda bahsedilenlerin tümü.

Bir geliştirici ne zaman Java EE'ye ihtiyaç duymadıklarına karar verir?

Normal bir konsol veya masaüstü uygulaması yazdıklarında.

Java SE ve Java EE'nin sürümleri neden eşitlenmemiş?

Java her zaman teknolojilerinin adlandırılması ve sürümlendirilmesiyle ilgili sorunlar yaşadı. Yani bu durum bir istisna değildir.

Java EE tamamen konteyner konseptiyle ilgilidir.
Kapsayıcı, uygulamanızı çalıştıracak ve bu son bir dizi hizmeti sağlayan bir yürütme bağlamıdır. Her hizmet türü, JSR adlı bir belirtimle tanımlanır. Örneğin, farklı kaynaklara karşı dağıtılmış işlemi yönetmek için standart bir yol sağlayan JSR 907, JTA (java işlem Api).
Belirli bir JSR için genellikle birçok farklı uygulama vardır, kullanacağınız uygulama kapsayıcı sağlayıcıya bağlıdır, ancak davranışın önceden tanımlanmış sözleşmeye, JSR API'sine uygun olduğundan emin olduğunuz için bunu gerçekten önemsemezsiniz.
Dolayısıyla, Java EE'den yararlanmak için uygulamanızı bir konteyner içinde çalıştırmanız gerekir. Bunlardan ikisi, herhangi bir Java EE sertifikalı uygulama sunucusunda bulunan EJB ve sunucu uygulaması kapsayıcısıdır.

Tüm bunların amacı, uygulamanızı yalnızca gerekli olan id.est ile paketlemeye izin verecek standart bir yürütme ortamı tanımlamaktır. senin işin. Aksi takdirde uygulamanızı paketlemeniz ve sağlamanız gereken ve sunucudaki diğer uygulamalarla çatışma kaynakları olabilecek bilinmeyen ve çeşitli üçüncü taraf kitaplıklarına bağlı olmaktan kaçınır. Java EE'de, güvenlik, işlem, ölçeklenebilirlik, uzaktan çağırma ve daha pek çoğu gibi işlevsel olmayan tüm standart gereksinimlerin kapsayıcı tarafından sağlanacağını (içinde çalışan tüm uygulamalar için faktörize edilmiş) biliyorsunuz ve işinizi buna dayandırmanız yeterli.