![]() |
The NMS quick start application demonstrates how to use asynchronous messaging to implement a system for purchasing a stock. To purchase a stock, a client application will send a stock request message containing the information about the stock, i.e. ticker symbol, quantity, etc. The client request message will be received by the server where it will perform business processing on the request, for example to determine if the user has sufficient credit to purchase the stock or if the user is even allowed to make the purchase due to existing account restrictions. These are typically external processes as well. Usually the server application will persist state about the request and forward it on to an execute venue where the actual execution of the stock request is performed. In addition, market data for the stock will be sent from the server process to the client. The high level exchange of information is shown below. ![]()
To implement this flow using messaging the following queues and topics will be used. All requests from the client to the server will be sent on the queue named APP.STOCK.REQUEST. Responses to the requests will be sent from the server to the client on a queue unique to each client. In this example the queue name is of the form APP.STOCK.<UserName>, and more specifically is configured to be APP.STOCK.JOE. Market data does not need to be delivered to an individual client as many client applications are interested in this shared information. As such, the server will send market data information on a topic named APP.STOCK.MARKETDATA. The messaging communication between the server and the execution venue is not included as part of the application. An local implementation of the service interface that represents the execution venue is used instead of one based on messaging or another middleware technology. The messaging flow showing the queues and topics used is shown below. ![]() Queues are shown in red and topics in green. Gateways represent the service operation to send a message. The
client will send a stock request to the server based on the contract
defined by the public interface IStockService { void Send(TradeRequest tradeRequest); } The server will send market data to the clients based on the
contract defined by the public interface IMarketDataService { void SendMarketData(); } The market data gateway has no method parameters as it is assumed
that implementations will manage the data to send internally. The
The use of interfaces allows for multiple implementations to be
created. Implementations that use messaging to communicate will be based
on the Spring's The <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" targetNamespace="http://www.springframework.net/nms/common/2008-08-05"> <xs:element name="TradeRequest"> <xs:complexType> <xs:sequence> <xs:element name="Ticker" type="xs:string"/> <xs:element name="Quantity" type="xs:long"/> <xs:element name="Price" type="xs:decimal"/> <xs:element name="OrderType" type="xs:string"/> <xs:element name="AccountName" type="xs:string"/> <xs:element name="BuyRequest" type="xs:boolean"/> <xs:element name="UserName" type="xs:string"/> <xs:element name="RequestID" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> Running xsd.exe on this schema will result in a class that contains properties for each of the element names. A partial code listing of the TradeRequest class is shown below // This code was generated by a tool. public partial class TradeRequest { public string Ticker { get { return this.tickerField; } set { this.tickerField = value; } } public long Quantity { get { return this.quantityField; } set { this.quantityField = value; } } // Additional properties not shown for brevity. } The schema and the When sending a response back to the client the type
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" targetNamespace="http://www.springframework.net/nms/common/2008-08-05"> <xs:element name="TradeResponse"> <xs:complexType> <xs:sequence> <xs:element name="Ticker" type="xs:string"/> <xs:element name="Quantity" type="xs:integer"/> <xs:element name="Price" type="xs:decimal"/> <xs:element name="OrderType" type="xs:string"/> <xs:element name="Error" type="xs:boolean"/> <xs:element name="ErrorMessage" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> The // This code was generated by a tool. public partial class TradeResponse { public string Ticker { get { return this.tickerField; } set { this.tickerField = value; } } public long Quantity { get { return this.quantityField; } set { this.quantityField = value; } } // Additional properties not shown for brevity. } The market data information will be sent using a Hashtable data structure. When the public class StockAppHandler { private IExecutionVenueService executionVenueService; private ICreditCheckService creditCheckService; private ITradingService tradingService; public TradeResponse Handle(TradeRequest tradeRequest) { TradeResponse tradeResponse; IList errors = new ArrayList(); if (creditCheckService.CanExecute(tradeRequest, errors)) { tradeResponse = executionVenueService.ExecuteTradeRequest(tradeRequest); tradingService.ProcessTrade(tradeRequest, tradeResponse); } else { tradeResponse = new TradeResponse(); tradeResponse.Error = true; tradeResponse.ErrorMessage = errors[0].ToString(); } return tradeResponse; } } The stub implementations of the services, located in the namespace
The client will receive a TradeResponse message as well as a Hashtable of data representing the market data. The message handle for the client is the class Spring.NmsQuickStart.Client.Handlers.StockAppHandler and is shown below. public class StockAppHandler { // definition of stockController omitted for brevity. public void Handle(Hashtable data) { // forward to controller to update view stockController.UpdateMarketData(data); } public void Handle(TradeResponse tradeResponse) { // forward to controller to update view stockController.UpdateTrade(tradeResponse); } } What is important to note about these handlers is that they contain no messaging API artifacts. As such you can write unit and integration tests against these classes independent of the middleware. The missing link between the messaging world and the objects processed by the message handlers are message converters. Spring's messaging helper classes, i.e. SimpleMessageListenerContainer and NmsTemplate use message converters to pass data to the handlers and to send data via messaging for gateway implementations The implementation of IMessageConverter used is
<object name="XmlMessageConverter" type= This configuration is common between the server and the client. The implementations of the gateway interfaces inherit from Spring's
helper class public class NmsStockServiceGateway : NmsGatewaySupport, IStockService { private IDestination defaultReplyToQueue; public IDestination DefaultReplyToQueue { set { defaultReplyToQueue = value; } } public void Send(TradeRequest tradeRequest) { // post process message NmsTemplate.ConvertAndSendWithDelegate(tradeRequest, delegate(IMessage message) { message.NMSReplyTo = defaultReplyToQueue; message.NMSCorrelationID = new Guid().ToString(); return message; }); } } The The object definition for the
<object name="StockServiceGateway" type= In this example the 'raw'
A similar configuration is used on the server to configure the class
Since the client is also a consumer of messages, on the topic APP.STOCK.MARKETDATA and the queue APP.STOCK.JOE (for Trader Joe!), two message listener containers are defined as shown below. <nms:listener-container connection-factory="ConnectionFactory"> <nms:listener ref="MessageListenerAdapter" destination="APP.STOCK.JOE" /> <nms:listener ref="MessageListenerAdapter" destination="APP.STOCK.MARKETDATA" pubsub-domain="true"/> </nms:listener-container> Refer to the messages reference docs for all the available attributes to configure the container and also the section on registering the NMS schema with Spring.. On the server we define a message listener container for the queue APP.STOCK.REQUEST but set the concurrency property to 10 so that 10 threads will be consuming messages from the queue. <nms:listener-container connection-factory="ConnectionFactory" concurrency="10"> <nms:listener ref="MessageListenerAdapter" destination="APP.STOCK.REQUEST" /> </nms:listener-container> To run both the client and server make sure that you select 'Multiple Startup Projects' within VS.NET. The GUI has a button to make a hardcoded trade request and show confirmation in a text box. A text area is used to display the market data. There is a 'Get Portfolio' button that is not implemented at the moment. A picture of the GUI after it has been running for a while and trade has been sent and responded to is shown below ![]()
|