<!--
  ~ Licensed to the Apache Software Foundation (ASF) under one
  ~ or more contributor license agreements. See the NOTICE file
  ~ distributed with this work for additional information
  ~ regarding copyright ownership. The ASF licenses this file
  ~ to you under the Apache License, Version 2.0 (the
  ~ "License"); you may not use this file except in compliance
  ~ with the License. You may obtain a copy of the License at
  ~
  ~ http://www.apache.org/licenses/LICENSE-2.0
  ~
  ~ Unless required by applicable law or agreed to in writing,
  ~ software distributed under the License is distributed on an
  ~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  ~ KIND, either express or implied. See the License for the
  ~ specific language governing permissions and limitations
  ~ under the License.
  -->

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
  "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="content-type" content=""/>
  <title>Axis2/Java HTTP/2 Integration Guide</title>
</head>

<body lang="en">

<h1>Axis2/Java HTTP/2 Integration Guide</h1>

<div style="background-color: #f0f8ff; border: 1px solid #0066cc; padding: 10px; margin: 10px 0;">
<strong>🏢 WildFly Users:</strong> If you're using <strong>WildFly application server</strong>, please refer to the
<a href="wildfly-http2-integration-guide.html">WildFly + Axis2 HTTP/2 Integration Guide</a> for optimized
configuration that provides enhanced performance through cooperative integration with Undertow.
</div>

<div style="background-color: #f0f8ff; border: 1px solid #0066cc; padding: 15px; margin: 15px 0;">
<h3>Quick start — pick your path</h3>
<ul>
  <li><strong>Just want the config?</strong> →
      <a href="axis2-http2-simplified-example.html">2 parameters in axis2.xml</a></li>
  <li><strong>Streaming large responses?</strong> →
      <a href="json-streaming-formatter.html">Streaming JSON Formatter</a>
      (64 KB flush + <code>?fields=</code> field selection)</li>
  <li><strong>WildFly?</strong> →
      <a href="wildfly-http2-integration-guide.html">WildFly HTTP/2 guide</a>
      &nbsp;|&nbsp; <strong>Tomcat?</strong> →
      <a href="tomcat-http2-integration-guide.html">Tomcat HTTP/2 guide</a></li>
  <li><strong>Why is Axis2 different?</strong> →
      <a href="#How_Axis2_HTTP2_Differs_From_Other_Frameworks">framework comparison</a> (below)</li>
</ul>
</div>

<h2>Overview</h2>

<p>Apache Axis2/Java has <strong>native HTTP/2 support</strong> via a dedicated
transport module (<code>modules/transport-h2</code>) built on Apache
HttpComponents 5.x. The architecture supports <strong>both HTTP/1.1 and
HTTP/2 as independent transport implementations</strong>, with runtime
protocol selection and automatic fallback. HTTP/2 awareness extends
into the JSON serialization pipeline — streaming formatters flush
every 64 KB, converting buffered responses into HTTP/2 DATA frames
during serialization rather than after. This is designed for
enterprise applications that process large JSON payloads (50MB+).</p>

<p><em>Note: sections below titled "Phase" or "Proposed" reflect the
original design process and are retained for architectural context.
The implementation is complete — see
<code>modules/transport-h2</code> and
<code>org.apache.axis2.json.streaming</code>.</em></p>

<h2>How Axis2 HTTP2 Differs From Other Frameworks</h2>

<p>Most web service frameworks treat HTTP/2 as a transparent transport
upgrade — the servlet container (Tomcat, Undertow, Netty) negotiates
HTTP/2 via ALPN, and the framework's serialization layer is unaware of
the underlying protocol. The response is fully buffered in memory before
being handed to the container, which then splits it into HTTP/2 DATA
frames. This means a 50MB JSON response is buffered as a single 50MB
byte array regardless of whether the wire protocol is HTTP/1.1 or
HTTP/2.</p>

<p>Axis2/Java takes a fundamentally different approach:
<strong>HTTP/2 awareness is built into the serialization pipeline
itself</strong>, not just the transport layer.</p>

