Scenario: Fan-in per device notification
In this scenario, many publisher devices publish messages to one topic string. There is one subscriber device that subscribes to this topic string.
Background to this scenario
A hospital wants to be able to monitor the blood pressure of individual patients. Patients take their blood pressure by using a device at home. An application on the device publishes to a topic string. These publishing devices sit in the internet. The published message contains information including the patient ID, blood pressure, and timestamp.
At the hospital, the Eclipse Amlen sits within the DMZ. An application that runs on a device within the hospital intranet subscribes to the blood pressure device topic string, and remotely monitors the blood pressure of each patient. Alerts are generated when necessary. 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 notification scenario.
- Understanding your publish/subscribe architecture
In this scenario, there are many publisher devices that publish messages to one topic string. There is one subscriber device that subscribes to this topic string. Therefore, this scenario is a fan-in per device notification. The following diagram shows the architecture of a fan-in per device notification 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 only one message per day is being sent from patients that are high risk, and therefore it is important that the subscriber device receives each message.
A quality of service of 1 is appropriate because the message delivery across the network must be guaranteed at least once. It is acceptable to have duplicates as any duplicates can be discarded. QoS 1 messages are persistent. The message is stored on the 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 sent between the devices is small. If some patients do not have internet access, then expensive mobile connections are used. The messages between the devices must be sent reliably. The MQTT protocol is designed for exchanging messages between small devices on low bandwidth, or expensive connections, and to send messages reliably. Therefore, MQTT protocol is appropriate in this scenario.
- What message size is appropriate?
In this scenario, the publisher devices send small, persistent messages. The information that is contained within the message is about patient ID, blood pressure, and time. 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 1, so messages are stored until a subscriber receives the message. Therefore, a higher message count might typically be considered.
- 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,
Hospital name/Blood Pressure
. By including the level of/Blood Pressure
, the hospital can easily include other measurements, such as heart rate, in the future. For example, the topic stringHospital name/Heart Rate
might be added. - How are you going to ensure that all of your user IDs are unique?
In this scenario, it is crucial that all user IDs are unique so that the blood pressure for each patient is recorded against the correct patient. In this scenario, you might decide to use the patient ID number as that number is unique to each patient.
- 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. All devices publish to the same topic string, therefore you need to ensure that the maximum message depth is sufficient to cope with the messages that are published from a given number of patients.
For more information about planning your solution, see Planning.
- Which protocol is appropriate?
- Writing your applications
In this scenario, you must decide the name of the topic strings that you are publishing and subscribing to. For this messaging pattern, each publisher must publish to one topic string. The subscriber device subscribes to the same topic string. In this scenario, the name of the topic string is
Hospital/Blood Pressure
.- 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 messaging policies.
In this scenario, the hospital requires one message hub because there is one goal - recording blood pressure. The hospital 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:
- Create your message hub. A message hub is an organizational configuration object to collect the
endpoints, connection policies, and messaging policies that are associated with a specific
goal in a single place. In this scenario, the message hub is called
Blood Pressure Monitoring Hub
.
curl -X POST \
-H 'Content-Type: application/json' \
-d '{
"MessageHub": {
"Blood Pressure Monitoring Hub": {
"Description": "Message Hub for monitoring blood pressure "
}
}
}
' \
http://127.0.0.1:9089/ima/v1/configuration - Create your connection policies. A connection policy is used to authorize a client to connect to
an endpoint.
- Create a connection policy for the publishers. In this scenario, the connection policy
is called
Blood Pressure Monitoring External ConPol
.In this scenario, the hospital restricts publisher access so that the publisher device must use MQTT protocol. Additionally, publisher access is restricted on appliance messaging group, where all publishers must be a member of the
Patients
group. - Create a connection policy for the subscriber. In this scenario, the connection policy
is called
Blood Pressure Monitoring Internal ConPol
.In this scenario, the hospital restricts subscriber access so that the subscriber device must use MQTT protocol.
You can use the following cURL commands to create the connection policies:
curl -X POST \
-H 'Content-Type: application/json' \
-d '{
"ConnectionPolicy": {
"Blood Pressure Monitoring External ConPol": {
"UserID": "*",
"Protocol": "MQTT",
"AllowDurable": false,
"Description": "Hospital external connection policy"
}
}
}
' \
http://127.0.0.1:9089/ima/v1/configuration
curl -X POST \
-H 'Content-Type: application/json' \
-d '{
"ConnectionPolicy": {
"Blood Pressure Monitoring Internal ConPol": {
"UserID": "*",
"Protocol": "MQTT",
"AllowDurable": false,
"Description": "Hospital internal connection policy"
}
}
}
' \
http://127.0.0.1:9089/ima/v1/configuration - Create a connection policy for the publishers. In this scenario, the connection policy
is called
- Create your topic policies. A topic policy is a messaging policy that is used to authorize a
client to publish or subscribe to a topic.
- Create a topic policy for the publisher. In this scenario, the topic policy is called
Blood Pressure Monitoring External TopicPol
.The hospital restricts publisher access so that the publisher devices can publish to the topic string
Hospital name/Blood Pressure
only. - Create a topic policy for the subscriber. In this scenario, the topic policy is called
Blood Pressure Monitoring Internal TopicPol
.The hospital restricts subscriber access so that the subscriber device can subscribe to the topic string
Hospital name/Blood Pressure
.
You can use the following cURL commands to create the topic policies:
curl -X POST \
-H 'Content-Type: application/json' \
-d '{
"TopicPolicy": {
"Blood Pressure Monitoring External TopicPol": {
"Topic": "Hospital name/Blood Pressure",
"UserID": "*",
"ActionList": "Subscribe",
"Protocol": "MQTT",
"MaxMessages": 5000,
"Description": "Hospital external topic policy"
}
}
}
' \
http://127.0.0.1:9089/ima/v1/configuration
curl -X POST \
-H 'Content-Type: application/json' \
-d '{
"TopicPolicy": {
"Blood Pressure Monitoring Internal TopicPol": {
"Topic": "Hospital name/Blood Pressure",
"UserID": "*",
"ActionList": "Publish",
"Protocol": "MQTT",
"MaxMessages": 5000,
"Description": "Hospital internal topic policy"
}
}
}
' \
http://127.0.0.1:9089/ima/v1/configuration - Create a topic policy for the publisher. In this scenario, the topic policy is called
- Create your endpoints. An endpoint authorizes a client to connect to the 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
Blood Pressure Monitoring External Endpoint
. Apply theBlood Pressure Monitoring External ConPol
, and theBlood Pressure Monitoring External TopicPol
to the endpoint. - Create an endpoint for intranet network requests. In this scenario, the endpoint is
called
Blood Pressure Monitoring Internal Endpoint
. Apply theBlood Pressure Monitoring Internal ConPol
, and theBlood Pressure Monitoring Internal TopicPol
to the endpoint.
You can use the following cURL commands to create the endpoints:
curl -X POST \
-H 'Content-Type: application/json' \
-d '{
"Endpoint": {
"Blood Pressure Monitoring External Endpoint": {
"Enabled": true,
"Port": 1884,
"MaxMessageSize": "1024KB",
"ConnectionPolicies": "Blood Pressure Monitoring External ConPol",
"TopicPolicies": "Blood Pressure Monitoring External TopicPol",
"MessageHub": "Blood Pressure Monitoring Hub",
"Protocol": "MQTT",
"Interface": "All",
"Description": "Hospital external endpoint"
}
}
}
' \
http://127.0.0.1:9089/ima/v1/configuration
curl -X POST \
-H 'Content-Type: application/json' \
-d '{
"Endpoint": {
"Devices Update Internal Endpoint": {
"Enabled": true,
"Port": 1885,
"MaxMessageSize": "1024KB",
"ConnectionPolicies": "Blood Pressure Monitoring Internal ConPol",
"TopicPolicies": "Blood Pressure Monitoring Internal TopicPol",
"MessageHub": "Blood Pressure Monitoring Hub",
"Protocol": "MQTT",
"Interface": "All",
"Description": "Hospital internal endpoint"
}
}
}
' \
http://127.0.0.1:9089/ima/v1/configuration - Create an endpoint for internet network requests. In this scenario, the endpoint is
called
- Create your message hub. A message hub is an organizational configuration object to collect the
endpoints, connection policies, and messaging policies that are associated with a specific
goal in a single place. In this scenario, the message hub is called
- 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.
- Create a certificate profile.
- 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.
- Set UsePasswordAuthentication to
- Apply the security profile to your endpoints.
- 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.
- Upload a client certificate, or CA certificate and key on each client.
- 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 toTrue
either by using REST Administration APIs, or by using the Amlen WebUI. For more information about enabling FIPS mode, see Configuring security.
- Using a server certificate.