1. 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

2. 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.

3. 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)

4. 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

5. 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

6. 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.)

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

8. 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

9. 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?

10. 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, >
<!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>

11. 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

12. 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

13. 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

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

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