<ul>
  <li><strong>Dedicated HTTP/2 transport module</strong>
      (<code>modules/transport-h2</code>) — a standalone module with
      ALPN protocol negotiation
      (<code>ALPNProtocolSelector</code>), per-stream flow control
      (<code>H2FlowControlManager</code>,
      <code>ProgressiveFlowControl</code>), adaptive buffering
      (<code>AdaptiveBufferManager</code>), compression optimization
      (<code>CompressionOptimizer</code>), and HTTP/1.1 fallback
      (<code>H2FallbackManager</code>). This is not a wrapper around
      the servlet container's HTTP/2 — it is an independent
      implementation using Apache HttpComponents 5.x.</li>
  <li><strong>Streaming JSON formatters</strong>
      (<code>MoshiStreamingMessageFormatter</code>,
      <code>JSONStreamingMessageFormatter</code>) — flush every 64 KB
      via <code>FlushingOutputStream</code>, converting a single
      buffered response into a stream of HTTP/2 DATA frames during
      serialization. Non-selected fields are never serialized when
      field filtering is active
      (<code>FieldFilteringMessageFormatter</code>). See
      <a href="json-streaming-formatter.html">Streaming JSON Formatter</a>.</li>
  <li><strong>C parity</strong> — the same architecture exists in
      <a href="https://axis.apache.org/axis2/c/core/">Axis2/C</a> via
      <a href="https://httpd.apache.org/">Apache httpd</a> <code>mod_h2</code> with
      <code>ap_rflush()</code> in the message formatter. Both
      implementations use the same 64 KB flush interval, producing
      identical HTTP/2 DATA frame patterns from both C and Java
      endpoints.</li>
</ul>

<p>For comparison with other frameworks:</p>

<table border="1">
  <tr>
    <th>Framework</th>
    <th>HTTP/2 approach</th>
    <th>Serialization-layer awareness</th>
    <th>Streaming during serialization</th>
  </tr>
  <tr>
    <td>Spring MVC / Spring WebFlux</td>
    <td>Servlet container handles HTTP/2 transparently</td>
    <td>No — ResponseEntity buffers in full</td>
    <td>WebFlux reactive streams possible, but not integrated into message formatters</td>
  </tr>
  <tr>
    <td>JAX-RS (Jersey, RESTEasy)</td>
    <td>Servlet container handles HTTP/2 transparently</td>
    <td>No — MessageBodyWriter buffers in full by default</td>
    <td>StreamingOutput possible but manual</td>
  </tr>
  <tr>
    <td>gRPC</td>
    <td>Mandatory HTTP/2 (the protocol is built on it)</td>
    <td>Yes — protobuf serialization is streaming-native</td>
    <td>Yes — but gRPC is a protocol, not an add-on</td>
  </tr>
  <tr>
    <td>Django REST Framework</td>
    <td>ASGI server handles HTTP/2; framework is oblivious</td>
    <td>No</td>
    <td>No</td>
  </tr>
  <tr>
    <td><strong>Apache Axis2/Java</strong></td>
    <td><strong>Dedicated transport-h2 module + ALPN negotiation + flow control</strong></td>
    <td><strong>Yes — FlushingOutputStream in the JSON formatter pipeline</strong></td>
    <td><strong>Yes — 64 KB incremental flush, field filtering during serialization, C/Java parity</strong></td>
  </tr>
</table>

<p>The practical impact: a 50MB Axis2 JSON response flows to the client
in ~780 HTTP/2 DATA frames as serialization progresses, with the first
frame arriving within milliseconds of the first serialized field. A
50MB Spring MVC response arrives as a single burst after the entire
object graph is serialized. For large payloads behind reverse proxies
(nginx, AWS ALB/NLB), the Axis2 approach prevents 502 Bad Gateway
timeouts because the proxy sees continuous data flow rather than a long
silence followed by a large write.</p>

<h2>Architecture Strategy: Dual-Protocol Design</h2>

<h3>Core Design Principle</h3>

<p><strong>Independent Protocol Implementations</strong>: HTTP/1.1 and HTTP/2 are implemented as separate, independent transport modules to ensure:</p>
<ul>
  <li><strong>Clean Separation</strong>: No shared code paths that could introduce compatibility issues</li>
  <li><strong>Protocol Selection</strong>: Runtime choice between HTTP/1.1 or HTTP/2 (not simultaneous)</li>
  <li><strong>Risk Mitigation</strong>: HTTP/1.1 remains completely unchanged as fallback</li>
  <li><strong>Future Maintenance</strong>: Each protocol can evolve independently</li>
</ul>

<h3>Module Structure</h3>

