See discussions, stats, and author profiles for this publication at: [Link]

net/publication/43121560

Upon a Message-Oriented Trading API

Article in Informatica Economica · January 2010

Source: DOAJ

CITATIONS READS

3 445

1 author:

Claudiu Vinte
Bucharest University of Economic Studies
27 PUBLICATIONS 70 CITATIONS

SEE PROFILE

All content following this page was uploaded by Claudiu Vinte on 30 March 2017.

The user has requested enhancement of the downloaded file.

208 Informatica Economică vol. 14, no. 1/2010

Upon a Message-Oriented Trading API

Claudiu VINŢE
Opteamsys Solutions, Bucharest, Romania
[Link]@[Link]

In this paper, we introduce the premises for a trading system application-programming

interface (API) based on a message-oriented middleware (MOM), and present the results of
our research regarding the design and the implementation of a simulation-trading system
employing a service-oriented architecture (SOA) and messaging. Our research has been
conducted with the aim of creating a simulation-trading platform, within the academic
environment, that will provide both the foundation for future experiments with trading
systems architectures, components, APIs, and the framework for research on trading
strategies, trading algorithm design, and equity markets analysis tools. Mathematics Subject
Classification: 68M14 (distributed systems).
Keywords: Trading System API, Straight-Through Processing, Distributed Computing,
Service-Oriented Architecture (SOA), Message-Oriented Middleware (MOM), Java Message
Service (JMS), OpenMQ

1 A brief introduction to trading APIs

The information technology (IT) has made
exchanges far more efficient in handling heavy
the exchange members face a multitude of
challenges when it comes to the ability to adapt
to continuous changes and improvements
volume in a timely fashion and at reasonable implemented both upstream (client connectivity
cost. Furthermore, IT enables geographically and interface) and downstream (settlement and
dispersed marketplaces to be more effectively clearing).
consolidated [1] [2]. The strategic advantage of In this context, the application-programming
an electronic platform can be summarized in interface (API) employed within the trading
form of the following beneficial effects: system of a broker/dealer, or a market access
 support for an efficient vertical integration provider, acts as a binding agent among a variety
(from trading to settlement); of applications that compose the system. From
 supply the premises for a national and that perspective, the manner in which the API is
regional strategy (horizontal integration); designed to facilitate the interactions between
 offers the fundaments for a decentralized applications, it determines the characteristics and
market access for participants; the general behavior of the entire trading system.
 continuous or extended trading hours; The architectural design and API design of a
 better overall services for members trading system are intrinsically connected [5].
(availability, functionality, support); There have been various approaches in trading
 means for an effective centralized market architecture design, along with the appropriate
surveillance from the national regulatory APIs.
bodies. One of the earliest approaches was the client-
In nowadays trading environment, a market server architecture, employing TCP/IP socket-
center strives to offer a fast and reliable access, based communication between the multiple
from anywhere and anytime, aiming to achieve a clients and the server [6] [7]. The corresponding
fully integrated straight-through processing API consists in a collection of call-forwards
(STP). The STP desiderate means that, once an (request calls from the clients) and call-backs
order is placed through the order routing channel, (responses or other informative data provided
it follows a fully integrated online procedure, back to the clients by the server). Conceptually,
passing seamlessly from its entrance on the order this communication paradigm can be identified in
book, to matching on the exchange, and on most of the distributed computing models, the
through to clearance and settlement [3] [4]. On differences residing in the underlying transfer
IT level, STP requires at least the vertical mechanism. One of the most commonly used
integration of the capital market. distributed computing model today by both Java
In this context, the trading systems employed by and .NET platforms is based on the concept of
Informatica Economică vol. 14, no. 1/2010 209

remote procedure call (RPC). Component-based the system as if it runs in one process. Work is
architectures such as JavaBeans are built on the performed sequentially, ensuring that tasks are
top of this model. RPC attempts to mimic the completed in a predefined order. The
behavior of a system that runs in one process. synchronized nature of RPC tightly couples the
When a remote procedure is invoked, the caller is client (the software making the call) to the server
blocked until the procedure completes and (the software servicing the call), as it is shown in
returns the control to the caller. This figure 1. The client cannot proceed – it is blocked
synchronized model allows the developer to view – until the server responds [8].

