Booil Jung

RTI Web Integration Service

본 보고서는 Real-Time Innovations(RTI)의 Web Integration Service(WIS)에 대한 심층적인 기술 분석을 제공합니다. RTI WIS는 고성능 실시간 RTI Connext DDS(Data Distribution Service) 데이터버스(Databus)와 웹 중심의 HTTP 및 WebSocket 프로토콜 세계를 연결하는 표준 기반 게이트웨이 솔루션입니다. 이 서비스의 핵심 목표는 기존 DDS 시스템을 수정하지 않고도 웹 기반 애플리케이션(예: 브라우저 기반 대시보드, 엔터프라이즈 백엔드 시스템)이 DDS 글로벌 데이터 공간(Global Data Space)에 ‘일급 시민(first-class citizens)’으로 참여할 수 있도록 하는 것입니다.

WIS는 RESTful API와 WebSocket API라는 두 가지 주요 인터페이스를 제공함으로써 이러한 통합을 실현합니다. RESTful API는 DDS 엔티티(도메인, 토픽, 데이터 작성자/판독기 등)의 생성, 관리 및 상태 비저장 데이터 교환과 같은 제어 플레인(control plane) 작업을 위해 설계되었습니다. 반면, WebSocket API는 실시간 데이터 스트리밍과 같은 데이터 플레인(data plane) 작업에 최적화되어, 낮은 지연 시간과 높은 처리량이 요구되는 애플리케이션에 이상적입니다.

본 보고서의 핵심 분석 결과는 다음과 같습니다. WIS는 자체적인 맞춤형 게이트웨이 개발에 비해 전략적으로 월등한 선택입니다. 이는 통합 노력의 대폭적인 절감, 웹 클라이언트에 대한 즉각적인 지원, 그리고 강력한 보안 기능의 내장이라는 명백한 이점을 제공하기 때문입니다. 결과적으로 WIS는 대부분의 시스템 통합 시나리오에서 더 빠르고, 신뢰할 수 있으며, 리스크가 낮은 경로를 제공하는 전략적으로 현명한 솔루션입니다. 본 문서는 시스템 아키텍트와 수석 엔지니어가 정보에 입각한 아키텍처 결정을 내리는 데 필요한 심층적인 통찰력을 제공하는 것을 목표로 합니다.

RTI Web Integration Service(WIS)는 Real-Time Innovations(RTI)에서 제공하는 즉시 사용 가능한(out-of-the-box) 전용 소프트웨어 구성 요소입니다. 이 서비스의 핵심 기능은 고성능, 실시간 RTI Connext DDS 에코시스템과 유비쿼터스 웹 기술 세계 사이의 투명한 브리지(transparent bridge) 역할을 하는 것입니다. 본질적으로 WIS는 웹 기반 애플리케이션(예: 브라우저 기반 사용자 인터페이스, JavaScript 클라이언트, 엔터프라이즈 백엔드 서비스)이 네이티브 DDS 라이브러리나 DDS에 대한 깊은 전문 지식 없이도 DDS 글로벌 데이터 공간에 ‘일급 시민’으로 참여할 수 있도록 지원합니다.

WIS가 해결하는 핵심 문제는 상태 기반(stateful), 바이너리, UDP 멀티캐스트 기반의 DDS 세계와 상태 비저장(stateless), 텍스트 기반, 요청-응답 모델의 HTTP 세계 간의 기술적 임피던스 불일치(impedance mismatch)입니다. WIS는 이 두 패러다임 간의 간극을 메워, 서로 다른 기술 스택을 사용하는 시스템들이 원활하게 데이터를 교환할 수 있도록 합니다.

보고서를 진행하기에 앞서, ‘RTI’라는 약어에 대한 명확한 정의가 필수적입니다. 수집된 자료에는 다양한 분야에서 ‘RTI’라는 약어를 사용하는 여러 독립적인 개체가 포함되어 있습니다. 예를 들어, 교육 분야의 “Response to Intervention”, 요식업 기술 분야의 “Restaurant Technologies Inc.”, 그리고 기타 금융 및 의료 분야의 기업들이 있습니다.

이러한 혼동을 피하기 위해, 본 보고서에서 ‘RTI’는 오직 Real-Time Innovations, Inc.를 지칭하는 것으로 한정합니다. Real-Time Innovations, Inc.는 Connext DDS와 본 보고서의 주제인 Web Integration Service를 개발한 회사입니다. 이 명확화는 정확하고 모호하지 않은 기술적 논의의 기반을 마련하는 데 매우 중요합니다.

WIS는 단순한 기술적 도구를 넘어, 시스템 통합을 위한 전략적 가속기로서의 가치를 지닙니다. 그 핵심 가치 제안은 다음과 같은 주요 이점들로 요약될 수 있습니다.

