Java EE: Soket dinleyicilerini dinamik olarak etki alanı modelinden oluşturma ve silme

Question

Kullanıcıların bir web arabiriminden "socketinfo" tabloları (bir veritabanında depolanan) ekleme/çıkarmalarını sağlayan bir Java EE uygulaması oluşturuyorum. Kullanıcı, web arayüzünden bir "socketinfo" etkinleştirirse, uygulama sunucusunun gelen paketler için bir soket dinleyicisi oluşturması ve verileri işlemesi gerekir. Kullanıcı "socketinfo" yu devre dışı bırakır veya silerse, dinleyici çıkarılmalıdır. Tüm ürün tek bir kulakta ve tercihen uyumlu bir şekilde bulunmalıdır. Ben kabul ama sorun haline koştum gibi yaklaşımlar şunlardır:

1. prizlerin bir JCA kaynak bağdaştırıcısı oluşturma ve dinleyici olarak MDBs kullanın. Burada karşılaştığım sorun, kullanıcı eklediğinde MDB'leri farklı soketlere program aracılığıyla nasıl dağıtacağımı anlayamıyorum.

2. Daemon iş parçacığını dikkatli bir eşitleme ile yöneten bir @ Singleton/@ Hizmet ejb'si oluşturun. Singleton ejb iş katmanına enjekte edilebilir, böylece CRUD işlemleri ve yuva manipülasyonu doğru iş akışında gerçekleşir. Buradaki problem, EJB'lerden gelen iplikler oluşturmanın kötü bir uygulama olarak kabul edildiğidir ve spesifik değildir (tekil yaşam döngüsü doğru şekilde ele alınmış ve uygun senkronizasyon mekanizmaları yürürlükte olsa bile).

3. Konuları, alan modeline (başka bir single?) Yerleştirin ve EJB'lerin modeli kullanmasını sağlayın. Uygulama sunucuları birden fazla sınıf yükleyiciye, genel olarak daha az konteyner desteğine sahip olma eğiliminde olduğundan, bu durumun en kötüsü de buydu.

Java EE'de bu durumu nasıl doğru şekilde ele alacağınız hakkında bir fikriniz var mı?

DÜZENLEME: Bu soruya bir uzantı: ewernli'nin çözüm 3'te önerdiği gibi bu soruna yaklaşmaya karar verdiğimi farz edersem, JCA'da (iç iş parçacıkları eklemek için özel bir arabirimle) bunu elde edemeyeceğim ne kazanırım? (iyi tasarlanmış) bir singleton olsun? Bir kaynak bağdaştırıcısı oluştururken korkunç bir görev gibi görünmüyor, tamamen önemsiz görünmüyor ve biraz zaman alıcı olabilir (ve belki diğer geliştiriciler için takip etmek daha da zor olabilir).

Answer 1

Analizleriniz mantıklı görünüyor ve MDB'yi dinamik olarak JCA ile uyumlu hale getiremediğinizi söylediğinizde haklısınız.

Az daha tasarım fikirleri:

• Bir soketi okumak için kullanabileceği, (JMS ruhunda) SocketConnections döndüren bir JCA konektörü yazabilirim. JMS benzeşimine devam etmek için, MDB MessageListener'u temsil ederken, göstereceğiniz şey MessageConsumer'dur.