Application
B
RPC
Client/Server

Application Application
A C
RPC RPC
Client/Server Client/Server

RPC RPC
Client/Server Client/Server
Application E Application
D

Fig. 1. A tightly coupled RPC based architecture

On of the most successful areas of the tightly synchronous call to each of the other systems.
coupled RPC model has been in building 3-tier, This cause the order entry system to block and
or n-tier, applications. In this model, a wait until each system is finished processing the
presentation layer (fist tier) communicates using order. Multithreading and looser RPC
RPC with business logic on the middle tier mechanisms like CORBA’s one-way call can be
(second tier), which accesses date stored on the employed as options, but these solutions have
backed (third tier). The tightly coupled nature of their own complexities. Threads are expensive
RPC creates highly interdependent systems, when not used wisely, and CORBA one-way
where a failure on one system has an immediate calls still require application-level error handling
and debilitating impact on other systems. RPC for failure conditions. Furthermore, systems can
works well in many scenarios, but its crash, object interfaces need to be updated and,
synchronous, tightly coupled nature is severe therefore, scheduled downtimes need to happen.
handicap in system-to-system processing where Summarizing, it is the synchronized, tightly
vertical applications are integrated together, as it coupled, interdependent nature of RPC systems
is the case with a trading platform, that has to that cause entire system to fail as a result of
integrate client connectivity components, order failures in subsystems. When a tightly coupled
processing, market execution capture, trade nature of RPC is not appropriate, as in system-to-
generation etc. In system-to-system scenarios, the system scenarios, messaging provides an
lines of communications between vertical alternative.
systems are many and multidirectional, as Figure On a different approach, problems with
1 illustrates. When there is a new system to be availability of subsystems are not an issue with
added to the platform that implies a going back, message-oriented middleware (MOM). A
and let all the other system know about it. When fundamental concept of messaging is that
one part of the system goes down, everything communication between applications is intended
halts. For example, when a client order is posted to be asynchronous. The API design to connect
to the order entry system, it needs to make a the applications together is a one-way message
210 Informatica Economică vol. 14, no. 1/2010

that requires no immediate response from another systems.

application. In other words, there is no blocking, In an asynchronous messaging trading system,
or least no indefinite blocking. Once a message is each subsystem (client connectivity lines, order
sent, the messaging client can move on to other managing, market ordering lines, market
tasks; it does not have to wait for a response. execution capture, trade generation etc.) is
This is the major difference between RPC and decoupled from the other subsystems, as figure 2
asynchronous messaging, and it is critical to illustrates.
understand the advantages offered by messaging
Application
Application
A B
JMS
JMS
Client Client

Message
Server
(Broker) Application
Application C
E JMS
JMS Client
Client

Application
D

JMS
Client

Fig. 2. JMS provides for a loosely coupled message-oriented architecture

