Connectivity... guaranteed. QTP as Transaction Transport Layer High-capacity, connection-oriented transaction transport (604)
Connectivity... guaranteed. Introduction u Who is INETCO? G Software vendor linking institutions with terminals G See u Our perspective G Financial/retail vertical market G Financial TP is often “Most mission critical application” G We make new elements evolving into a system communicate with what is already there. G Normally we work in all layers below ISO8583 or equivalent message. u Why are we here? G Joint authors of QTP - transport protocol for POS transactions over IP. G SOAP/HTTP emphasizes client- web-server interaction. QTP addresses concentration points (back-end). u Scope G Deal with communication issues, not use of RPC vs. Message API.
Connectivity... guaranteed. Typical POS Architecture X.25/Dial Access Network SNA/X.25/FR Access Network Access Controllers or FEP POS Terminals (1000s to 100ks) Institutions EFT TPs Visa, TPDU, CLNP, TPDUVisa, TPDU, CLNP, None X.25, FR, IPHDLC, X.25, Async MessageMessage (ISO8583 or other)
Connectivity... guaranteed. Transport Layer Requirements u Performance G Fast connection processing G High availability u Security G Restrict by source access network address G Restrict by source transport-layer address G Restrict RAS - INAC communication G Provide legal intercept u Transaction delivery G Either non-reliable delivery, or G Reliable delivery with end-to-end data acknowledgements u Access Network independence G X.25, FR, Dialup,... u Transport layer independence G TCP or UDP, FR, other u Scaling G >100k transaction terminals G >100 financial institutions G Initial peak ~500 TPS with scalable growth
Connectivity... guaranteed. IP-oriented Architecture IP Network X.25/Dial Access Network SNA/X.25/FR Access Network Remote Access Servers INAC clusters QTP POS Terminals Institution EFT TPs X.25, SNA, FR HDLC, X.25, Async UDP/IP Message (as is) Message (ISO8583 or other) Transport (as is)Host transportVisa, TPDU, CLNP, None
Connectivity... guaranteed. QTP Overview u Status G Released as Internet Draft: draft-cornish-qtp-01.txt G First applications in production G Incorporated by other vendors. G Opensource version available for draft-cornish-qtp-00.txt u Characteristics G Lightweight connection multiplexing G Symmetric G Individual message acks G Status for source routing decisions. G Independent of lower-level transport G Attribute/Value based G Extensible u Header G Version G Msg ID, Msg ID Ack, Priority flags G Length G Src / Dest Logical Channel Number G Optional Msg ID, Msg ID Ack values u Attributes for G Session establishment G Data transfer G Session management G Element status G Statistical information G Vendor extensions
Connectivity... guaranteed. QTP Attributes u Session Establishment G Called / Calling party addresses G Called / Calling party subaddresses G Address family (E.164, X.121, …) G Profile, speed, idle timeout G Max message G Protocol identifier G Customer group identifier u Data Transfer G Data / Block data G Management info G Q Data / Call Data u Session Management G Cause (Normal, various QTP causes) G Remote cause (Normal, various Access causes) u Element Status G Flow control state (Available, Congested) G Station status (Primary, Secondary, …) G Ping G Call state u Statistical Information G Messages received / sent G Unacked messages G Time since last restart
Connectivity... guaranteed. Closing Comments u QTP not a fit for client side, unless client is really a gateway / proxy for many transaction generators. u Primary incentive for choosing QTP today is scaling beyond TCP session limits. QTP addresses concentrated connection-oriented transactions. u May be future interest in SOAP over QTP. G Would require split into SOAP encapsulation and SOAP over HTTP specs. u As transaction concentration increases, so does emphasis on security, reliability, and performance.