EJB nedir ve ne işe yarar?

EJBFasulyenin ne olduğunu, örneklerinin bir havuzda yönetilmesinin ne anlama geldiğini öğrenmeye çalışıyorum , falan filan. Onları gerçekten iyi kavrayamıyorum.

Bana gerçekte ne olduklarını açıklayabilir misiniz (neredeyse bir Java Programcısı için)? Onlar ne yapar? Amaçları neler? Neden onları gerçekten kullanıyorsunuz? (Neden sadece sadık kalmıyorsunuz POJO?) Belki örnek bir uygulama?

Lütfen yalnızca güncellenmiş bilgilere bakın EJB 3.1. EJB ile ilgili tarihli bilgiler yanıltıcı olabilir.

EJB öğrenmeye yeni başlayanlar için lütfen dikkat:

EJB, dağıtılmış nesnelere dayanır ; bu, bir ağ tarafından bağlanmış birden çok makinede (sanal veya fiziksel) çalışan yazılım parçalarına karşılık gelir .

Neden onları gerçekten kullanıyorsunuz? (Neden sadece POJO'ya bağlı kalmıyorsun?)

Veritabanına erişen veya diğer bağlantı / dizin kaynaklarına erişen veya birden çok istemciden erişilen veya SOA hizmeti olarak tasarlanmış bir bileşene ihtiyacınız varsa, bugün EJB'ler genellikle "daha büyük, daha güçlü, daha hızlı (veya en azından daha ölçeklenebilir) ve POJO'lardan daha basit ". Web veya kurumsal ağ üzerinden çok sayıda kullanıcıya hizmet vermek için en değerlidir ve bir departmandaki küçük uygulamalar için biraz daha az değerlidir.

1. Gevşek Kaplin ile birden fazla uygulama / istemcide Mantık Yeniden / Paylaşım.
   EJB'ler kendi kavanozlarında paketlenebilir, yerleştirilebilir ve birçok yerden çağrılabilir. Bunlar ortak bileşenlerdir. Doğru, POJO'lar (dikkatlice!) Kütüphane olarak tasarlanabilir ve kavanoz olarak paketlenebilir. Ancak EJB'ler, yerel java arayüzü, şeffaf RMI, JMS zaman uyumsuz mesajı ve SOAP / REST web hizmeti dahil olmak üzere hem yerel hem de uzak ağ erişimini destekler ve çoklu (tutarsız?) Dağıtımlarla kes ve yapıştır jar bağımlılıklarından tasarruf sağlar.
   SOA hizmetleri oluşturmak için çok kullanışlıdırlar. Yerel erişim için kullanıldığında bunlar POJO'lardır (ücretsiz konteyner hizmetleri eklenmiştir). Ayrı bir EJB katmanı tasarlama eylemi, kapsülleme, gevşek bağlantı ve uyumu en üst düzeye çıkarmak için ekstra bakımı teşvik eder ve arayanları karmaşık işleme ve veri modellerinden koruyan temiz bir arayüzü (Cephe) teşvik eder.

2. Ölçeklenebilirlik ve Güvenilirlik Çeşitli çağrı iletileri / süreçleri / iş parçacıklarından çok sayıda istek uygularsanız, bunlar önce havuzdaki kullanılabilir EJB örnekleri arasında dağıtılır ve sıraya alınır. Bu, saniyede gelen isteklerin sayısının sunucunun işleyebileceğinden daha fazla olması durumunda, nazikçe bozunduğumuz anlamına gelir - her zaman bazı isteklerin verimli bir şekilde işlenmesi ve fazla taleplerin beklenmesi sağlanır. TÜM isteklerin aynı anda korkunç yanıt süresi yaşadığı sunucu "erimesine" ulaşmıyoruz, ayrıca sunucu donanım ve işletim sisteminin üstesinden gelebileceğinden ve dolayısıyla çökmelerden daha fazla kaynağa erişmeye çalışıyor. EJB'ler, kümelenebilen ayrı bir katmana yerleştirilebilir - bu, bir sunucudan diğerine yük devretme yoluyla güvenilirlik sağlar, ayrıca doğrusal olarak ölçeklemek için donanım eklenebilir.

3. Eşzamanlılık Yönetimi. Kapsayıcı, EJB örneklerine birden çok istemci tarafından otomatik olarak güvenli bir şekilde (seri olarak) erişilmesini sağlar. Kapsayıcı EJB havuzunu, iş parçacığı havuzunu, çağırma kuyruğunu yönetir ve yöntem düzeyinde yazma kilitleme (varsayılan) veya okuma kilitleme (@Lock (READ) aracılığıyla) otomatik olarak gerçekleştirir. Bu, eşzamanlı yazma-yazma çakışmalarıyla verileri bozulmaya karşı korur ve okuma-yazma çakışmalarını önleyerek verilerin tutarlı bir şekilde okunmasına yardımcı olur.
   Bu temelde, çekirdeğin istemci arayanlar arasında ortak durumu manipüle ettiği ve paylaştığı @Singleton oturum çekirdekleri için kullanışlıdır. Bu, eşzamanlı kod yürütme ve veri erişimi için gelişmiş senaryoları manuel olarak yapılandırmak veya programlı olarak kontrol etmek için kolayca geçersiz kılınabilir.

4. Otomatik işlem yönetimi.
   Hiçbir şey yapmayın ve tüm EJB yöntemleriniz bir JTA işleminde çalıştırılır. Bir veritabanına JPA veya JDBC kullanarak erişirseniz, otomatik olarak işleme kaydedilir. JMS ve JCA çağrıları için aynıdır. Bir yöntemden önce @TransactionAttribute (someTransactionMode) öğesini belirtin, bu yöntemin JTA işleminde ayrışıp ayrışmayacağını / nasıl ayrıldığını belirleme ve varsayılan modu geçersiz kılma: "Gerekli".

5. Enjeksiyon yoluyla çok basit kaynak / bağımlılık erişimi.
   Kapsayıcı kaynakları arar ve kaynak referanslarını EJB'deki örnek alanları olarak ayarlar: örneğin JNDI depolanan JDBC bağlantıları, JMS bağlantıları / konuları / kuyrukları, diğer EJB'ler, JTA İşlemleri, JPA varlık yöneticisi kalıcılık bağlamları, JPA varlık yöneticisi fabrika kalıcılık birimleri ve JCA adaptör kaynakları. örneğin, başka bir EJB ve bir JTA İşlemi ve bir JPA varlık Yöneticisi ve bir JMS bağlantı fabrikası ve kuyruğuna referans oluşturmak için:

   @Stateless
   public class MyAccountsBean {
   
       @EJB SomeOtherBeanClass someOtherBean;
       @Resource UserTransaction jtaTx;
       @PersistenceContext(unitName="AccountsPU") EntityManager em;
       @Resource QueueConnectionFactory accountsJMSfactory;
       @Resource Queue accountPaymentDestinationQueue;
   
       public List<Account> processAccounts(DepartmentId id) {
           // Use all of above instance variables with no additional setup.
           // They automatically partake in a (server coordinated) JTA transaction
       }
   }
   

   Bir Sunucu Uygulaması, basitçe bir örnek değişkeni bildirerek bu çekirdeği yerel olarak çağırabilir:

   @EJB MyAccountsBean accountsBean;    
   

   ve sonra sadece 'yöntemlerini istendiği gibi çağırıyoruz.

6. JPA ile akıllı etkileşim. Varsayılan olarak, yukarıdaki gibi enjekte edilen EntityManager, işlem kapsamındaki bir kalıcılık bağlamı kullanır. Bu durum, durum bilgisi olmayan oturum çekirdekleri için mükemmeldir. (Durum bilgisi olmayan) bir EJB yöntemi çağrıldığında, yeni işlem içinde yeni bir kalıcılık bağlamı oluşturulur, DB'ye alınan / DB'ye yazılan tüm varlık nesnesi örnekleri yalnızca bu yöntem çağrısı içinde görünür ve diğer yöntemlerden yalıtılır. Ancak yöntem tarafından diğer durumsuz EJB'ler çağrılırsa, kap aynı PC'yi çoğaltır ve paylaşır, böylece aynı varlıklar aynı işlemde bilgisayar aracılığıyla otomatik olarak tutarlı bir şekilde paylaşılır.
   Bir @Stateful oturum çekirdeği bildirilirse, entityManager'ı genişletilmiş bir kapsam olarak bildirerek JPA ile eşit akıllı yakınlık elde edilir: @PersistentContent (unitName = "AccountsPU, type = EXTENDED). birden fazla fasulye çağrısı ve işleminde, daha önce alınmış / yazılmış DB varlıklarının bellek içi kopyalarının önbelleğe alınması, böylece yeniden alınması gerekmez.

7. Yaşam döngüsü yönetimi. EJB'lerin yaşam döngüsü konteyner tarafından yönetilir. Gerektiğinde, EJB örnekleri oluşturur, durumlu oturum fasulye durumunu temizler ve başlatır, pasifleştirir ve etkinleştirir ve yaşam döngüsü geri arama yöntemlerini çağırır, böylece EJB kodu, kaynakları almak ve serbest bırakmak veya diğer başlatma ve kapatma davranışlarını gerçekleştirmek için yaşam döngüsü işlemlerine katılabilir. Ayrıca tüm istisnaları yakalar, bunları günlüğe kaydeder, işlemleri gerektiği gibi geri alır ve gerektiğinde yeni EJB istisnaları veya @ApplicationExceptions atar.

8. Güvenlik Yönetimi. EJB'lere rol tabanlı erişim kontrolü, basit bir ek açıklama veya XML ayarı aracılığıyla yapılandırılabilir. Sunucu, kimliği doğrulanmış kullanıcı ayrıntılarını her çağrı ile birlikte güvenlik bağlamı (çağrı sorumlusu ve rolü) olarak otomatik olarak iletir. Tüm RBAC kurallarının otomatik olarak uygulanmasını sağlar, böylece yöntemler yanlış rol tarafından yasadışı olarak çağrılamaz. EJB'lerin ekstra programlı kontrol için kullanıcı / rol ayrıntılarına kolayca erişmesini sağlar. Ek güvenlik işlemlerini (hatta IAM araçlarını) kaba standart bir şekilde takmayı sağlar.

9. Standardizasyon ve Taşınabilirlik. EJB uygulamaları Java EE standartlarına ve kodlama kurallarına uygundur, kalite ve anlayış ve bakım kolaylığı sağlar. Ayrıca, hepsinin aynı standart özellikleri ve davranışları desteklemesini sağlayarak ve geliştiricilerin yanlışlıkla tescilli
   taşınabilir olmayan satıcı özelliklerini benimsemelerini önleyerek kodun yeni satıcı uygulama sunucularına taşınabilirliğini destekler .

10. Gerçek Kicker: Basitlik. Yukarıdakilerin tümü, Java EE 6 içindeki EJB'ler için varsayılan ayarları kullanarak veya birkaç ek açıklama ekleyerek çok akıcı bir kodla yapılabilir. Kendi POJOs kurumsal / endüstriyel gücü özelliklerini Kodlama olacağını yolu daha korku pek karmaşık ve hataya açık. EJB'lerle kodlamaya başladığınızda, geliştirilmeleri ve büyük bir "serbest sürüş" avantajları seti sağlamaları oldukça kolaydır.

10 yıl önceki orijinal EJB spesifikasyonunda, EJB'ler büyük bir verimlilik sorunu yaşadı. Şişirildiler, çok sayıda kod ve yapılandırma artefaktına ihtiyaç duydular ve yukarıdaki faydaların yaklaşık 2 / 3'ünü sağladılar. Çoğu web projesi aslında bunları kullanmamıştır. Ancak bu, 10 yıllık tweaking, revizyon, fonksiyonel geliştirme ve geliştirme akış astarı ile önemli ölçüde değişti. Java EE 6'da maksimum düzeyde endüstriyel güç ve kullanım kolaylığı sağlarlar.

Ne gibi değil ?? :-) :-)

