1.
SDP라고 있습니다. Single Dealer Platform의 약자입니다.
국내 은행의 경우 투자자가 은행 지점을 방문하면 지점 RM이 해당상품에 대한 가격정보등을 딜링센터에 전화로 요청하면 이를 받아서 다시 투자자와 상담하여 계약을 체결합니다. 체결된 정보는 딜링센터로 전달되어 처리됩니다.? SDP는 이런 과정(Process)를 자동화할 뿐 아니라 사내 및 사외 투자자들이 직접 딜러를 통해 금융상품에 투자할 수 있도록 하는 시스템입니다.즉, 다양한 금융상품(주식,외환, 채권 및 파생상품등)의 실시간 가격정보를 제공하고 딜러들이 고객(기관 및 개인투자자 혹은 사내 고객)들의 주문을 받아 처리할 수 있도록 하는 플랫폼입니다. SDP는 당연히 투자정보 혹은 주문정보(Deal Contract)를 실시간으로 처리할 수 있는 기능을 갖추어야 합니다.
미국의 어떤 회사가 SDP를 Comet기술을 기반으로 하여 개발,판매하고 있습니다.? Comet?? 인터넷과 관련된 기술동향에서 손을 놓으지 오래되서 – 사실 3년정도지만 – 이해가 되지 않았습니다.
2.
제 기억으로는 소프트그램이 1998년 LG투자증권에 처음으로 브라우저를 통해 주문서비스가 가능하도록 시스템을 개발하였습니다. 이 때로부터 WTS(Web Trading System)는 다양한 방식으로 발전했습니다. 저도 여러 증권사에 시스템을 납품하였지만 Java Applet을 이용한 모델, DHTML(UI)과 ActiveX(통신)를 결합한 모델, ActiveX Application 모델등을 사용하였습니다. 마지막에는 Ajax를 이용하여 구축하였습니다. 그렇지만 어떤 경우이든 HTTP가 아니라 Socket을 이용하여 시세 및 주문정보를 실시간으로 처리하여야 하기때문에 ActiveX든 Java Applet이든 별도의 통신프로그램을 Plugin형태로 공급했어야 했습니다.? 그리고 3년이 지난 이후 Comet을 보았습니다.
지난 3년사이에 인터넷이 많은 변화가 있었다고 합니다. ReadWriteWeb이 선정한 2009년의 5대 흐름중 하나로 실시간 웹을 들고 있었습니다. 또한 브라우저는 단순히 HTML과 HTTP를 처리하는 어플리케이션이 아니라 Application Container라는 위치로 바뀌고 있었습니다.
브라우저가 Application Container가 되기 위해선 HTTP가 아닌 다른 네트워크통신환경을 제공하여야 합니다. 이런 변화의 흐름속에서 Comet이 탄생한 듯 합니다. 또한 Comet은 Ajax기술이 나온 이후 실시간 개념을 적용하기 위하여 탄생한 듯 합니다. 우선 전통적인 동기식 모델과 비동기식 모델인 Ajax의 비교를 Wikipedia에서 살펴보죠.
기존의 웹 애플리케이션은 브라우저에서 폼을 채우고 이를 웹 서버로 제출(submit)을 하면 하나의 요청으로 웹 서버는 요청된 내용에 따라서 데이터를 가공하여 새로운 웹 페이지를 작성하고 응답으로 되돌려준다. 이때 최초에 폼을 가지고 있던 페이지와 사용자가 이 폼을 채워 결과물로서 되돌려 받은 페이지는 일반적으로 유사한 내용을 가지고 있는 경우가 많다. 결과적으로 중복되는 HTML 코드를 다시 한번 전송 받게 됨으로써 많은 대역폭을 낭비하게 된다. 대역폭의 낭비는 금전적 손실을 야기할 수 있으며 사용자와 대화(상호 반응)하는 서비스를 만들기 어렵게도 한다.
반면에 Ajax 애플리케이션은 필요한 데이터만을 웹서버에 요청해서 받은 후 클라이언트에서 데이터에 대한 처리를 할 수 있다. 보통 SOAP이나 XML 기반의 웹 서비스 프로토콜이 사용되며, 웹 서버의 응답을 처리하기 위해 클라이언트 쪽에서는 자바스크립트를 쓴다. 웹 서버에 서 전적으로 처리되던 데이터 처리의 일부분이 클라이언트 쪽에서 처리 되므로 웹 브라우저와 웹 서버 사이에 교환되는 데이터량과 웹서버의 데이터 처리량도 줄어들기 때문에 애플리케이션의 응답성이 좋아진다. 또한 웹서버의 데이터 처리에 대한 부하를 줄여주는 일이 요청을 주는 수많은 컴퓨터에 대해서 일어나기 때문에 전체적인 웹 서버 처리량도 줄어들게 된다.
2004년쯤 Ajax 어플리케이션을 브라우저에서 실행하고 실시간데이타를 처리하기 위하여 ActiveX로 만들었던 것을 대시할 수 있는 기술들이 등장하는데 Reverse Ajax라고 하고 그중 하나가? Comet입니다.
Reverse ajax ( comet ) Chapter 1 : web기술의 변화
Wikipedia를 보면 Comet이란 개념을 처음 사용한 사람은 Alex Rusell입니다.
Comet: Low Latency Data for the Browser
< 이런 흐름의 연장선인지 Google도 역시 실시간웹을 위한 API를 도입하였더군요. Building real-time web apps with App Engine and the Feed API
3.
그러면 Reverse Ajax 혹은? Server-Push와 관련된 다른 기술은 없을까요?
1)Long-polling:?This merely refers to an HTTP connection that is maintained for a long duration, without disconnection. A server, upon receiving a request,?keeps the connection with the client open, and sends streams of data back to the client. The response is never deemed to have completed,?hence the server can continue to keep pushing data to a client over this connection, thus emulating push
2)BOSH: A BOSH library uses upto 2 connections to a server? – one connection for the client to send data to the server, and another for the server to send data to the client. The client opens a first connection and sends a request to the server. The server does not respond, and then subsequently can use this connection to send a response whenever it is ready. If the client meanwhile needs to send data to the server it does so through a request from a second connection. The moment the server receives this request from a second connection, it sends a response out to the first connection thus reversing the roles of the the two connections
3)Web Sockets: Plagiarising from Wikipedia ? “WebSockets is a technology providing for bi-directional, full-duplex communications channels, over a TCP socket and is being standardized by the W3C and IETF”. Websockets is still limited in the sense that it is not a protocol-independent binary socket connection. A reference implementation (client and server) is available at http://jwebsocket.org/
Methods of opening a bi-directional socket from a Browser 중에서
위의 블로그를 보시면 나와 있지만? Java Applet이나 ActiveX를 이용하여 Server-Push를 구현한 한국의 방식이 낡았다는 생각은 들지 않습니다. 이미 운영하고 있는 Trading System을 이용하여 실시간웹서비스를 구축한다고 하면 Comet과 같은 방식을 사용하지 않아도 될 듯 합니다.? 다만 웹이라는 환경에서 다양한 데이타를 통합하여 제공할 때, 앞서와 같이 Trading Portal Service를 웹기반으로 구축하고자 할 경우엔 Comet Server를 사용하는 것도 좋은 방법이 아닐까 합니다.
Comet Server를 이용하여 실시간웹환경을 구축하고자 하는 분들을 위해 다양한 Comet Server를 비교한 자료를 소개합니다.
Comet Servers for a Single-Dealer Platform (SDP)
위의 자료는 아래의 질문에 답하는 형식으로 잘 정리되어 있습니다. 관심있는 분들은 꼭 방문하시길 바랍니다. 당연히 오픈소스도 포함입니다.
1. What is the structure of the messages or objects?
2. Does it support bidirectional messaging?
3. Can it throttle or conflate fast updating data?
4. What languages are client APIs available in?
5. What languages are backend integration APIs available in?
6. How does it perform with high numbers of users and update rates?
7. How does it perform in terms of message latency?
8. How does it integrate with permissions systems and Single Sign On (SSO) ?
9. How much bandwidth does it use?
