Question

我正在开发网络应用程序，同样在我的产品中我们也提供金融非金融移动服务。

详细说明。

在我的网络应用程序中，没有什么比一步一步维护流程，简单的所有CRUD操作，目前我们正在使用符合我们要求的 Spring MVC ，但对于基于移动的服务，我们提供喜欢消息总线支持在客户端和服务器之间交换背负信息，我们有自定义代码来实现解决方案。

此外，我们的基于移动的服务需要通过SOAP，REST等不同协议公开，同时需要将通信数据包与服务分离。

我们仅使用 SPRING MVC 解决了上述所有问题。

我的问题是

是否值得使用 Spring Integration 框架替换自定义代码解决方案以使用Spring Integration实现消息总线，如果是，那么我的Web应用程序的流程是什么？
如果我在我的Web应用程序中使用Spring Integration，它将如何向SI提交HTTP请求？
对于任何独立的基于Web的应用程序，Spring Integration是否是正确的选择？

Answer 1

Spring Integration以Enterprise Integration Patterns为模型，可以最好地将其视为支持Message Driven Architecture。 Spring MVC的历史和起源是为类似于Struts的MVC模式提供解决方案，主要以线性方式公开服务支持的模型和控制视图。 Spring MVC的核心之一是允许JSP页面（View）访问的模型的动态填充。所有这些都是Web App的定位和结束。

随着服务（Web，RESTful）的发展，Spring MVC填补了空白并不断扩展以支持HTTP访问服务，尽管这是其职责的扩展，而不是第一个起源。同时，Spring Integration的设计理念是处理消息和消息与服务的交互，而不依赖于访问它的协议。要启用不同的协议，可以使用不同的端点来公开相同的服务。例如，我可以将我的crud服务构建在POJO中，通过Service Activator公开，现在可用于许多不同的协议，包括REST，HTTP，Web服务，Twitter，XMPP聊天服务，RMI，TCP等。

简而言之，Spring MVC == HTTP访问，Spring Integration ==消息访问（来自HTTP，文件，数据库等）

在Spring Integration中通过HTTP公开服务，使用HTTP端点。通常在请求/响应中（比如从数据库中读取），您将要使用<int-http:inbound-gateway/>，它看起来像这样;

<int-http:inbound-gateway request-channel="request.channel" reply-channel="reply.channel"
   path="/myService" supported-methods="GET"/>
<int:channel id="request.channel"/>
<int:service-activator input-channel="request.channel" ref="myService"/>
<int:channel id="output.channel"/>

（要记住的关键点是以下......

<bean class="org.springframework.integration.http.inbound.UriPathHandlerMapping"/>

这有助于将入站网关的path属性映射到servletdispatcher）

是否值得将Spring Integration而不是Spring MVC用于基于Web或基于移动的应用程序？

1 个答案: