Xml Work Shop An Introduction to XML Technologies

An Introduction to XML Technologies and Standards for Futures and Options Industry Professionals Presented by The Futures Industry Association Standards Working Group in conjunction with The Fix Protocol Ltd. Global Derivatives Committee 1

Agenda - Morning • Welcome 9: 00 am • Angela Krug, Deutsche Bank AG • XML: The Crash Course, part 1 9: 05 am – Why XML? Why Now? • Ed Gogol, Chicago Mercantile Exchange – What is XML? What is a well defined XML message? • Jim Northey, The FIX Global Derivatives Committee • • Break 10: 15 am XML : The Crash Course Part 2 10: 30 am – How are XML messages defined and validated? • Jim Northey, The FIX Global Derivatives Committee • XML: The Benefits 11: 15 am – How are XML Messages accessed from an application program? • Oren Miller, Thought. Works, Inc. • Accessing XML Messages 11: 45 am – How are XML messages accessed from application programs? • Matt Simpson, Chicago Mercantile Exchange 2

Agenda - Afternoon • • Lunch 12: 30 pm Implementing XML Based Solutions 1: 15 pm • David Li, Chief Architect, New York Mercantile Exchange • Elliot Napakh, Technical Architect, New York Mercantile Exchange – Question and answers • The CME Pilot Project using FIXML 2: 00 pm • Matt Simpson - Chicago Mercantile Exchange – Questions and answers • • Break 3: 00 pm What Standards Exist for Derivatives Markets? 3: 15 pm • Jim Northey, The FIX Global Derivatives Committee • Conclude 4: 00 pm 3

Welcome • Chicago: John Munro – Senior Vice President Product Development, Rolfe & Nolan – Chairman, FIA Standards Working Group • New York: Angela Krug – Vice President, Deutsche Bank AG – Vice Chairman, FIA Standards Working Group • Thanks to our hosts – Chicago - The Chicago Board of Trade - Tom Mc. Cabe – New York - Salomon Smith Barney - Mike Mortkowitz • • Why are we here? Presenters – – – Jim Northey - FIX Protocol Limited Matt Simpson - Chicago Mercantile Exchange Oren Miller - Thoughtworks, Inc. David Li - New York Mercantile Exchange Elliot Napakh - New York Mercantile Exchange 4

XML: The Crash Course Ed Gogol, Director, Systems Development, Clearing House, Chicago Mercantile Exchange Jim Northey Chair, FIX Protocol Ltd. Global Derivatives Committee 5

XML: The Crash Course • Introduction to XML by Ed Gogol – Why XML? Why Now? • • • XML Basics Well Formed XML Documents Describing XML Documents – Document Type Definitions – XML Schema – Namespaces • XML Path 6

Why XML? Why Now? Advantages • • Technology is easily integrated Focus on integration Wide adoption across computer vendors Ability to interoperate across standards 7

What is XML? It’s a. D Top esse ping rt !! ax!! W loor A F It’s The 8 d n MS’ a e RDB c ing sin EW th BEST N cts!!! Obje

What is XML? • • • History Move beyond the closed markup language HTML to add semantic e. Xtensible Markup Language – Open ended mark up language • XML is a Meta markup language 1980 s SGML 1994 HTML – Markup language used to create other markup languages • Just like HTML uses Tags to organize data – The tags describe the content of the message • Self describing data – Description of the message with the message provides for considerable flexibility http: //www. w 3. org/XML/1999/XML-in-10 -points 9 1998 XML 1999 XHTML

Driving force behind XML • W 3 C - World Wide Web Consortium http: //www. w 3 c. org – founded in October 1994 to lead the World Wide Web to its full potential by developing common protocols that promote its evolution and ensure its interoperability. Today, W 3 C has over 450 Members and nearly 70 full-time staff around the world who contribute to the development of W 3 C specifications and software. – http: //www. w 3. org/Consortium/Points/ 10

HTML - A Closed Markup Language

A note on terminology • In this presentation “XML Message” and “XML Document” are used interchangeably 12

Quick Overview on XML • • An XML Document or Message is made up of Elements are composed of – – – • All tags contain a name An Opening Tag optional attributes optional content A Closing Tag Elements can be empty – Meaning the Opening Tag can be terminated with a backslash character • Elements are nested – Elements can contain other elements containing other elements …. – Forms a tree of information • this is the data for this element White space is ignored with the exception of the information between the element opening tag and closing tag 13 Customer Unknown

Well Formed XML Messages • • There are only a handful of rules that need to be followed to create XML messages that follow the simple rules are considered to be: Well Formed XML Messages Well Formed Messages are good A Well Formed XML document is not to be confused with a Valid XML document 14

Anatomy of an XML Message XML Declaration Element Root Element Opening Tag Value Closing Tag Nested Elements What’s This? 15 Empty Tag 12345 Attribute Value EK Attribute 10000