The applications, subsystems communicate will deliver all the messages that the consumers
through messaging server (message broker), so missed while not connected to the message
that a failure in one does not impede the broker. The guaranteed delivery capability of a
operation of the others. This aspect is particularly MOM sets it apart from an object request broker
critical in the case of a trading platform, where is (ORB). An ORB or ORB-based middleware
imperiously necessary to offer order entry enables an application’s objects to be distributed
availability to the clients, and ensure that the and shared across heterogeneous networks, but
executions results are returned to the investors as object persistence, even when this is ability is
soon as they are captured from the market by the offered, it increases the complexity of the ORB
member or intermediary trading system. In a and makes for an even more accentuated
distributed computing system, partial failure is a dependency upon the common object libraries to
fact. One of the subsystems may have an be distributed and maintained across the systems
unpredictable failure or may need to be shut [9] [10].
down at some time during its continuous
operation. Geographic dispersion of in-house and 2 API requirements within a simulation-
partner trading systems can further amplify a trading environment
failure situation. In recognition of this, Java In real world environment, a trading system has
Message Service (JMS) provides guaranteed to combine a multitude of requirements, many of
delivery, which ensures that intended consumers them having puling in different directions and,
will eventually receive a message, even if partial consequently, and equilibrium of contraries it is
failure occurs. Guaranteed delivery uses a store- desired to be obtained: it has to be fast, yet
and-forward mechanism, which means that the flexible and adaptable; responsive, yet reliable
underlying message broker will write the and consistent. In order to achieve such
incoming messages out to a persistent store, it the characteristics, technically opposite in their
intended consumers are not currently available, nature, the architectural design and the API
or active, from the message server perspective. employed for the inter-application
When the receiving applications become communication have to be carefully tailored to
available later, the store-and-forward mechanism the specific needs. In our case, we have explored
Informatica Economică vol. 14, no. 1/2010 211

for an appropriate architecture and API suitable forward mechanism for possible assistance in
for a simulation-trading platform, within the recovery scenarios.
academic environment. In this context, sheer Having the above stated requirements, for a
response time of the system as whole is not an simulation-trading platform that is to be design
issue and, therefore, rather than focusing on the from ground up, an API design based on a
inter-application communication aspects we have message-oriented middleware seems to be the
opted out to research into the system most appropriate approach [11] [12]. We
functionalities and the application- programming presented in [13] our earlier research upon the
interface that connects everything together. design of a trading system architecture based on a
Therefore, the API requirements within a MOM, namely OpenMQ.
simulation-trading environment concern the In this paper, we present the results of the
followings: subsequent level of our research, concerning the
 the simulation-trading platform should consist application-programming interface for the
of the following systems at minimum: architectural trading design previously
o trading graphical user interface (GUI); introduced.
o order management server (OMS);
o trade generation and portfolio management 3 Designing a service-oriented trading
server (PMS); architecture
o exchange simulation engine (ESE), to act In the process of designing an API for a trading
as a market place; architecture of a service-orientation, we departed
o pseudo-random order generator (PROG), from the functionalities the systems listed above
to enable a controlled, and desirably high, have to provide within the trading platform, and
liquidity on the simulation market; the nature of the data that is to be exchanged
o delayed-data feed (DDF), components to between them [14]. The trading API is design
be built around web service clients, for based on platform independent Java Message
capturing and disseminating delayed-data Service (JMS) interface [15] [16]. It exploits all
supplied by the Bucharest Stock Exchange the communication models and the mechanisms
(BSE) through the means of web services; provided by JMS, for supporting the specific
 the architecture for the trading platform has to functionality of each system, and the way it
be one of service-orientation; the component interacts with another. For example, when an
applications/subsystems need to be clearly investor places a new order in the system, it is
defined functionally, and have to have the employed the asynchronous request/reply
functionality exposed in the manner of a mechanism provided by JMS. The trading GUI
service provider; produces and sends a new order message, to the
 the communication layer has to offer support destination queue ORDER_REQUEST_QUEUE,
for both point-to-point and publish-and- and then waits on the reply queue
subscribe communication models; ORDER_REPLY_QUEUE, for a specified amount
 the point-to-point communication model has of time, to receive an acknowledgement from the
to offer support for an event-driven order management server (OMS). The name of
architectural behavior, and for a request/reply the reply queue is sent to the initial receiver
type of mechanism; (OMS) through the request message. We have to
 the simulation-trading platform has to be point out here that the asynchronous
reliable when it comes to order clients, request/reply offered through the JMS interface
matching results, trades and portfolios does not block the requester processing flow
handling i.e., in case of subsystems failure, indefinitely, as is the case with a synchronous,
there should be recovery mechanisms in RPC-based request/reply, but for a certain
place; amount of time, specified by the application
 the system architecture has to offer great programmer through the JMS interface. Once the
