Sponsored Link •
Now that I've identified a few advantages of objects over documents, I'd like to consider some disadvantages of using the object approach for client-server interaction.
One potential disadvantage of the object approach is the amount of client-side overhead required to receive and use a mobile object. To host a Jini service object, for example, a client needs a Java virtual machine and a significant set of Java APIs. If your client only needs to deal with one or two kinds of services, taking the protocol approach will likely yield a client program with a smaller footprint. Why? Because the footprint of a client taking the object approach will, by definition, include the footprint of some incarnation of the Java Platform.
If the machine that will be hosting your client has sufficient resources (for example, if you will be running your client on a PC or workstation), selecting and installing an implementation of the Java Platform is quite straightforward. The future trend, however, is that more embedded devices will be connected to networks, and those embedded devices will want to offer and consume services across those networks. The economics of many embedded devices are such that very tiny increments in unit cost can quickly translate into real money. As a result, there is usually great pressure to constrain the computation resources of an embedded device to the minimum amount possible. If an embedded device can get by with speaking just a handful of protocols, therefore, the chances are good that the protocol approach will be deemed more economically viable than the object approach. (Note that in this discussion I am considering the economic effects of just the technical differences between the object and document approaches. Embedded device vendors who are interested in Jini also need to worry about signing a commercial agreement with Sun in conjunction with the Sun Community Source License (SCSL), and paying the required logo fee.)
If you are developing an embedded light-switch device, for example, and you want to offer a simple on/off-switch service across the network from the device, it would likely not make economic sense to put a JVM in that light switch. Instead, your light switch would talk a protocol.
Yet with a little help, a protocol-based service could still participate in a Jini federation. For example, somewhere nearby on the network to which the light switch is connected, perhaps in a set-top box or some other central host or gateway, a Java Platform could reside. On top of that Java Platform, some software (a "surrogate") could serve as an object-oriented front end to the light switches. Through this surrogate, clients and other services can use object-level interfaces to talk to the light switches. The light switches themselves talk to the surrogate via a network protocol. The surrogate project at Jini.org is currently working to define a standard way to bring protocol-based services to Jini federations using such an architecture.
Another concern raised by the mobile object approach is the increased potential for denial-of-service assaults, be they intentional or the result of an unintended bug. Although the Java Platform has an extensive security model that you can use to prevent untrusted code from taking many actions that could represent security threats, the security model does not guard against certain denial-of-service attacks. For example, a network-mobile object could fire off threads, allocate memory, or open sockets until the client-side resources are fully consumed. Or, network-mobile objects could merely neglect to release the fair share of client resources they legitimately claimed, resulting in a gradual resource leak.
Denial-of-service attacks in general are difficult to guard against. Even the protocol approach has potential avenues for these attacks. A Web server, for example, could serve up an infinite length page that would fill up the client browser's cache. Or, a server could be kept so busy dealing with fake client requests that it has no time to handle actual client requests. But the mobile object approach, because it involves injecting code into a client, opens up many more avenues for creative denial-of-service attacks compared to the mobile document approach. This aspect of mobile objects will generally make it infeasible to pull mobile objects into certain kinds of environments, such as mission-critical servers.
Another security-related disadvantage of mobile objects is that despite Java's security model, mobile objects still carry a greater security risk than mobile documents that don't contain executable code. Although Java's security model has extensive and flexible mechanisms to protect client-side systems from malicious or buggy mobile code, various implementations of the Java Platform have occasionally contained bugs that opened up security holes. Although these bugs have historically been promptly fixed, and no actual damage has ever resulted from them, the very possibility of future bugs raises the risk of hosting mobile objects compared to documents. In addition, the complexity of defining a security policy more lenient than the standard applet sandbox creates the risk of mistakes that could also open up security holes. For some security-sensitive environments, therefore, these risks of bugs in the security model implementation, or human error in configuring it, may disqualify the mobile object approach.