XML Declaration • First line in XML document • • Delimited by Three properties that you can set – version • Always use this property • There is only one version now “ 1. 0” – encoding • Use if you require support of an alternative character set • Usually not needed • Default character set is UTF-8, which is the ~ASCII part of Unicode – standalone • Use this property to tell an XML processor if there are other files required to process this XML document • Valid values “yes” or “no” 16

XML Declaration Examples Which of the following are well-formed? _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ 17

XML Declaration Examples Which of the following are well-formed? _____ _____ _____ _____ _____ _____ _____ _____ _____ _____ 18

Elements • • • Have an Opening Tag and a Closing Tag XML Elements are nested - into a tree structure The outer most (top level) element is called the Root Element Content for the element is contained between the Opening Tag and the Closing Tag names (element names) – cannot have embedded spaces or punctuation characters other than - and _ – are case sensitive 19

Element Examples Which of the following are well-formed? _____ _____ data here _____ _____ _____ Chevrolet _____ _____ Chevrolet 20

Element Examples Which of the following are well-formed? _____ _____ data here _____ _____ _____ Chevrolet _____ _____ Chevrolet 21

Attributes • • • Can be added to the Opening Tag of an Element name=“value” or name=‘value’ format White space ignored – name = ‘value’ • No embedded spaces or punctuation in an attribute name – except “-” and “_” • IMHO: Think of elements as objects, think of attributes as urrrr. . . , well attributes of the objects (elements) – Sometimes objects contain other objects (elements) – Sometimes they just have attributes (data elements, member variables) – In fact the ISO 15022 Working Group 10 creating ISO/XML uses object modeling (UML) to create their XML definitions 22

Attribute Examples Which of the following are well-formed? _____ _____ _____ _____ _____ 23

Attribute Examples Which of the following are well-formed? _____ _____ _____ _____ _____ 24

Comments • Comments start with • Comments can appear anywhere in the XML message Which of the following are well-formed? _____ <--! this is my comment--> _____ _____ _____ 25

Comments • Comments start with • Comments can appear anywhere in the XML message Which of the following are well-formed? _____ <--! this is my comment--> _____ _____ _____ 26

CDATA Sections • Sometimes you just need to not parse something - you have special characters - such as code examples or even XML 27

What tools can be used to edit XML documents • Low end - what ever you have on your PC – Notepad – Internet Browser • Microsoft Internet Explorer • Netscape Navigator • Open Source – Xerlin http: //www. xerlin. org • Commercial Editors – XML Spy – XML Pro Edit • There are many, many products out there to choose from NEW 28

Let’s revisit our example. . . Document Type Declaration 29 12345 EK 10000

Document Type Declarations • • Delimited with Follows the XML Declaration 30

Entities • XML also provides entities which act placeholders – kind of like variables a little bit • • Kind of like C #defines and #includes Two types – General Entities • Place holders for any content that occurs at the level of or inside the root element – Parameter Entities (ignore these for now) 31

% Entities ENTITIES %name; &name; General Parameters Internal External predefined 32 & Character numbered named Mixed Content Internal Unparsed External

Character Entities • • If & / > < “ are all special characters in XML, how can we get these to appear in our XML documents? By the use of predefined character entities amp & apos ‘ gt > lt < quot “ • What would the following produce as output from an XML document < ' & ' > 33

The answer < ' & ' > becomes… <‘&’> 34

Numbered character entities ç &#x. F 9; • Represents the character’s position within the Unicode character set • Named Character Entities have nmeumonic name for specific characters 35

Using Entities Using Entities ]> &Co. Acr; &Co. Name; SSB Salomon Smith Barney NEW 36

Mixed Content Entities • • Defined as part of the document type declaration From our example – Internal • think #define • Everywhere that &exch; appears - the text “CBOT” would be replaced • Everywhere that &exname; appears - the text “Chicago Board of Trade” would be replaced – External • think #include • Everywhere that &disclosure; appears - the contents of the file disclosure. txt would be read and substituted ]> NEW 37

An Example Mixed Content Entities ]> &Co. Acr; &Co. Name; " &Disclosure; " SSB Salomon Smith Barney “This is a standard disclosure file that contains all of the legalize required on each and every document as we have become a quite litigious society and failure to include such disclaimers in our documents will most certainly lead to unwanted incursion of legal expenses. Therefore, we must include these disclaimers, even though they are seldom read and still will not prevent litigation under the right circumstance. ” NEW 38

" src="https://present5.com/presentation/75bb6d0ddfc70ddc69d9c731ddb55675/image-39.jpg" alt=" Defining our own XML Message " /> Defining our own XML Message 100 80. 00 20020130 John Doe 102435 ABC-1453 -20020130 SSB Is this Well Formed? ? ? NEW 39

Defining our own markup languages • • • We said earlier that XML is a meta markup language XML is used to create domain specific markup languages How do we agree upon a dialect and then share this with others? How do we know if an XML message complies with our XML dialect (a *ML if you will) ? There has to be … – some mechanism we can use to describe our particular markup language (be it FIXML, Fp. ML, Jim. ML, Ed. ML, Math. ML, Ag. XML, …) – some way to share this description of our *ML – some way automate the process of making sure an incoming XML message is a valid *ML message Good News There Is!!!! 40

