start of nms quickstart docs
quartz doc cleanup
This commit is contained in:
@@ -43,6 +43,7 @@
|
||||
<!ENTITY data-quickstart SYSTEM "data-quickstart.xml">
|
||||
<!ENTITY tx-quickstart SYSTEM "tx-quickstart.xml">
|
||||
<!ENTITY quartz-quickstart SYSTEM "quartz-quickstart.xml">
|
||||
<!ENTITY nms-quickstart SYSTEM "nms-quickstart.xml">
|
||||
<!ENTITY javadevelopers SYSTEM "javadevelopers.xml">
|
||||
<!ENTITY misc SYSTEM "misc.xml">
|
||||
<!ENTITY pooling-example SYSTEM "pooling-example.xml">
|
||||
@@ -366,6 +367,9 @@
|
||||
<listitem>
|
||||
<xref linkend="quartz-quickstart" />
|
||||
</listitem>
|
||||
<listitem>
|
||||
<xref linkend="nms-quickstart" />
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</partintro>
|
||||
&quickstarts;
|
||||
@@ -376,6 +380,7 @@
|
||||
&data-quickstart;
|
||||
&tx-quickstart;
|
||||
&quartz-quickstart;
|
||||
&nms-quickstart;
|
||||
</part>
|
||||
<part id="index-javadevelopers">
|
||||
<title>Spring.NET for Java developers</title>
|
||||
|
||||
241
doc/reference/src/nms-quickstart.xml
Normal file
241
doc/reference/src/nms-quickstart.xml
Normal file
@@ -0,0 +1,241 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<chapter id="nms-quickstart">
|
||||
<title>NMS QuickStart</title>
|
||||
|
||||
<section>
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>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 recieved by the server where it will
|
||||
perform business processing on the requst, 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. 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
|
||||
peformed. In addition, market data for the stock will be sent from the
|
||||
server process to the client. The high level messaging flow is shown
|
||||
below.</para>
|
||||
|
||||
<para></para>
|
||||
|
||||
<para></para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Message Destinations</title>
|
||||
|
||||
<para>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.</para>
|
||||
|
||||
<para> </para>
|
||||
|
||||
<para></para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Gateways</title>
|
||||
|
||||
<para>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 <classname>IStockService</classname> interface . </para>
|
||||
|
||||
<programlisting> public interface IStockService
|
||||
{
|
||||
void Send(TradeRequest tradeRequest);
|
||||
}</programlisting>
|
||||
|
||||
<para>The server will send market data to the clients based on the
|
||||
contract defined by the <classname>IMarketDataService</classname>
|
||||
interface. </para>
|
||||
|
||||
<programlisting> public interface IMarketDataService
|
||||
{
|
||||
void SendMarketData();
|
||||
}</programlisting>
|
||||
|
||||
<para>The market data gateway has no method parameters as it is assumed
|
||||
that implementations will manage the data to send internally. The
|
||||
<classname>TradeRequest</classname> object is one of the data objects that
|
||||
will be exchanged in the application and is discussed in the next
|
||||
section.</para>
|
||||
|
||||
<para>The use of interfaces allows for multiple implementations to be
|
||||
created. Implementations that use messaging to communicate will be based
|
||||
on the Spring's <classname>NmsGateway</classname> class and will be
|
||||
discussed later. stub or mock implementations can be used for testing
|
||||
purposes. </para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Message Data</title>
|
||||
|
||||
<para>The <classname>TradeRequest</classname> object shown above contains
|
||||
all the information required to process a stock order. To promote the
|
||||
interoperability of this data across different platforms the
|
||||
<classname>TradeRequest</classname> class is generated from an XML Schema
|
||||
using Microsoft's Schema Definition Tool (xsd.exe). The schema for trade
|
||||
request is shown below</para>
|
||||
|
||||
<programlisting><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>
|
||||
</programlisting>
|
||||
|
||||
<para>Running xsd.exe on this schema will result in a class that contains
|
||||
properties for each of the element names. A parital code listing of the
|
||||
TradeRequest class is shown below</para>
|
||||
|
||||
<programlisting>// 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.
|
||||
|
||||
}</programlisting>
|
||||
|
||||
<para>The schema and the <classname>TradeRequest</classname> class are
|
||||
located in the project <classname>Spring.NmsQuickStart.Common</classname>.
|
||||
This common project will be shared between the server and client for
|
||||
convenience.</para>
|
||||
|
||||
<para>When sending a response back to the client the type
|
||||
<classname>TradeResponse</classname> will be used. The schema for the
|
||||
<classname>TradeResponse</classname> is shown below </para>
|
||||
|
||||
<programlisting><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></programlisting>
|
||||
|
||||
<para>The <classname>TradeResponse</classname> type also generated from a
|
||||
schema using xsd.exe. A partial code listing is shown below</para>
|
||||
|
||||
<programlisting>// 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.
|
||||
|
||||
}</programlisting>
|
||||
|
||||
<para>The market data information will be sent using a Hashtable data
|
||||
structure.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Mesage Handlers</title>
|
||||
|
||||
<para>When the <classname>TradeRequest</classname> message is received by
|
||||
the server, it wll be handled by the class
|
||||
<classname>Spring.NmsQuickStart.Server.Handlers.StockAppHandler
|
||||
</classname>shown below</para>
|
||||
|
||||
<programlisting> 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;
|
||||
}
|
||||
}</programlisting>
|
||||
|
||||
<para></para>
|
||||
</section>
|
||||
</chapter>
|
||||
@@ -9,9 +9,9 @@
|
||||
a given time without any user interaction, usually to perform some
|
||||
administrative tasks. These tasks need to be scheduled, say to perform a
|
||||
job in the early hours of the morning before the start of business. This
|
||||
functionality is provided by a using job scheduling software. Quartz.NET
|
||||
is an excellent open source job scheduler that can be used for these
|
||||
purposes. It provides a wealth of features ,such as persistent jobs and
|
||||
functionality is provided by using job scheduling software. Quartz.NET is
|
||||
an excellent open source job scheduler that can be used for these
|
||||
purposes. It provides a wealth of features, such as persistent jobs and
|
||||
clustering. To find out more about Quartz.NET visit their <ulink
|
||||
url="http://quartznet.sourceforge.net/">web site</ulink>. Spring
|
||||
integration allows you to use Spring to configure Quartz jobs, triggers,
|
||||
@@ -31,12 +31,13 @@
|
||||
in order to pass information between different job instances you stash
|
||||
data away in a hashtable that gets passed to the each Job instance upon
|
||||
its creation. Quartz's <classname>JobDetail</classname> class combines the
|
||||
<classname>IJob</classname> and this hashtable of data. Instead of a
|
||||
generic hashtable the class <classname>JobDataMap</classname> is used.
|
||||
Triggers are registered with a Quartz <classname>IScheduler</classname>
|
||||
implementation that manages the overall execution of the triggers and
|
||||
jobs. The implementation <classname>StdSchedulerFactory</classname> is
|
||||
generally used.</para>
|
||||
<classname>IJob</classname> and this hashtable of data. Instead of the
|
||||
standard <classname>System.Collections.Hashtable</classname> the class
|
||||
<classname>JobDataMap</classname> is used. Triggers are registered with a
|
||||
Quartz <classname>IScheduler</classname> implementation that manages the
|
||||
overall execution of the triggers and jobs. The
|
||||
<classname>StdSchedulerFactory</classname> implementation is generally
|
||||
used.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@@ -46,9 +47,9 @@
|
||||
Spring's convenience base class <classname>QuartzJobObject</classname> and
|
||||
another which does not inherit from any base class. The latter class is
|
||||
adapted by Spring to be a Job. Two triggers, one for each of the jobs, are
|
||||
created, and these triggers are in turn registered with a scheduler. In
|
||||
each case the job implementation will write information to the
|
||||
console.</para>
|
||||
created. These triggers are in turn registered with a scheduler. In each
|
||||
case the job implementation will write information to the console when it
|
||||
is executed.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@@ -187,10 +188,11 @@
|
||||
</object></programlisting>
|
||||
|
||||
<para>This creates an instances of Quartz's SimpleTrigger class (as
|
||||
compared to its CronTrigger class used in the previous section. StartDelay
|
||||
and RepeatInterval properties are TimeSpan objects than can be set using
|
||||
the convenient strings such as 10s, 1h, etc, as supported by Spring's
|
||||
custom TypeConverter.</para>
|
||||
compared to its CronTrigger class used in the previous section).
|
||||
<literal>StartDelay</literal> and <literal>RepeatInterval</literal>
|
||||
properties are TimeSpan objects than can be set using the convenient
|
||||
strings such as 10s, 1h, etc, as supported by Spring's custom
|
||||
TypeConverter for TimeSpans.</para>
|
||||
|
||||
<para>This trigger can then be added to the scheduler's list of registered
|
||||
triggers as shown below.</para>
|
||||
|
||||
Reference in New Issue
Block a user