<pre>
modules/
├── transport/
│   └── http/          # Existing HTTP/1.1 implementation (unchanged)
│       ├── src/main/java/org/apache/axis2/transport/http/
│       │   ├── impl/httpclient5/     # Current HttpClient 5.x HTTP/1.1
│       │   ├── server/               # HTTP/1.1 server components
│       │   └── *.java               # Core HTTP/1.1 transport classes
│       └── src/test/java/           # HTTP/1.1 tests
│
└── transport-h2/      # Independent HTTP/2 module (new)
    ├── pom.xml         # Independent Maven module
    ├── src/main/java/org/apache/axis2/transport/h2/
    │   ├── impl/httpclient5/     # HTTP/2-specific HttpClient 5.x async
    │   ├── server/               # HTTP/2 server components
    │   └── *.java               # HTTP/2 transport classes
    └── src/test/java/           # HTTP/2-specific tests
</pre>

<h3>Package Mapping Strategy</h3>

<p><strong>HTTP/1.1 Packages (Unchanged)</strong>:</p>
<ul>
  <li><code>org.apache.axis2.transport.http.*</code></li>
  <li><code>org.apache.axis2.transport.http.impl.httpclient5.*</code></li>
  <li><code>org.apache.axis2.transport.http.server.*</code></li>
</ul>

<p><strong>HTTP/2 Packages (New Independent Module)</strong>:</p>
<ul>
  <li><code>org.apache.axis2.transport.h2.*</code></li>
  <li><code>org.apache.axis2.transport.h2.impl.httpclient5.*</code></li>
  <li><code>org.apache.axis2.transport.h2.server.*</code></li>
</ul>

<h3>Protocol Selection Configuration</h3>

<p><strong>Axis2 Configuration (axis2.xml)</strong>:</p>
<pre>
&lt;!-- HTTP/1.1 Transport (Default) --&gt;
&lt;transportSender name="http" class="org.apache.axis2.transport.http.impl.httpclient5.HTTPClient5TransportSender"&gt;
    &lt;parameter name="PROTOCOL"&gt;HTTP/1.1&lt;/parameter&gt;
&lt;/transportSender&gt;

&lt;!-- HTTP/2 Transport (Independent Module) --&gt;
&lt;transportSender name="h2" class="org.apache.axis2.transport.h2.impl.httpclient5.H2TransportSender"&gt;
    &lt;parameter name="PROTOCOL"&gt;HTTP/2.0&lt;/parameter&gt;
    &lt;parameter name="maxConcurrentStreams"&gt;100&lt;/parameter&gt;
    &lt;parameter name="initialWindowSize"&gt;2097152&lt;/parameter&gt;
&lt;/transportSender&gt;
</pre>

<p><strong>Runtime Protocol Selection</strong>:</p>
<pre>
// Application chooses protocol at service configuration
MessageContext msgContext = new MessageContext();
msgContext.setProperty(Constants.Configuration.TRANSPORT_NAME, "h2");    // HTTP/2
// msgContext.setProperty(Constants.Configuration.TRANSPORT_NAME, "http"); // HTTP/1.1
</pre>

<p><strong>Deployment Modes</strong>:</p>
<ol>
  <li><strong>HTTP/1.1 Only</strong>: Deploy only the existing <code>transport/http</code> module</li>
  <li><strong>HTTP/2 Only</strong>: Deploy only the new <code>transport-h2</code> module</li>
  <li><strong>Dual Support</strong>: Deploy both modules, select per service/operation</li>
</ol>

<h2>Implementation Benefits</h2>

<h3>Advantages ✅</h3>

<h4>1. Risk Mitigation</h4>
<ul>
  <li><strong>Zero Impact on HTTP/1.1</strong>: Existing implementation remains completely unchanged</li>
  <li><strong>Independent Development</strong>: HTTP/2 features can be developed without affecting stable HTTP/1.1</li>
  <li><strong>Easy Rollback</strong>: Can disable HTTP/2 module if issues arise</li>
  <li><strong>Gradual Migration</strong>: Services can migrate to HTTP/2 individually</li>
</ul>

<h4>2. Clean Architecture</h4>
<ul>
  <li><strong>Clear Separation</strong>: No conditional logic mixing HTTP/1.1 and HTTP/2 code paths</li>
  <li><strong>Dedicated Optimization</strong>: Each protocol can be optimized independently</li>
  <li><strong>Maintainability</strong>: Future changes to one protocol don't affect the other</li>
  <li><strong>Testing Isolation</strong>: Separate test suites prevent cross-protocol issues</li>
