Java Reference
In-Depth Information
Web
Browser
launch
Servlet
Server
Repository
Plug-In
Client
Deploy
let
server-side
management
deployment
services and
lifecycle
methods
user-applet
interaction
Server
Deploylet
End-User
F
IGURE
7.10
A deploylet runtime operation.
The client side and server side of the deploylet strictly interact (by means of the RMI proto-
col). By using such an architecture, a variety of deployment services and advanced features are
possible, even though we don't have a custom AH installed on the client platform (such as the
ad-hoc deployment architecture presented in Chapter 6, “Deploying Existing Software”).
Indeed, we can compare the two architectures, noting that this one is less “client-obtrusive,”
and the server needs to devote more resources than the other solution. Such an architecture is
perfectly suited for intranet environments, in which clients are possibly fewer and available
resources are greater (predictable connections, hardware resources, user population, and so on),
allowing for more sophisticated services.
It is important to point out that this architecture provides advanced deployment services, while
client applets are free to use any other business-related connection mechanism or code they
need (such as database JDBC connections, other RMI connections, and so on), just like “nor-
mal” Java code. Applets taking advantage of this framework could be developed faster and eas-
ier than usual applets.
What is interesting to see here is how this mechanism could cover the whole deployment
abstract model we discussed in Chapter 2.
Before getting any further, we anticipate some implementation details for clarity. The deploylet
entity is implemented in two classes—
ClientDeploylet
and
ServerDeploylet
—that share a
common
Deploylet
interface.
ServerDeploylets
are kept in an RMI-enabled server, imple-
mented in the
ServerRepositoryImpl
class that administers them.
Figure 7.11 shows a simplified version of that deployment model regarding the lifecycle issue.
