WARs oturum bilgilerini neden paylaşamıyor?

Bu sorun için bir çözüm arayan birkaç geliştirici gördüm: oturum bilgilerine farklı bir savaştan erişmek (aynı EAR içinde bile olsa) - işte bazı örnekler: Tomcat'teki farklı uygulamalar arasında oturum durumunu paylaşmanın herhangi bir yolu var mı? , Erişim oturumu başka bir web uygulaması , farklı WAR dosyaları, paylaşılan kaynaklar , Tomcat: Nasıl iki uygulama arasında veri paylaşımı? , Tomcat'te crossContext özniteliği ne yapar? Oturum paylaşımını etkinleştiriyor mu? ve bunun gibi...

Aradığım her şeyden, konteynere bağlı olarak bazı özel çözümler var, ancak bir şekilde ' spesifikasyonun aksine '. Ayrıca, bir cevap bulma şansı olmadan Java EE spesifikasyonlarına da baktım.

Bazı geliştiriciler web uygulamaları arasındaki bağlantıdan bahseder, ancak katılmıyorum. Bağlanmadığı takdirde SAVAŞLARI aynı EAR içinde tutmanın nedeni nedir? Örneğin EJB'lere yerel olarak erişilebilir (aynı EAR içindeki başka bir EJB JAR içinde olsa bile).

Daha spesifik olarak, SAVAŞ'ımdan biri kimlik doğrulama ve yetkilendirmeyi ele alıyor ve bu bilgileri diğer SAVAŞ'larla (aynı EAR'da) paylaşmak istiyorum. Daha önce benzer sorunları çözmeyi, WAR'leri JAR olarak paketleyip tek bir WAR projesine (WEB-INF / lib) yerleştirerek başardım. Yine de bu çözümü sevmiyorum (sunucu uygulaması adlandırma vb. İçin büyük çaba gerektirir).

Ve ilk (ve en önemli) soruyu hiçbir çözüm yanıtlamadı: WARs oturum bilgilerini neden paylaşamıyor?

Bir EAR'a sahte sanal makine gibi davranın

Bir EAR, genellikle JAR'lardan gelen ortak yapılandırma ve kütüphaneleri paylaşan bir WAR dosyaları topluluğudur. Bu, birbirine bağlı hizmetlerin bir koleksiyonunun bir uygulama kapsayıcısında daha kolay yönetilmesini sağlar. Böylece, bir EAR'ı, kabına yerleştirildikten sonra basit bir sanal makine biçimi olarak düşünebilirsiniz.

Sanal makinedeki bir işlemin diğerini etkilememesi gibi, EAR için de aynı durum geçerlidir. Tüm SAVAŞLAR iç durumlarını korumak için izole edilmiştir.

Ölçekleme kimlik doğrulaması

Genel olarak web uygulamalarının iyi ölçeklendirilebilmesi için vatansız olmaları gerekir. Oturumda çok fazla bilgiye sahip olmak, bunu engelleyen bir anti-kalıptır. Bu, HTTP'nin durumsuz doğası ile hızlı ve özelleştirilmiş bir kullanıcı deneyimi sağlama ihtiyacı arasında bir çatışmaya yol açar. Kimlik doğrulama klasik bir kullanım örneğidir ve son kullanıcı işlevselliğini sağlamak için çok sayıda kimlik doğrulaması yapılmasını gerektiren sohbet API'larında yaygındır.

Tek Oturum Açma ve Tek Oturum Kapatma özelliğinin düzgün çalışması için dikkatli sinyal vermesi gerekir (özellikle kısmi Oturumu Kapatmayı düşünün), özellikle yatay ölçeklendirme mevcut olduğunda. Oturum durumunu paylaşmak neredeyse hiç iyi bir çözüm değildir ve daha iyi bir yaklaşım, kümedeki tüm düğümlerin erişebildiği kullanıcı bilgileri için tek bir başvuru noktası kullanmaktır.

İlgili bilgilere hızlı bir şekilde önbelleğe alınmış erişime odaklanmak, bazı karmaşık, kırılgan oturum paylaşım çözümlerinden çok daha ölçeklenebilir sonuçlar verecektir.

JEE EAR belirtimindeki işlevsellik eksik olduğunu düşündüğüm bir şey - bir EAR içinde bağlı birden çok web arşivi arasında web oturumlarını paylaşma yeteneği.

Weblogic gibi uygulama sunucularının bu işlevsellik için standart dışı uygulamaları vardır.

AFAIKS, bunu yapmak için gerçek bir neden yok. WAR, kendi (web uygulamasına özel) kapsamları (oturum kapsamı gibi) olan bağımsız bir web uygulamasıdır. İşlevselliği (Java kodu, JSP sayfaları, CSS dosyaları) paylaşmanız gerekiyorsa, birden fazla WAR arasında bunları JAR dosyaları olarak paketleme ve uygulama sunucunuza dağıtma konusunda çok daha mantıklı bir seçeneğiniz vardır. WAR paketi daha karmaşık bir paketleme çözümüdür ve basit "ortak kod / işlevsellik" ten farklı bir şeyi kapsüllemek için tasarlanmıştır. JAR daha basit bir formattır ve kod ve işlevselliği paketlemek ve paylaşmak için tasarlanmıştır. Zaten daha basit ve daha uygun bir paket biçimine sahip olduğunuzda, bir şeyi paylaşmak için neden daha karmaşık ve özel olarak tasarlanmamış bir ambalajı kullanmak istersiniz?

Farklı web uygulamalarının yanlışlıkla oturum bilgilerinin üzerine yazılmasını önlemek için bu amaçla yapıldığını düşünüyorum. Durumunuzda kullanışlı olabilir, ancak genel olarak, kullanıcıların aynı anda iki web uygulaması kullandıkları için uygulamanın çökmesini veya ayrıcalıklarını artırmasını istemezsiniz. Web uygulamaları arasında açık bir şekilde bilgi paylaşmak tam olarak zor değildir; statik HashMap ile bir sınıf oluşturun, GUID'leri anahtar olarak kullanın ve URL veya HTTP parametresinin bir parçası olarak aktarın.