flexibility regarding the possibility of adding client order was successfully received and
new application/subsystems in the future; the processed by OMS, it is then flowed to the
API has to be design in such a way that, in the simulation exchange (ESE) by being sent to the
eventuality of an extension, the current destination queue CLIENT_ORDER_QUEUE.
functionality has not to be affected; This point-to-point order sending, from OMS to
 the communication middleware has to provide ESE, is achieved using the fire-and-forget
support for data persistence and store-and- mechanism, which means that the OMS sends the
212 Informatica Economică vol. 14, no. 1/2010

client order to the specified destination, and then messages sent from ESE to the destination queue
continues its processing flow, without waiting for MARKET_ORDER_QUEUE. The figure 3
any reply from ESE. This mechanism completely illustrates these flows, in a normal trading
decouples ESE from OMS. However, the client operation scenario.
order status can be captured back by OMS, in a
similar asynchronous fashion, by receiving the

PMS ESE

Message Broker

CLIENT_EXECUTION_TOPIC MARKET_EXECUTION_QUEUE

Trading GUI CLIENT_ORDER_TOPIC MARKET_ORDER_QUEUE

CLIENT_ORDER_QUEUE
DDF
ORDER_REPLY_QUEUE

ORDER_REQUEST_QUEUE PRICE_TOPIC

OMS PROG

Fig. 3. Client order and market execution flows in normal operation scenario

The dashed lines depict the reply message flow. On a different flow, the delayed-data feed (DDF)
If the client order is matched on the simulation publishes, for the applications interested in it,
market, then ESE generates an execution real market data updates captured from Bucharest
message, which is sent asynchronously to the Stock Exchange (BSE), via a collection of web
destination MARKET_EXECUTION_QUEUE. service clients. Figure 3 shows the pseudo-
OMS listens to both destinations random order generator (PROG) as subscriber to
MARKET_ORDER_QUEUE and the PRICE_TOPIC. Based on the price updates
MARKET_EXECUTION_QUEUE, which are fed received from this topic, PROG is designed to
asynchronously by ESE, and then publishes the generate new orders and send them to ESE, for
order status updates and the market generated enabling a controlled, and desirably high,
executions to the CLIENT_ORDER_TOPIC and liquidity on the simulation market.
CLIENT_EXECUTION_TOPIC, respectively. The trading GUI is offered as a web browser
The applications that subscribe to these topics, accessible Java applet and, consequently, its
trading GUIs and portfolio management server communication with the messaging platform is
(PMS), will have to filter the published messages achieved through a Java servlet responsible with
in order to process only the messages intended to the HTTP tunneling. The intention and the format
them. In particular, PMS will subscribe for all of this paper do not afford us the necessary space
client order updates and market executions, in to go into all the details of this message-oriented
order to generate the corresponding trades and trading API. For further references, can be
maintain client portfolios. It is worth mentioning consulted our website: [Link]. There
here, that PMS subscriptions to afore mentioned are numerous message flows, which cover
topics are realized in a durable way. That allows various levels of communication between
PMS to receive all the messages published to applications, for supporting multiple layers of
those topics, regardless of it maintaining system business logic. For example, the
continuously an active connection to the message initialization phase of the trading GUI, may
broker. involve the acquirement of the list of tradable
financial instruments for the given trading day.
Informatica Economică vol. 14, no. 1/2010 213

Trading GUI achieves the list from OMS, then waits for OMS reply on destination
through the asynchronous request/reply INSTRUMENT_LIST_REPLY_QUEUE, as
mechanism supplied by JMS. GUI sends a figure 4 shows.
request to the destination
INSTRUMENT_LIST_REQUEST_QUEUE and
Message Broker
PRICE_TOPIC

INSTRUMENT_LIST_REPLY_QUEUE

INSTRUMENT_LIST_REQUEST_QUEUE

LOG_OUT_REPLY_QUEUE DDF
Trading GUI
LOG_OUT_REQUEST_QUEUE

LOG_IN_REPLY_QUEUE

LOG_IN_REQUEST_QUEUE