• 개발 시간 및 노력 단축: WIS는 사전에 구축되고 검증된 표준 기반 솔루션을 제공함으로써, 맞춤형 게이트웨이를 개발하는 데 필요한 막대한 엔지니어링 노력을 제거합니다. 이를 통해 개발팀은 인프라 구축이 아닌 핵심 비즈니스 로직에 집중할 수 있습니다.
• 표준 기반 상호운용성: 이 서비스는 OMG(Object Management Group)의 Web-Enabled DDS(DDS-WEB) 표준을 활용하여 웹과 DDS 도메인 간에 일관되고 독점적이지 않은 인터페이스를 보장합니다. 이는 벤더 종속성을 피하고 장기적인 시스템 유연성을 확보하는 데 기여합니다.
• 연결이 끊어지거나 상태 없는 클라이언트 지원: 이는 WIS의 매우 중요한 기능 중 하나입니다. WIS는 DDS 도메인에 영구적으로 존재할 수 없는 일시적인 웹 클라이언트(예: 브라우저 탭)를 대신하여 DDS 상태를 관리하는 프록시 역할을 합니다. 웹 클라이언트가 연결을 끊더라도 WIS는 DDS 구독을 유지하고 데이터를 캐싱하여 클라이언트가 다시 연결될 때 필요한 정보를 제공할 수 있습니다.
• 언어 및 플랫폼 상호운용성: WIS는 HTTP 요청을 하거나 WebSocket을 사용할 수 있는 모든 프로그래밍 언어(예: JavaScript, Python, Ruby 등)로 작성된 애플리케이션이 DDS 시스템과 상호작용할 수 있게 해줍니다. 이는 해당 언어/플랫폼에 대한 네이티브 Connext DDS SDK가 없는 경우에도 마찬가지입니다.
• 중앙 집중식 접근 제어: WIS는 DDS 글로벌 데이터 공간에 대한 웹 기반 접근을 인증하고 권한을 부여하는 단일 제어 지점을 제공하여 시스템 보안을 강화합니다.

WIS의 설계 철학에서 “기존 DDS 애플리케이션을 수정할 필요가 없다(unmodified DDS applications)”는 점은 매우 중요한 아키텍처적 의미를 가집니다. 이는 WIS가 기존 DDS 시스템에 비침습적인(non-intrusive) 추가 요소로 설계되었음을 시사합니다. WIS는 데이터버스 상에서 표준을 준수하는 또 다른 DDS 참여자처럼 동작합니다. 결과적으로, 시스템 아키텍트는 이미 성숙하게 운영되고 검증된 실시간 시스템에 웹 인터페이스를 추가할 때, 핵심 DDS 구성 요소를 재설계, 재코딩 또는 재검증할 필요가 없습니다. 이는 통합 프로세스의 리스크를 현저히 줄이고 기존 실시간 인프라에 대한 투자를 보호합니다. 즉, “웹을 위해 시스템을 어떻게 재구축할 것인가?”라는 복잡한 문제를 “시스템을 웹에 노출하기 위해 게이트웨이를 어떻게 구성할 것인가?”라는 훨씬 단순한 문제로 전환시킵니다.

RTI WIS의 아키텍처는 근본적으로 DDS 글로벌 데이터 공간과 다양한 웹 클라이언트(브라우저, 모바일 앱, 엔터프라이즈 서비스 등) 사이에 위치하는 프로토콜 게이트웨이이자 상태 관리자입니다. 이 서비스는 웹 도메인으로부터의 요청(HTTP/WebSocket)을 DDS 도메인에서의 동작(발행/구독)으로 변환하고, 그 반대의 변환도 수행합니다.

이 아키텍처는 중앙 집중식 브로커 대신 분산된 P2P(peer-to-peer) 데이터버스를 강조하는 RTI의 광범위한 데이터 중심 접근 방식(data-centric approach)의 일부입니다. WIS는 이 데이터버스 위에서 웹 통합이라는 특수한 임무를 수행하는 전문화된 피어(peer)로서 작동합니다.

WIS는 다음과 같은 핵심 내부 구성 요소들로 이루어져 있습니다.