• Bir iş parçacığını simüle etmek için periyodik bir zamanlayıcı kullanabilirsiniz. While döngüsü olan bir iş parçacığı yerine, kendisini yeniden zamanlayan bir zamanlayıcıya sahip olursunuz. Bir uygulamanın bir arka plan sürecine sahip olduğunu ve bunun iyi çalıştığını kullandım. Ayrıca, başka bir uygulamada eşzamanlı bir hesaplama yapmak için EJB'lerden doğru iplikler ürettiğimi ve aynı zamanda iyi çalıştığını unutmayın. Ancak, kısa ömürlü ve fasulye içindeki iş yönteminin tümü tamamlanana kadar beklerdi, bu nedenle spesifikasyonun büyük bir ihlali değildi. Yine başka bir tasarım, JCA konektör kolu dişlerine vb. Sahip olmalı ve tüm mesajları MDB'ye iletecektir. MDB, verileri karşılık gelen verileri, örneğin, "kanal" ile ilgili bilgiler ile birlikte alır. Soket bağlantı noktası. Tek bir MDB'de çoğullamaya benzer, daha sonra verileri deşifre eder.Konektörünüz, iş parçacığı vb .'nin oluşturulmasını kontrol etmek için ekstra API sağlayabilir ve bu arabirim EJB'nize (ConnectionFactory benzeri) enjekte edilebilir. Bağlayıcınız iş parçacığı oluşturmayı kontrol etmek için ek bir API sağlayabilir. Çok açık değil ama umarım bu fikri alırsınız. Eğer haklıysam, JCA konektörü en azından her sokette MDB'ye eşzamanlı olarak veri iletebildiğinden, MDB'nin verileri sırayla işleyebilmesini sağlayabilirsiniz. geliştirme süresinin izin veriyorsa

Ben, 3. için gider.

DÜZENLEME

Bu seçim kısmen gerçekten tasarım saflık bir sorudur. Kullanıcı tarafından ele alınan iş parçacıklarıyla ilgili bir sorun, açıkçası onlar için bildirimsel işlemler kullanamazsınız. İşlemi sınırlamak için bir UserTransaction kullanabilirsiniz. Böyle bir iş parçacığında da EntityManager'u ne kadar iyi kullanabileceğinizi bilmiyorum. Eğer daha çok veri işliyorsanız ve ara katman yazılımının çok fazla özelliğini kullanmıyorsanız, iş parçacığını kendiniz toplayabilirsiniz. Başka bir yanıtı gör: How can an EJB parallelize a long, CPU intensive process?. Aklıma gelen diğer şeyler (sorunlu olup olmadıklarını bilmiyorum): güvenlik yöneticisi, (?) Iş parçacığı oluşturmayı engelleyebilir, bu da uygulamayı engelleyebilecek deamon threads olarak oluşturmaz. Sunucu düzgün şekilde kapatıldı (?). Başlangıçta ServeletContextListener'dan gelen iplikleri ürettiğimi ve bunun çok güzel çalıştığını unutmayın. Bu, spesifikasyonları ihlal etse bile sıkça kullanılan bir numaradır. Aynı durum, "yeni" piyasaya sürülen tekli fasulyeler için de geçerli olabilir. Yani, eğer vaktiniz kısasa, tek bir fasülye ile teklifinizi deneyebilir ve neyin işe yarayıp yaramadığını görebilirsiniz.

Answer 2

Eminim ki # 2 en iyi çözümdür (ve aynı zamanda geçerli). Ben yeni "Singleton" ejb'leri için spekülasyona bakmadım ama benim varsayımım, bunların içinde iş parçacığının kabul edilebilir olması (bu ejberin içinde kendi senkronizasyonunuzu yapmak kabul edilebilir) göz önüne alındığında. Bunlar daha önce JMX kullanarak yapabildiğiniz yönetim tipi hizmetlerin dağıtımını kolaylaştırmak için tasarlandı (dağıtım standartlaştırılmamış olsa da). Bir JMX mbean içinde , kendi iplik yönetimi, yapmak kesinlikle kabul edilebilir, bu yüzden Tekton ejbs için taşıyacak.

, ejb 3.1 teknik özelliklerinin hızlı bir kaygısını gerçekleştirdi ve sanırım Singleton'un tek parası eşzamanlılık kontrolü, iş parçacığı/soket malzemesi değil. aptalca bir tür. Tam teşekküllü bir JMX mbean yerine geçmediklerini düşünüyorum. Bu, her ne kadar dağıtım standart olmayan olsa da, her zaman bir JMX mbean kullanabiliriz. jboss kullanıyorsanız, Servis notu, her şeyin izin verilebileceği (thread, priz, vb.) bir JMX mbean'a eşdeğer'dur.