Announcement Announcement Module
Collapse
No announcement yet.
Co-location and DMZ Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Co-location and DMZ

    Hi,

    I've been trawling this forum for a couple of hours and I can't find anything related so I'll just spit it out...

    My client requires that there is a DMZ set up with the web server (with web components) behind the first firewall and the app server behind the second firewall.

    I'm concerned that this approach is going to impact performance quite heavily in terms of the extra remoting.

    Are there any alternatives where we can have the same level of security and colocated web components and services?

    Eg. Have an apache server attached to the public network acting as a first firewall which accepts external traffic. This apache instance proxies traffic to a second apache server which only accepts traffic from the first apache instance and finally proxies to an internal network webserver running the target web components and colocated services?

    thanks for any feedback.

    Neil

  • #2
    Hi Neil,

    the approach you have right now, is commonly used and the performance of your application must not be affected (if there are a good configuration of DMZ there is no problem with performance in terms of extra remoting)

    If you think about it quietly, the security department of the client will be more satisfied about the solution and also the client.

    I hope it helps.

    Greetings.

    Comment


    • #3
      Hi,

      thanks for your reply.

      My understanding is that Rod Johnson advocates a co-located architecture whereever possible to prevent unnecessary remoting overhead (and for that matter a much trickier architecture - web components can no longer access hibernate loaded domain objects in memory with OpenSessionInView etc - now I have to deal with messaging/DTOs/Assemblers etc).

      I've worked on internal systems where we colocated and performance is improved dramatically. Serialization overhead was the root cause, not network latency. I thought this was an accepted fact in the Spring Community.

      So I suppose I'm saying that I don't accept remoting will incur no overhead.

      Plus I also don't want to have to deal with a much more complex remoting architecture if I don't have to.

      I just want to know how all you Spring guys are colocating the web and business tiers as recommended in Rod's book if your client's demand a DMZ like network topology.

      any thoughts?

      Neil

      Comment


      • #4
        Hi Neil,

        always that I can reply and help I will do.

        I supose that you refer to "J2EE Development without EJB" book, is in the Chapter 3 when talks about, explains the benefits of co-location versus separation, but also talks about the importance of separate the client side of business services too.

        If you have a good separation between layers the problem should be minor, in other case you will have remoting overhead. I believe too that co-locate both layers is the best option in terms of performance and simplicity, but I also believe that the client has always the ¿reason?.

        My last affirmation does not mean that you should not recommend other choice, in fact you should do. The arguments you need might be just the same that Rod explains in his book.

        I hope it helps.

        Greetings.

        Comment

        Working...
        X