• 서비스 엔진 (Service Engine): 다른 구성 요소들을 호스팅하는 핵심 프로세스입니다. 독립 실행형 실행 파일로 실행하거나 더 큰 애플리케이션에 라이브러리로 연결하여 사용할 수 있습니다.
• HTTP/REST 엔드포인트 (HTTP/REST Endpoint): 들어오는 RESTful API 호출을 수신하고 처리하는 서버 구성 요소입니다. DDS 엔티티 관리 및 단순 데이터 입출력과 같은 상태 비저장 요청을 처리합니다.
• WebSocket 엔드포인트 (WebSocket Endpoint): 낮은 지연 시간의 실시간 데이터 스트리밍을 위해 영구적이고 양방향인 WebSocket 연결을 관리하는 서버 구성 요소입니다.
• DDS 인터페이스 계층 (DDS Interface Layer): 웹 클라이언트를 대신하여 필요한 모든 DDS 엔티티(DomainParticipants, Publishers, Subscribers, DataWriters, DataReaders)를 생성하고 관리하는 내부 구성 요소입니다. 이 계층은 Connext DDS 핵심 라이브러리와의 모든 상호작용을 담당합니다.

WIS의 가장 중요한 기능 중 하나는 서로 다른 기술 도메인 간의 데이터 표현을 변환하는 것입니다.

• 데이터 쓰기 (웹 –» DDS): 웹 클라이언트는 JSON 또는 XML 페이로드를 포함하는 HTTP POST 요청을 보냅니다. WIS는 이 페이로드를 수신하여 파싱하고, 해당 데이터를 DDS의 표준 바이너리 형식인 CDR(Common Data Representation)로 직렬화(serialize)합니다. 그런 다음, 네이티브 DDS DataWriter를 사용하여 이 CDR 샘플을 데이터버스에 발행합니다.1
• 데이터 읽기 (DDS –» 웹): WIS 내의 네이티브 DDS DataReader는 데이터버스에서 CDR 데이터 샘플을 수신합니다. 웹 클라이언트가 HTTP GET 요청을 보내면, WIS는 DataReader의 캐시에서 CDR 샘플을 가져와 요청된 형식(JSON 또는 XML)으로 역직렬화(deserialize)한 후 HTTP 응답 본문으로 전송합니다.1

이러한 변환 기능은 RTI 툴체인의 핵심 역량 중 하나입니다. 예를 들어, rticonverter와 같은 도구는 기록된 CDR 데이터를 JSON이나 CSV로 변환할 수 있는 기능을 제공하는데, WIS는 이와 유사한 메커니즘을 실시간으로 수행하여 동적인 데이터 교환을 가능하게 합니다.

DDS 개념	DDS 표현	프로토콜	웹 표현	WIS 동작
데이터 샘플 (쓰기)	struct MyData	HTTP POST	JSON/XML 객체	WIS가 JSON/XML을 CDR로 직렬화하여 발행
데이터 샘플 (읽기)	struct MyData	HTTP GET	JSON/XML 객체	WIS가 캐시에서 CDR을 읽어 JSON/XML로 역직렬화
데이터 타입 정의	IDL	HTTP POST	XML <struct> 태그	WIS가 DomainParticipant에 타입을 등록
엔티티 생성	N/A	HTTP POST	XML <datawriter> 태그	WIS가 해당 DDS 엔티티를 생성

WIS는 두 가지 주요 운영 모드를 지원하여 다양한 배포 시나리오에 유연하게 대응할 수 있습니다.

• 독립형 모드 (Standalone Mode): 가장 일반적인 배포 방식입니다. rtiwebintegrationservice를 별도의 프로세스로 실행하고, XML 파일을 통해 구성합니다. 이 방식은 웹 게이트웨이를 특정 애플리케이션의 생명 주기와 분리(decouple)시켜 독립적인 관리를 가능하게 합니다.
• 연결된 라이브러리 모드 (Linked Library Mode): 긴밀하게 통합된 시스템을 위해 WIS 서비스를 라이브러리로 사용할 수 있습니다. 이를 통해 C/C++ 애플리케이션이 웹 게이트웨이 기능을 직접 내장하여, 그 생명 주기와 구성을 프로그래밍 방식으로 더 세밀하게 제어할 수 있습니다.

WIS의 아키텍처는 ‘상태 비저장 웹 대 상태 기반 DDS’라는 근본적인 문제를 해결하기 위해 설계되었습니다. 즉, WIS는 상태 비저장 클라이언트를 위한 상태 기반 프록시 역할을 수행합니다. 웹, 특히 REST over HTTP는 본질적으로 상태가 없으며 각 요청은 독립적입니다. 반면, DDS는 DomainParticipant의 생명 주기, 시간 소요가 필요한 검색 과정, 데이터 캐시를 유지하는 DataReader 등 본질적으로 상태 기반입니다. 단순한 웹 클라이언트(예: JavaScript의 fetch 호출)는 이러한 상태를 관리할 수 없습니다. 따라서 WIS 서비스 자체가 장기 실행되는 상태 기반 엔티티가 되어야 합니다. WIS는 DomainParticipant를 생성하고 유지하며, 웹 클라이언트가 “데이터 읽기”를 요청할 때, 실제로는 웹 클라이언트가 WIS 서비스에게 내부 DDS DataReader에서 데이터를 읽어 결과를 반환하도록 요청하는 것입니다. 이 아키텍처 패턴은 WIS가 DDS의 생명 주기 관리, 검색, 상태 유지의 모든 복잡성을 흡수하고, 웹 세계에는 단순화된 상태 비저장 인터페이스를 제공한다는 점에서 그 가치의 핵심을 이룹니다. 이것이 바로 WIS가 ‘투명한 브리지’로 불리는 이유입니다.

