Recent top five:
Java.next -- Four languages that represent the future of Java
Blogger Stuart Halloway has begun a series of posts on trends that point to the future of the Java platform. In his first
post, he compares Clojure, Groovy, JRuby, and Scala -- four wildly different languages that nonetheless all play together
in the JRE. Find out what unites these languages and what they can tell us about the future of Java-based development ...
| Enterprise AJAX - Transcend the Hype |
| Memory Analysis in Eclipse |
| Oracle Compatibility Developer's Guide |
| Memory Analysis in Eclipse |
TEXTBOX:
TEXTBOX_HEAD: Activatable Jini services: Read the whole series!
:END_TEXTBOX
The notion of a service lies at the heart of Jini. The Jini Specification defines a service as "... something that can be used by a person, a program, or another service ... Services will appear programmatically as objects in the Java programming language, perhaps made up of other objects ... A service will have an interface, which defines the operations that can be requested of that service. The type of the service determines the interfaces that make up that service." (See Resources for the Jini Specification.)
In Jini, a software component makes its services available through a proxy. Other services must locate that proxy to interact with a service within djinn, a federation of Jini services. Jini offers a robust mechanism, based on the Java language interfaces implemented by the proxy, that helps you look up proxies and other optional parameters. However, the ubiquitous computing environments promised by Jini and other service-oriented architectures require a service that is easily locatable and readily available.
For services with simple functionality, the proxy, once retrieved from the lookup service, might be able to operate independently -- making it a "strictly local" proxy. For instance, a service that converts decimal numbers into their hexadecimal equivalents would likely perform this computation entirely in the client's address space. For more involved services, the proxy might have to communicate with external resources running on other hosts. An example would be a currency converter, which must obtain up-to-date currency valuations to perform its service. For such a service, the proxy is not enough -- any other resources the proxy needs must also be on hand.
The Jini Specification leaves the proxy, protocol, and server to communicate with the service implementation. The service implementation is hidden from the client, which only has to agree on the Java programming language interface, not a specific wire protocol, to interact with the service. Java Remote Method Invocation (RMI) can conveniently arrange such communication. All Jini services in Sun's implementation of the Jini Specification use RMI. Since Jini proxies can implement any part of the J2SE platform, of which RMI is a required component, any client VM using a Jini service proxy probably supports RMI.
RemoteException, explains why it is a checked exception and not a runtime exception, and discusses the difference between remote and local
method invocationsActivationGroupDesc can be used to set up a common environment for a group