Announcement Announcement Module
No announcement yet.
Question about architecture and posibilities Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Question about architecture and posibilities


    I'm beginning with Spring Integration, and I love the Josh Long's presentation Enterprise Integration and Batch Processing on Cloud Foundry (specially the 11th slide).

    But I have a question regarding the architecture:

    I have a monolithic EAR, just like the one that appears in the slide 18. It has a lot of disadvantages, but every service is in memory within the same server, so I can call an "autowired" service from another service.

    Let's imagine thar AccountingService is a core Service that will be called by everyone else.

    I'd like to use an asynchronous architecture, see slide 24, but a question regarding the use of a core service arises:

    How can I call a service from another with Spring Integration with reasonable performance?

    I mean, what can I configure in the service broker using Spring Integration in order to call services that I used to have in memory?

    I think that sending messages to AccountingService using WebServices or JMS instead of direct calling will be slower in comparision.

    Another option would be to duplicate the AccountingService (the core services in general) code among all the deployed WARs.

  • #2
    I am not all that sure what you are asking, but i think it would be nice if you go through some of the samples to get a beter feel for how SI works and than may be your question will be a bit more concrete -


    • #3

      Thank you very much for your response and apologies for the bad way in which I asked you the question.

      I've been using the sample code to learn how to build Spring Integration applications. By the way, you have done a very good job with those examples. Congratulations.

      But I still don't know how exchange messages among separate applications and what will be the performance and throughput.

      What for?

      Imagine I have to integrate a Payment application with a Shipping application. Both web applications.

      I can create a fresh new web application with Spring Integration to create the flow of messages to achieve the integration, with some Service activators to call the payment and shipping services of this very application (imagine that it's possible to copy all the original code into this new application). Just like the coffe break application.

      The advantage is that the services and the Spring Integration objects live all in the same memory space and I can use them as Spring beans directly in an application context.

      Alternatively, I can create a Spring Integration application that sends messages using JMS, Web Services or similar to the existing applications (that would have be modified with some integration logic too)

      The advantage of this approach is that I could integrate more applications by modifying the extra Spring Integration and by editing the proper Integration logic of each application to be integrated.

      The disadvantage is that passing messages of the second approach should be more slower than the direct calls of the first approach. But the scalability seems better and I'd like to avoid the duplication of some code.

      The questions are:

      Do you have any advice in this kind of scenarios?

      Do you have any measurement of the throughput of passing messages between separate applications?

      Thank you very much again, and apologies one more time, because it's the first time I face an EAI.


      • #4
        Did you say you want asynchronous architecture? if you can accept your "core services" as asynchronous services, then you shouldn't worry about latency of the services 'cause your core services will be offline. If you want to go for asynchronous architecture, think about using Spring Messaging with JMS and ActiveMQ broker, it is a scalable asynchronous architecture.

        BTW duplicate "core services" code in each web application is really not good idea.


        • #5
          First of all, I appreciate a lot your response.

          Originally posted by tannoy View Post
          BTW duplicate "core services" code in each web application is really not good idea.
          I agree. That's the reason I posted this question.

          My main problem is that it's the first time I face EAI, and it seems my mind it's not well prepared yet.

          Until now, we used to program single projects in monolithic ears where we can manage modules as desired. We can even cheat at deploying time by using shared libraries (it's not easy to explain right now)

          This new project must integrate two separate systems, and it's very simple to create a fresh new project with the necessary resources (for instance, two datasources) but it has little scalability.

          On the other hand, your suggestion is highly scalable (asynchronous messages) but, besides some issues with serialization, for the time being I don't think the "core services" can be asynchronous.

          Anyway, all your answers help me a lot to think about the architecture.

          I'll try to use the Cafe Sample Application.

          In the first stage, everything will be in the same project. Instead of copying the original code, I'll consider some kind of refactoring.

          In later stages, if there's need to integrate more functionality, I'll try the AMQP version of the Cafe Application.

          Thanks for all the responses.