RTI WIS의 REST API는 구성, 관리 및 비스트리밍 방식의 단순 데이터 상호작용을 위해 설계되었습니다. 이 API는 생성(Create), 읽기(Read), 갱신(Update), 삭제(Delete)를 의미하는 CRUD 작업에 표준 HTTP 동사(GET, POST, PUT, DELETE)를 일관되게 매핑합니다.

주요 목적은 서비스 재시작 없이 DomainParticipants, Topics, DataWriters, DataReaders와 같이 데이터 교환에 사용될 DDS 엔티티를 동적으로 생성하고 관리하는 것입니다. 이는 시스템의 유연성과 동적 재구성 능력을 크게 향상시킵니다.

WIS의 REST API는 계층적인 리소스 구조를 따릅니다. 주요 엔드포인트는 다음과 같습니다.

• /dds/rest1/types: 데이터 타입을 생성하고 목록을 조회합니다.
• /dds/rest1/qos_libraries/...: QoS 라이브러리 및 프로파일을 생성하고 관리합니다.
• /dds/rest1/domain_participants/<participant_name>/...: 특정 도메인 참여자 내의 엔티티를 관리합니다.
• .../data_writers/<writer_name>: 데이터 쓰기를 위한 엔드포인트입니다. 이 URL에 POST 요청을 보내면 데이터 샘플이 발행됩니다.
• .../data_readers/<reader_name>: 데이터 읽기를 위한 엔드포인트입니다. 이 URL에 GET 요청을 보내면 판독기 캐시에서 샘플을 검색합니다.

이 API는 다양한 엔티티 유형에 대한 POST 작업을 지원하여, 필요한 모든 DDS 엔티티를 동적으로 생성할 수 있는 강력한 기능을 제공합니다.

• 시스템 초기화: 시작 스크립트는 REST API를 사용하여 전체 DDS-웹 인터페이스를 프로그래밍 방식으로 구성할 수 있습니다. 필요한 모든 타입, 토픽, 엔드포인트를 동적으로 생성합니다.
• 온디맨드 데이터 조회: 웹 대시보드는 DataReader 엔드포인트에 GET 요청을 보내 시스템의 현재 상태(예: “모든 차량의 마지막 알려진 위치 가져오기”)를 가져올 수 있습니다.
• 명령 전송: 웹 UI에서 사용자가 버튼을 클릭하면 DataWriter 엔드포인트에 POST 요청이 트리거되어 DDS 시스템으로 명령(예: “5번 로봇에게 청소 주기 시작 지시”)을 보낼 수 있습니다.

REST API의 설계는 의도적인 관심사 분리(separation of concerns)를 보여줍니다. REST API는 ‘제어 플레인’(구성 및 관리)을 처리하는 반면, WebSocket은 ‘데이터 플레인’(고빈도 데이터 흐름)을 처리합니다. 문서에서는 생성, 삭제, 나열, 업데이트와 같은 작업에는 REST API를 사용하고, 읽기 및 쓰기 작업에는 WebSocket API를 사용하도록 명시적으로 권장합니다. REST는 “토픽 생성”이나 “데이터라이터 삭제”와 같은 상태 비저장 또는 트랜잭션 성격의 관리 작업에 본질적으로 적합합니다. 반면, 고빈도 데이터 스트리밍은 모든 메시지에 대해 새로운 HTTP 연결을 설정하는 오버헤드 때문에 REST를 통해 처리하기에는 비효율적입니다. 이러한 의도적인 분리는 WIS를 사용하는 애플리케이션을 위한 모범 사례 아키텍처를 제시합니다. 즉, 설정, 해체 및 드문 명령에는 REST를 사용하고, 지속적인 실시간 데이터 시각화나 원격 측정에는 WebSocket을 사용하는 것입니다. 초당 수천 개의 REST POST 요청을 통해 실시간 비디오를 스트리밍하려는 시도는 이 아키텍처의 심각한 오용이 될 것입니다.

