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

我正在开发Web应用程序,同样在我的产品中我们也提供金融非金融移动服务.

详细介绍.

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

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

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

我的问题是

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

最佳答案
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"/>

这有助于将入站网关的路径属性映射到servletdispatcher)

转载注明原文:是否值得将Spring Integration而不是Spring MVC用于基于Web或基于移动的应用程序? - 代码日志