Endpoints and Stores
When an application uses persistence stores and durables, endpoints play an additional role. Administrators can associate each application endpoint with at most one persistence store.
That persistence store serves all publisher and subscriber instances of the endpoint, in all process instances of the application.
Programs can supply either a durable name or a subscriber name to the create subscriber call, connecting the new subscriber object to a specific durable within the endpoint’s persistence store.
Number of Endpoints
For many applications a single endpoint name suffices.
Minimizing the number of endpoints usually simplifies design, programming, and administration. Justify each additional endpoint based on requirements, for example:
- A functional requirement (such as forwarding)
- A business requirement to separate the data streams (such as security, or data priority)
- An administrative requirement to control the endpoints in different ways (such as efficiency, or flexibility)
Notice that endpoint is not analogous to the concept of destination in the Java Messaging System (JMS). Within a program, one endpoint name can yield several subscriber objects, each selecting a different subset of inbound messages. Furthermore, one endpoint can instantiate publishers as well as subscribers.
Tactics to Reduce Endpoints
If you think an additional endpoint might be necessary, consider whether these tactics might reduce that need, and simplify the situation:
- A program can create several publishers and subscribers from a single endpoint name.
- Administrators can define connectors to carry the four abilities of an endpoint in a way that either merges their sub-streams, or keeps them separate.
- Administrators can configure all application instance definitions to implement an endpoint using a common bus as a shared communication medium, or configure disjoint subsets of instances that use totally separate buses.