</ul>

<h4>3. Deployment Flexibility</h4>
<ul>
  <li><strong>Protocol Choice</strong>: Applications can choose optimal protocol per use case</li>
  <li><strong>Performance Testing</strong>: Easy A/B testing between protocols</li>
  <li><strong>Incremental Adoption</strong>: Organizations can adopt HTTP/2 at their own pace</li>
  <li><strong>Backward Compatibility</strong>: Legacy systems continue using HTTP/1.1 seamlessly</li>
</ul>

<h3>Disadvantages ⚠️</h3>

<h4>1. Code Duplication</h4>
<ul>
  <li><strong>File Count</strong>: ~56 Java files duplicated (2x maintenance burden)</li>
  <li><strong>Bug Fixes</strong>: Security fixes need to be applied to both modules</li>
  <li><strong>Feature Parity</strong>: New features may need implementation in both protocols</li>
</ul>

<h4>2. JAR Size Impact</h4>
<ul>
  <li><strong>Binary Size</strong>: ~40-50% increase in transport module size</li>
  <li><strong>Memory Footprint</strong>: Both protocol implementations loaded (even if only one used)</li>
  <li><strong>Deployment Overhead</strong>: Larger WAR/EAR files</li>
</ul>

<h2>HTTP/2 Configuration Guide</h2>

<h3>Simplified HTTP/2 Transport Configuration</h3>

<div style="background-color: #f0f8ff; border: 1px solid #0066cc; padding: 10px; margin: 10px 0;">
<strong>🎯 Intelligent Defaults:</strong> All HTTP/2 and Enhanced Moshi H2 parameters now have
production-ready intelligent defaults. <strong>Minimal configuration required!</strong>
<br/><em>Note: Enhanced GSON H2 support also available (Moshi preferred for performance)</em>
</div>

<p><strong>1. Minimal HTTP/2 Transport Configuration (Recommended):</strong></p>
<pre>
&lt;!-- Minimal HTTP/2 configuration - intelligent defaults handle the rest --&gt;
&lt;transportSender name="h2" class="org.apache.axis2.transport.h2.impl.httpclient5.H2TransportSender"&gt;
    &lt;parameter name="PROTOCOL"&gt;HTTP/2.0&lt;/parameter&gt;
&lt;/transportSender&gt;
</pre>

<p><strong>2. Optional Parameter Override (Advanced):</strong></p>
<pre>
&lt;!-- Override defaults only if needed for specific requirements --&gt;
&lt;transportSender name="h2" class="org.apache.axis2.transport.h2.impl.httpclient5.H2TransportSender"&gt;
    &lt;parameter name="PROTOCOL"&gt;HTTP/2.0&lt;/parameter&gt;
    &lt;!-- Optional: Override intelligent defaults if required --&gt;
    &lt;parameter name="maxConcurrentStreams"&gt;100&lt;/parameter&gt;        &lt;!-- Default: 100 --&gt;
    &lt;parameter name="initialWindowSize"&gt;2097152&lt;/parameter&gt;       &lt;!-- Default: 2097152 (2MB: avoids flow-control round trips) --&gt;
    &lt;parameter name="maxConnectionsTotal"&gt;50&lt;/parameter&gt;          &lt;!-- Default: 50 --&gt;
    &lt;parameter name="connectionTimeout"&gt;30000&lt;/parameter&gt;        &lt;!-- Default: 30000 (30s) --&gt;
    &lt;parameter name="responseTimeout"&gt;300000&lt;/parameter&gt;         &lt;!-- Default: 300000 (5m) --&gt;
&lt;/transportSender&gt;
</pre>

<p><strong>2. Service-Level HTTP/2 Configuration:</strong></p>
<pre>
// Enable HTTP/2 for specific service operations
ServiceClient client = new ServiceClient();
client.getOptions().setProperty(Constants.Configuration.TRANSPORT_NAME, "h2");
client.getOptions().setTo(new EndpointReference("https://example.com/service"));
</pre>

<p><strong>3. Large Payload Optimization:</strong></p>
<p>Streaming for large payloads is enabled by selecting a streaming message
formatter (e.g. <code>MoshiStreamingMessageFormatter</code>) in axis2.xml.
No programmatic property flags are required — the formatter handles
chunked HTTP/2 DATA frames and flow control automatically.</p>