Describing XML Messages • • Document Type Definitions (DTDs) XML Schema The Bad News is there is more than one way! 41

XML: The Crash Course, Part 2 Defining and validating XML Messages 42

XML: Crash Course Part 2 • • • Describing XML Documents Validation Document Type Definitions – – – • • • Elements Attributes Internal External Using Internal and External together Namespaces XML Schema XML Documents as a tree – XPath – XLink – XPointer NEW 43

Describing XML Messages • Document Type Definitions (DTDs) – – – Provided with the original definition of SGML as defined by Goldfarb Think of DTD statements as control statements for defining XML documents DTD statements are not really XML statements Cannot use XML tools to manipulate DTD statements Some consider the DTD statements as a separate language • In practice it is a separate language though it is a fundamental part of XML • XML Schema – – An XML based language for defining XML documents Permits manipulation of the schema using standard XML tools This is like defining the database schema in tables in a relational database A recursion if you will Improved 44

Why add rules to our Trade XML? • Allows us – to document and communicate what we consider as a valid trade message – to validate our own trade messages – to validate trade messages we receive from others NEW 45

Document Type Definitions • • • DTDs are sets of rules that define the elements and attributes in any XML document Have their own syntax - kind of Why aren’t they required? 46

DTD Building Blocks • We previously discussed the following – – • Elements Tags Attributes Entities Types of data in XML Documents – PCDATA • Parsed Character Data • An XML Processor looks for other XML building blocks within the data – CDATA • Character Data • An XML Processor does not look for other XML within the data NEW 47

Defining Elements • Defining an element that can contain any kind of data • Defining an empty element • Defining an element that has mixed content – Choice • Defining an element that has only child elements – Sequential order 48

Defining Child Elements • Declaring one and only one child element • 1. . 1 Declaring at least one child element, permitting multiple occurrences + = 1. . n • • • Declaring zero or to one occurrences of a child element ? = 0. . 1 Declaring zero or to one occurrences of the same child element * = 0. . n Declaring Options Elements NEW 49

Defining Child Elements • Permitting different child elements (either/or) | = or • Permitting a mix of child elements Defining an ordered sequence , = sequence NEW 50

Working with Groups of Elements • You can apply the cardinality rules to groups of elements NEW 51

Defining Attributes - Syntax • Defining Attributes for Elements NEW 52

Attribute Datatypes • Attribute Datatypes (or just types) – CDATA • Character Data – an enumerated list using the | • Values separated by the | (vertical bars) – Other types (we won’t talk about today) NEW • • ID IDREFS ENTITY ENTITIES NMTOKENS NOTATION 53

Attribute Default Values • Attribute Default Values – #REQUIRED • Attribute must be included in the Element – #IMPLIED • The attribute is optional (does not have to be supplied) – #FIXED default-value • The attribute is optional - if it is not supplied use the default value provided – default-value • For enumerated lists - the default if the attribute is not specified NEW 54

Defining Attributes • Defining an element that can contain any kind of data NEW 55

Defining Attributes • Defining an element that can contain any kind of data NEW 56

Proposed FIX 4. 4 Positions Report in TO-FIXML … NEW 57

" src="https://present5.com/presentation/75bb6d0ddfc70ddc69d9c731ddb55675/image-58.jpg" alt=" Defining DTD statements for TO-FIXML " /> Defining DTD statements for TO-FIXML NEW 58

Adding an internal definition to our XML ] > … rest of TRADE xml omitted on this slide < /Trade> 59 NEW

100 80. 00 20020130 John Doe 102435 ABC-1453 -20020130 SSB NEW 60

" src="https://present5.com/presentation/75bb6d0ddfc70ddc69d9c731ddb55675/image-61.jpg" alt=" Our External Trade DTD File " /> Our External Trade DTD File 61

XML Namespaces • • Sometimes you need to reuse other definitions Sometimes you have naming conflicts between different syntax NEW 62

XML Schema • Using XML to define XML messages NEW 63

Think of an XML Document as a Tree of Information 64

XML document as a tree of information • Operating System File Systems – File Systems are organized in a tree like structure – Files Systems contain directories that contain files and other directories (sub directories) – The main directory is called the root directory – You can traverse the file system directory tree using commands, such as cd (change directory) – There is the concept of the current working directory - where you are in the file system tree structure 65 • XML Documents – XML documents are organized into a tree like structure – XML documents contain elements that contain attributes and other elements (nested elements) – The main element is called the root element – You can traverse the XML document element tree using your own programs or XPATH commands – There is a concept of the current node - the point where you are in the XML document tree structure

• • • There is a name for this XML tree inside a program The Document Object Model (DOM) is a way to represent an XML message within a program The Document Object Model is organized as a tree of XML elements starting at the root element You can walk the tree using the DOM application programming interface 66

