Open topic with navigation

# Cluster-Facing and Application-Facing Endpoints

Each eFTL service in the cluster has a single cluster-facing endpoint, which it uses to exchange protocols with other services in the cluster. In addition, each channel has a single application-facing endpoint, which the channel uses to exchange message data across the services in the cluster (but within the channel), and also with eFTL clients of the channel.

In the diagram the blue square under each service’s name represents its cluster-facing endpoint.

Figure 83: Cluster-Facing Endpoints

When defining a cluster, the configuration must include a separate FTL transport bus for the each of these endpoints. When you create a cluster or a channel, the FTL server automatically generates a dynamic TCP transport (DTCP) for each of these endpoints as part of the initial configuration.

The initial configuration is often sufficient. It is good practice to use these automatically generated transports without modification, except for the following needs:

- To attach additional transport connectors to application-facing endpoints
- To define application instances to meet specific constraints of your network or hardware

If you choose to define your own transports for these endpoints, use these guidelines:

- The bus must be a full mesh topology: that is, a complete graph.
- The best practice is to use a dynamic TCP transport, such as those automatically generated in the initial configuration.

  Alternatively, you could use any transport protocol, but for clusters of two or more services it is convenient to use a symmetric transport definition: either a dynamic TCP transport or a symmetric multicast transport.

- The cluster-facing endpoint requires its own dedicated transport bus. You must not use that same transport to implement any FTL application endpoints: otherwise, you risk duplicate message delivery. You must not use that same transport to implement any application-facing endpoints: otherwise, you risk crosstalk among channels.

  Similarly, each application-facing endpoint requires its own dedicated transport bus. You must not use the same transport to implement more than one application-facing endpoint, nor any cluster-facing endpoint: otherwise you risk crosstalk among channels.

## Use Unique Transports

If a transport is bound to either the cluster-facing endpoint, or any application-facing endpoint of a cluster, then you may not bind the same transport to any other endpoint in any eFTL cluster or channel.

Warning: Reusing a transport can result in unwanted crosstalk between channels, or even between clusters.

Nonetheless, you may extend a transport that is bound to an application-facing endpoint, by binding it to an endpoint of an FTL application. This type of extension is the preferred method for connecting an FTL application to an FTL channel.

Did you find this helpful?

Yes No
Great!
Thanks for taking the time to give us some feedback.
Sorry about that

Why wasn't this helpful? (check all that apply)

Could not find what I was looking for
Instructions confusing or unclear
Instructions did not work

Want to tell us more?

Please select at least one option or provide details about the issue!!

Error occurred while submitting feedback.

Error2 occurred while submitting feedback.

TIBCO FTL® - Enterprise Edition

Copyright © 2009-2024. Cloud Software Group, Inc. All Rights Reserved.