WebSocket API는 특히 높은 처리량, 낮은 지연 시간의 실시간 통신을 위해 설계되었습니다. REST와 달리, WebSocket은 웹 클라이언트와 WIS 사이에 단일의 영구적인 전이중(full-duplex) TCP 연결을 설정합니다. 이를 통해 양측은 새로운 연결 핸드셰이크의 오버헤드 없이 언제든지 데이터를 전송할 수 있습니다. 이 특성 덕분에 라이브 데이터 대시보드, 실시간 협업 도구, 스트리밍 원격 측정과 같은 사용 사례에 이상적입니다.

WebSocket 연결은 다음과 같은 명확한 생명 주기를 따릅니다.

1. 활성화 (Enablement): WebSocket 지원은 선택적 기능이므로, WIS를 시작할 때 -enableWebSockets 명령줄 인수를 사용하여 명시적으로 활성화해야 합니다.
2. 연결 이름 생성 (Connection Name Creation): WebSocket이 연결되기 전에, REST POST 요청을 통해 ‘연결 이름’을 미리 생성해야 합니다. 이는 WebSocket 엔드포인트를 사전에 등록하는 역할을 합니다.
3. 핸드셰이크 및 연결 (Handshake and Connection): 클라이언트는 ws://<host>/dds/websocket/<connection_name> 주소로 연결을 설정합니다. 클라이언트가 보내는 첫 번째 메시지는 핸드셰이크를 완료하기 위한 HELLO 메시지여야 합니다.
4. 바인딩 (Binding): 연결이 설정되면, 클라이언트는 BIND 메시지를 보내 DDS 엔티티(REST API URI로 식별되는 DataWriters 또는 DataReaders)를 WebSocket 연결과 연결합니다. 이는 WIS에게 이 특정 소켓을 통해 어떤 데이터를 스트리밍할지 알려주는 과정입니다.
5. 데이터 교환 (Data Exchange): 바인딩이 완료된 후, DDS 데이터 샘플(JSON 또는 XML 형식)을 포함하는 REQUEST 및 RESPONSE 메시지가 소켓을 통해 교환됩니다.

WIS의 맥락에서 두 프로토콜의 특성을 종합적으로 비교하여 개발자와 아키텍트가 특정 작업에 적합한 API를 선택할 수 있도록 명확한 가이드를 제공합니다.

• REST 사용 사례: 일회성 데이터 읽기, 명령 전송, 시스템 구성, 그리고 클라이언트가 매우 일시적이어서 연결을 유지할 수 없는 시나리오.
• WebSocket 사용 사례: 지속적인 데이터 스트림(예: 센서 판독값, 상태 업데이트) 구독, 가능한 가장 낮은 지연 시간이 요구되는 애플리케이션, 그리고 서버가 선행 요청 없이 클라이언트에게 데이터를 푸시해야 하는 시나리오.

특성	REST API	WebSocket API
통신 모델	요청-응답 (Request-Response)	전이중/이벤트 기반 (Full-Duplex/Event-Driven)
상태 유지	상태 비저장 (Stateless)	상태 기반 (Stateful - 영구 연결)
주요 사용 사례	관리 및 명령 (제어 플레인)	실시간 데이터 스트리밍 (데이터 플레인)
지연 시간	높음 (요청당 연결 오버헤드)	낮음 (영구 연결)
서버–»클라이언트 푸시	불가 (폴링/롱폴링 필요)	가능 (네이티브 기능)
일반적인 작업	엔티티 생성/삭제/목록, 드문 읽기/쓰기	데이터 샘플의 지속적인 읽기/쓰기

RTI WIS의 구성은 독립적인 시스템이 아니라, RTI Connext의 더 넓은 “XML 기반 애플리케이션 생성(XML-Based Application Creation)” 기능의 일부입니다. 이는 단일 XML 파일 세트를 사용하여 QoS 정책과 데이터 타입뿐만 아니라, DDS 엔티티(DomainParticipants, Topics 등)의 전체 계층 구조와 WIS 서비스 자체를 정의할 수 있음을 의미합니다. 이 접근 방식은 애플리케이션 코드를 재컴파일하지 않고도 구성을 변경할 수 있게 해주어 시스템 유지보수 및 튜닝에 상당한 이점을 제공합니다.

이 섹션에서는 제공된 자료의 패턴을 참조하여 완전하고 주석이 달린 USER_QOS_PROFILES.xml 예제 파일을 단계별로 구성하는 방법을 설명합니다.