<h3>Performance Tuning (Optional Overrides)</h3>

<div style="background-color: #e8f5e8; border: 1px solid #4CAF50; padding: 10px; margin: 10px 0;">
<strong>✅ Automatic Optimization:</strong> Intelligent defaults are already optimized for:
<ul>
  <li><strong>Memory-Constrained Environments</strong> - Conservative connection limits for smaller deployments</li>
  <li><strong>Enterprise Big Data Processing</strong> - 64KB buffers for 50MB+ JSON payloads</li>
  <li><strong>Enhanced Moshi H2 Integration</strong> - Async processing thresholds and memory management (GSON H2 also supported)</li>
</ul>
</div>

<p><strong>Default Intelligent Configuration (Automatic):</strong></p>
<pre>
&lt;!-- These values are automatically applied - no configuration needed --&gt;
maxConcurrentStreams = 100        (Memory-constrained: vs library default 1000)
maxConnectionsTotal = 50          (Memory-constrained: vs library default 100)
maxConnectionsPerRoute = 10       (Route-specific limit: vs library default 20)
initialWindowSize = 2097152       (2MB: avoids flow-control round trips)
streamingBufferSize = 65536       (64KB chunks for 50MB+ processing)
connectionKeepAliveTime = 300000  (5 minutes balanced timeout)
responseTimeout = 300000          (5 minutes for large payload processing)

</pre>

<p><strong>Override Only If Required (Advanced Tuning):</strong></p>
<pre>
&lt;!-- Example: Custom tuning for specific enterprise requirements --&gt;
&lt;parameter name="maxConcurrentStreams"&gt;200&lt;/parameter&gt;     &lt;!-- Higher concurrency for powerful servers --&gt;
&lt;parameter name="initialWindowSize"&gt;131072&lt;/parameter&gt;     &lt;!-- 128KB for very large payloads --&gt;
</pre>

<h2>Performance Expectations</h2>

<h3>Expected Benefits</h3>

<p>HTTP/2 provides structural improvements over HTTP/1.1. Actual gains
depend on payload size, network conditions, and JVM configuration:</p>

<ul>
  <li><strong>Connection multiplexing</strong> — many concurrent streams over a single TCP connection,
    eliminating the 6-8 connection limit of HTTP/1.1</li>
  <li><strong>Header compression</strong> — HPACK reduces per-request overhead, especially for
    APIs with large or repetitive headers</li>
  <li><strong>Streaming</strong> — large JSON responses can be flushed incrementally via
    HTTP/2 DATA frames, reducing time-to-first-byte</li>
  <li><strong>Fewer connections</strong> — multiplexing typically reduces connection count by 80%+</li>
</ul>

<h3>Memory Optimization Strategy</h3>

<ol>
  <li><strong>Connection Pooling</strong>:
    <ul>
      <li>HTTP/1.1: 50 connections × 2MB = 100MB overhead</li>
      <li>HTTP/2: 10 connections × 1MB = 10MB overhead</li>
      <li><strong>Savings: 90MB memory</strong></li>
    </ul>
  </li>
  <li><strong>Request Queuing</strong>:
    <ul>
      <li>HTTP/1.1: Per-connection queuing</li>
      <li>HTTP/2: Stream-based queuing with backpressure</li>
      <li><strong>Result: Better memory predictability</strong></li>
    </ul>
  </li>
  <li><strong>JSON Streaming</strong>:
    <ul>
      <li>HTTP/1.1: Full payload buffering (50MB × 4 concurrent = 200MB)</li>
      <li>HTTP/2: Streaming with 8MB buffers (8MB × 4 = 32MB)</li>
      <li><strong>Savings: 168MB memory</strong></li>
    </ul>
  </li>
</ol>

<h2>Recommended Adoption Path</h2>

<p>HTTP/2 and HTTP/1.1 coexist as independent transport implementations.
A typical rollout:</p>
<ol>
  <li><strong>Start with high-payload services</strong> — services returning
      10MB+ JSON responses benefit most from streaming (FlushingOutputStream
      prevents reverse proxy timeouts).</li>
  <li><strong>Enable globally</strong> — once validated, switch the
      <code>axis2.xml</code> formatter to
      <code>FieldFilteringMessageFormatter</code> (wraps the streaming
      Moshi formatter). All services benefit; small responses have zero
      overhead.</li>
  <li><strong>HTTP/1.1 fallback remains available</strong> — the original
      transport is unchanged and can be restored by reverting the
      <code>axis2.xml</code> formatter class.</li>