OMS

Fig. 4. Logging in and out, along with GUI initialization flows

Employing the same JMS communication model, message may have defined certain application-
the logging in and logging out procedures are specific properties, in the form of a list of pairs:
achieved from the trading GUI with respect to the <property name><property value>.
corresponding involvement of OMS. The application-specific properties may be used
The trading GUI may also subscribe to the for message filtering, event-driven processing, or
PRICE_TOPIC, if the user wants to consult the for letting the consumer know about the nature of
price data available from the market, along with the message and, therefore, the possible ways of
daily volume, number of transactions etc. for a processing it. Departing from Message
specified symbol. interface, JMS defines five more types of
All the messages flowed through the trading messages that can be handled by the JMS
system are marked to be persistent and, therefore, message server, namely: TextMessage,
to be stored by the message broker until the ObjectMessage, BytesMessage,
intended destination acknowledge their StreamMessage, and MapMessage [17].
consumption. Once a persistent message is The Message interfaces are defined according
received and acknowledged by the messaging to the kind of payload they are designed to carry.
platform, its delivery to the intended destination In some cases, Message types were included in
is guaranteed. The message server stores out on JMS to support legacy payloads that are common
disk every message marked as persistent, and useful, which is the case with the
providing a guaranteed delivery of the message TextMessage, BytesMessage, and
to the destination even in the case of server
StreamMessage message types. In other
failure.
cases, the Message types were defined to
In line with JMS requirements, the messages are
to be autonomous and self-contained entities. facilitate emerging needs; for example
Each message of the trading API contains only ObjectMessage can transport serializable
the relevant data for a potential consumer to Java objects.
process it. A message does not carry imbedded Being a new design from the ground up, our
instructions regarding the way in which it has to current implementation of the proposed trading
be process by the consumer. However, a JMS API makes use of the ObjectMessage
interface, since the whole trading system is based
214 Informatica Economică vol. 14, no. 1/2010

on the Java platform. However, it may be easily current trading day. In order to achieve this
converted to a more open approach, which would desiderate transparently to the user, the trading
employ the MapMessage interface. This GUI has to actively request from OMS the list of
interface allows for defining the payload as list of the orders that the investor has placed into the
pairs <key><value>. This approach would open order book during the current trading session, and
the road for a self-defined API: each data field in the list of the market executions associated to the
the system has a uniquely assigned identification possibly matched orders. These flows make use
label (key). Hence, each message payload may be of the asynchronous request/reply mechanism, as
composed of a subset of the generically defined figure 5 illustrates.
collection of available date fields in the system. In addition to procedures described above, there
Such an implementation would require additional may be requests from the investor for consulting
layers in the applications, for accomplishing the his or her history of completed transactions, and
necessary marshaling and de-marshaling the current situation of the portfolio of owned
activities, in order to convert the data financial instruments.
encapsulated in a Java object to the In case of an ESE failure, being a simulation-
MapMessage type of payload, and vice versa. trading environment, the recovery procedure
implies an active request to the OMS for all the
4 Messaging as an agile and reliable approach client orders sent to the market during the current
for a trading API trading session, and which are not totally
Benefiting from the guaranteed message delivery executed. The exchange simulation engine is
supported by the JMS server, along with the designed to be very responsive and, in order to
store-and-forward mechanism offered to the achieve that, it keeps all the data in memory, and
durable subscribers, the trading API that we does not waste time in persisting any data on
propose does not need to address aspects related disk.
to data persistence in each subsystem of the Summarizing, messaging is a very effective
trading platform. In fact, the order management means of building the abstraction layer within
server (OMS) and the portfolio management SOA, needed to fully abstract a business service
server (PMS) are the only subsystems that are (functionality) from its underlying
designed to interact with a database. It is the implementation. Through business messaging,
business logic of the trading platform, which the business service (say, the order booking) does
commands for a persistent storage of the order not need to be concerned about where the
books, market executions and client portfolios. In corresponding implementation service is, what
addition to that, the trading API has to provide language it is written in, what platform it is
reliable procedures for system recovery in case of deployed in, or even the name of the
a partial failure. For example, by subscribing in a implementation service. Messaging also provides
durable manner to CLIENT_ORDER_TOPIC the scalability needed within a SOA
and CLIENT_EXECUTION_TOPIC, PMS environment, and also provides a robust level of
ensures that if it goes down unexpectedly, all the monitoring and control of requests coming into
messages published to those topics, while it has and out of an enterprise service bus (ESB). For
lost the connection to the message server, will be example, in our implementation of the trading
delivered to it once the connection is API, it was not important how many OMS
reestablished. Similarly, the message broker will instances might be brought up and kept running
store the client order messages, placed by OMS at the same time. Scalability, in the context of
onto the CLIENT_ORDER_QUEUE, until the messaging systems, is achieved by introducing
exchange simulation engine (ESE) consumes multiple message receivers that can process
them. However, there are restart/recovery different messages concurrently. As messages
procedures that need to be addressed stack up waiting to be processed, the number of
programmatically, and the trading API has to messages in the queue, or what is otherwise
support them. For example, a trading GUI may known as the queue depth, starts to increase. As
normally connect to and disconnect from the the queue depth increases (as client order
trading system for multiple times during a trading requests may accumulate in the
session. The investor would need to have ORDER_REQUEST_QUEUE, for example)
recovered and shown in the GUI the entire system response time increases and throughput
trading activity that he or she has done during the decreases. One way to increase the scalability of
a system is to add multiple message listeners to
Informatica Economică vol. 14, no. 1/2010 215

