Posts
The HttpUrlConnection is from the standard Java SE API and HttpClient is a Apache Commons library which is built on top of the standard Java SE one. Apache Commons libraries in turn are usually more convenienced and less opaque (read: less low-level).
In fact, everything can be done with the standard Java SE API. Major goal of those kind of libraries are just faster development and lesser code. In this particular example you can for instance send a POST request with just one or two HttpClient methods instead of writing 10~20 lines of code as you would do with plain
Features Comparison :
Explanations
[unsupported] - This feature exists in this release, but may not be supported in future releases.
idle connection timeout - Most servers timeout connections after a certain interval. When HTTP clients use connection pooling, the fact that the connection was closed is detected when the next request is written to the connection. If it's an idempotent request (like a GET, or PUT) then it can just be retried on a new connection. However, POST cannot be retried (we don't know if it has been processed by the server or not), so the user of the HTTP client will get an error on this POST. The Oakland Software implementation provides a facility to terminate connections which have been idle for a (configurable) length of time, or alternatively to send a "ping" message before using a connection (if it has been idle for a certain amount of time). This ensures that POST requests will not be affected by the server connection timeout processing.
pipelining of requests - This allows multiple requests to be sent on the same connection before getting the response to the first one. This can make a tremendous performance difference when fetching many objects from the same server (as you don't have to pay the round trip latency for each request). This can also make a substantial throughput difference when in high volume applications by reducing the latency and sharing the socket connections for multiple requests at a time. The Oakland Software pipelining implementation is the only implementation that automatically handles all authentication modes before starting pipelining, allows pipelining for POST (useful in certain controlled environments), and automatically adapts to the server closing connections for maximum pipelining performance.
non-blocking I/O - In most HTTP implementations, the outstanding HTTP request ties up a thread until it is completed. This restricts the number of outstanding HTTP requests to the number of possible threads, which is a significant limitation (since each thread consumes a certain amount of memory). With non-blocking I/O the request can be sent and the response can be received on a different thread, thus an unlimited number of outstanding connections can be active with a small number of active threads. This support is useful for applications where large numbers of connections must be processed quickly. This (especially combined with pipelining and the use of direct reading and writing from the socket) give maximum throughput.
connection pool throttling - This is very useful in certain server situations. This is a limit on the number of connections to a given host and port. The HTTP 1.1 specification recommends that no more than 2 connections are established (to a given host/port). In any of the other implementations (that use connection pooling) it will open as many connections as you have requested. This can cause problems for some servers.
connection request timeout - A good timeout mechanism has three parts: timeout when establishing the initial connection, setting the TCP timeout on the connection (so that each request is subject to the timeout), and, if connection pooling is used, timeout while waiting for a connection to be available from the pool. The Oakland Software implementation is the only implementation that supports all of these.
true request/response streams - The older JRE implementations by default record the request data into a byte array and does not actually send the data until the connection is open. This results in double copying of the data, resulting in slower performance in cases where there is a lot of data. Other implementations allow you to read/write directly to the underlying connection stream, avoiding this double copy of the data. It also avoids reading this data if not required by the application, which is not possible if there is not a true response input stream.
After JRE 5, direct streaming to the output was implemented by adding new methods (setChunkedStreamingMode() and setFixedLengthStreamingMode()) however, these methods will not work if the connection requires authentication. The Oakland Software implementation will perform the authentication automatically before beginning the streaming processing so streaming works transparently with authentication.
NTLM - The JRE 1.4.2 supports NTLM only on Windows. The Oakland Software and Apache HTTP clients support NTLM on any platform. However only the Oakland Software NTLM support correctly supports both Unicode and OEM encoding for NTLM and supports NTLM V2. The Sun implementation in JRE 6 and 1.5_08 and higher support NTLM V2 on all platforms, though on Windows they use the current user's credentials by default.
plug compatible - This is true if you can switch to this HTTP Client from the Sun HTTP client without changing any code and it will just work. This means the HTTP Client implements the java.net.HttpURLConnection class, and the necessary protocol handlers for HTTP and HTTPS.
versions - JRE versions prior to 1.2.x and 1.3.x are supported only with version 1.x of the Oakland Software HTTP client. This includes all of the features except pipelining and Axis2 support. Version 2.x and higher of the Oakland Software HTTP client require JRE version 1.4.2 or higher.
slow turnaround - You get fixes to the Sun HTTP Client when a new version of the JDK is released, which is usually a long wait.
fast turnaround - Considering the Oakland Software product is actively supported, and support contracts are available, fixes can be released as fast as next day and usually within a week.
medium turnaround - The Apache HTTP Client is supported as there are volunteers to work on it. Currently they offer pretty quick support, so long as you are willing to take their nightly builds. There have been periods though where no one was working on it, and this could be the case again. You can't be sure, but you can fix it yourself if you want.
In fact, everything can be done with the standard Java SE API. Major goal of those kind of libraries are just faster development and lesser code. In this particular example you can for instance send a POST request with just one or two HttpClient methods instead of writing 10~20 lines of code as you would do with plain
HttpUrlConnection. The same story applies on the Apache Commons IO v.s. java.io and Apache Commons Lang v.s. java.lang, Apache Commons Collections and Google Collections v.s. Java Collections, etcetera.Features Comparison :
- Oakland Software
- Sun JRE
- innovation.ch HTTPClient
- Apache HTTP Client
| Oakland Software | Sun JRE < 1.4.2 | Sun JRE >= 1.4.2 | Sun JRE >= 5 | Sun JRE >= 6 | Innovation | Apache | |
|---|---|---|---|---|---|---|---|
| Features | |||||||
| cookies | X | X | X | X | |||
| WebDAV support | X | ||||||
| Apache Axis/Axis2 support | Axis and Axis2 | Axis and Axis2 | |||||
| plug compatible | X | X | X | X | X | X | |
| multi-part POST (file upload) | X | ||||||
| true request output stream | X | X | X | X | X | ||
| auto authentication with streaming | X | ||||||
| true response input stream | X | X | X | X | X | X | X |
| connection keep alive | X | X | X | X | X | X | X |
| connection pool throttling | X | X | |||||
| connection/request timeout | X | X [uns] | X [uns] | X [uns] | X | X | |
| idle connection timeout | X | X | |||||
| pipelining of requests | X | X | |||||
| auto authentication with pipelining | X | ||||||
| non-blocking I/O | X | ||||||
| SSL | X | X | X | X | X | X | X |
| basic authentication | X | X | X | X | X | X | X |
| digest authentication | X | X | X | X | X | X | X |
| NTLM authentication | X | [Windows only] | [Windows only]* | X | [partial] | ||
| NTLM V2 authentication | X | [Windows only] | [Windows only]* | X* | |||
| proxy authentication | X | X | X | X | X | X | X |
| Support | |||||||
| minimum JRE version | 1.2* | 1.0 | 1.4.2 | 5 | 6 | 1.2 | 1.2 |
| price | not free | free | free | free | free | free | free |
| source available | X | X | X | ||||
| diagnostic tracing | X | X | X | ||||
| actively supported | X | X | X | X | X | X | |
| fix turnaround | fast | slow | slow | slow | slow | none | medium |
| license | purchase | Sun JRE | Sun JRE | Sun JRE | Sun JRE | LGPL | Apache |
Explanations
[unsupported] - This feature exists in this release, but may not be supported in future releases.
idle connection timeout - Most servers timeout connections after a certain interval. When HTTP clients use connection pooling, the fact that the connection was closed is detected when the next request is written to the connection. If it's an idempotent request (like a GET, or PUT) then it can just be retried on a new connection. However, POST cannot be retried (we don't know if it has been processed by the server or not), so the user of the HTTP client will get an error on this POST. The Oakland Software implementation provides a facility to terminate connections which have been idle for a (configurable) length of time, or alternatively to send a "ping" message before using a connection (if it has been idle for a certain amount of time). This ensures that POST requests will not be affected by the server connection timeout processing.
pipelining of requests - This allows multiple requests to be sent on the same connection before getting the response to the first one. This can make a tremendous performance difference when fetching many objects from the same server (as you don't have to pay the round trip latency for each request). This can also make a substantial throughput difference when in high volume applications by reducing the latency and sharing the socket connections for multiple requests at a time. The Oakland Software pipelining implementation is the only implementation that automatically handles all authentication modes before starting pipelining, allows pipelining for POST (useful in certain controlled environments), and automatically adapts to the server closing connections for maximum pipelining performance.
non-blocking I/O - In most HTTP implementations, the outstanding HTTP request ties up a thread until it is completed. This restricts the number of outstanding HTTP requests to the number of possible threads, which is a significant limitation (since each thread consumes a certain amount of memory). With non-blocking I/O the request can be sent and the response can be received on a different thread, thus an unlimited number of outstanding connections can be active with a small number of active threads. This support is useful for applications where large numbers of connections must be processed quickly. This (especially combined with pipelining and the use of direct reading and writing from the socket) give maximum throughput.
connection pool throttling - This is very useful in certain server situations. This is a limit on the number of connections to a given host and port. The HTTP 1.1 specification recommends that no more than 2 connections are established (to a given host/port). In any of the other implementations (that use connection pooling) it will open as many connections as you have requested. This can cause problems for some servers.
connection request timeout - A good timeout mechanism has three parts: timeout when establishing the initial connection, setting the TCP timeout on the connection (so that each request is subject to the timeout), and, if connection pooling is used, timeout while waiting for a connection to be available from the pool. The Oakland Software implementation is the only implementation that supports all of these.
true request/response streams - The older JRE implementations by default record the request data into a byte array and does not actually send the data until the connection is open. This results in double copying of the data, resulting in slower performance in cases where there is a lot of data. Other implementations allow you to read/write directly to the underlying connection stream, avoiding this double copy of the data. It also avoids reading this data if not required by the application, which is not possible if there is not a true response input stream.
After JRE 5, direct streaming to the output was implemented by adding new methods (setChunkedStreamingMode() and setFixedLengthStreamingMode()) however, these methods will not work if the connection requires authentication. The Oakland Software implementation will perform the authentication automatically before beginning the streaming processing so streaming works transparently with authentication.
NTLM - The JRE 1.4.2 supports NTLM only on Windows. The Oakland Software and Apache HTTP clients support NTLM on any platform. However only the Oakland Software NTLM support correctly supports both Unicode and OEM encoding for NTLM and supports NTLM V2. The Sun implementation in JRE 6 and 1.5_08 and higher support NTLM V2 on all platforms, though on Windows they use the current user's credentials by default.
plug compatible - This is true if you can switch to this HTTP Client from the Sun HTTP client without changing any code and it will just work. This means the HTTP Client implements the java.net.HttpURLConnection class, and the necessary protocol handlers for HTTP and HTTPS.
versions - JRE versions prior to 1.2.x and 1.3.x are supported only with version 1.x of the Oakland Software HTTP client. This includes all of the features except pipelining and Axis2 support. Version 2.x and higher of the Oakland Software HTTP client require JRE version 1.4.2 or higher.
slow turnaround - You get fixes to the Sun HTTP Client when a new version of the JDK is released, which is usually a long wait.
fast turnaround - Considering the Oakland Software product is actively supported, and support contracts are available, fixes can be released as fast as next day and usually within a week.
medium turnaround - The Apache HTTP Client is supported as there are volunteers to work on it. Currently they offer pretty quick support, so long as you are willing to take their nightly builds. There have been periods though where no one was working on it, and this could be the case again. You can't be sure, but you can fix it yourself if you want.
No comments:
Post a Comment