客户端(Tomcat)调用Stateless Session Bean(JBoss),如何处理Client Identifier

发布于 2024-11-16 07:50:19 字数 587 浏览 3 评论 0原文

我们有以下设置:

  • Tomcat(Web 应用程序)调用 JBoss 5.1.0 EAP (EJB 3.0) 中的服务(无状态会话 Bean)
  • JBoss 有两个使用两个不同数据库定义的不同持久性上下文
  • JBoss 服务需要知道哪个客户端调用了它的服务服务,类似于标识符(多租户?),

我们可以更改 Jboss 端的所有服务方法以接受客户端标识符作为参数。那么我们需要更改服务内每个可能的方法调用来传输此标识符,这对我来说听起来太麻烦了。

首先我想到了类似于 ThreadLocal 变量的东西......我想这在 Java EE 的世界里是被禁止的。

你们知道“传输”客户端标识符的任何优雅的解决方案吗?我认为 JAAS 做了类似的事情,过滤来自“外部”世界的每个呼叫,并将用户凭据应用于每个呼叫。一旦调用进入“Jboss 服务世界”,所有后续方法调用都具有调用者标识。

我希望我的应用程序尽可能“与客户端无关”,它应该根据哪个客户端调用服务来“注入”正确的配置(如持久性上下文)。逻辑是相同的,只是其使用的资源不同(某种拦截器架构)。

我有点失落。非常感谢任何帮助。

干杯 马塞尔

we have the following setup:

  • Tomcat (Web App) calls a service (Stateless Session Bean) in JBoss 5.1.0 EAP (EJB 3.0)
  • JBoss has two different Persistence Contexts defined using two different databases
  • The JBoss Service needs to know which client called its service, something like an identifier (multi tenancy?)

we could change all service methods on the Jboss side to accept a client identifier as parameter. then we would need to change every possible method call inside the service to transport this identifier, which to me sounds too much of a hassle.

first i thought about something similar to a ThreadLocal variable... which i guess is forbidden in the world of Java EE.

do you guys know of any elegant solution of "transporting" a client identifier? i think JAAS does something similar by which every call from the "outside" world is filtered and user credentials are applied to every call. once the call enters the "Jboss service world" all subsequent method invocations have the caller identification.

i want my application to be as "client agnostic" as possible it should just get the right config "injected" (like the persistence context) depending on which client called a service. the logic will be the same, just the resources its using are different (some kind of interceptor architecture).

i am a bit lost. any help is highly appreciated.

cheers
marcel

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

浮生面具三千个 2024-11-23 07:50:19

在 @AroundInvoke 拦截器中,您应该能够通过检查 InspirationContext.getContextData() 的内容来检测 Web 服务,该内容根据 JAX-WS 规范与 Web 服务上下文共享。您仍然需要在内部传播它。

只要您记得自己进行清理,Java EE 中的 ThreadLocal 不一定是坏事:(

tl.set(something);
try {
  deepMethodCallHierarchy();
} finally {
  tl.remove();
}

当然,显式传递上下文可能是最干净的。)

From an @AroundInvoke interceptor, you should be able to detect webservices by checking the contents of InvocationContext.getContextData(), which is shared with the webservice context per the JAX-WS spec. You would still have to propagate it internally.

ThreadLocal in Java EE isn't necessarily bad so long as you remember to clean up after yourself:

tl.set(something);
try {
  deepMethodCallHierarchy();
} finally {
  tl.remove();
}

(Of course, explicitly passing the context around is probably the cleanest.)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文