In a single High-speed Service Framework (HSF) call, the HSF consumer sends a request to the HSF provider over the network, the provider runs the target method, and the result travels back to the consumer. This process involves multiple threads and several domain objects specific to the HSF protocol.
Understanding this call flow helps you debug latency issues, interpret thread dumps, and pinpoint where failures occur in your Enterprise Distributed Application Service (EDAS) applications.
Call flow overview
An HSF call has three phases:
Client-side preparation (steps 1-3) -- The client thread serializes the request and hands it to the I/O thread for encoding and transmission.
Server-side processing (steps 4-8) -- The provider's I/O thread decodes the incoming data, the HSF server thread runs the target method through reflection, then serializes and encodes the response.
Response return (steps 9-11) -- The encoded response travels back to the consumer, the I/O thread decodes it, and the client thread deserializes the result.
The following diagram shows the complete 11-step process.
Thread model
Three thread types participate in every HSF call:
| Thread | Role |
|---|---|
| Client thread | Initiates the call on the consumer side. Serializes request parameters, waits for the response, and deserializes the result. |
| I/O thread | Handles network communication on both sides. Encodes outbound objects into binary content and decodes inbound binary content into communication objects. |
| HSF server thread | Processes the request on the provider side. Deserializes the request, invokes the target method, and serializes the response. |
This separation prevents slow method runs from blocking network I/O for other concurrent calls, and prevents network latency or congestion from starving the business thread pool.
Domain objects
HSF uses two layers of objects to separate user data from protocol metadata:
| Object | Purpose |
|---|---|
| Request object | Contains the request parameters -- the actual method arguments. |
| Request communication object | An HSF protocol wrapper around the request object. Includes protocol-level metadata such as the request ID. |
| Response object | Contains the method return value. |
| Response communication object | An HSF protocol wrapper around the response object. Includes protocol-level metadata for the return trip. |
This two-layer design lets HSF attach routing, tracing, and protocol information without modifying the user's data. When you debug issues, this distinction helps you determine whether a problem lies in the business logic (request/response objects) or the protocol layer (communication objects).
Detailed step-by-step flow
Phase 1: Client-side preparation (steps 1-3)
| Step | What happens |
|---|---|
| 1 | The client thread serializes the request parameters into a request object, then wraps it in a request communication object. The communication object follows the HSF protocol and includes metadata such as the request ID. |
| 2 | The client thread submits the request communication object to the I/O thread, which encodes it into binary content. |
| 3 | The I/O thread transmits the encoded binary content to the HSF provider. The client thread blocks and waits for the response. |
Phase 2: Server-side processing (steps 4-8)
| Step | What happens |
|---|---|
| 4 | The HSF provider's I/O thread receives the binary content and decodes it into a request communication object, then submits the object to the HSF server thread. |
| 5 | The server thread deserializes the request communication object to restore the original request object. |
| 6 | The server thread invokes the target method through a reflection call and gets the response object. |
| 7 | The server thread serializes the response object and wraps it in a response communication object. |
| 8 | The server thread submits the response communication object to the I/O thread, which encodes it into binary content. |
Phase 3: Response return (steps 9-11)
| Step | What happens |
|---|---|
| 9 | The HSF provider's I/O thread transmits the encoded binary content back to the HSF consumer. |
| 10 | The HSF consumer's I/O thread receives the binary content, decodes it into a response communication object, and wakes up the blocked client thread. |
| 11 | The client thread deserializes the response communication object to extract the response object. The caller receives the result, and the remote call completes. |
Design rationale
Serialization vs. encoding
HSF applies two separate transformations to outbound data:
Serialization converts objects (request or response objects) into a byte-stream format suitable for inclusion in a communication object.
Encoding converts the complete communication object -- including protocol metadata -- into binary content for network transmission.
On the receiving side, decoding reconstructs the communication object from binary content, and deserialization extracts the original object from the communication object.
Keeping these steps separate lets HSF swap serialization formats independently of the wire protocol encoding.
Separate I/O and business threads
The I/O thread handles network reads, writes, encoding, and decoding. The HSF server thread handles deserialization and method invocation. This separation provides two benefits:
A slow business method does not block network I/O for other concurrent calls.
Network latency or congestion does not starve the business thread pool.
Synchronous blocking on the consumer side
During a standard synchronous HSF call, the client thread blocks at step 3 until the I/O thread wakes it at step 10. The total blocking time includes network round-trip latency, server-side processing time, and serialization/encoding overhead on both sides.