</ol>

<h2>Security Considerations</h2>

<h3>HTTPS-Only Enforcement</h3>
<ul>
  <li>HTTP/2 transport <strong>requires HTTPS</strong> (RFC 7540 compliance)</li>
  <li>HTTP URLs will be rejected with clear error messages</li>
  <li>Ensure SSL certificates are properly configured</li>
</ul>

<h3>TLS Configuration (Intelligent Defaults)</h3>

<div style="background-color: #fff4e6; border: 1px solid #ff9800; padding: 10px; margin: 10px 0;">
<strong>🔒 Security Defaults:</strong> TLS and ALPN settings are automatically configured with secure defaults.
Manual configuration is only required for specialized security requirements.
</div>

<p><strong>Automatic TLS Configuration:</strong></p>
<pre>
&lt;!-- These security settings are automatically applied --&gt;
supportedProtocols = "TLSv1.2,TLSv1.3"                    (Modern TLS versions)
supportedCipherSuites = "TLS_AES_256_GCM_SHA384,..."       (Secure cipher suites)
enableALPN = true                                          (Required for HTTP/2)
</pre>

<p><strong>Override Only for Specialized Requirements:</strong></p>
<pre>
&lt;!-- Example: Custom security policy requirements --&gt;
&lt;parameter name="supportedProtocols"&gt;TLSv1.3&lt;/parameter&gt;  &lt;!-- TLS 1.3 only --&gt;
&lt;parameter name="supportedCipherSuites"&gt;TLS_AES_256_GCM_SHA384&lt;/parameter&gt; &lt;!-- Specific cipher --&gt;
</pre>

<h2>Intelligent Defaults Benefits</h2>

<div style="background-color: #f0f8ff; border: 1px solid #0066cc; padding: 15px; margin: 15px 0;">
<h3>🎯 Configuration Simplification</h3>
<p><strong>Before (Complex Configuration):</strong> Required 20+ parameters for optimal performance</p>
<p><strong>After (Intelligent Defaults):</strong> Single parameter for HTTP/2 enablement</p>
</div>

<h3>Key Improvements</h3>

<table border="1">
<tr><th>Aspect</th><th>Before</th><th>After</th><th>Benefit</th></tr>
<tr><td>Configuration Size</td><td>20+ parameters</td><td>1 parameter</td><td>95% reduction</td></tr>
<tr><td>Setup Time</td><td>30+ minutes</td><td>2 minutes</td><td>93% faster</td></tr>
<tr><td>Error Probability</td><td>High (manual tuning)</td><td>Low (tested defaults)</td><td>Increased reliability</td></tr>
<tr><td>Performance</td><td>Variable</td><td>Optimized automatically</td><td>Consistent performance</td></tr>
<tr><td>Maintenance</td><td>Manual parameter updates</td><td>Automatic optimization</td><td>Zero maintenance</td></tr>
</table>

<h3>Production-Ready Defaults</h3>

<ul>
  <li><strong>Memory-Constrained Optimization</strong>: Defaults are conservative and work across deployment sizes</li>
  <li><strong>Large Payload Support</strong>: Automatic 64KB buffer alignment for 50MB+ JSON</li>
  <li><strong>Enterprise Integration</strong>: Enhanced Moshi H2 parameters pre-configured</li>
  <li><strong>Security Hardening</strong>: Modern TLS and cipher suite defaults</li>
  <li><strong>Performance Monitoring</strong>: Built-in metrics and optimization recommendations</li>
</ul>

<h3>Migration Path</h3>

<ol>
  <li><strong>Immediate</strong>: Replace complex configuration with minimal setup</li>
  <li><strong>Validation</strong>: Test with intelligent defaults</li>
  <li><strong>Optimization</strong>: Override specific parameters only if needed</li>
  <li><strong>Monitoring</strong>: Use built-in recommendations for fine-tuning</li>
</ol>

<h2>Monitoring and Metrics</h2>

<h3>Key Performance Indicators</h3>
<ul>
  <li>Request latency improvement vs HTTP/1.1</li>
  <li>JSON processing time for large payloads</li>
  <li>Memory usage (target: 20% reduction in peak usage)</li>
  <li>Connection efficiency (multiplexing reduces connection count)</li>
</ul>

