relating to interoperability of systems, particularly in legacy systems using Component Object Model (COM) objects. APPLICATION PROGRAMMING INTERFACES In short, a software application’s API defines the proper way for other applications to interact with and request services from it. In the trading industry, APIs facilitate the exchange of data between different software applications and will provide for interoperability between financial indus try software packages and our own software built in VB.NET. Through APIs we are able to integrate multiple commercial off-the-shelf (COTS) software products with our own proprietary software to create customized trading and risk management systems—and at a fraction of the cost of developing a complete system from the ground up. APIs allow us to create a kind of middleware that shares data across different trading platforms and networks. Most, if not all, software packages that you will encounter as a financial engineer will have APIs that either are a free bundled part of their software package itself or are separately licensed packages available for a fee. An API is a set of rules for writing function calls or instantiating objects that access function definitions or classes in a library, usually in the form of a .dll file. Programs we create that use these functions or classes can communicate with the COTS software to, for example, run an optimization routine, exchange information such as market data feeds, process buy and sell transactions, and post trade fill information to a database. Once we have created objects based upon the classes in the library, the API classes do all the work for us, totally transparent to our application. In addition to performing data-sharing tasks, APIs usually check network parameters and error conditions for us so as to deliver robust interoperation between the programs. As opposed to fully open source code, which exposes the software maker’s proprietary methods, APIs represent a stream- lined way to grant access to an application without giving away intellectual property. APIs grant less access than open source code but certainly more than entirely closed software. Software Connectivity and Interoperability 273 Team-LRN Among financial markets COTS software, APIs exist in many different forms. You should fully understand the implementation of the API, contained in the software vendor’s API documentation, before you proceed. EXCHANGE APPLICATION PROGRAMMING INTERFACES The major exchanges all have APIs to which developers can write to create market data feed and order routing applications. Writing to an exchange API, or alternatively to the FIX interface, and building proprietary software from the ground up requires a healthy amount of research, time, and money. As was discussed in Chapter 1, for most small firms this is not a feasible option for building automated trading systems. However, we can gain a somewhat greater understanding of market connectively and electronic exchange order routing if we briefly look at three exchange APIs. The Chicago Board Options Exchange offers an API through which developers can access the CBOE’s Electronic Trading System. The CBOE also supports the FIX messages for the purposes of order routing. This FIX interface is available as an alternative to connection through the API. The all-electronic International Securities Exchange (ISE) offers an API to which member firms can program to access market data, send trades, and receive trade fill confirmations and information. Through this API, the ISE’s electronic access members and market makers can develop applications for automated trading purposes or for back-office systems. The Chicago Mercantile Exchange has the Globex system, which contains open APIs for market data and order routing so that trading firms can write applications to receive real-time market data from and place automated orders on the CME’s electronic markets. As we have seen previously, firms involved in trading on multiple markets will need to connect to multiple APIs for market data and order entry. And every exchange API is different. Furthermore, to add to the complexity, in most cases applications 274 Advanced VB.NET Team-LRN developed to interact with an exchange’s API must be approved by the exchange itself. Fortunately several third-party developers have written customized applications to the respective exchange APIs for market data and execution of securities, futures, and options trades. We will look at how to connect to two of these COTS software applications in Chapter 17. COM INTEROPERATION As we have seen in Chapter 10, in order to create VB.NET code that requests services from an external component, we must first add a reference to it. The components can be of the following types: ^ .NET class libraries ^ COM components ^ XML web services We have, up till now, looked only at .NET class libraries. Although the new .NET libraries and assemblies are now a much- improved model for development, at times we need to make use of COM objects. .NET applications may someday replace COM ones, but until then, if we need to use a COM object in a VB.NET application, we will need to understand something about COM itself and how it differs from the .NET Framework. COM is a Microsoft specification used prior to .NET that controls library usage and compatibility and communication. Through COM, objects are exposed and their functionality is available to other applications. Via COM, libraries are ensured to be highly organized and reusable. Microsoft defined COM so that developers could create co mpatible libraries of classes and components. Virtually all Windows libraries that were constructed prior to the advent of the .NET Framework adhere to the COM specification, and most software today includes COM objects. But COM is difficult to program and deploy because developers must guarantee that new COM components are compatible. If a COM library is placed on a system without being properly registered, applications will be unable to find or use the library. An understanding of COM involves an understanding of how COM objects exist in memory. Whereas .NET objects are held in Software Connectivity and Interoperability 275 Team-LRN managed memory, which is controlled by CLR (the common language run time), COM objects are held in unmanaged memory. The CLR in .NET manages certain tasks such as dynamic memory allocation and type checking. VB.NET uses managed code, but we can access the unmanaged COM code using interoperability assemblies. Many companies have invested significant amounts of time and effort into creating COM components but now find themselves eager for a migration to .NET. Fortunately Microsoft created tools for integrating legacy systems and COM components into .NET Framework implementations. The .NET Framework provides for direct interaction between objects in managed and unmanaged memory. These tools enable interoperability with COM so that we can use existing COM objects in our VB.NET programs. This process is known within the .NET Framework as COM interop. VB.NET uses an interoperability assembly to find COM methods and translate data between the .NET and COM types. This translation is performed by the run-time callable wrapper (RCW), which is created by .NET based upon the information in an object’s interop assembly. As we discussed in Chapter 10, assemblies are collections of functionality usually in the form of classes contained in one or several files with their assembly manifest. Assembly manifests perform the same function in .NET as type libraries do in COM components. They include information about v ersion numbering, constituent files, types and resources, compile-time dependencies, and permissions. The RCW controls the COM object and carries out communication between .NET and COM code. When we create an instance of a COM object in VB.NET, we are really creating a new instance of the RCW of the object. Fortunately for VB.NET developers, the communication between an RCW and its COM object is completely transparent to us. So we can create and interact with COM objects as if they were .NET objects. Adding references to COM objects is the same as in previous incarnations of Visual Basic except that .NET adds the creation of this interop assembly to the process. References to the COM object properties and methods in VB.NET are routed to the interop assembly prior to proceeding to the actual COM object code. On the way back, responses are routed 276 Advanced VB.NET Team-LRN first to the interop assembly and before being forwarded back to calling code in .NET. Should the need arise, we can create new COM objects in VB.NET by using the .NET Framework’s COM class template, which can create a new class and configures the project so as to generate the COM class and register it with the operating system. COM objects referenced via interop assemblies must be registered, which we accomplish by using the Regsvr32 utility included with all Windows operating systems. If you are familiar with VB 6.0, you are a ware that ActiveX controls are commonly used COM components. Through the interop assembly, we can import ActiveX controls into our .NET IDE toolbox using the Customize Toolbox option, which will list all the COM components that are registered with the operating system. We are then free to use the ActiveX control in our VB.NET application. .NET Framework components do not need to be registered since .NET components maintain all of their type identification information internally. In Visual Basic .NET, adding references to COM objects that have type libraries is similar to doing so in previous versions of Visual Basic. However, Visual Basic .NET adds the creation of an interop assembly to the procedure. References to the members of the COM object are routed to the interop assembly and then forwarded to the actual COM object. Responses from the COM object are routed to the interop assembly and forwarded to your .NET application. If, for example, the input argument and return values of a COM object’s properties and methods use different data types than .NET does, a process called interop marshaling converts equivalent data types as they flow back and forth between COM objects. In fact all .NET programs share a set of common types that permit interoperability of objects, regardless of the programming language. While COM objects have been the foundation of Visual Basic applications for many years, .NET applications designed for CLR offer many advantages. In the .NET framework, COM components are no longer necessary. Through the use of assembly manifests, .NET components hold on to the benefits of COM while solving many of its inherent problems. Software Connectivity and Interoperability 277 Team-LRN SUMMARY The financial markets of the twenty-first century require connectivity and interoperability of disparate hardwa re and software systems. The use of APIs and XML will enable software we create in VB.NET to connect and exchange information with other systems. Furthermore, even within Visual Basic itself there are interoperability issues to confront, particularly those pertaining to legacy systems making use of COM components. 278 Advanced VB.NET Team-LRN PROBLEMS 1. What is middleware? 2. What is an API? 3. Rather than connecting to exchange APIs ourselves, what is our alternative for creating automated trading systems? 4. What is COM? 5. What is an RCW? Software Connectivity and Interoperability 279 Team-LRN This page intentionally left blank. Team-LRN CHAPTER 17 Connecting to Trading Software An important problem to solve when developing automated trading or risk management systems is market connectivity. Connecting to live electronic markets is no small task. Millions of dollars and literally years of time can be spent building such a system from the ground up. However, we can substantially reduce the amount of up-front time and expense needed to establish a connection to a market by licensing third-party software that already provides the required functionality. What’s more, most of these software packages already connect to more than one market, sometimes dozens of them, around the world enabling traders, or financial engineers, to be active in multiple markets simul- taneously. More often than not, this kind of third-party software will include an API that we can write to in VB.NET. These APIs usually exist in a single .dll library file or a set of .dll files. These libraries contain classes that enable us to connect to the licensed COTS software. When we create objects based upon the classes in such a library, we can use the functionality provided by these objects to interact with the software and subsequently pass data back and forth. Such functionality might include getting live, real-time market quotes, placing buy and sell orders, or receiving trade fill confirmations. Rather than require that you license some of this commercial software yourself, we have provided two libraries on the CD, called Trader API.dll and OptionsAPI.dll. 281 Copyright © 2004 by The McGraw-Hill Companies, Inc . C lick here for terms of use. Team-LRN CONNECTING TO A FUTURES MARKET The classes in the TraderAPI.dll library allow us to simulate a connection to a popular industry software package from Trading Technologies, Inc., called X_Trader. Trading Technologies, Inc. (TT) develops high-performance derivatives trading software including the X_TRADER product, which provides professional traders with connectivity to electronic derivatives markets around the world. Furthermore, the X_TRADER application contains an API consist- ing of 10 classes that financial engineers can instantiate for the purposes of developing, among other things, automated analytics, order entry, and trade fill information processing systems. However, you do not need to license X_Trader to use the TraderAPI.dll library included on the CD. As we said, by creating objects from the classes in TraderAPI.dll, we achieve the goal of market connectivity, albeit simulated. As a result, a VB.NET program that adds a reference to TraderAPI.dll and instantiates the objects in it can see the “real- time” market price movements of the S&P 500 eMini futures market, can place market buy and sell orders, and can receive trade fill confirmations. TraderAPI.dll can be used to create applications to customize order entry screens, monitor live fill feeds, perform live profit and loss calculations, and automatically execute trades based upon outside conditions and customized algorithms. While providing only a subset of all the possible functionalities, TraderAPI.dll will give our programs the look and feel of connecting to real markets through TT’s X_Trader API. While APIs are always changing and being upgraded, we have, in every way possible, tried to make the architecture of TraderAPI.dll mimic the API that comes with X_TRADER. The TraderAPI.dll file included with this book uses the same classes, method calls, and methodology, albeit somewhat abbre- viated in functionality, as if you were in a real-life environment using the X_TRADER API. TraderAPI.dll contains five classes that simulate a portion of the X_TRADER API’s functionality. The five classes are: 282 Advanced VB.NET Team-LRN [...]... Now that we have listed the information about a trade, let’s define a markup language using XML tags to describe it and then rewrite our trade in that language We will call our new markup language FMML—the Financial Markets Markup Language, pronounced “fimmel.” In the same way that a variable in VB.NET should be named using a naming convention, which describes the data held in the variable, our FMML tags... data in real time between different technology systems Financial markets, firms, and professionals who utilize XML find it to be a powerful tool for financial data representation and messaging and see it as the key technology in meeting the challenges of global interconnectivity (Bradley, 2002) Because XML is a metalanguage, segments of the financial markets industry have already been able to create their... own domains In addition to learning the technology of XML in this chapter, we will be able to see some of the business reasons why financial institutions are so keen on developing XML-based technologies, even to the point of inventing their own customized markup languages using XML In the following chapter, we will look at some specific XML technologies used in the financial markets and create programs... VB.NET programs XML AND FINANCIAL MARKETS The ultimate goal of developing firmwide, real-time global positioning systems that exploit profitable trading opportunities and manage risk will require a much higher degree of interconnectivity between departments within a firm, trading counterparties, and exchanges than exists today As a result, institutions involved in the financial markets have caught on to... Double, _ ByVal Quant As Long) Dim Inst As New IndexOp() Dim CBOEOrd As New CBOEorder() Inst.ExpyMonth = ExMonth Inst.ExpyYear = ExYear Inst.OpenClose = 1 Inst.CoverNaked = 2 Inst.Root = Microsoft.VisualBasic.Left(OPRA, 3) Inst.Strike = Strike Inst.Underlier = Pos.SYMBOL Inst.CallPut = 1 CBOEOrd.OrdPrice = Price CBOEOrd.OrdQty = Math.Abs(Quant) CBOEOrd.Account = Pos.Account CBOEOrd.Duration = 1 CBOEOrd.Instrument... languages Whereas Hypertext Markup Language (HTML) is used for formatting and displaying data, XML allows users to represent the contextual meaning of the data they wish to model using human readable tags In this chapter we will cover the basics of XML notation as well as ways to describe and encapsulate data in an XML document, also called an XML message In addition, we will go over how to write VB.NET programs... feel of connecting to real options markets through MicroHedge’s API The architecture of OptionsAPI.dll attempts to mimic the SBT API that you can license from MicroHedge The OptionsAPI.dll file included with this book uses the same classes, method calls, and methodology (although again they are abbreviated in functionality) as if you were in a real-life environment using the MH SBT API As we said, OptionsAPI.dll... can communicate between themselves using that dialect of XML As you can imagine then, DTDs are very powerful They define industry standards for the meanings and business rules of an XML document Earlier in this chapter we mentioned that XML tags mean nothing to the computer But to people, they mean a lot Technology professionals of entire segments within the financial markets industry meet and define DTDs... that the recipient of the document will be able to read it This is one of the main advantages of using XML to transfer data It allows individual firms or even entire industries to create their own customized markup language Again, in the following chapter, we will look at a few examples of DTDs for financial markets But for right now, let’s take a look at how a DTD validates an XML document DOCUMENT TYPE... program Figure 17.5 shows the results The timer will tick every 5 seconds and refresh the data Trades will execute as before SUMMARY In this chapter we have looked at two methods for connecting to real markets through connections to the APIs of two popular financial industry software packages Building software for Team-LRN Connecting to Trading Software 297 monitoring real-time prices, performing analytics, . our VB .NET application. .NET Framework components do not need to be registered since .NET components maintain all of their type identification information internally. In Visual Basic .NET, adding. objects that have type libraries is similar to doing so in previous versions of Visual Basic. However, Visual Basic .NET adds the creation of an interop assembly to the procedure. References to. assembly and before being forwarded back to calling code in .NET. Should the need arise, we can create new COM objects in VB .NET by using the .NET Framework’s COM class template, which can create a