There are certainly a lot of different methods for getting the path and name for a configuration file, however for the purposes
+ of this sample application, they are simply defined as macros
+ =semlit,insert,define_configs=
+
Also note the LBM_APPLICATION_NAME. This is needed for loading the XML configuration file
+
Load XML File
+
Here is how the XML configuration file gets load into the application. It's important to note that the application name must be
+ provided here in order to ensure that this application loads the correct configurations.
+ =semlit,insert,xml_file=
+
Creating Context 1
+
When creating a context to use a specific configuration out of an XML file, UM applications can map a context attribute object
+ to a specific context name (TRD1) define in the XML using the appropriate API like so:
+ =semlit,insert,ctx_1=
+
Same for the second context, but note the different attribute object, and the different context name (TRD2) when initializing the
+ context attribute object:
+ =semlit,insert,ctx_2=
+
Error Checking
+
Error handling can be one of the most complicated issues facing a programmer. Each application may have its own unique error
+ handling conventions. For these example programs, a very simplistic error handling approach is taken: if anything unexpected happens,
+ print a message and exit the program:
+ =semlit,insert,error_check=
+
The EX_LBM_CHK() macro checks a UM API return value. If negative, it assumes an error. One reason for making this a macro is so
+ that the __FILE__ and __LINE__ compiler built-ins reference the file and line of the usages of the macro, not the file and line of
+ the macro defintion itself.
+
Most UM functions are designed to return one of only two integer values: 0 for success and -1 for failure. The lbm.h header file
+ defines the symbols LBM_OK and LBM_FAILURE respectively for these. However, there are a few functions which can return a value of 0 or
+ greater in the event of success (for example: lbm_event_dispatch() and lbm_send_response() to name two). So the example EX_LBM_CHK()
+ macro was written to be somewhat more general. However, be aware that there are a few other functions which do not return an integer
+ status at all (for exmaple: lbm_serialize_response() to name one). Please refer to the API documentation for each UM function you call.
+
Includes
+
A small effort was made to provide a some portability between Unix and Windows. For example:
+ =semlit,insert,includes=
+
Different sets of header files should be included for Unix v.s. Windows applications.
+
+
+
Configuration Explanation
+
XML Configuration File
+
Here in the application section of the XML is the definitions of the two contexts, and the different topic resolution domains for
+ each context.
+
Topic Resolution Domain 1 / Context 1
+ =semlit,insert,trd1=
+
Topic Resolution Domain 2 / Context 2
+ =semlit,insert,trd2=
+
+
diff --git a/multi_context/c/multi_context.sldoc.html b/multi_context/c/multi_context.sldoc.html
new file mode 100644
index 0000000..77c9a66
--- /dev/null
+++ b/multi_context/c/multi_context.sldoc.html
@@ -0,0 +1,158 @@
+
+
+
+ Load Configuration File
+
+
+ Example index
+
Configuring Multiple Contexts with an XML Configuration File
+
In this example, the application will be creating two contexts, and each context will exist in different topic
+ resolution domains. Each individual context configuration will be pulled from the same XML configuration file.
+
Topic resolution domains are an important aspect to Ultra Messaging, because only contexts that exist within the
+ same topic resolution domain can publish/subscribe to one another. The UM Dynamic Routing Option (DRO) is one method
+ to bridge topic resolution domains, and is particularly useful for bridging topic resolution domains separated by a
+ WAN. Other than using the DRO, building applications with multiple contexts is the only other way to bridge topic
+ resolution domains
+
Using multiple topic resolution domains in a messaging environment can be an extremely useful option, particularly
+ in environments with large topic spaces and scattered topic interest. For example, in a market data environment, some
+ clients might only be interested in the latest tick for a stock, where as other clients might only be interested in
+ option prices. In this case, it might make sense to put options and ticks in different topic resolution domains.
+
This type of application can be useful for multiple use cases, such as:
+
+
Message Monitor - Some application use cases call for a monitoring application that simply receives messages
+ from all topic resolution environments.
+
Bridge / Republisher - Receive messages from one domain, copy and republish into another. Also useful for
+ subscribing to inter-host protocol such as LBTIPC or LBTSMX, and republishing the messages for off-host
+ consumption
+
+
+
+
multi_context.c
+ - (right-click and save as "multi_context.c") main program.
There are certainly a lot of different methods for getting the path and name for a configuration file, however for the purposes
+ of this sample application, they are simply defined as macros
Also note the LBM_APPLICATION_NAME. This is needed for loading the XML configuration file
+
Load XML File
+
Here is how the XML configuration file gets load into the application. It's important to note that the application name must be
+ provided here in order to ensure that this application loads the correct configurations.
When creating a context to use a specific configuration out of an XML file, UM applications can map a context attribute object
+ to a specific context name (TRD1) define in the XML using the appropriate API like so:
Same for the second context, but note the different attribute object, and the different context name (TRD2) when initializing the
+ context attribute object:
Error handling can be one of the most complicated issues facing a programmer. Each application may have its own unique error
+ handling conventions. For these example programs, a very simplistic error handling approach is taken: if anything unexpected happens,
+ print a message and exit the program:
+
+
+00018 /* Example error checking macro. Include after each UM call. */
+00019 #define EX_LBM_CHK(err) do { \
+00020 if ((err) < 0) { \
+00021 fprintf(stderr, "%s:%d, lbm error: '%s'\n", \
+00022 __FILE__, __LINE__, lbm_errmsg()); \
+00023 exit(1); \
+00024 } \
+00025 } while (0)
+
+
+
+
The EX_LBM_CHK() macro checks a UM API return value. If negative, it assumes an error. One reason for making this a macro is so
+ that the __FILE__ and __LINE__ compiler built-ins reference the file and line of the usages of the macro, not the file and line of
+ the macro defintion itself.
+ Most UM functions are designed to return one of only two integer values: 0 for success and -1 for failure. The lbm.h header file
+ defines the symbols LBM_OK and LBM_FAILURE respectively for these. However, there are a few functions which can return a value of 0 or
+ greater in the event of success (for example: lbm_event_dispatch() and lbm_send_response() to name two). So the example EX_LBM_CHK()
+ macro was written to be somewhat more general. However, be aware that there are a few other functions which do not return an integer
+ status at all (for exmaple: lbm_serialize_response() to name one). Please refer to the API documentation for each UM function you call.
+
Includes
+
A small effort was made to provide a some portability between Unix and Windows. For example:
diff --git a/multi_context/c/multi_context_config.xml b/multi_context/c/multi_context_config.xml
new file mode 100644
index 0000000..6586d6e
--- /dev/null
+++ b/multi_context/c/multi_context_config.xml
@@ -0,0 +1,18 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/multi_context/intro.sldoc b/multi_context/intro.sldoc
new file mode 100644
index 0000000..420f39c
--- /dev/null
+++ b/multi_context/intro.sldoc
@@ -0,0 +1,21 @@
+ Example index
+
Configuring Multiple Contexts with an XML Configuration File
+
In this example, the application will be creating two contexts, and each context will exist in different topic
+ resolution domains. Each individual context configuration will be pulled from the same XML configuration file.
+
Topic resolution domains are an important aspect to Ultra Messaging, because only contexts that exist within the
+ same topic resolution domain can publish/subscribe to one another. The UM Dynamic Routing Option (DRO) is one method
+ to bridge topic resolution domains, and is particularly useful for bridging topic resolution domains separated by a
+ WAN. Other than using the DRO, building applications with multiple contexts is the only other way to bridge topic
+ resolution domains
+
Using multiple topic resolution domains in a messaging environment can be an extremely useful option, particularly
+ in environments with large topic spaces and scattered topic interest. For example, in a market data environment, some
+ clients might only be interested in the latest tick for a stock, where as other clients might only be interested in
+ option prices. In this case, it might make sense to put options and ticks in different topic resolution domains.
+
This type of application can be useful for multiple use cases, such as:
+
+
Message Monitor - Some application use cases call for a monitoring application that simply receives messages
+ from all topic resolution environments.
+
Bridge / Republisher - Receive messages from one domain, copy and republish into another. Also useful for
+ subscribing to inter-host protocol such as LBTIPC or LBTSMX, and republishing the messages for off-host
+ consumption
There are certainly a lot of different methods for getting the path and name for a configuration file, however for the purposes
+ of this sample application, they are simply defined as macros
+ =semlit,insert,define_configs=
+
Also note the LBM_APPLICATION_NAME. This is needed for loading the XML configuration file
+
Load XML File
+
Here is how the XML configuration file gets load into the application. It's important to note that the application name must be
+ provided here in order to ensure that this application loads the correct configurations.
+ =semlit,insert,xml_file=
+
Creating Contexts
+
When creating a context to use a specific configuration out of an XML file, UM applications can map a context attribute object
+ to a specific context name (TRD1) define in the XML using the appropriate API like so:
+ =semlit,insert,ctx_1=
+
Same for the second context, but note the different attribute object, and the different context name (TRD2) when initializing the
+ context attribute object:
+ =semlit,insert,ctx_2=
+
+
Configuration Explanation
+
XML Configuration File
+
Here in the application section of the XML is the definitions of the two contexts, and the different topic resolution domains for
+ each context.
+
Topic Resolution Domain 1 / Context 1
+ =semlit,insert,trd1=
+
Topic Resolution Domain 2 / Context 2
+ =semlit,insert,trd2=
+
+
diff --git a/multi_context/java/multi_context.sldoc.html b/multi_context/java/multi_context.sldoc.html
new file mode 100644
index 0000000..cee8478
--- /dev/null
+++ b/multi_context/java/multi_context.sldoc.html
@@ -0,0 +1,105 @@
+
+
+
+ Load Configuration File
+
+
+ Example index
+
Configuring Multiple Contexts with an XML Configuration File
+
In this example, the application will be creating two contexts, and each context will exist in different topic
+ resolution domains. Each individual context configuration will be pulled from the same XML configuration file.
+
Topic resolution domains are an important aspect to Ultra Messaging, because only contexts that exist within the
+ same topic resolution domain can publish/subscribe to one another. The UM Dynamic Routing Option (DRO) is one method
+ to bridge topic resolution domains, and is particularly useful for bridging topic resolution domains separated by a
+ WAN. Other than using the DRO, building applications with multiple contexts is the only other way to bridge topic
+ resolution domains
+
Using multiple topic resolution domains in a messaging environment can be an extremely useful option, particularly
+ in environments with large topic spaces and scattered topic interest. For example, in a market data environment, some
+ clients might only be interested in the latest tick for a stock, where as other clients might only be interested in
+ option prices. In this case, it might make sense to put options and ticks in different topic resolution domains.
+
This type of application can be useful for multiple use cases, such as:
+
+
Message Monitor - Some application use cases call for a monitoring application that simply receives messages
+ from all topic resolution environments.
+
Bridge / Republisher - Receive messages from one domain, copy and republish into another. Also useful for
+ subscribing to inter-host protocol such as LBTIPC or LBTSMX, and republishing the messages for off-host
+ consumption
+
+
+
+
MultiContext.java
+ - (right-click and save as "MultiContext.java") main program.
There are certainly a lot of different methods for getting the path and name for a configuration file, however for the purposes
+ of this sample application, they are simply defined as macros
+
+
+00006 public static String xml_conf = "./multi_context_config.xml";
+00007 public static String app_name = "main";
+
+
+
+
Also note the LBM_APPLICATION_NAME. This is needed for loading the XML configuration file
+
Load XML File
+
Here is how the XML configuration file gets load into the application. It's important to note that the application name must be
+ provided here in order to ensure that this application loads the correct configurations.
When creating a context to use a specific configuration out of an XML file, UM applications can map a context attribute object
+ to a specific context name (TRD1) define in the XML using the appropriate API like so:
+
+
+00013 LBMContextAttributes ctxAttrOne = new LBMContextAttributes();
+00014 ctxAttrOne.setFromXml("TRD1");
+00015 LBMContext ctxOne = new LBMContext(ctxAttrOne);
+
+
+
+
Same for the second context, but note the different attribute object, and the different context name (TRD2) when initializing the
+ context attribute object:
+
+
+00017 LBMContextAttributes ctxAttrTwo = new LBMContextAttributes();
+00018 ctxAttrTwo.setFromXml("TRD2");
+00019 LBMContext ctxTwo = new LBMContext(ctxAttrTwo);
+
+
+
+
+
Configuration Explanation
+
XML Configuration File
+
Here in the application section of the XML is the definitions of the two contexts, and the different topic resolution domains for
+ each context.
There are certainly a lot of different methods for getting the path and name for a configuration file, however for the purposes
+ of this sample application, they are simply defined as macros
+ =semlit,insert,define_configs=
+
Also note the LBM_APPLICATION_NAME. This is needed for loading the XML configuration file
+
Load XML File
+
Here is how the XML configuration file gets load into the application. It's important to note that the application name must be
+ provided here in order to ensure that this application loads the correct configurations.
+ =semlit,insert,xml_file=
+
Creating Contexts
+
When creating a context to use a specific configuration out of an XML file, UM applications can map a context attribute object
+ to a specific context name (TRD1) define in the XML using the appropriate API like so:
+ =semlit,insert,ctx_1=
+
Same for the second context, but note the different attribute object, and the different context name (TRD2) when initializing the
+ context attribute object:
+ =semlit,insert,ctx_2=
+
+
Configuration Explanation
+
XML Configuration File
+
Here in the application section of the XML is the definitions of the two contexts, and the different topic resolution domains for
+ each context.
+
Topic Resolution Domain 1 / Context 1
+ =semlit,insert,trd1=
+
Topic Resolution Domain 2 / Context 2
+ =semlit,insert,trd2=
+
+
diff --git a/multi_context/dotnet/multi_context.sldoc.html b/multi_context/dotnet/multi_context.sldoc.html
new file mode 100644
index 0000000..a530caa
--- /dev/null
+++ b/multi_context/dotnet/multi_context.sldoc.html
@@ -0,0 +1,105 @@
+
+
+
+ Load Configuration File
+
+
+ Example index
+
Configuring Multiple Contexts with an XML Configuration File
+
In this example, the application will be creating two contexts, and each context will exist in different topic
+ resolution domains. Each individual context configuration will be pulled from the same XML configuration file.
+
Topic resolution domains are an important aspect to Ultra Messaging, because only contexts that exist within the
+ same topic resolution domain can publish/subscribe to one another. The UM Dynamic Routing Option (DRO) is one method
+ to bridge topic resolution domains, and is particularly useful for bridging topic resolution domains separated by a
+ WAN. Other than using the DRO, building applications with multiple contexts is the only other way to bridge topic
+ resolution domains
+
Using multiple topic resolution domains in a messaging environment can be an extremely useful option, particularly
+ in environments with large topic spaces and scattered topic interest. For example, in a market data environment, some
+ clients might only be interested in the latest tick for a stock, where as other clients might only be interested in
+ option prices. In this case, it might make sense to put options and ticks in different topic resolution domains.
+
This type of application can be useful for multiple use cases, such as:
+
+
Message Monitor - Some application use cases call for a monitoring application that simply receives messages
+ from all topic resolution environments.
+
Bridge / Republisher - Receive messages from one domain, copy and republish into another. Also useful for
+ subscribing to inter-host protocol such as LBTIPC or LBTSMX, and republishing the messages for off-host
+ consumption
+
+
+
+
MultiContext.cs
+ - (right-click and save as "MultiContext.cs") main program.
There are certainly a lot of different methods for getting the path and name for a configuration file, however for the purposes
+ of this sample application, they are simply defined as macros
+
+
+00011 public static String xml_conf = "./multi_context_config.xml";
+00012 public static String app_name = "main";
+
+
+
+
Also note the LBM_APPLICATION_NAME. This is needed for loading the XML configuration file
+
Load XML File
+
Here is how the XML configuration file gets load into the application. It's important to note that the application name must be
+ provided here in order to ensure that this application loads the correct configurations.
When creating a context to use a specific configuration out of an XML file, UM applications can map a context attribute object
+ to a specific context name (TRD1) define in the XML using the appropriate API like so:
+
+
+00017 LBMContextAttributes ctxAttrOne = new LBMContextAttributes();
+00018 ctxAttrOne.setFromXml("TRD1");
+00019 LBMContext ctxOne = new LBMContext(ctxAttrOne);
+
+
+
+
Same for the second context, but note the different attribute object, and the different context name (TRD2) when initializing the
+ context attribute object:
+
+
+00021 LBMContextAttributes ctxAttrTwo = new LBMContextAttributes();
+00022 ctxAttrTwo.setFromXml("TRD2");
+00023 LBMContext ctxTwo = new LBMContext(ctxAttrTwo);
+
+
+
+
+
Configuration Explanation
+
XML Configuration File
+
Here in the application section of the XML is the definitions of the two contexts, and the different topic resolution domains for
+ each context.