Empresas
Empregos
  • Sobre nós
  • Soluções
    • Publicação de vagas
      Publique sua vaga e receba candidatos qualificados em 48h.
    • Avaliações de candidatos
      Mais de 500 testes técnicos e psicológicos, mais anti-fraude.
    • Headhunting
      Busca executiva personalizada do início ao fim.
    • Folha de Pagamento + EOR
      Dispersão de folha e EOR em mais de 15 países da LATAM.
  • Preços
  • Empregos

0

153
Visualizações
Spring integration flow vs regular service and adapter

I had some legacy code that had SOAP services. Now I am building Rest API for some objects that may call one or more SOAP operation. I was looking into Spring Integration. From the docs

In addition to wiring together fine-grained components, Spring Integration provides a wide selection of channel adapters and gateways to communicate with external systems.

Above statement sounds enticing. I was writing rest microservice controller, Validation service, Rest request to SOAP request mapper and SOAP client. I some cases when there are multiple calls, there is even more code I had to write and I did write the code in many cases.

Spring Integration at high level looked like a framework oriented for Async messages. My problem is that the call need to be more or less a synchronous call and performance is critical. Had anyone used Spring integration for this problem and can you share your experiences.

about 4 years ago · Santiago Trujillo
2 Respostas
Responde à pergunta

0

To complement Artem's answer it's worth to note that if you're going to use one of Spring Integration DSLs (Java, Groovy or Scala) then (the synchronous) DirectChannel will be picked by default by Spring Integration to wire up the endpoints of your integration flow. This means that as long as your endpoints stay synchronous and you rely on default channels between them, the whole integration flow stay synchronous as well.

For instance (in Java DSL):

  @Bean
  public IntegrationFlow syncFlow() {
    return IntegrationFlows
        .from(/* get a REST message from microservice */)
        // here the DirectChannel is used by default 
        .filter(/* validate (and filter out) incorrect messages */)
        // here the DirectChannel is used by default too
        .transform(/* map REST to SOAP */)
        // guess what would be here?
        .handle(/* send a message with SOAP client */)
        .get();
  }

This absolutely doesn't mean you tied up with synchronous flow forever. At any step you can go async or parallel. For example, if you decide to send SOAP messages in parallel all you need to do is to specify appropriate channel before SOAP client invocation:

  @Bean
  public IntegrationFlow syncFlow() {
        // ... the same as above ...
        .transform(/* map REST to SOAP */)
        .channel(c -> c.executor(Executors.newCachedThreadPool()))  // see (1)
        .handle(/* send a message with SOAP client */)
        .get();
  }

(1) From this point on the downstream flow will be processed in parallel thanks to use of ExecutorChannel.

Note that message endpoints may also behave asynchronously depending on their logic.

I've used Spring Integration for building synchronous integration flows in my home and work projects and it's proven to be a very powerful yet flexible solution.

about 4 years ago · Santiago Trujillo Relatório

0

One of the first class citizens in Spring Integration is MessageChannel abstraction. The simplest, synchronous, and therefore direct method invocation is DirectChannel.

Not sure what makes you think that everything in Spring Integration is async. Actually it is always direct unless you tell to be async.

about 4 years ago · Santiago Trujillo Relatório
Responde à pergunta
Encontrar trabalhos remotos

Descubra a nova forma de encontrar um emprego!

melhores empregos
Principais categorias de trabalho
Empresas
Postar vaga Preços Comercial
Jurídico
Termos e Condições Política de privacidade
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomende algumas ofertas para mim
Preciso de ajuda