Figure 10.4 In combination with a firewall, an intermediate server can be used to provide safe access
to a secure system without allowing direct access to it.
much use at all. On the other hand, you don't want users to have free access to the data-
base machine, or probably even access to the network port exposing the database.
Remoting allows you to get around these sorts of problems by accessing a third
party. If you have a reasonably secure intermediary system, then you can use that to
access the backend service that you need. The intermediary is trusted to only access
the database in a safe way, and so can be allowed through the firewall, whereas the cli-
ent speaks to the intermediary and is shielded from the valuable content of the data-
base (see figure 10.4).
This model isn't useful only for improving security; it also has a significant role to
play in the performance of your system. It's best if services you access regularly can be
accessed quickly. This is most likely if you're physically close (co-located) to the service
you want to access. If performing a particular task requires you to access a service mul-
tiple times, then sending a single request to an intermediary, which then makes the
rest of the calls and returns the result, can provide a significant performance boost.
Although remoting does have a number of advantages, it should be noted that
there are some drawbacks when accessing remote systems.
The drawbacks of remoting
Although remoting is a critical part of enterprise programming, there are good rea-
sons why it isn't used a lot of the time. Probably the single biggest reason that people
avoid remoting is because of performance.
WHY REMOTING IS SO SLOW
One of the big lessons for most programmers is to avoid prematurely optimizing your
code; still, it's worth thinking about trying to avoid things that have a negative impact
Search WWH ::