/ciol/media/agency_attachments/c0E28gS06GM3VmrXNw5G.png)
Follow UsBrian Maso
Up until Java 2, a real-world project had a lot of infrastructure to build: what with class loaders, security, distributed lookup and communications, etc. Between JavaTM 1.1 and Java 2 Sun fleshed-out concrete implementations of what had been merely interesting abstractions:
Security managers based on a concrete java.lang.SecurityManager implementation
Secure class loading based on java.lang.SecureClassLoader
A rich GUI framework provided by Swing
And the motley crew of distributed application tools provided by Java 1.1 is a parade of frameworks in Java 2--it's difficult for a single programmer to even get a handle on the differences between Jini, Enterprise JavaBeansTM, JMX, FMA/Jiro, Java Naming and Directory InterfaceTM, JMS, etc.
Interestingly, of these powerful APIs and implementations, almost all have strong dependencies on URL objects. HTTP and FTP are good, general purpose protocols--definitely enough for general stream-based resource access. For fine-grained resource types like internationalizable resource strings, Java class file resources, and security policy resources, the workhorse HTTP and FTP protocols are long in the tooth and short on configurable performance. For faster, more efficient data flow you often need protocols designed for specific applications.
Based on a set of easily configurable factory patterns, the java.net.URL architecture allows you to implement easily a custom protocol handler and slip it into an application's java.net.URL class structure. This architecture has hardly changed since 1.0. Only now, with all the dependencies on URLs in Java 2's Core APIs and extensions, is it really worth your while to study this architecture and maybe even build your own custom protocol handlers. The really cool part is that your custom protocol handler is instantly usable by all of Java 2's advanced API implementations. For example, you can use a java.net.URLClassLoader to load classes using not just "file:"-, "http:"-, and "ftp:"- based classes and other resources, but also to access resources based on your own custom protocols--DB-based protocols, protocols with complex encryption and security, or maybe XML-based protocols (SOAP, XML-RPC, and so forth.).
In addition, custom protocols and URLs fit right into Java 2's configurable code-based security. A Java policy file that refers to your custom protocols will correctly sandbox code loaded using those protocols.
The myriad of systems coming from major vendors based on migrating code-such as Jini, JMX, FMA/Jiro, Java Embedded Server, etc., or are also based, ultimately, on the lowly java.net.URL class and its architecture of pluggable protocol handlers. This paper describes for you everything you need to know to exploit the custom protocol plug-in architecture. After reading this paper, you'll have a good understanding of the java.net.URL architecture and how different java.net package objects interact to resolve URLs into resource streams. Knowing the architecture shows you how to build your own protocol handlers, which involves (at a minimum) providing a concrete implementation of two important java.net packet classes: java.net.URLStreamHandler and java.net.URLConnection. Once you've designed and created a custom protocol handler, you'll also need to know some tricks about deploying them in real-world Java execution environments. For most deployment scenarios, just placing a protocol handler on the classpath isn't enough. This paper details everything you need to know about deployment.
Once you have the architecture, know how to implement, and know how to deploy custom protocol handlers, you'll be able to integrate them into your Java-based applications with ease.