Java Reference
In-Depth Information
the number of departments, increase the user load, and increase the volume of data
involved, then things might be a little more constrained. These sorts of scaling
requirements mean that many enterprise applications can't run on a single server
because the volume of data and users would overwhelm the system. At this point, you
have no choice but to distribute the application over more than one machine. This
distribution process can be extremely painful if the application hasn't been designed
for it. Fortunately, well-written
OSG
i code lends itself well to distributed systems, and
the
OSG
i Enterprise Specification offers us a standard mechanism for expanding
OSG
i
beyond a single framework using remote services.
Before we dive straight into the details of authoring a remote service, let's first
make sure you understand some of the reasons why you might want to access a remote
service. It's also important that you know about the drawbacks of using remote calls
instead of local ones, particularly that you understand the limitations that being
remotely available places on the design of the service you wish to access. It would be
embarrassing to author a remote service only to find that you can't use it remotely!
10.1
The principles of remoting
Enterprise applications have to cope with huge scales, both in terms of the application
and the user base. As an application and the demands upon it get bigger, it becomes
impractical, or even impossible, to host the whole application on a single machine.
Accessing services hosted on another machine is therefore a vitally important part of
enterprise programming.
10.1.1
The benefits of remoting
The primary benefit of remoting is obvious: by allowing applications to access services
and/or resources on another machine, you can dramatically reduce the computa-
tional load on a single machine. Spreading computationally difficult and memory-
intensive tasks out to remote machines ensures that the server hosting your frontend
has ample resources to accept new
HTTP
connections from other clients.
Remoting isn't the only way to scale out applications. As you've seen from the
example applications in this topic, it's perfectly feasible to write an enterprise applica-
tion that can live comfortably on a single machine. But if this application needs to
support a large number of concurrent users, then that single machine may not be
capable of servicing every request without overloading its
CPU
or network adapter.
Often applications like these are scaled out
horizontally
by adding more machines run-
ning the same application. Using a simple router fronting, these machines' clients can
be transparently redirected to an instance of the application. Most routers are even
able to remember which machine a client has previously been redirected to and
ensure subsequent requests are sent to the same machine (see figure 10.1). Given that
this sort of design is possible, why would you bother physically separating parts of your
application with remoting?