the queue to process more requests concurrently. the design of our trading API we carefully
This can be easily done dynamically, if the API is ensured that each specified destination handles a
designed to use message queues that handle particular type of payload.
homogenous type of messages. Consequently, in

PMS

Message Broker
TRADE_LIST_REQUEST_QUEUE

TRADE_LIST_REQUEST_QUEUE

PORTFOLIO_LIST_REPLY_QUEUE
ESE
PORTFOLIO_LIST_REQUEST_QUEUE

Trading GUI ORDER_LIST_REPLY_QUEUE

ORDER_LIST_REQUEST_QUEUE

EXECUTION_LIST_REPLY_QUEUE

EXECUTION_LIST_REQUEST_QUEUE

OMS

Fig. 5. Flows concerning trading GUI and ESE restart/recovery scenarios

The use of messaging, as part of the overall system as a whole.

service-oriented trading solution, allows for With the presented API, the architecture of the
greater architectural flexibility and agility. These trading system that we intend to build within the
qualities are achieved through the use of ASETS project (an abbreviation from the
abstraction and decoupling. With messaging, Romanian version of the Trading System of The
subsystems, components, and even services can Bucharest Academy of Economic Studies), is
be abstracted to the point where they can be currently contoured. In a simulation-trading
replaced with little or no knowledge by the client environment, human agents compete on
components. Architectural agility is the ability to resources created by computer algorithms, within
respond quickly to constantly changing a scenario-driven market place. The components
environment. By using messaging to abstract and that create these scenarios have to sense the
decouple components, the trading API that we trading patterns of the human investors, and act
have proposed in this paper, can quickly respond accordingly. Designing a trading API based on a
to changes in software, hardware and even message-oriented middleware provides the
business logic. Our intention was to design a optimum balance, with regards to the overall
trading API, which can be adapted with ease to system response, availability, reliability, and
the academic needs for future researches on flexibility in accepting future changes and
trading strategies, design of trading algorithms, extensions.
and equity markets analysis tools. The ability to swap out one system for another,
change a technology platform, or even change a
5 Conclusions vendor solution without affecting the client
As part of our undergoing research, directed to applications can be achieved through abstraction
the overall design and implementation of a using messaging. Through messaging, the
simulation-trading platform within an academic, message producer, or client component (from the
the trading API proposed in this paper perspective of the message server), does not need
intrinsically determines the characteristics of the to know which programming language or
 216 Informatica Economică vol. 14, no. 1/2010