EJB, iş mantığını içeren, bir kapsayıcıda dağıttığınız ve ek açıklamalar sayesinde kapsayıcı tarafından sağlanan teknik hizmetlerden genellikle bildirici bir şekilde yararlanan bir Java bileşenidir:

• işlem yönetimi: bir işlem EJB'nin bir yöntemi çağrılmadan önce otomatik olarak başlatılabilir ve bu yöntem geri döndükten sonra işlenir veya geri alınır. Bu işlemsel bağlam, diğer EJB'lere yapılan çağrılara yayılır.
• güvenlik yönetimi: arayanın yöntemi yürütmek için gerekli rollere sahip olup olmadığını kontrol edebilir.
• bağımlılık enjeksiyonu: diğer EJB'ler veya JPA varlık yöneticisi, JDBC veri kaynağı vb. kaynaklar EJB'ye enjekte edilebilir.
• eşzamanlılık: kapsayıcı, aynı anda yalnızca bir iş parçacığının EJB örneğinizin bir yöntemini çağırmasını sağlar.
• dağıtım: Bazı EJB'ler başka bir JVM'den uzaktan çağrılabilir.
• yük devretme ve yük dengeleme: EJB'lerinizin uzak istemcileri gerektiğinde çağrılarının otomatik olarak başka bir sunucuya yönlendirilmesini sağlayabilir.
• kaynak yönetimi: durum bilgisi olan fasulye, sunucunuzun bellek tüketimini sınırlamak için otomatik olarak diske pasifleştirilebilir.
• ... muhtemelen bazı noktaları unuttum.