1. XML 헤더 및 스키마: 표준 XML 선언과 <dds> 루트 태그로 시작하며, 유효성 검사 및 편집기 자동 완성을 위해 RTI DDS QoS 스키마를 참조하는 xsi:noNamespaceSchemaLocation 속성을 포함합니다.

   <?xml version="1.0"?>
   <dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="http://community.rti.com/schema/7.5.0/rti_dds_qos_profiles.xsd">
   

2. 타입 정의 (<types>): 교환될 데이터의 struct를 정의하는 방법을 보여줍니다. 예를 들어, HelloWorld 또는 ShapeType과 유사하게 정의할 수 있습니다.

   <types>
       <struct name="HelloWorld">
           <member name="sender" type="string" stringMaxLength="256" key="true"/>
           <member name="message" type="string" stringMaxLength="256"/>
           <member name="count" type="long"/>
       </struct>
   </types>
   

3. QoS 정의 (<qos_library>): 신뢰성, 내구성 등과 같은 QoS 설정을 담을 <qos_library>와 <qos_profile>을 생성하는 방법을 시연합니다. 이는 표준 DDS 관행입니다.

   <qos_library name="MyQosLibrary">
       <qos_profile name="DefaultProfile" is_default_qos="true">
           <datawriter_qos>
               <reliability><kind>RELIABLE_RELIABILITY_QOS</kind></reliability>
           </datawriter_qos>
           <datareader_qos>
               <reliability><kind>RELIABLE_RELIABILITY_QOS</kind></reliability>
           </datareader_qos>
       </qos_profile>
   </qos_library>
   

4. WIS 서비스 구성 (<web_integration_service>): WIS 구성의 핵심입니다. 이 태그는 서비스의 동작을 정의하며, 내부적으로 DDS 엔티티를 생성하고 REST 및 WebSocket 엔드포인트를 설정합니다.

   <web_integration_service name="MyWebService">
       <application name="HelloWorldWebApp">
           <domain_participant name="MyParticipant">
               <domain_id>0</domain_id>
               <register_type name="HelloWorldType" type_ref="HelloWorld"/>
               <topic name="HelloWorldTopic" register_type_ref="HelloWorldType"/>
               <publisher name="MyPublisher">
                   <data_writer name="MyWriter" topic_ref="HelloWorldTopic"/>
               </publisher>
               <subscriber name="MySubscriber">
                   <data_reader name="MyReader" topic_ref="HelloWorldTopic"/>
               </subscriber>
           </domain_participant>
       </application>
       <rest>
           <http_port>8080</http_port>
       </rest>
       <web_socket>
           <enable>true</enable>
           <port>8081</port>
       </web_socket>
   </web_integration_service>
   </dds>
   

   위 예제는 WIS가 MyParticipant라는 이름의 DomainParticipant를 0번 도메인에 생성하고, HelloWorld 타입을 등록하며, HelloWorldTopic이라는 토픽을 생성하도록 지시합니다. 또한, 해당 토픽에 대한 DataWriter와 DataReader를 생성하고, REST 서비스는 8080 포트, WebSocket 서비스는 8081 포트에서 실행되도록 구성합니다.

• QoS 통합: WIS에 의해 생성된 DataWriters 및 DataReaders는 <qos_library>에 정의된 QoS 프로파일을 참조하여 구성됩니다. 이를 통해 웹에 노출된 데이터 스트림에 대해 신뢰성, 이력, 마감일 등과 같은 서비스 품질을 세밀하게 제어할 수 있습니다.
• 보안 통합: WIS는 RTI Connext DDS 보안 플러그인과 완벽하게 통합됩니다. 구성은 QoS 프로파일의 <domain_participant_qos> 섹션 내에서 처리됩니다. 아키텍트는 보안 플러그인을 로드하고 필요한 거버넌스(governance) 및 권한(permissions) 파일을 가리키는 속성을 지정해야 합니다. 이 파일들은 어떤 웹 기반 참여자가 도메인에 참여할 수 있는지, 그리고 어떤 토픽을 발행하거나 구독할 수 있는지를 정의합니다. 이는 모든 웹 트래픽에 대해 강력하고 중앙 집중화된 보안 시행 지점을 제공합니다. 이 과정은 다른 Connext DDS 애플리케이션을 보호하는 표준 절차와 동일하게, 참여자 QoS의 <property> 태그 내에 특정 속성을 설정하는 것을 포함합니다.

이것은 WIS의 주요 사용 사례입니다. DDS는 산업 시스템에서 센서 및 제어 데이터를 위해 널리 사용됩니다. WIS는 이 실시간 데이터(예: 기계 온도, 진동, 생산 상태)를 웹 기반 대시보드(예: Grafana)로 직접 스트리밍하여 운영자가 모니터링하거나 상위 수준 시스템이 분석할 수 있도록 합니다.