<h3>JVM Parameters</h3>
<p>HTTP/2 and streaming are enabled entirely through axis2.xml
by selecting the appropriate message receiver and formatter classes (e.g.
<code>EnhancedMoshiJsonFormatter</code>, <code>MoshiStreamingMessageFormatter</code>).
No JVM system properties are required for HTTP/2 support.</p>

<h2>Testing Strategy</h2>

<h3>Primary Focus: JSON Web Services Testing (90% Effort)</h3>

<p>Since HTTP/2 transport is <strong>primarily designed for JSON-based web services</strong>, testing strategy prioritizes JSON over SOAP.</p>

<h4>Phase 1: Core HTTP/2 Transport Tests</h4>
<ul>
  <li>HTTPS-Only Validation: Ensure HTTP URLs rejected with clear error messages</li>
  <li>Async Client Creation: Verify HTTP/2 client configuration and connection pooling</li>
  <li>Request Interface Compliance: All Request interface methods work correctly</li>
  <li>Entity Conversion: AxisRequestEntity → HTTP/2 SimpleHttpRequest conversion</li>
  <li>Error Handling: Proper AxisFault generation for HTTP/2 specific issues</li>
</ul>

<h4>Phase 2: HTTP/2 + JSON Integration Tests</h4>
<ul>
  <li>Large JSON Payload Tests (50MB+): Core business requirement</li>
  <li>JSON-RPC over HTTP/2: Verify HTTP/2 multiplexing benefits</li>
  <li>Performance Benchmarks: HTTP/1.1 vs HTTP/2 comparison</li>
  <li>Memory usage under load</li>
</ul>

<h4>Phase 3: HTTP/2 Specific Feature Tests</h4>
<ul>
  <li>Connection Multiplexing: Test concurrent requests over single HTTP/2 connection</li>
  <li>Security Enforcement: Verify HTTP URLs rejected properly</li>
  <li>Flow Control: Large payload streaming optimization</li>
</ul>

<h3>Secondary Focus: SOAP Compatibility Tests (10% Effort - Optional)</h3>

<p><strong>Limited Business Case Analysis</strong>:</p>

<table border="1">
<tr><th>Factor</th><th>Assessment</th><th>Rationale</th></tr>
<tr><td><strong>Market Reality</strong></td><td>SOAP usage declining</td><td>New services predominantly use REST/JSON APIs</td></tr>
<tr><td><strong>Legacy Focus</strong></td><td>Most SOAP on HTTP/1.1</td><td>SOAP organizations slow to adopt new protocols</td></tr>
<tr><td><strong>Technical Benefits</strong></td><td>Marginal for SOAP</td><td>SOAP/XML verbose - limited HTTP/2 binary efficiency gains</td></tr>
<tr><td><strong>Testing ROI</strong></td><td>Low value/high effort</td><td>Limited adoption likelihood</td></tr>
</table>

<h2>Success Criteria</h2>

<h3>Overall Project Success</h3>
<ul>
  <li>✅ <strong>Performance</strong>: 30% latency reduction, 40% JSON processing improvement</li>
  <li>✅ <strong>Memory</strong>: Reduced peak memory usage via streaming</li>
  <li>✅ <strong>Stability</strong>: No regression in existing functionality</li>
  <li>✅ <strong>Scalability</strong>: Support for 100+ concurrent streams</li>
  <li>✅ <strong>Production</strong>: Successful deployment with modern JVM and garbage collection</li>
</ul>

<h2>Summary</h2>

<p>The independent transport-h2 module approach provides <strong>optimal balance</strong> between performance improvements and deployment safety for Axis2.
This dual-protocol architecture allows organizations to:</p>

<ul>
  <li><strong>Evaluate HTTP/2 benefits</strong> without risk to existing HTTP/1.1 services</li>
  <li><strong>Migrate incrementally</strong> at their own pace</li>
  <li><strong>Optimize performance</strong> for large JSON payload processing</li>
  <li><strong>Maintain compatibility</strong> across diverse deployment environments</li>
</ul>

<div style="background-color: #f0f8ff; border: 1px solid #0066cc; padding: 10px; margin: 10px 0;">
<strong>🏢 WildFly Users:</strong> Don't forget to check the
<a href="wildfly-http2-integration-guide.html">WildFly + Axis2 HTTP/2 Integration Guide</a> for enhanced
performance through cooperative integration with Undertow HTTP/2 infrastructure.
</div>

</body>
</html>