AllJoyn™ is a peer-to-peer technology that enables ad hoc, proximity-based, device-to-device communication without the use of an intermediary server.
AllJoyn 기술에 대하여 간결하게 설명하고 있는 듯 하네요. 중계서버 없이 device와 device가 direct로 통신할 수 있도록 도와주는 프레임워크 또는 라이브러리로 이해하시면 됩니다.
일단 데모를 한번 보겠습니다.
안드로이드 Device끼리 연결되어서 각 Device에 저장된 사진을 공유하는 시나리오와 PC용 게임을 안드로이드 Device로 제어하는 시나리오를 보여주고 있습니다.
이 시나리오를 직접 구현해야 한다면, AllJoyn과 같은 기기간 연동를 도와주는 기술을 한번 쯤은 관심있게 검토하게 되겠죠?
Q&A 형식을 빌려 AllJoyn 기술을 조금 더 깊이 들여다 보도록 하겠습니다.
AllJoyn을 활용할 수 있는 플랫폼은?
윈도우, 리눅스, 안드로이드에서 AllJoyn 기반의 애플리케이션을 개발 할 수 있습니다.
사용할 수 있는 프로그래밍 언어는?
현재는 Java와 C++ API를 제공하고 있습니다. 차후에는 Browser Plugin을 설치하는 방식으로 JavaScript API도 제공할 것으로 알고 있습니다.
각 Device들은 어떻게 연결되어 있을까요?
답은 Wi-Fi 입니다. 같은 AP에 Wi-Fi로 물려 있는 Device간에 통신이 가능하도록 도와주는 것이 AllJoyn 기술입니다. 사이트에서는 블루투스와 Wi-Fi Direct도 지원한다고 설명하고 있지만, Wi-Fi Direct는 아직 구현 중이고, 블루투스도 안드로이드 커널, 프레임워크 수정을 피할 수 없기 때문에 현재로서는 활용하지 못한다고 보는 것이 맞을 것 같습니다.
AllJoyn이 장점으로 내세우는 것 중에 하나가 애플리케이션 개발자가 네트워크 레이어에서 어떤 기술을 통신 사용하는지 신경쓰지 않아도 된다는 것입니다. 개념적으로는 AllJoyn 프레임워크가 알아서 Wi-Fi든 Bluetooth든 상황에 맞게 선택한다고 이해하시면 됩니다. 그러나 앞서 말씀드린 것 처럼 현실적으로는 동일 Network내에 있는 Device끼리 Wi-Fi로 통신하는 방법밖에 없습니다.
연결된 Device들은 어떤 방식으로 데이터를 전달할까요?
답은 Remote Method Invocation(RMI) 입니다. Annotation을 추가한 인터페이스 파일을 서로 공유하고, proxy를 통해 해당 인터페이스의 메서드를 호출하는 방식으로 데이터를 전달합니다. 소켓 프로그래밍처럼 주고 받을 데이터의 순서와 타입에 대한 약속을 하고 힘들게 예외처리 할 필요 없이 우아하게 메서드를 정의하고 호출하면 그만입니다.
각 Device는 서로를 어떻게 찾을 수 있을까요?
지금까지 AllJoyn 프레임워크라고 뭉뚱그려 설명했는데, 이제는 AllJoyn Daemon의 개념을 제대로 설명해 드려야 할 것 같습니다.
<
p style=”text-align: left; clear: none; float: none; “>
AllJoyn 기반의 애플리케이션이 정상적으로 다른 Device와 통신하기 위해서는 각 Device에 한개 이상의 AllJoyn Daemon이 동작하고 있어야 합니다. 애플리케이션 개발자는 AllJoyn 라이브러리를 링크하고 여기에 정의된 API를 호출하는 방식으로 Daemon에 Service를 등록하거나 Client로서 Service를 찾고 연결하여 메서드를 호출할 수 있습니다.
Daemon이 설치된 Device가 같은 네트워크안에 연결되면, Daemon끼리 서로의 존재를 인지하고 정보를 교환합니다.
자신에게 어떤 Service가 연결되어 있는지
자신에게 어떤 이름의 Service를 찾는 Client가 연결되어 있는지
개념적으로는 같은 네트워크 안에 연결된 Device가 하나로 연결되어 가상의 AllJoyn Bus가 만들어 진다고 이해할 수 있습니다. 자연스럽게 Device의 경계는 무너지는거죠. 가상의 AllJoyn Bus에 누가 어떤 이름의 Service를 하고 있고 누가 어떤 이름의 Service를 찾고 있는지만 중요하게 됩니다.
Service는 누군가 자신을 유일하게 구별할 수 있도록 이름(well-known name)을 광고(advertise)해야 합니다. 이 이름은 Java 세상에서 패키지 이름처럼 도메인을 거꾸로 쓰는 표기법을 사용합니다.
예를 들어 다음과 같은 채팅 애플리케이션이 만들어낸 Service의 이름에서,
org.alljoyn.sample.chat.bob
org.alljoyn.sample.chat.carol
특정 Service를 나타내는 prefix는 org.alljoyn.sample.chat이고 이를 Bus에서 유일하게(Unique) 만들어주는 suffix는 bob과 carol이 됩니다. Client는 prefix로 Service를 탐색합니다. 이 예제에서 Client는 org.alljoyn.sample.chat로 Service를 탐색하게 되고 탐색(discovery) API는 org.alljoyn.sample.chat.bob와 org.alljoyn.sample.chat.carol를 모두 반환합니다. bob이 만든 채팅방과 carol이 만든 채팅방을 모두 찾은 셈이죠. 사용자의 선택에 따라 선택된 특정 Service(채팅방)와 연결하고 Service가 제공하는 메서드를 호출하면 통신은 간단히 이루어 집니다.