Umarım Oracle doc bu benim gibi birinin EJB konusunu basit bir şekilde anlamasına yardımcı olacaktır.

Kurumsal Fasulye Nedir? Java programlama dilinde yazılan bir kurumsal fasulye, bir uygulamanın iş mantığını kapsülleyen sunucu tarafı bir bileşendir. İş mantığı, uygulamanın amacını yerine getiren koddur. Örneğin, bir envanter kontrol uygulamasında işletme çekirdekleri, iş mantığını checkInventoryLevel ve orderProduct adı verilen yöntemlerde uygulayabilir. Bu yöntemleri çağırarak istemciler, uygulamanın sağladığı envanter hizmetlerine erişebilir.

Kuru Fasulye Faydaları Çeşitli nedenlerden dolayı, kuru fasulye büyük, dağıtılmış uygulamaların geliştirilmesini kolaylaştırır. Birincisi, EJB konteyneri kurumsal fasulyelere sistem düzeyinde hizmetler sağladığı için, fasülye geliştiricisi iş problemlerini çözmeye odaklanabilir. Fasulye geliştiricisi yerine EJB konteyneri, işlem yönetimi ve güvenlik yetkilendirmesi gibi sistem seviyesi hizmetlerden sorumludur.

İkincisi, istemciler yerine fasulye uygulamanın iş mantığını içerdiğinden, istemci geliştirici istemcinin sunumuna odaklanabilir. İstemci geliştiricisinin iş kurallarını uygulayan veya veritabanlarına erişen rutinleri kodlaması gerekmez. Sonuç olarak, müşteriler daha incedir, bu özellikle küçük cihazlarda çalışan istemciler için önemli bir avantajdır.

