Using Visual Basic NET Databases to Create Pricing Trading R_7

Software Connectivity and Interoperability 273 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 industry 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 systemfrom theground up.APIsallow usto createa 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. Team-LRN 274 Advanced VB.NET 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 andmarketmakers candevelopapplications forautomatedtrading 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 Team-LRN Software Connectivity and Interoperability 275 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.NETcode that requests services from an external component, we must first add a reference to it. The components can be of the following types: ^ .NETclass 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 compatible 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 Team-LRN 276 Advanced VB.NET 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 .NETand 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 .NETas type libraries do in COM components. They include information about version 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 .NETadds the creation of this interop assembly to the process. References to the COM object properties and methods in VB.NETarerouted to theinterop assemblyprior to proceedingto the actual COM object code. On the way back, responses are routed Team-LRN Software Connectivity and Interoperability 277 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 aware 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 .NETcomponents 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. Team-LRN ... - tailieumienphi.vn