XML Data Distribution Platform A Protocol Stack for XML data distribution Transport Layer: http Resources (find, access): Web-Server Request/Response: XML-RPC types Content: XML structured Mutual understanding: XML-Schemas RCS: A Possible Architecture

Protocol Stack for XML data distribution Directory Layer Schema definitions and resource locations Semantic Layer Schema processors and translators Request/Resp. Layer Fine grained XML RPC or simple get/post Syntax Layer API’s to process XML streams (SAX, DOM) Transport Layer Http, ftp, MQ, File access: XML doesn’t care Storage Layer Oracle, Tamino, Excelon, Hummingbird etc.

Services for XML data distribution Service Provider Web server Resource/Service Locations Schema definitions Locate resources XML RPC request over http Requestor Store Applications XML base API’s XML rpc client http client XSL translation engine XML base API’s (DOM,SAX) Service Provider Infrastructure Service Provider Infrastructure (COM,DCOM,CORBA,RMI,EJB)

Transport Protocol: http Simple protocol, goes through firewalls Small client side interface Allows internal and external access through same mechanism No single point of control of failure (besides DNS) But: no callbacks yet, no transactions

Web-Server, not File Server Provides additional level of indirection (for personalisation etc.) Resources can be easily found Standard way to access resources Allows Client specific processing of resources (e.g. Html conversion for humans, XML for machines) But: Needs extra operational support instead of NOS integration

Request/Response: XML-RPC types Text based, light-weight interoperability for Business-To-Business needs. Standard or custom requests possible Well suited for versioning. Transaction support coming Avoids tying the client into the service providers infrastructure No stubs necessary But: different standards (XML-RPC, SOAP, B2B, MADIS, etc.)

What you get from the service RPC Example: SOAP Don‘t care Request: POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/xml-SOAP Content-Length: nnnn MessageType: Call <GetLastTradePrice> <ticker>DIS</ticker> </GetLastTradePrice> Response: HTTP/1.1 200 OK Connection: close MessageType: CallResponse <GetLastTradePriceResponse> <__return>34.5</__return> </GetLastTradePriceResponse> What you want Don‘t care What you get from the service

Content: XML structured XML encoded streams are more verbose than binary coded streams XML encoded streams compress extremely well XML encoded streams allow for schema evolution without disrupting older applications XML encoded information can use URLs to create fragments and allow incremental download Modelling is also done using XML

Understanding Content:XML-Schemas Parsers will understand only very generic schemas Applications will use special (domain) schemas e.g. FPML Domain standards make life easier but are NOT a requirement – XML translates easily between different schemas Currently many companies/organisation define schemas: FPML (J.P.Morgan, PWC), FIXML, XML-EDI, Biztalk (Microsoft e.al.), Swift?

Schema Example: FPML Swap <?xml version="1.0" standalone="no"?> <!-- Copyright (c) 1999 by J.P.Morgan and PricewaterhouseCoopers. PricewaterhouseCoopers refers to the individual member firms of the world wide PricewaterhouseCoopers organization. All rights reserved. --> <!-- version 1.0b2 : August 6, 1999 --> <!DOCTYPE fpml:FpML SYSTEM "fpml.dtd"> <fpml:FpML xmlns:fpml="urn:fpml-FpML" xmlns:d="urn:fpml-date" xmlns:m="urn:fpml-money" xmlns:r="urn:fpml-rate"> <fpml:Trade> <fpml:tradeIDs> <tid:TradeIDs xmlns:tid="urn:fpml-TradeID"> <tid:TradeID> <tid:partyReference>ABC Trust</tid:partyReference> <tid:transactionReferenceNumber>237732</tid:transactionReferenceNumber> </tid:TradeID> <tid:partyReference>XYZ Group</tid:partyReference> <tid:transactionReferenceNumber>1230</tid:transactionReferenceNumber> </tid:TradeIDs> ....................................

Example: RCS data distribution architecture What do we want? Feed and Application Processing Definition of pull vs. Push, Web-server use, Protocols Validation and viewing issues Schemas (content and request/response) Tools Service Aggregation Workshop coming Monday

What do we want? From proprietary formats to XML schema(s) support for different backends support for read only access. No OLAP. separation of data consolidation/validation from application easy and uniform information access protocol Definition of pull vs. Push, Web-server use, Protocols re-use of RCS results

RCS:Feed processing ClientGate Client Data Client Data Client Data Web server Client Data Client Data Client Data Client Data Client Data RCS conversion validation consolidation, scheduling Client Data Client Data RCS XML Web Server RCS conversion validation consolidation, scheduling Client Data Web server CSV, binary XML, etc. Client Data Client Data Web Server Client Data Market Data RCS XML Web Server Other Data

RCS:App.processing RCS viewer XML persistence Web mapper Web server styles RCS context dependent validation, processing

Service Aggregation Workshop Update operations Database mapping tools Converter framework application factoring