XPath • • • Trees can be climbed (traversed) Syntax for searching and traversing an XML document tree Sort of like wild cards or regular expressions – Instead of applying to a text file - applied to a tree • Thinking about Paths – There is a path to take – Here is the path taken 67

Internet Resources • W 3 Schools. com – http: //www. w 3 schools. com • World Wide Web Consortium – Definitions of everything we have talked about – http: //www. w 3 c. org • The Cover Pages by Robin Cover – http: //xml. coverpages. org/ • Open OASIS - Supporting XML based industry standards – http: //www. oasis-open. org/ Improved 68

XML: The Benefits Oren Miller Senior Director of Software Development, Thoughtworks, Inc. 69

• • Extensible Stylesheet Language Transformations (XSLT) Used to transform XML Content (And *IS* XML) Rule Based Language (Not Sequential) Declarative Query Syntax (Xpath), like SQL Templates – – • Data Retrieval – • Iteration – • Decisions – – , • Variables – , 70

Position Report to be Transform to an SQL Update … 71

Creating an extract of positions only Contains position and trade record XML messages Position Report Trade Capture FIXML File extposrepts. xsl Selects Position Reports from the file with position reports and trade detail Positions XML File Improved 72

Selecting only Position Reports • The following XSLT statement is used to select only the Position reports from the file containing Position Report and Trade Capture messages Improved 73

Creating a text file Position Report Trade Capture FIXML File Contains position and trade record XML messages Selects the position reports and creates a comma delimited text file fixml 2 text. xsl Text file containing the position information Positions text file Improved 74

Creating a database insert script Contains position and trade record XML messages Position Report Trade Capture FIXML File fixmltosql. xsl Selects the position reports and creates an SQL script to insert positions into a database SQL script created by the XSLT SQL Script Positions Database Improved 75

Position Report Database Schema Position Report Parties 76 Positions Amounts

Accessing the parties, positions, and amounts • • The following XSLT fragment writes the Parties, positions, and amounts into separate tables Notice that a “subroutine” or template is used, sql-insertcollection 77

The sql-insert-collection Template • • This template is used to iterate through multiple elements (such as parties or positions) and create insert statements Notice that it calls two other templates, sql-insert-fields and sql-insert-values INSERT INTO ( Rpt. ID, ) VALUES ( " " , ); 78

Templates that are used in this example • Templates created to iterate and create the fields and the values for the table insert 79 Notice each of the templates on the left use the comma template. . . ,

Accessing XML Messages from an application program Matt Simpson Associate Director, Clearing IT, Chicago Mercantile Exchange, Inc. 80

XML Integration Assumptions • Java is your base development language • You can run a Java Virtual Machine (JVM) on your platform • Your Operating System can be Sun/Solaris, HP-Unix, OS 390 -based Unix, Microsoft OS’s including NT, XP, and Windows, and various flavors of Linux • Your development is J 2 EE-oriented and can leverage XML API’s • App Servers are not necessary, but a number can be used including Weblogic, Websphere, Apache Tomcat, and others • There are others products and implementations which will not be addressed in this overview. 81

Principles of the Java XML API’s • J 2 EE XML API’s - engineered by Sun and accepted as a standard by much of the industry – are a good starting point for any XML-oriented application • Adhere to industry standards regarding XML and thus ensure interoperability • Broad functionality allows choice of application architectures • Flexibility within a well-defined framework ensures that all implementations will deliver standard functionality. 82

What makes XML an Attractive Technology • Extensibility – tags can be added as needed • Portability – given a DTD, a parser will know the structure and type of content for any xml document • Loosely coupled to Business Processes • Human readable – allows business users to interpret data • System independent way of representing data • New Java API’s making XML easier to use • Validation of documents can be enforced or not, depending on the need 83

JAXB – Java API for XML Binding Overview… • JAXB is a new standard being developed via Suns Java Community which provides a way to map XML documents to Java objects. • Suns implementation generates Java classes representing elements in a DTD. These classes contain XML parsing logic. • JAXB is essentially a bridge between XML and Java. It allows creation of Java objects at the same level as the XML. • Maps XML to Java data objects • Acts as a code-generator using a DTD (not a schema) • Uses a DTD to “bind” to a set of generated classes • The binding schema is an XML-based binding language • Classes are generated which maps your XML to internal data objects 84

JAXB – Java API for XML Binding 85

JAXB – Java API for XML Binding Disadvantages of JAXB… • The evolving FIXML standard may require generating new Java classes each time the DTD changes. • In order to avoid coding changes to the business logic an additional abstraction is required which complicates the overall architecture. • You’re Stuck with the object that is generated. • Classes containing business logic are more likely to change as XMLmapping classes and the DTD change. May not address some of the mapping issues needed for complex xmlobject mappings. Causes domain/data objects to contain XML parsing logic. In order to avoid coding changes to the business logic an additional abstraction is required which complicates the overall architecture. May introduce additional OO complexity. Evaluated, but not used by CME. Would have caused the CMEs switch to attributes to be more cumbersome. • • 86

