【问题标题】:In-process communication between wars in the same container同一容器中的战争之间的进程内通信
【发布时间】:2012-03-20 08:58:41
【问题描述】:

有哪些选项可以在同一码头容器中运行的两场战争之间实现低延迟通信?

我基本上需要在一场战争中从另一场战争中调用一项服务,但无法承担将其作为 Web 服务调用的开销。

由于它们在同一个 JVM 中运行,我希望避免使用 RMI/JMS 等,但我不知道我还有哪些其他选择?

我查看了 servlet 间通信,但由于直接方法调用是 deprecated,这似乎不是正确的选择?

我也找到了kyronet,但是由于这是在同一个 JVM 中,有没有更好的解决方案?

我正在寻找类似于 Apache Camel 的 VM Component(网络应用程序之间的 seda),但由于只有一个应用程序使用 Camel,因此这不是一种选择。

我知道我可能不得不在两次战争之间共享一些 DTO,但请不要建议将服务拉入共享库,如果这是一个选项我不会问这个问题:)

编辑:

嵌入 EJB 容器也可能不是一种选择。

【问题讨论】:

    标签: java low-latency communication-protocol


    【解决方案1】:

    向 JNDI 注册接口并使它们成为全局的,以便“其他”servlet 可以从存储库中检索它们。

    查看this

    (注意:我们放弃了 JNDI 以支持我们自己的注册表实现,但我们在同一个 JVM 中以编程方式启动注册表和 Jetty)

    【讨论】:

    • 感谢您的回答!为什么放弃 Jetty 的 JNDI 支持?那么,您是实现了自己的 NamingManager,但仍然使用 Context API,还是一起放弃了 JNDI?您能否指出一些资源,描述如何在 Jetty 上注册有问题?哦,最后,通过此解决方案传输的对象是通过引用传递还是序列化?
    • 我们通过“引用”传递,因此对象实例可以直接寻址。 JNDI 很好:试试这个链接获取一些信息link。我们放弃它的原因有两个:我们想要更大的灵活性(具有固定接口、查询功能、运行时注册的多个注册表)和更精简的包(JNDI 是通用的,并提供我们不需要的功能)。实现你的注册表需要你正确处理 webapp 生命周期,这可能并不容易
    • 在Jboss中怎么做同样的事情,基本上我需要了解,服务组件是如何暴露给JNDI的?
    【解决方案2】:

    通过使用 ServletContext.getContext(String uriPath) 和 RequestDispatchers(甚至是 ServletContext 侦听器),可以在两个位于同一位置的 Web 应用程序之间“通信”。

    以下是工作代码。由 Peer Reynders (http://www.coderanch.com/t/222608/Web-Services/java/communicate-war-files) 建议

    public void doGet(HttpServletRequest Prequest, HttpServletResponse Presponse)
      throws IOException, ServletException {
    
      ServletContext    sc = getServletContext().getContext("/war2");
      RequestDispatcher rd = sc.getRequestDispatcher("/LoginHandler?UserId=DummyUser");
      rd.forward(Prequest, Presponse);
    } /* End of doGet */
    

    【讨论】:

      【解决方案3】:

      将服务公开为具有本地接口的 EJB 是一种选择。该标准不保证这将在跨应用程序完成时作为直接调用实现,但apparently most app servers implement it that way。要在 Jetty 中运行,您必须使用可嵌入的 EJB 容器,例如 OpenEJBJBoss embeddableSpring's Pitchfork

      【讨论】:

      • 谢谢!由于我们有一个基于自定义嵌入式码头包装器的大型 SOA 部署,我不认为嵌入 EJB 容器会与我的经理一起飞行。
      • @ebaxt:我怀疑这完全取决于“EJB”这个标签及其 10 年前的坏名声。如果没有其他简单的解决方案出现,可能值得一试。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2016-07-02
      • 1970-01-01
      • 2020-10-23
      • 1970-01-01
      • 1970-01-01
      • 2013-02-01
      • 1970-01-01
      相关资源
      最近更新 更多