Thursday, April 29, 2010
Tuesday, April 6, 2010
Monday, April 5, 2010
Asynchronous HTTP and Comet architectures
Asynchronous HTTP and Comet architectures
Comet has popularized the asynchronous processing and non-blocking streaming of response data. Comet defines a Web architecture that enables the server to push events or data to the client without waiting for the client to request it. In essence, the Comet pattern is based on creating and maintaining long-lived HTTP connections.
Comet has popularized the asynchronous processing and non-blocking streaming of response data. Comet defines a Web architecture that enables the server to push events or data to the client without waiting for the client to request it. In essence, the Comet pattern is based on creating and maintaining long-lived HTTP connections.
Tutorials & Code Camps A New Era for Java Protocol Handlers
Tutorials & Code Camps: A New Era for Java Protocol Handlers
Introduction
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.
Introduction
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.
Asynchronous HTTP Connections on Android: A Tutorial
Asynchronous HTTP Connections on Android: A Tutorial
For a pleasant Android user experience it is vital for applications to actively provide feedback. When downloading images and data from the web, delays are expected. Developers should implement asynchronous connections and provide active feedback on their progress.
Throttling connections is another important technique. Android phones are mainly on 3G and Edge connections and are prone to slow connection speeds. Imagine downloading 100 images from the web simultaneously at 1 KB/second each. That certainly doesn’t make for the greatest user experience. Executing connections in smaller chunks is a much better option. For example, downloading those 100 images I mentioned earlier in chunks of 5 connections would allow for a comparable 20 KB/second rate.
Below is an example of my asynchronous HTTP connection implementation using the classes HttpConnection and ConnectionManager. It uses Apache’s HttpClient methods and allows for GET, POST, PUT and DELETE requests. A built in Bitmap decoder is also included.
To receive status updates from an HttpConnection a Handler is used (but not required). The HttpConnection will dispatch a message to the Handler at the occurrence of the following:
HttpConnection.DID_START – The connection is removed from the ConnectionManager’s queue and started
HttpConnection.DID_SUCCEED – The connection was successful and the response is stored in the Message instance obj field
HttpConnection.DID_ERROR – The connection failed and the exception is stored in the Message instance obj field
For a pleasant Android user experience it is vital for applications to actively provide feedback. When downloading images and data from the web, delays are expected. Developers should implement asynchronous connections and provide active feedback on their progress.
Throttling connections is another important technique. Android phones are mainly on 3G and Edge connections and are prone to slow connection speeds. Imagine downloading 100 images from the web simultaneously at 1 KB/second each. That certainly doesn’t make for the greatest user experience. Executing connections in smaller chunks is a much better option. For example, downloading those 100 images I mentioned earlier in chunks of 5 connections would allow for a comparable 20 KB/second rate.
Below is an example of my asynchronous HTTP connection implementation using the classes HttpConnection and ConnectionManager. It uses Apache’s HttpClient methods and allows for GET, POST, PUT and DELETE requests. A built in Bitmap decoder is also included.
To receive status updates from an HttpConnection a Handler is used (but not required). The HttpConnection will dispatch a message to the Handler at the occurrence of the following:
HttpConnection.DID_START – The connection is removed from the ConnectionManager’s queue and started
HttpConnection.DID_SUCCEED – The connection was successful and the response is stored in the Message instance obj field
HttpConnection.DID_ERROR – The connection failed and the exception is stored in the Message instance obj field
Subscribe to:
Comments (Atom)
