Scenario: Fan-in per device request-reply

Background to this scenario

An online customer wants to be able to reserve an item from a particular store. The request is published from the customer device, and a response is required from the store to confirm reservation of that item. The response must be sent only to that requesting device. The customer device is a publisher and subscriber device on the internet.

At the store, Eclipse Amlen sits within the DMZ. An application that runs on a device within the store intranet subscribes to customer request topic strings and publishes a reservation response to the unique customer response topic string. Complete the steps in the following section to understand how to set up this scenario.

Planning and implementing the solution

Use the following information to help you to plan and implement a fan-in per device request-reply scenario.

Understanding your publish/subscribe architecture

In this scenario, there are many internet devices that publish and subscribe to unique topic strings. There is one intranet device that publishes and subscribes to each unique topic string. This scenario is a fan-in per device request-reply. The following diagram shows the architecture of a fan-in per device request-reply scenario.

Understanding the required messaging behavior for your solution

Do you want durable or non-durable subscriptions? What quality of service do you need?

If a subscription is durable, when the subscribing application disconnects, the subscription remains in place and can be used by the subscribing application when it reconnects. In this scenario, the subscriptions are durable because it is important that the customer device receives the reservation message even if the connection is lost.

A quality of service of 2 is appropriate because the message delivery across the network must be guaranteed at most once. It is not acceptable to have duplicates because customers want to reserve once and multiple messages could result in a poor customer experience. QoS 2 messages are persistent. The message is stored on Eclipse Amlen until the message is received by the subscriber of the message.

Planning your solution

In this scenario, consider the following key points:

• Which protocol is appropriate?

  Eclipse Amlen natively supports MQTT and JMS. You must consider which protocol is appropriate for your business needs. The amount of data that is sent between the devices is small. The messages between the devices must be sent reliably. The customer device is using a web application that runs in a web browser. MQTT over WebSockets is designed for exchanging messages between web applications that run in a web browser, and to send messages reliably. Therefore, MQTT over WebSockets is appropriate in this scenario.

• What message size is appropriate?

  In this scenario, the customer devices send small, persistent messages. The information that is contained within the message is about reserving an item. Therefore, the message can be relatively small. You can limit the message size that is allowed to be sent through Eclipse Amlen by using the maximum message size attribute of an endpoint. For more information about endpoints, see Message hub, endpoints, and policies.

• What message count is appropriate?

  Consider what maximum message count is sensible for your messaging needs. In this scenario, the quality of service is 2, so messages are stored until a subscriber receives the message. Therefore, a higher message count might typically be considered. However, as each customer device publishes and subscribes to unique topic strings, a lower maximum message count is sufficient.

• What is the maximum number of topic levels that you need?

  You can have up to 32 levels in a topic string. Fewer levels are easier to manage, but many levels might be required to set up specific solutions. In this scenario, the topic string length can be relatively short. For example, Reserve/Request/OrderNumber or Reserve/Response/OrderNumber. By including the level of /Reserve, the store can include other customer requests, such as home delivery, in the future. For example, the topic string Delivery/Request/OrderNumber or Delivery/Response/OrderNumber might be added.

• How are you going to ensure that all of your customer IDs are unique?

  In this scenario, it is crucial that all customer IDs are unique so that the reservation request for each customer is recorded against the correct person. In this scenario, you might decide to use the order number as that number is unique to each customer. The client ID of the device is set to be the order number for each order that is placed.

• What message depth is appropriate?

  When the maximum message depth is reached, you cannot publish any more updates to that topic string until the number of messages is reduced. However, as each customer device publishes and subscribes to unique topic strings, the maximum message depth does not need to be as large as it would be if all devices published and subscribed to the same topic strings.

For more information about planning your solution, see Planning.

Writing your applications

In this scenario, you must decide the name of the topic strings that you are publishing and subscribing to. The store needs many topic strings because they are receiving requests from many customers. For this messaging pattern, each internet device must publish to a unique request topic string so that the intranet device knows which topic string to publish the response to. The request topic string must be subscribed to by the intranet device. The intranet device must publish to a unique response topic string. The internet device must subscribe to the relevant response topic string. By using the unique customer ID in the topic string, you can ensure that each topic is unique.

To ensure that customer devices do not publish to an incorrect topic string, you can use the topic string variable substitution available in the Eclipse Amlen topic policies. By using topic string variable substitution you can create a topic policy with single topic string that includes an order number variable. This substitution ensures that applications can publish and subscribe only to the topic string that matches their order number. For example, a topic string of Reserve/Request/${ClientID} is specified in the topic policy. The customer with a client ID of 123 is allowed to publish to Reserve/Request/123, but is not allowed to publish to Reserve/Request/456, or Reserve/Request/789 because the client ID does not match. For more information about topic policies and variable substitution, see Messaging policies.

