EJB nedir? Kurumsal JavaBeans'in evrimi

Kurumsal JavaBeans (EJB), Java platformunda büyük ölçekli, dağıtılmış iş uygulamaları geliştirmek için bir özelliktir. EJB 1.0, 1998'de piyasaya sürüldü. En güncel sürüm olan EJB 3.2.3, Jakarta EE'ye dahil edilmek üzere kabul edildi ve Jakarta Enterprise Beans olarak yeniden adlandırılacak.

EJB mimarisi

EJB mimarisi üç ana bileşenden oluşur: kurumsal çekirdekler (EJB'ler), EJB konteyneri ve Java uygulama sunucusu. EJB'ler bir EJB kapsayıcısı içinde çalışır ve EJB kabı bir Java uygulama sunucusu içinde çalışır.

İki tür EJB vardır - oturum fasulye ve mesaj odaklı fasulye:

  • Oturum çekirdekleri , istemci tarafından çağrılır ve işlemler ve kaynak yönetimi gibi kurumsal işlevselliği, istemciye programlı olarak kullanılabilir hale getirir.
  • Mesaj güdümlü fasulye ayrıca kurumsal işlevselliği de kapsüller ve sunar, ancak bunlar eşzamansız ve olay güdümlüdür. Mesaj güdümlü fasulye olayları dinler ve yanıt verir ve istemci tarafından çağrılamaz.

EJB sisteminde kalıcılık sağlamak için bir kez kullanıldığında, varlık çekirdeklerinin yerini Java Persistence API almıştır. Oturum fasulyeleri ve mesaj odaklı fasulye hakkında daha fazla bilgi edinmek için okumaya devam edin.

EJB ve JavaBeans

Enterprise JavaBeans, Java EE için ilk bileşen tabanlı geliştirme modeliydi. EJB, bileşen tabanlı olması bakımından JavaBeans'e benzer, ancak benzerlik burada biter:

  • Bir JavaBean belli sözleşmelere birden fazla nesne ve esaslara uygun kapsüller bir Java sınıftır. JavaBeans, esas olarak istemci tarafı geliştirme için kullanılır.
  • Bir kuruluş fasulyesi (EJB) belirli sunucu tarafı yetenekleri ile aşılanmış bir Java sınıftır. Kurumsal çekirdekler, büyük ölçekli iş uygulamalarında ve sistemlerinde kullanılır.

Oturum fasulyeleri

Bir oturumu fasulye bir istemci tarafından çağrılabilir iş işlevselliği bir öbek temsil kurumsal fasulye en genel türüdür. Bu durumda istemci, yerel JVM'deki başka bir sınıf veya bir uzak arama olabilir.

EJB kapsayıcısı, fasulye durumu tarafından belirlenen oturum çekirdeği yaşam döngüsünü yönetir:

  • Durumsuz oturum çekirdekleri , Java Servlet API'sindeki istek kapsamına benzer. Durum bilgisi olmayan oturum çekirdekleri bir yığın çağrılabilir işlevsellik içerir, ancak bunun dışında durumsuzdur.
  • Durum bilgisi olan oturum çekirdekleri yalnızca bir müşteriyle ilişkilendirilir ve bu müşterinin devam eden oturumuna eklenir. Durum bilgisi olan oturum çekirdekleri, Servlet API'deki oturum kapsamına benzer şekilde çalışır.
  • Singleton çekirdekleri , Servlet API'deki uygulama kapsamına benzer. Bir singleton oturum fasulyesi, her müşteri için yalnızca bir kez mevcuttur.

Oturum fasulyeleri ile iş parçacığı güvenliği

Durum bilgisi olan bir oturum çekirdeğine aynı anda yalnızca bir istemci tarafından erişilebilir, bu nedenle bu tür fasulye ile çalışırken iş parçacığı güvenliği garanti edilir. Durumsuz oturum çekirdekleri ve tek çekirdekler, geliştirici tarafından yönetilmesi gereken eşzamanlı bağlantılara izin verecek şekilde daha esnektir. Bu tür çekirdeklerle çalışırken iplik güvenliğinden siz sorumlusunuz.

Mesaj odaklı fasulye

Mesajla çalışan çekirdekler (MDB'ler), JMS (Java Mesaj Servisi) mesajları aracılığıyla çağrılır. JMS, mesajla çalışan çekirdeğin komut için dinleyici görevi gördüğü dağıtılmış bir Komut modeli gibi çalışır. Bir konuya veya kuyruğa bir mesaj geldiğinde, o konuyu dinleyen mesaj odaklı fasulye çağrılır.

Mesaj odaklı çekirdekler, oturum fasulyeleri kadar yaygın olarak kullanılmaz, ancak güçlüdürler. Eşzamansız ve olay odaklı olduklarından, özellikle kaynakları korumanın önemli olduğu uzun süreli işler için kullanışlıdırlar.

En basit mimari, EJB uygulaması ve MDB'leri işleyen mesaj servisi ile koordinasyon sağlayan konteyneri ve sunucusundan oluşacaktır. Üretimde, mimariniz muhtemelen çekirdekleri tüketmeye adanmış üçüncü bir bileşen içerecektir. Geliştirme aşamasında, bu bileşenlerin tümü aynı yerel makinede çalışabilir.

Şekil 1, mesaj güdümlü fasulye içeren tipik bir olay odaklı mimariyi göstermektedir.

Matthew Tyson

Mesaj odaklı fasulyelerle çalışmak, oturum fasulyeleri kullanmaktan daha karmaşıktır. Olay odaklı bir ortamda, genellikle ActiveMQ gibi bir mesaj aracısına ihtiyacınız olacaktır.

Oturum çekirdekleri daha basitken ve bu nedenle EJB'de daha yaygın olarak kullanılsa da, olay odaklı mimariler, özellikle mikro hizmetlerin patlamasıyla popüler hale geldi. 

EJB ek açıklamaları

EJB spesifikasyonuna ek açıklamalar getiren EJB 3.0'a kadar, kurumsal fasülyelerin tanımlanması ve tüketilmesi birçok geliştirici için bir tartışma noktasıydı. Ek açıklamalar, Java EE'de bulunan çok çeşitli işlevler için kurumsal fasulyeleri yapılandırmayı çok kolaylaştırır. EJB ek açıklamalarını kullanmaya başlamak için okumaya devam edin.

@Stateless: Durum bilgisi olmayan bir oturum çekirdeği tanımlayın

Bir sınıfı durum bilgisiz oturum çekirdeği olarak belirlemek için, javax.ejb.Statelessek açıklamayı Liste 1'de gösterildiği gibi kullanırsınız .

Liste 1. @ Stateless ek açıklama örneği

 import javax.ejb.Stateless; @Stateless public class MyStatelessBean { public String getGreeting() { return "Hello JavaWorld."; } } 

Bu durum bilgisi olmayan fasulye, bağımsız değişken almayan ve bir dize döndüren basit bir imza içerir. Yine de basitliğin sizi yanıltmasına izin vermeyin: Bu fasulye, diğer çekirdeklerle, hizmetlerle veya uygulamanızın veri katmanıyla etkileşim dahil olmak üzere ihtiyacınız olan her şeyi yapabilir.

@EJB: Durum bilgisi olmayan bir oturum fasulyesi tüketin

Bir oturum fasulyesi tanımladıktan sonra, onu kullanmak çok basit:

Liste 2. @EJB ek açıklama örneği

 public class MyServlet extends HttpServlet { @EJB MyStatelessBean myEjb; public void doGet(HttpServletRequest request, HttpServletResponse response) { response.getWriter().write("EJB Says " + testStatelessEjb.getGreeting()); } } 

Burada, vatansız fasulyeyi bir servlet içine enjekte ediyoruz ve sonra kullanıma hazır. @EJBEk açıklamanın altında fasulyenin nasıl tanımlandığına dikkat edin . "Vatansız" tanımı bize bu fasulyenin müşteriyi takip etmeyeceğini söylüyor. Durumsuz olduğu için, çağrılan yöntemin dışında herhangi bir iş yaparsa, bu çekirdeğin iş parçacığına tabi olduğunu da biliyoruz.

@Remote: Uzak bir EJB arabirimi tanımlayın

Yukarıdaki örneklerde, EJB ve EJB istemcisinin aynı JVM'de çalıştığını varsaydım. Kurumsal Bean ve istemcisi ayrı JVM'lerde çalışıyorsa, EJB'nin bir @Remotearayüz tanımlaması gerekir . Bu durumda, Liste 3'te gösterildiği gibi arayüzü tanımlamak ve uygulamak size kalmıştır.

Liste 3. @Remote ek açıklama örneği

 @Remote public interface MyStatelessEjbRemote { String sayHello(String name); } 

Uzak arabirim istemciye çağrılması için gönderilir. Buna yönelik çağrılar daha sonra EJB'nin sunucu tarafı uygulaması tarafından yerine getirilecektir. MyStatelessBean4 uygular uzaktan izleme Liste örneğin.

Liste 4. Uzak arabirim uygulama

 public class MyStatelessBean implements MyStatelessEjbRemote{ ... } 

Bir uzak arabirim, bir arabirimi uygulayan normal bir sınıf gibi uygulanır. Uzak bir EJB'nin tüketicisi olarak, istemci uygulamasının uzak arabirim için sınıf tanımına erişebilmesi gerekir. Uzak arabirimin sınıf tanımını bir bağımlılık JAR olarak paketleyebilirsiniz.

Yerel ve uzak arayüz

While it's important to know how to implement a remote interface, in practice it's more common to use a local interface. The local interface is used by default and works whenever the EJB is invoked within the same JVM context. Using the remote interface comes into play when the application is distributed across multiple JVMs.

Stateful sessions beans and singleton beans

The process for defining and consuming stateful @Session beans and @Singleton beans is the same as what you've seen for @Stateless beans. Remember the semantics:

  • Multiple session beans can be instantiated and used for the same client.
  • A singleton bean will exist only once for the entire application.

Thread safety and scheduling with singletons

Thread safety is built in when you're working with session beans, but both stateless and singleton beans can be accessed concurrently by multiple clients. Developers are responsible for thread safety when implementing these types of beans.

Singleton beans offer some support for thread safety via the @Lock annotation. You can use the @Lock annotation on singleton bean methods to set read/write privileges for each method. The two options are @Lock(LockType.READ) or @Lock(LockType.WRITE), which is the default.

Another useful feature of singleton beans is the ability to schedule tasks in a simple way, using the @Schedule annotation. Listing 5 shows how to schedule a task daily at noon.

Listing 5. @Schedule annotation example

 @Singleton public class MySchedulerBean { @Schedule(hour = "12") void doIt() { System.out.println("Hello at Noon!"); } } 

CDI vs EJB

CDI, or Context and Dependency Injection is a newer enterprise specification that some developers have proposed could replace EJB.

At a high level, CDI offers a general-purpose component framework, while EJB stands out for its richly featured, individual components. Whereas CDI uses dependency injection to define and reference any software component, EJB components are more formally defined, with each offering a specific set of capabilities out of the box. Both specs are planned for future development as part of Jakarta EE, where the question of whether CDI should replace EJB will eventually be resolved.

Conclusion

Kurumsal JavaBeans, kurumsal Java uygulamalarında iş mantığını kapsüllemek ve yeniden kullanmak için kolay bir yol sunan ilk teknik özelliktir. Eskinin ağır sıklet devinden çok uzak olan EJB, bugün çok çeşitli kurumsal işlevlere kutudan çıktığı anda erişmenizi sağlayan yalın, açıklama tabanlı bir çerçevedir. Bir dahaki sefere dağıtılmış, ölçeklenebilir bir iş uygulamasını hızla geliştirmeniz istendiğinde EJB'yi düşünün. Sana hoş bir sürpriz olmuş olmalı.

"EJB nedir? Enterprise JavaBeans'ın evrimi" adlı bu hikaye, orijinal olarak JavaWorld tarafından yayınlandı.