platform the receiving component is written in, [8] A. S. Tanenbaum, S. Van Maarten,
where the component or service is located, what Distributed Systems - Principles and
the component or service implementation name Paradigm, Vrije Universiteit Amsterdam,
is, or even the protocol used to access that The Netherlands, Prentice Hall, New Jersey,
component or service (as we have seen with the 2002.
HTTP tunneling, for web accessible trading [9] C. Vinţe Claudiu, Aspecte ale Proiectării
GUI). It is by means of these levels of abstraction unui Order Request Broker (ORB) - Partea I,
that enable for replacing the components and Informatica Economică, Vol. 5, No. 2 (18),
subsystems more easily, thereby increasing Bucharest, 2001.
architectural agility. [10] C. Vinţe Claudiu, Aspecte ale Proiectării
unui Order Request Broker (ORB) - Partea a
References II-a, Informatica Economică, Vol. 5, No.
[1] H. McIntyre (editor), How the U.S. Securities 3(19), Bucharest, 2001.
Industry Works - Updated and Expanded in [11] J. Kerievsky, Refactoring to Patterns,
2004, The Summit Group Press, New York, Addison-Wesley, Boston, 2005.
2004. [12] T. G. Mattson, B. A. Sanders and B. L.
[2] A. R. Schwartz, R. Francioni, Equity Markets Massingill, Patterns for Parallel
in Action (The Fundamentals of Liquidity, Programming, Addison-Wesley, Boston,
Market Structure & Trading), John Wiley & 2005.
Sons, Inc., 2004. [13] C. Vinţe, „Upon a Trading System
[3] H. McIntyre (editor), Straight Through Architecture based on OpenMQ
Processing, The Summit Group Publishing, Middleware,” Open Source Scientific
Inc., New York, 2004. Journal, Vol.1, No.1, 2009, Available at:
[4] L. Harris, Trading and Exchanges, Oxford [Link]
University Press, Oxford, 2003. [14] T. Erl (with additional contributors), SOA
[5] C. Vinţe, „The Informatics of the Equity Design Patterns, Prentice Hall by SOA
Markets - A Collaborative Approach,” Systems Inc., New Jersey, 2009.
Informatica Economică, Vol. 13, No. 2, [15] Sun Microsystems, Inc., Java Message
Bucharest, 2009. Service, Available at:
[6] W. R. Stevens, UNIX Network Programming, [Link]
Vol. 1, Networking APIs: Sockets and XTI, [16] Sun Microsystems, Inc., Open Message
Second Edition, Prentice Hall, 1998. Queue: Open Source Java Message Service
[7] A. S. Tanenbaum, Computer Networks - (JMS), Available at: [Link]
Fourth Edition, Vrije Universiteit [17] M. Richards, R. Monson-Haefel and D. A.
Amsterdam, The Netherlands, Pearson Chappell, Java Message Service (Second
Education Inc., Prentice Hall PTR, New Edition), O’Reilly Media Inc., Sebastopol,
Jersey, 2003. California, 2009.

Claudiu VINŢE has over twelve years experience in the design and
implementation of software for equity trading systems and automatic trade
processing. He is currently CEO and co-founder of Opteamsys Solutions, a
software provider in the field of securities trading technology and equity
markets analysis tools. Previously he was for over six years with Goldman
Sachs in Tokyo, Japan, as Senior Analyst Developer in the Trading
Technology Department. Claudiu graduated in 1994 The Faculty of
Cybernetics, Statistics and Economic Informatics, Department of Economic Informatics,
within The Bucharest Academy of Economic Studies. He holds a PhD in Economics from
The Bucharest Academy of Economic Studies. Claudiu has also given lectures and
coordinated the course and seminars upon The Informatics of the Equity Markets, within the
Master’s program organized by the Department of Economic Informatics. His domains of
interest and research include combinatorial algorithms, middleware components, and web
technologies for equity markets analysis.

View publication stats