Announcement Announcement Module
Collapse
No announcement yet.
JNDIExport for MessageChannels Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • JNDIExport for MessageChannels

    Hello, Mark & Oleg

    Here's my case:

    1. I've got two applications as moduls in EAR
    2. Both have some Spring-configs with some Spring-integration logic
    3. But there is some logic when I need to make calls from one application to another as Web-Client to EJB
    4. Now I connect them, you guessed it, via an EJB-local-interface

    I don't like having one else layer with transport proxy, and it is difficult to boot Spring-container in EJB-layer via
    org.springframework.ejb.interceptor.SpringBeanAuto wiringInterceptor, because it uses static ContextSingletonBeanFactoryLocator.getInstance().
    When I want to have several independent Spring-containers I have to inherit from SpringBeanAutowiringInterceptor.
    Also for starting that container on application start I have to invoke some intecepted method on my EJB-component in that module.

    I want connect my applications in one JVM without EJB.

    So, it is my question (or proposal):
    What about implement JndiExport for MessageChannels, where one application bind to JNDI and another read it from JNDI, as it did for EJB?
    I know about JMS-, http-, tcp- and RMI-transports, but them all use serialization and some others steps before sending and receiving messages.


    Thanks for your work,
    Artem Bilan

  • #2
    Artem

    Before even geting into any details let me ask a question.
    Are you forced to use EJB to communicate between modules?
    And as far as serialization lets make sure that you are not becoming a victim of "premature optimization" Have you evaluated what if any hit are you taking with serialization? Have you run through a load which shows you that serialization is going to cost you missing your SLA?
    I think i know what you are trying to do, but I also think you are getting ahead of yourself a little bit here

    Comment


    • #3

      Ok, Oleg.
      The reason is:
      1. Dispose of EJB
      2. Start several independence Spring containers
      3. Use shared domain object
      4. Do not use some external systems: JMS, RMI, JDBC etc.

      MessageChannel is a good point for connections, but I don't see solution without additional transport...

      Comment


      • #4
        Don't forget EJB is also a transport and although in the local case it might not be serializing the object value, your object still has to jump a lot of hoops in the EJB container, JNDI registry, that is why I am questioning wether you really saving anything by not introducing some light weight transport. IN fact I would not be surprised if introducing some transport in between would actually increase a performance rather then affect it.

        Remember you are already a fan of Messaging architecture and in such architecture relying on 'strong type' sharing in the multi-class-loader setup is asking for trouble IMHO. That is why EIP defines transformers, marshallers etc, to apply them whenever you need to bring message to a state your app can understand. For example in a single app it is ok to pass strong types as message payloads, but in the multi app environment I would strongly discourage that simply because you can not guarantee how your apps will be deployed. I know you can guarantee while you are developing it, but your application depends on a specific deployment model (to EARs sitting locally). What is at some point your app gets distributed and two EARs are now on different VMs?

        And as always, follow the Martin Fawler's 3 main principles:
        - Make it work
        - Make it right
        - Make it fast

        You seem to be trying the last one first
        Cheers

        Comment


        • #5

          In my case it work, fast, but not right.
          What transport do you recommend, when I only want to decouple my application into different Spring containers?
          I see: RMI-support is the simplest solution in that case. Yes?

          Comment


          • #6
            Also I tried do it with JdbcMessageStore, when one application puts message to channel and stores one in DB. Other application reads message from DB on poll method
            But it works only on queues.
            It is posible to implement synchronous request/response via Gateway and queues?

            Comment


            • #7
              Interesting question about what transport. My answer is why one transport instead of several.
              Are you aware that by having more then one subscriber to a direct channel the dispatcher strategy by default configure with automatic failover as well as load balancing? This means that each subsequent request will go to the next subscriber unless you disable load balancing. And by disabling load balancing you essentially enabling primary/secondary subscriber model.
              For example:
              Code:
              <int:channel id="input">
              	<int:dispatcher load-balancer="null"/>
              </int:channel>
              
              <int-amqp:inbound-channel-adapter channel="input". . ./>
              
              <int:http-outbound-adapter channel="input" . . ./>
              . . .
              In the above configuration requests will always go to AMQP adapter since it is defined first, but you can also manage it with 'order' attribute if you don't want to rely on the xml order. But if AMQP fails, dispatcher will failover to the next subscriber which in this case is HTTP and only when both fail the exception will be thrown bac at you. So you can implement as many transports as you want to support and with that providing a much higher level of guarantee that the message will reach its destination.

              Comment


              • #8
                Ohh and btw, which transport do I prefer for intra-module communication?
                AMQP! And i can almost guarantee that it is faster then EJB

                Comment

                Working...
                X