이 시나리오에서 WebSocket API는 시계열 데이터를 스트리밍하는 데 이상적이며, REST API는 제어 명령을 공장 현장으로 다시 보내는 데 사용될 수 있습니다.

많은 엔터프라이즈 시스템과 데이터 과학 툴체인은 우수한 HTTP 라이브러리를 갖춘 Python, Java 또는 기타 스크립팅 언어를 기반으로 구축되지만, 네이티브 DDS 지원이 없을 수 있습니다. WIS는 간단한 RESTful 인터페이스를 제공하여 이러한 시스템이 복잡한 통합 코드 없이 실시간 DDS 환경에서 데이터를 쉽게 가져오거나 명령을 푸시할 수 있도록 합니다.

항공 우주 및 국방과 같은 분야에서는 고성능 DDS 네트워크에서 복잡한 시뮬레이션이 실행됩니다. WIS는 시뮬레이션 상태 데이터를 원격 웹 기반 시각화 도구(예: HTTP 호출이 가능한 Unity 또는 Unreal Engine으로 구축)에 노출하거나, 원격 운영자가 간단한 웹 인터페이스를 통해 시뮬레이션에 명령과 시나리오를 주입할 수 있도록 합니다.

WIS는 단순한 도구를 넘어 ‘디지털 트윈(Digital Twin)’ 및 ‘엣지-투-클라우드(Edge-to-Cloud)’와 같은 중요한 아키텍처 패턴을 가능하게 하는 핵심 기술입니다. IIoT 모니터링 대시보드는 본질적으로 물리적 자산 상태의 실시간 시각화이며, 이는 디지털 트윈의 핵심 구성 요소입니다. DDS는 ‘엣지’(공장, 차량 등)에서 실시간 데이터 패브릭을 제공하고, WIS는 이 데이터를 ‘클라우드’나 ‘포그’ 계층에 있는 디지털 트윈 애플리케이션이나 분석 플랫폼으로 전달하는 다리 역할을 합니다. 따라서 WIS는 물리적 자산의 데이터 스트림(DDS를 통해)을 가상 표현(웹 기술을 통해)에 연결함으로써 강력한 실시간 디지털 트윈 아키텍처를 구현하는 데 필수적인 기술입니다.

RTI Connext DDS 시스템을 웹과 통합해야 하는 과제에 직면했을 때, 아키텍트는 RTI WIS라는 기성 솔루션을 ‘구매(Buy)’할 것인지, 아니면 자체적으로 맞춤형 게이트웨이를 ‘구축(Build)’할 것인지 결정해야 합니다. 이 결정은 프로젝트의 비용, 시간, 리스크 및 장기적인 유지보수에 지대한 영향을 미칩니다.

RTI WIS를 채택하는 것은 다음과 같은 강력한 이점을 제공합니다.

• 시장 출시 시간 단축 (Reduced Time-to-Market): 사전에 구축되고, 테스트되었으며, 문서화된 솔루션을 활용하여 개발 주기를 극적으로 단축시킵니다.
• 기술적 리스크 감소 (Lower Technical Risk): 두 개의 복잡한 프로토콜을 올바르게 구현하고, DDS 검색의 예외적인 경우를 처리하며, 보안을 관리하고, 성능을 보장하는 등 맞춤형 개발의 많은 함정을 피할 수 있습니다. RTI는 이미 이러한 문제들을 해결했습니다.
• 핵심 비즈니스 로직에 집중: 개발팀이 인프라 구축 대신 애플리케이션의 기능 개발에 집중할 수 있도록 합니다.
• 유지보수 및 지원: 상용 제품으로서 WIS는 보안 패치 및 성능 개선을 포함하여 RTI에 의해 유지, 업데이트 및 지원됩니다. 맞춤형 솔루션의 유지보수는 지속적인 내부 비용입니다.
• 풍부한 기능: QoS 및 보안 플러그인과 같은 고급 DDS 기능에 대한 지원이 내장되어 있어, 이를 맞춤형 솔루션에서 올바르게 구현하는 데 드는 복잡성과 시간을 절약할 수 있습니다.

자체 게이트웨이를 구축하는 길은 상당한 도전 과제를 동반합니다.