You can also use the topic string variable substitution to ensure that customer devices do not subscribe to an incorrect topic string. For example, specify a topic string of Reserve/Response/${ClientID} in the topic policy. Only the customer with a client ID of 123 is allowed to subscribe to Reserve/Response/123.

In this scenario, the name of the request topic string is Reserve/Request/${ClientID}. The name of the response topic string is Reserve/Response/${ClientID}.

The order in which your applications perform publish and subscribe actions is important. Both the client and the back-end application must subscribe to the relevant topic string before any messages are published. Otherwise, messages might be published but not received as no subscription was set up at the time that the message was published.

The following diagram shows this message flow between client and back-end devices through Eclipse Amlen.

1. The client publishes a message to the topic string Reserve/Request/${Client ID}.
2. The message is sent to the back-end appliance, which is authorized to subscribe to topic string Reserve/Request/${Client ID}.
3. The back-end appliance publishes a response to Reserve/Response/${Client ID}.
4. The message is sent to the client that is authorized to subscribe to topic string Reserve/Response/#.

Setting up your Eclipse Amlen infrastructure, and security

Create the infrastructure by configuring message hubs and endpoints. Set up your security by creating connection and topic policies.

In this scenario, the store requires one message hub because there is one goal - reserving stock. The store requires two endpoints to ensure that internal and external network traffic is kept separate.

Complete the following steps to set up a message hub and endpoints for this scenario:

1. Create your message hub. A message hub is an organizational configuration object to collect the endpoints, connection policies, and topic policies that are associated with a specific goal in a single place. In this scenario, the message hub is called Stock Reservation Hub.
2. Create your connection policies. A connection policy is used to authorize a client to connect to an endpoint.
   • Create a connection policy for the customer devices. In this scenario, the connection policy is called Stock Reservation External ConPol.

     In this scenario, the store restricts customer device access so that the device must use the MQTT protocol.

   • Create a connection policy for the back-end. In this scenario, the connection policy is called Stock Reservation Internal ConPol.

     In this scenario, the store restricts back-end access so that the back-end device must use the MQTT protocol, and use the IP address 192.0.2.020. Only one IP address is required because only one back-end system is publishing and subscribing.

3. Create your topic policies. A topic policy is a type of messaging policy is used to authorize a client to publish or subscribe to a topic.
   • Create two topic policies for the customer devices. In this scenario, the request topic policy is called Stock Reservation Request External TopicPol and the response topic policy is called Stock Reservation Response External TopicPol.

     The store restricts access so that the devices can publish to the topic string Reserve/Request/${ClientID} and subscribe to Reserve/Response/${ClientID}.

   • Create two topic policies for the back-end. In this scenario, the request topic policy is called Stock Reservation Request Internal TopicPol and the response topic policy is called Stock Reservation Response Internal TopicPol.

     The store restricts back-end access so that the device can subscribe to the topic string Reserve/Request/# and publish to Reserve/Response/#.

4. Create your endpoints. An endpoint authorizes a client to connect to Eclipse Amlen on one, or all configured ethernet interfaces, and a specific port. You create endpoints on a message hub.
   • Create an endpoint for internet network requests. In this scenario, the endpoint is called Stock Reservation External Endpoint. Apply the Stock Reservation External ConPol, the Stock Reservation Request External TopicPol, and the Stock Reservation Response External TopicPol to the endpoint.
   • Create an endpoint for intranet network requests. In this scenario, the endpoint is called Stock Reservation Internal Endpoint. Apply the Stock Reservation Internal ConPol, the Stock Reservation Request Internal TopicPol, and the Stock Reservation Response Internal TopicPol to the endpoint.

Testing your solution

For information about troubleshooting any problems that arise during testing, see Troubleshooting.

Monitoring your solution

There are various statistics that you can monitor. In this scenario, use topic monitor, connection monitor, and subscription monitor to understand the health of the solution.

Strengthening your security

You can increase the level of security of a solution in a number of ways:

• Using a server certificate.
  1. Create a certificate profile.
  2. Create a security profile to encrypt wire traffic.
     • Set UsePasswordAuthentication to True on your security profile in order to force authentication on user ID and password.
  3. Apply the security profile to your endpoints.
  4. Add the server certificate that you are using to the clients so that the clients can authenticate the server.

  For more information about certificates, see Transport Layer Security.

• Using a client certificate. You must have a sever certificate installed before you use a client certificate.
  1. Upload a client certificate, or CA certificate and key on each client.
  2. Add the specific client certificate, or the CA certificate to the trustStore on Eclipse Amlen. The trustStore points to a file containing trusted certificates, so that the server can authenticate the client.
• Using FIPS.

  FIPS increases message security by using cryptography that complies with the Federal Information Processing Standards (FIPS). Enable FIPS mode by setting the FIPS parameter to True. You can set FIPS to True either by using REST Administration APIs, or by using the Amlen WebUI. For more information about enabling FIPS mode, see Configuring security.