JAXP – Java API for XML Processing Overview… • A J 2 EE API that provides access to the XML parsing techniques SAX and DOM. • Has a “Pluggabability-Player” feature allows any XML-compliant parser to be used. • Implementation Independent – meaning any API compliant parser can be used with JAXP • The prominent implementations are provided by Crimson and Apache Xerces 87

JAXP – Java API for XML Processing • Both implementations provide SAX, DOM, XSLT API’s - SAX and DOM being parsers • Adds methods that allows generated code to be “parser-independent” • Xerces has it’s own implementation of SAX and DOM used by JAXP • For reconstruction, we ended up bypassing the JAXP interfaces and using the Xerces interfaces directly. Disadvantages… • JAXP provides a way to reconstruct an XML document using DOM • …but serialization to a string requires using an XSL transformation which is very slow. 88

JAXP – Java API for XML Processing 89

The SAX Parser Overview… • SAX (Simple API for XML) is an event-based parser which reads XML in a stream and each time it recognizes a tag, extracts the data. • SAX is most effective when only a part of a document needs to be parsed. • As SAX parses, the data is extracted from the XML string and made available for mapping. • Code is required to map SAX object to internal Java data object. Disadvantages… • More complex – requires creating your own tree-like structure. • Does not provide support for Reconstruction of documents. 90

SAX Sample The sample code belows show the SAX “start. Element” method and it’s implementation which prints out the tag name public void start. Element (String _uri, String _local. Name, String _prefix, Attributes attrs) throws SAXException { if (_local. Name. equals. Ignore. Case("App. Msg")) System. out. println(" tag found!"); else if (_local. Name. equals. Ignore. Case("Pos. Req")) System. out. println(" tag found!"); . . . } This method is called by SAX when it sees the body of the tag. public void characters (char buf [], int offset, int len) throws SAXException { String str = new String(buf, offset, len); System. out. println(str); } 91

DOM Parsing • DOM (Document Object Model) is a parser which allows random access to particular pieces of data AFTER the entire document has been loaded into memory • Once in memory, the document can be modified, something which SAX does not support. • DOM provides a simple way to construct a new XML document in memory and add elements to it while traversing the Java domain objects. Disadvantages (vs. SAX) • In general, DOM is less efficient since it takes more time to load and search memory • Does not provide a parser independent way to serialize an XML document into a String – meaning XSL must be used 92