Üçüncüsü, kurumsal fasulye taşınabilir bileşenler olduğu için, uygulama birleştiricisi mevcut çekirdeklerden yeni uygulamalar oluşturabilir. Bu uygulamalar, standart API'leri kullanmaları koşuluyla, uyumlu herhangi bir Java EE sunucusunda çalışabilir.

Kurumsal Fasulye Ne Zaman Kullanılmalı Uygulamanız aşağıdaki koşullardan birine sahipse kurumsal fasulye kullanmayı düşünmelisiniz:

Uygulama ölçeklenebilir olmalıdır. Artan sayıda kullanıcıya uyum sağlamak için bir uygulamanın bileşenlerini birden çok makineye dağıtmanız gerekebilir. Bir uygulamanın işletme fasulyesi sadece farklı makinelerde çalışamaz, aynı zamanda konumları müşterilere şeffaf kalacaktır.

İşlemler veri bütünlüğünü sağlamalıdır. Kurumsal fasulye, paylaşılan nesnelerin eşzamanlı erişimini yöneten mekanizmaları, işlemleri destekler.

Uygulama müşterileri çeşitli olacak. Sadece birkaç satır kodla, uzak istemciler kurumsal fasulyeleri kolayca bulabilir. Bu müşteriler ince, çeşitli ve sayısız olabilir.

