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.