An Endpoint defines an external service endpoint to which a message could be sent by a supported transport. Endpoints maybe defined in-line within a proxy service definition, or defined externally with a name, and referenced by one or more proxy services.
When defined within the scope of a proxy service, an endpoint would be either the inDestination or the outDestination for messages. The inDestination defines the target where messages are typically forwarded to, and the outDestination is typically defined as a response destination.
<u:proxy id="rest-proxy">
<u:transport id="http-8280"/>
<u:target>
<u:inDestination>
<u:address type="prefix">http://localhost:9000/rest-services</u:address>
<u:property name="switchLocationHeadersTo" value="http://localhost:8280/service/rest-proxy"/>
</u:inDestination>
<u:outDestination>
<u:address type="response"/>
</u:outDestination>
</u:target>
</u:proxy>
An endpoint will belong to one of the following types. In subsequent releases support for new endpoint types based on response time feedback and dynamic endpoints where new members are detected and stale members removed will be possible. If an endpoint does not specify its type, its defaulted as a 'Single address' endpoint.
-
Single address endpoint
-
Round-robin [only] group - i.e. does not fail-over
-
Round-robin with fail over group
-
Fail-over [only] group - i.e. always use the first ready address
-
Weighted [only] group - i.e. does not fail-over
-
Weighted with fail over group
-
Random [only] group - i.e. does not fail-over
-
Random with fail over group
An address specified by an endpoint will belong to one of the following types:
-
URL - i.e. specifies an absolute and complete address URL
-
Prefix - i.e. specifies a URL prefix which maybe supplemented at runtime
-
Default - i.e. specifies that the destination URL set on the message should be the address
-
Response - i.e. specifies that the message should be sent via the default response channel - e.g. as the synchronous response on the same TCP socket for an http/s message
An endpoint may specify one or more properties to be set onto the message as it passes the endpoint. An example is shown below.
<u:inDestination>
<u:address type="prefix">http://localhost:9000/service/HtmlServlet</u:address>
<u:property name="switchLocationHeadersTo" value="http://localhost:8280/vpath"/>
</u:inDestination>
Advanced options
Endpoints can be configured with custom timeouts, action to take on replies arriving after timeout, and how to deal with possibly slow responding endpoints, or failed endpoints. The following example shows a round-robin endpoint definition as discussed later.
<u:inDestination type="round-robin" timeout="1000" action="discard">
<u:address id="port-9000">http://localhost:9000/service/EchoService</u:address>
<u:address id="port-9001">http://localhost:9001/service/EchoService</u:address>
<u:markAsTimedout>
<u:retriesBeforeSuspend>3</u:retriesBeforeSuspend>
<u:retryDelay>2000</u:retryDelay>
</u:markAsTimedout>
<u:suspendOnFailure>
<u:initialDuration>2000</u:initialDuration>
<u:progressionFactor>1.0</u:progressionFactor>
<u:maximumDuration>10000</u:maximumDuration>
</u:suspendOnFailure>
</u:inDestination>
The 'timeout' attribute specifies a duration in milliseconds to be used as the timeout when sending messages to the endpoint. When using the http/s transports, this translates into the TCP socket timeout used. The 'action' attribute specifies if delayed responses should be silently discarded or reported as an error
The 'markAsTimedout' element specifies aspects considered when the endpoint encounters non-fatal exceptions such as socket timeouts for requests, or an unexpected connection close. An optional list of errorCodes maybe specified to finetune the conditions considered as indicating temporary failure of an endpoint. On the detection of such a temporary error condition, the endpoint is marked as timedout, and retried a number of times with the specified delay before its considerd as failed. If any retry attempt succeeds, the endpoint returns to the active state again, and the retry count is reset. The retryDelay is specified in milliseconds.
If an endpoint encounters a fatal error - such as a connection refuse, or IOException, the endpoint is considered as failed, and is suspended from future use. The expiration of retries after temporary failure as discussed above also leads to endpoint suspension. When an endpoint is suspended it will not be used subsequently within the suspension period. The suspension period is computed as a geometric series, using the initialDuration and multiplying it with the progressionFactor at each subsequent re-suspension. By adjustting the progression factor one could easily re-suspend the endpoint for the same initialDuration, or increase the duration by a factor of 1.5, or 2 (exponential) etc. The maximumDuration specifies a ceiling value of suspension to limit the computed duration. The initialDuration and the maximumDurations are specified in milliseconds.
| < Prev | Next > |
|---|