Beni en çok ilgilendiren soru onları nasıl ve nerede kullanabilirim. Bunu anlamak için önce ne tür EJB'lerin var olduğunu görmemiz gerekir. 2 büyük kategori vardır:

1. Oturum fasulyeleri
2. Mesaj güdümlü fasulye

Bakla Fasulye. Bunlar 3 çeşittir:

1. Durum bilgisi olan - bu bileşenler durumu korur ve birden fazla istekte bulunan bir istemciye özgüdür. Bir oturum olarak görün. Bunların hemen kullanılabileceği dükkanlar veya diğer oturum türleri (giriş oturumu vb.)
2. Vatansız - bunlar, istekler arasında bilgi saklamayan, ancak kullanıcıya özgü olan bağımsız bileşenlerdir. Akla gelen derhal kullanım - Servis katmanındaki servis sınıfları . Hayal edin OrderService. Bunlar için bir başka büyük kullanım web hizmetlerini ortaya çıkarmaktır. Yine, bu Hizmet katmanında veya tamamen ayrı olmalıdır.
3. Singleton - bunlar uygulama başına var olan ve bir kez yaratılan ve birden çok kez tekrar kullanılabilen / erişilebilen çekirdeklerdir. ConfigurationBileşen hemen akla geliyor - burada uygulama düzeyi yapılandırmalarını depolayabilir ve ihtiyacınız olduğunda onlara erişebilirsiniz.

Artık diğer özellikler veya özellikler bu gibi durumlarda katmanlar arasında kullanılabilir:

• Güvenlik - çağrılan yöntem hakkında ek açıklama içeren izinleri kontrol edebilirsiniz. Bu, Hizmet katmanında ve isterseniz Denetleyicide de olabilir.
• İşlem yönetimi - Bu, Hizmet katmanında veya Kalıcılık katmanında belirgin bir adaydır
• Bağımlılık Enjeksiyonu - yine her yerde kullanılacak

Modern zamanlarda en büyük kullanımlardan biri Mikro Hizmetler ve Servis Odaklı Mimarilerdir. Bazı iş mantığı bileşenlerini EJB olarak paketleyebilir ve bunları birden çok istemci tarafından kullanılmak üzere kuruluşa dağıtabilirsiniz (burada müşteri tarafından diğer arka uç uygulamaları kastediyorum).

Ve bunun gibi. Şimdi en büyük dezavantajı, EJB kapsayıcısına çok bağımlı olmanız ve 2 referans uygulaması arasında geçiş yapabilmenize rağmen, daha hafif bir şeye geçemeyeceksiniz - örneğin Tomcat. Ama neden tüm faydaları feda etmek istersiniz?