DOM Sample The sample code below shows how DOM references an XML document in memory. In this example, an element called “Pos. Req” is located and the corresponding data is subsequently extracted and printed. Document. Builder. Factory factory = Document. Builder. Factory. new. Instance(); Document. Builder builder = factory. new. Document. Builder(); Document document = builder. parse(new Byte. Array. Input. Stream(xml. get. Bytes())); Node. List list = document. get. Elements. By. Tag. Name("Pos. Req"); for(int i=0; i

The Apache Digester Model Overview: • Provides an easily configurable framework for mapping XML messages to Java objects using an XML parser • Conforms to the SAX 2. 0 specification • The Digester component leverages the strengths of the SAX event model for parsing XML which include speed and efficient memory usage • Used to load configuration data • Does not build mapping classes like JAXB • Uses a pattern to perform mapping which can be expressed in a java class or in a. properties or config file • The Digester hides its complexity behind an easy to use interface Disadvantages: • Significantly slower than a custom solution due to complexity 94

The Apache Digester Model 95

A Customized Approach Overview: • The custom solution uses the Apache Xerces parser which provides support for JAXP, DOM, and SAX API’s. • the JAXP interfaces were bypassed for serialization and the Xerces interface was called directly. Why? ? ? • the SAX API provides fast and memory efficient event driven parsing of XML documents. It is the most rapid way to put XML string into a Java object. • The incoming messages are first mapped to a tree of lightweight objects representing the elements in the document. • This representation uses fewer objects and therefore less memory than a DOM representation. • The tree is then traversed and custom code is used to map each of the elements in the tree to a corresponding Java domain object. • Apache Xerces SAX parser implementation is used under the covers and is masked from the developer. 96

97 A Customized Approach

A Customized Approach Advantages • The FIXML Translator implementation encapsulates all the XML document parsing and construction logic behind a simple interface. • It isolates the rest of the Position Services application from changes to the evolving FIXML standard. • The custom code used for the implementation leverages standard APIs familiar to Java developers and can be quickly and easily updated when changes to the FIXML standard are required. 98

• • • XML Reconstruction DOM is used to map Java domain objects to outgoing FIXML messages The DOM API is used because the SAX API does not provide a way to construct an XML document The DOM API provides a simple way to construct a new XML document in memory and add elements After the XML document is constructed, it is serialized into a String using a Xerces parser specific API. DOM does not provide a parser independent way to serialize an XML document into a String, so JAXP provides a way to do this via XSLT. – XSL Transformation API is slow • • • Reconstruction – a customized approach DOM used to build doc in memory Xerces specific API used to construct outbound string – • • XMLSerializer class used to for this purpose JAXP is bypassed for serialization Sun is aware of this shortcoming and will provide better support for message reconstruction in the next release 99

Conclusion • JAXB – DTD code generation solution for XML to Object mapping. • Digester – Pattern-based solution for XML to Object mapping • JAXP – Complete standard API for XML handling – includes SAX and DOM • SAX – Event-based parsing. Fast and efficient. Does not support Reconstruction • DOM – Loads entire XML document to memory tree. Supports Reconstruction 100

Implementing XML: Notes from the field David Li Chief Architect, New York Mercantile Exchange 101

XML Practice in Nymex Universal Trading Message - UTM 102

Goal Create internal messaging protocol for loosely coupled applications. • Messaging (Smart. Socket) pub/sub queue • Legacy, J 2 EE, stand alone, Java, C++ 103

Resolve Task Define comprehensive messaging schema for application data exchange. • Started using Fix superset • Originally used tag definitions based on Fix protocol in the form of value • Used blocks similar to Fix to group relevant data elements • Schema in one file 104

Issues This is problematic for the following reasons: • • • Not user readable Large file size for even small sets of data creates difficulty (12 k) Schema management Schema elements are not reusable Unable to successfully use it with data binding tools 105

How we resolved the issues Changed tags to user readable tags • • Changed data to format so that only repeated data gets its own tag. Reduced the size and simplified data binding process. (15 k) Broke schema down to “block” level, which allowed for reusability and easy management 106

Data Binding Tools • Based on the schema, classes get generated • To maintain object library held to maintain only schema, without any programming • Excellent performance; castor uses JAX parser to set data fields 107

Instant validation • • • by setting fields to XML on UML generated object libraries, perform instant validation Used in common code repository for different application, enforces versioning and data consistency throughout the enterprise Link to JAXB, Castor, Talarian, Clearcase 108

Conclusion Recommendations and highlights: • • • Make sure schema is extendable Data binding is in use by all applications in enterprise Effective use of code repository to distribute latest data objects and schema throughout the enterprise 109

Putting XML to Work Today Matt Simpson Associate Director, Clearing IT, Chicago Mercantile Exchange, Inc. 110

Objectives of Post-Trade API’s q Extend Clearing beyond the traditional screen and browser based offering by providing a message-based interface into a core set of Clearing Services. q Actively support and advance a standard that will achieve a “Build once, interface many times” approach for the firms. q Allow firms to connect back-office systems to CME Clearing in order to seamlessly integrate transaction processing between CME Clearing and firms. q Eliminate/reduce redundant maintenance. Firms will no longer need to perform maintenance in their systems and again in CME Clearing Systems. q Promote Straight-thru-processing to reduce the risk of exposure of the CME and firms, and to allow greater financial transparency. q Provide an open systems architecture that will host firm access to CME Clearing and allow firms to interface with the API’s via MQSeries 111

XML for STP 112

The Post-Trade API’s 1 st Quarter 2003 Deliverable • Exercise Notice • Abandonment Notice • Position Adjustment • Final Position Instruction (PCS) • Margin Disposition • Request for Position • This intent of this service is to replace and supercede the Machine Readable Trade Register which is a limited-format batch file. • The Position Request will return varying levels of detail based on the nature of the request. • And More are on the way! 113

Architectural Goals The Post-trade Architecture adheres to the following design goals: • Decouple FIX-specific dependencies from the underlying business logic of the Post-Trade API System. • Decouple Message Delivery dependencies from the underlying business logic of the Post-Trade API System and from the FIXML format itself. • Ensure that the Post-Trade API System has a well-defined transaction context for each request/response. • Support additional FIXML messages with “close-to-zero” integration effort. • Enforce controlled exception handling. • Support processing of messages that may be initiated via nonmessage-based requests, eg User Interface Requests 114

High-level Architecture 115

116 Internal Architecture

Architectural Components There are three high-level control layers for the i. CPS architecture. – – – RD Mediator FIX Command Session 117 (for communication) (translation, delegated execution) (execution)

118 XML Class Structure

Principals of Optimizing FIXML • Use meaningful abbreviations for element and attribute names wherever possible. Use standard abbreviations for common words (ie. Price = Px, Currency = Ccy). • Identify the messages used in the application and create top level elements to represent them. For position services, these elements are the position maintenance request (Pos. Maint. Req), position maintenance report (Pos. Maint. Rpt), position request (Pos. Req), position request acknowledgement (Pos. Req. Ack), position report (Pos. Rpt), and trade capture report (Trd. Cap. Rpt). • Identify data items that can be grouped together to describe a logical object and create an element to represent the object. For example, an account ID and account type can be grouped together as an account element with supporting attributes. • Reuse elements to represent common logical objects which are parts of other objects rather than creating new elements. For example, a party is an object that is part of a position maintenance request, position request, and trade capture report side and can also be nested within a position quantity. • Reuse attributes across multiple objects • Identify elements that can be repeated and create a collection element to contain the repeated elements. For example, multiple parties are needed on a message and a collection element called Parties was created to contain multiple Pty elements. 119

FIXML Message Components Parties Block 1. The purpose of the Parties Block is to provide an efficient, standard way of expressing Firm and Account information in API Messages. The Parties Block consists of the following elements: – Party Role, Party ID, Party Sub ID, and Party ID Source. – Party Role is a static number used to express the type of party, for example Clearing Organization, Clearing Firm, etc. – Party ID is the value representing the party, for example, “CME”, “ 560”, etc. – Party Sub ID is used to express information which further defines the party such as segregation code for the Position Account. – Party ID Source identifies the owner of the standard, for example, ISO. The CME is not planning on using this element in its implementation. This is a Non-Referenced (“N”) element. 120

FIXML Message Components Quantity and Amount Blocks – – The purpose of the Quantity and Amount Blocks is to represent the different types of quantities and amounts that can be associated with a Message using a concise set of symbology. 2. Quantity Block (see example below) • • Request Messages generally carry only a single instance in the Quantity Block; transaction quantity A PCS Request may carry up to 3 quantity instances; transaction quantity (TQ), intra-spread quantity (IAS), and inter-spread quantity (IES). Report Messages generally carry 3 quantity instances: – submitted (Type=TQ, Status=0) – accepted (Type=TQ, Status=1) – total quantity (Type=TOT, Status=1) A Position Report may carry 10 or more instances in the quantity block since its purpose is to describe the position in detail 121

FIXML Position Maintenance Request - EXR 122

FIXML Position Maintenance Report - EXR Quantity on EXR request is greater than available quantity 123

FIXML Position Request 124

FIXML Position Report 125

FIXML Trade Capture Report 126

FIXML Metrics Message Type Position Maintenance Request Parse 5 ms Position Maintenance Report Position Request Construct 8 ms 5 ms Position Report 10 ms Trade Capture Report 12 ms 127

Position Services with FIXML Requesting Specific Services – 1. A service can be requested by building and submitting a message that conforms to FIXML message requirements. 2. The service invoked by a message is in large part determined by 2 control elements: – – Action Code – indicates the mode of the message Position Transaction Type – indicates the type of service being requested 3. FIXML API Messaging supports 3 types of actions: – – – New – is equivalent to an Add Replace – is equivalent to an Update Cancel – is equivalent to a Delete 128

Position Services with FIXML Referential Messaging • 1. The valid combinations of Referential Messages which will be supported are: • Replace on New Cancel on New Replace on Replace Cancel on Replace – – – Any ‘New’ message carrying a reference id Cancel on a Cancel Replace on a Cancel – • – – If the same request is referenced on multiple occasions, all requests after the initial referential request will be rejected as errors. Non-referential messages may be sent subsequent to a referential request and will be processed successfully. Referential requests referencing other referential requests will be allowed. This is explained below under the heading of Complex Referential Messaging 2. Invalid combinations are: 3. As stated above, a message may be referenced once and only once. – – • • 4. What can be changed? On a Replace, only Quantity can be changed. A change in position account requires a message to be cancelled and submitted as ‘new’. 129

XML Standards applicable to the Derivatives Markets Jim Northey Chair, FIX Protocol Ltd. Global Derivatives Committee 130

Contact for CME API egogol@cme. com 131

XML Standards applicable to Derivatives Markets • XML Languages for Financial Markets – – – FIXML Fp. ML ISO/XML MDDL SFXL others. . . 132

XML Standards for the financial industry FIXML, Fp. ML, ISO/XML, SFXL, MDDL 133

What is FIXML? • • XML version of FIX Provided as a DTD with each version of FIX – If you here FIX 4. 2 - there is an XML and a tag=value version • • FIXML for messaging FIX 4. 4 Timeline 134

FIXML Representation of an Order 8=FIX. 4. 1^9=0235^35=D^34=10^43=N^49=VENDOR^50=CUSTOME R^56=BROKER^52=19980930 -09: 25: 58 ^1=XQCCFUND^11=10^21=1^55=EK^48=277461109^22=1^54=1^38 =10000^40=2^44=76. 750000^59=0^10=165 Becomes… 135

Likely Evolution of FIXML 2001 DTD 2001 FIXML 4. 3 2003 XML Schema 2003 DTD 2003 FIXML 4. 4 2003 XML Schema 2003 Transport Optimized FIXML 136 2003 XSLT converter 2002 -2004 Reverse Engineering ISO/XML

Other Standards • • Fp. ML SFXL ISO/XML MDDL XBRL RIXML TAXML OFX 137

Financial Products Markup Language • • • Developed to specify Over the Counter Derivatives An XML Document that codifies the ISDA contract Specific definitions by asset class – – – • Interest Rate FX Equity Credit Energy Complex definitions – Cash flows – Multiple legs • Fp. ML. org becomes part of ISDA Slides taken from a presentation developed by Brian Lynn and Jim Northey at the Marcus-Evans derivatives trading seminar in Chicago Spring 2001 and the SIMC *ML Revolution seminar in New York April 2002 NEW 138

Fp. ML - Background • • Proposed in 1999 by JPMorgan and Pricewaterhouse. Coopers Focus on enabling e-commerce for OTC financial derivatives Led by ~10 major players in OTC derivative marketplace, plus ~6 major vendors and many smaller vendors Recently merged with ISDA Version 1. 0 (Rec ‘ 2001) covered IR swaps and FRAs Version 2. 0 (TR ‘ 2001) adds common IR options Version 3. 0 (WD ‘ 2002) adds FX spot, fwd & options, and OTC equity options. 139

Fp. ML -General Comments • • • Versions 1. 0 -3. 0 are Product Only (don’t cover business processes) Treats each product as customized Makes extensive use of XML features - structures, references, etc. Represents products parametrically (rather than using cash flows) Because products are complex, Fp. ML documents are complex (typically 3 -10 pages when printed). Adoption 140

Fp. ML - Current Direction • • New product coverage (More equity derivs, credit derivs, energy derivs, etc. ) Migration to XML schema Better support for extensions, versioning, digital signatures, etc. Business process definitions Validation, matching, and tools Integration and interoperability with other financial standards Support deployment as required 141

FIX and Fp. ML Product Spaces Standardized Customized Exotics and Hybrids Equities Structured IR Swaps Futures Vanilla IR Swaps Options FX Exotic Options FX Spots Fixed Income FX Spots, Swaps Vanilla OTC Equity Options Option Strategies Multileg Products 142 Standard Terms

FIX and Fp. ML Focus Standardized Transactions Between Organizations 143 Primary Business Focus Message Flows Product Definition Within Organizations

FIXML and Fp. ML Coverage 144

FIXML and Fp. ML - Similarities and Differences • Similarities – Both are XML based – Both are financial industry standards, wide participation • Differences – Different but converging product coverage/focus: Fp. ML on complex, FIXML on standardized – Fp. ML focuses on product description, FIXML mostly on business process description – Historically, FIXML predated by non-XML standard, while Fp. ML is an XML-only standard – Fp. ML covers a less automated business than FIX. 145

FIXML/Fp. ML - Business Process Integration • FIXML supports many standard business processes, e. g. – negotiation, execution, position reporting • • Fp. ML doesn’t currently define any business processes, but will need many of the same processes as FIX supports. However, business processes often work differently in different asset classes – e. g. negotiation on price (equities) vs. negotiation of terms (OTC swaps) • There will be a need to integrate some processes for cross asset trading (e. g. asset swaps). 146

FIXML/Fp. ML Product Overlap • Core products are different, but. . . – Both cover FX spot and forward, some OTC equity options – Fp. ML references cash equities for OTC options - need common identification – Fp. ML may start to cover/reference fixed income instruments, e. g. as part of asset swaps - need common identification – In the future there may be overlap in listed derivatives (futures and options). 147

• • • Future interoperability and cooperation opportunities Using FIX session layer as an envelope Using FIX instrument identification for standard instruments Using FIX process definitions as starting point for Fp. ML Using Fp. ML product description for instruments (e. g. bonds, convertibles) Schema - both migrating to schema ISO 15022/WG 10 148

Fp. ML: A Closer Look • • Why is Automation Harder for OTC Derivatives? A simple equity order might be represented in XML as follows: IBM 12345 5000 SELL 93. 5 149 Industry standard security identifier is understood by both sender and receiver of message

Automation Challenges • • • An OTC derivative trade is a privately negotiated contract between two parties Each trade is a unique instrument that can only be communicated by exchanging all the economic terms There is no equivalent to a security identifier (e. g. ISIN or CUSIP) found in the equity and bond markets The challenge is to transcribe the contract terms electronically in a format that supports the complexity and variety of derivative product features XML provides an excellent framework for representing these highly structured products. 150

The in Fp. ML ! 151

Fp. ML Architecture - Key Elements • Some key parts of the 1. 0 architecture specification include: – – Naming Conventions Rules for representing structures (e. g. composition, lists, sub-classing) Version identification Rules for referencing elements 152

Summary of Fp. ML 1. 0 Product Standard • • Initial focus on interest rate derivative products, in particular interest rate swaps and FRAs, the most widely traded OTC instruments Fp. ML 1. 0 defines trade content structures for these products . . . . . . . . . . . . 153

Key elements of the Fp. ML Product Standards • • • Symmetrical view of trade (same from either counterpart) Precise parametric trade representation similar to ISDA confirmations (e. g. “quarterly floating rate payments”) IR swaps support optional cash flow representation Uses ISDA terminology and borrows naming schemes from SWIFT (business centers) and ISO (currencies) Creates a variety of building blocks that can be reused for future products 154

ISO 15022 XML • Effort to provide one common repository of messaging and business processes for full life cycle of trading – SWIFT – FPL NEW 155

Thank you for attending! 156