• 높은 비용 및 전문성 요구: Connext DDS 내부 구조와 최신 웹 서비스 개발 양쪽에 대한 깊은 전문 지식이 필요합니다. 이러한 인재는 드물고 비용이 많이 듭니다.
• DDS의 복잡성: DDS는 단순한 프로토콜이 아닙니다. 맞춤형 게이트웨이는 검색, 엔티티 관리, QoS 협상, 데이터 직렬화(CDR), 네트워크 전송(UDP/TCP, 멀티캐스트/유니캐스트) 등 전체 DDS 생명 주기를 올바르게 처리해야 합니다.
• 보안 구현: 맞춤형 게이트웨이는 인증, 접근 제어, 암호화를 처음부터 구현해야 하며, 이는 올바르게 구현하기 매우 어려운 분야입니다.
• 확장성 및 성능 튜닝: 부하가 높은 상황에서도 확장 가능하고 성능이 좋은 맞춤형 게이트웨이를 설계하는 것은 중요한 엔지니어링 과제입니다.
• 인증 및 장기 유지보수: OS 및 라이브러리 업데이트에 맞춰 맞춤형 코드베이스를 테스트하고, 필요한 경우 인증하며, 유지보수하는 지속적인 부담이 따릅니다.

요소	RTI Web Integration Service (WIS)	맞춤형 인하우스 게이트웨이
개발 노력 및 시간	낮음 (구성 기반)	매우 높음 (처음부터 개발)
필요 전문성	웹 서비스, 기본 DDS 개념	DDS 및 웹 서비스 양쪽에 대한 깊은 전문가 수준
총 소유 비용(TCO)	라이선스 비용 + 낮은 유지보수	높은 개발 비용 + 높은 지속적 유지보수
시장 출시 시간	빠름	느림
보안	DDS 보안과 통합, 강력함	직접 구축해야 함, 높은 리스크
QoS 지원	XML 구성을 통한 완벽한 지원	직접 구현해야 함, 복잡함
지원 및 유지보수	RTI에서 제공	내부 책임
유연성/맞춤화	높음 (구성을 통해)	궁극적 (그러나 높은 비용 수반)

모든 게이트웨이는 프로토콜 변환 및 데이터 직렬화/역직렬화로 인해 약간의 오버헤드를 발생시킵니다. WIS에 대한 구체적인 벤치마크는 제공되지 않았지만, 기반 기술인 RTI Connext DDS 자체는 매우 높은 처리량과 낮은 지연 시간을 위해 벤치마킹되었습니다. WIS의 오버헤드는 RTI 제품군의 일부로서 최적화되었을 것으로 예상됩니다. 반면, 맞춤형 게이트웨이의 성능은 구현 품질에 전적으로 의존하는 미지수입니다.

본 보고서의 분석을 통해 RTI Web Integration Service(WIS)가 웹 애플리케이션을 RTI Connext DDS 시스템과 통합하기 위한 성숙하고, 표준 기반이며, 매우 효과적인 솔루션임이 명확해졌습니다. WIS는 관리 및 실시간 데이터 스트리밍 요구를 모두 충족시키기 위해 이중 REST 및 WebSocket API를 제공합니다. 그 아키텍처는 DDS의 복잡성을 지능적으로 추상화하며, 구성 중심 접근 방식은 개발 리스크를 크게 줄이고 개발 속도를 가속화합니다.

• ‘구축’보다 ‘구매’ 강력 권장: 대다수의 프로젝트에서 RTI WIS를 채택하는 것이 맞춤형 게이트웨이를 구축하는 것보다 우월한 아키텍처 선택입니다. 속도, 신뢰성, 보안 및 낮은 총 소유 비용 측면에서의 이점은 압도적입니다.
• 맞춤형 개발을 고려해야 할 경우: 맞춤형 게이트웨이는 WIS에서 지원하지 않는 비표준 웹 프로토콜을 통합해야 하거나, 일반적인 게이트웨이의 최소한의 오버헤드조차 허용할 수 없는 극단적인 성능 요구사항이 있어 고도로 전문화된 포인트-투-포인트 솔루션이 정당화되는 매우 드문 경우에만 고려되어야 합니다.
• 구현 모범 사례:
  1. 제어 플레인에는 REST API 사용: 시스템 구성, 엔티티 관리, 일회성 명령 전송과 같은 작업에는 REST API를 활용하십시오.
  2. 데이터 플레인에는 WebSocket API 사용: 실시간 데이터 스트리밍, 지속적인 상태 업데이트, 낮은 지연 시간이 중요한 통신에는 WebSocket API를 사용하십시오.
  3. XML 구성을 적극적으로 활용: 시스템 로직을 애플리케이션 코드와 분리하기 위해 XML 기반 구성을 최대한 활용하십시오. 이는 유지보수성과 유연성을 크게 향상시킵니다.
  4. 초기부터 DDS 보안 통합: 설계 단계부터 DDS 보안 플러그인을 통합하여 ‘보안 우선 설계(secure-by-design)’ 아키텍처를 보장하십시오. 이는 웹을 통해 시스템에 접근하는 모든 경로를 보호하는 데 필수적입니다.