소프트웨어는 우리의 생활 속 구석구석까지 스며들어 늘 우리와 함께 하고 있습니다. 메일이나 메신저를 이용하여 친구나 가족들의 안부를 묻기도 하구요. 워드 프로세서나 스프레드 쉬트 같은 소프트웨어로 우리의 일상 업무를 처리하고 있습니다. 이것이 가능한 이유는 다양한 디바이스들이 우리 곁에 있기 때문입니다.
이러한 소프트웨어들은 서비스 또는 애플리케이션 형태로 제공됩니다. 우리에게 제공되는 형태에 따라 분류하면 PC에서 설치하여 사용하는 데스크탑 애플리케이션이 있고, Web에서 서비스 형태로 제공되는 애플리케이션, 그리고 모바일 애플리케이션 등이 있습니다. 또한 이들 애플리케이션들은 제공 형태에 따라 실행하는 Platform이 다르고 기술구조도 각기 다릅니다. 그래서 애플리케이션 개발자는 개발 초기에 타겟이 되는 Platform을 결정하게 됩니다. 예를 들어 PC기반으로 동작하는 데스크탑 형태로 갈지, 아니면 Web 서비스 형태로 제공할지 결정하게 됩니다.
그러나 오늘날 애플리케이션을 사용하는 사용자들의 경험은 점점 세련되고 이들의 요구사항은 좀 더 다양해 지고 있습니다. 사용자들은 자신이 사용하는 서비스를 데스크탑 뿐만 아니라 Web이나 모바일에서도 접하길 원하고 있습니다. 이 말은 개발자들이 구현해야할 타겟 Platform들이 늘어나고 구현 기술이 다양해진다는 의미입니다. 그만큼 개발자들의 부담은 늘어나고 있습니다.
온라인 사진편집기
이 문제를 해결할 방법은 없을까요? 우선 pixlr.com 을 한 번 살펴보겠습니다. pixlr를 방문해 보면 온라인에서 자신의 사진을 편집할 수 있는 기능이 있습니다.
우리가 사진이나 이미지를 편집할 때 보통 PC에 설치하는 PhotoShop같은 소프트웨어를 사용합니다. 그러나 사용자에 따라서 자신의 PC에 이와 같은 무거운 소프트웨어를 설치하지 않고 바로 사진편집을 원하는 사람이 있습니다. 이런 사용자들에게 pixlr는 하나의 대안이 될 수 있습니다.
pixler와 같은 서비스 형태를 SaaS(Software as a Service)라고 합니다. SaaS는 클라우드 컴퓨팅의 한 유형이죠. SaaS는 온라인 워드 프로세서나 온라인 포토샵과 같은 데스크탑 애플리케이션을 Web에서 서비스 형태로 구현합니다.
그럼 여기서 이런 생각을 할 수 있습니다. 만일 데스크탑 애플리케이션에서 제공하는 소프트웨어 기능을 Web에서 동일한 형태로 제공한다면 어떨까요? 데스크탑 기반으로 동작하는 애플리케이션을 그대로 Web에 옮길수 있다면 어떨까요? 만일 그게 가능하다면 그 응용범위는 아마 굉장히 광범위할 것입니다.
데스크탑 기반으로 실행되는 응용 소프트웨어를 Web에서 바로 가능하게 할 수 있다고 생각하는 개발자는 별로 없을겁니다. Web을 위하여 동일한 기능을 가진 애플리케이션을 따로 개발해야 된다고 생각할 것입니다. 그러나 이것을 가능하게 해 주는 방법이 존재합니다. 그것은 Java 기반의 Eclipse RCP + RAP의 조합입니다.
Eclipse RAP(Remote Application Platform)
Eclipse RCP(Rich Client Platform)은 Java 기반의 데스크탑 애플리케이션을 위한 플랫폼입니다. 자바기반의 개발도구인 Eclipse IDE 의 플랫폼이기도 합니다. 그리고 RCP는 NASA를 비롯한 여러 기업 시스템에서 데스크탑 애플리케이션의 기반 플랫폼으로 사용되고 있습니다. 반면 Eclipse RAP(Remote Application Platform)는 Java 기반의 Web을 위한 플랫폼입니다. RAP는 RCP와 유사한 개발환경을 가졌으며 유사한 API를 사용합니다. 그래서 RCP 기반으로 동작하는 코드가 RAP에서도 동작합니다.
Single Sourcing
이와 같이 하나의 소스로 데스크탑 및 Web 에서 동작하는 것을 Single Sourcing 이라 합니다. 즉 One Source, Multi Platform 이죠. Eclipse RCP와 RAP를 사용하면 이와 같은 Single Sourcing 이 가능합니다. 또한 RCP로 만들어진 기존 제품이 있다면 RAP로 마이그레이션이 쉬워 데스크탑 애플리케이션 기능을 쉽게 Web에서 구현 가능합니다. 그럼 RAP에서 왜 이것이 가능한지 알아보겠습니다.
RAP는 RCP에서 사용하는 Rich Client 개념을 Web에 적용하기 위해서 나타난 개념입니다. Rich Client란 화면을 구성하는 로직이 서버가 아닌 클라이언트에 존재하는 시스템입니다. RAP에서 Rich Client 개념을 구현하기 위하여 Ajax 방식을 사용합니다. RAP의 초창기 시절에는 Rich Ajax Platform이라고 불렸습니다. 바로 Ajax를 사용하였기 때문입니다.
RCP와 RAP 사이에서 Single Soursing 이 가능한 이유는 두가지 플랫폼이 아키텍쳐가 비슷하기 때문입니다. 또한 RCP에서 UI를 구성하는 기반이 되는 기술이 SWT(Standard Widget Toolkit)인데 RAP에는 여기에 대응하는 RWT(RAP Widget Toolkit)를 구현하였습니다. RAP 아키텍쳐는 RCP 아키텍처의 SWT 부분만 RWT로 바뀝니다. 그리고 RWT는 서버 영역과 클라이언트 영역으로 나뉘며 이 둘 사이는 HTTP로 통신합니다.
SWT와 RWT
RWT는 SWT에서 구현했던 UI 위젯을 Web에 대응 가능한 형태로 구현하였습니다. 즉, 데스크탑 애플리케이션 화면에 존재하는 Button 위젯을 Web 화면에 표현 가능한 Button 위젯으로 구현하였습니다. 이 둘 사이에 접근하는 API는 동일하나 구현방식은 완전히 다른 형태로 되어 있습니다.
그럼 RCP와 RAP 사이에서 Single Sourcing 이 왜 가능한지 RCP로 구현한 코드와 RAP로 구현 코드를 살펴보겠습니다.
public class HelloSWT2 {
public static void main(String[] args) {
Display display = new Display();
Shell shell = new Shell(display);
shell.setText("SWT");
FillLayout layout = new FillLayout();
layout.marginHeight = 20;
shell.setLayout(layout);
Label label = new Label(shell, SWT.CENTER);
label.setText("Hello World!");
shell.setSize(200, 100);
shell.open();
while (!shell.isDisposed()) {
if (!display.readAndDispatch())
display.sleep();
}
display.dispose();
}
}
[코드1]RCP-SWT 구현 코드
public class HelloEntryPoint implements EntryPoint {
public int createUI() {
Display display = new Display();
Shell shell = new Shell(display);
shell.setText("SWT");
FillLayout layout = new FillLayout();
layout.marginHeight = 20;
shell.setLayout(layout);
Label label = new Label(shell, SWT.CENTER);
label.setText("Hello World!");
shell.setSize(200, 100);
shell.open();
while (!shell.isDisposed()) {
if (!display.readAndDispatch())
display.sleep();
}
display.dispose();
return 0;
}
}
[코드2]RAP-RWT 구현 코드
SWT와 RWT로 각각 구현된 코드를 비교해 보면 코드가 거의 같다는 사실을 알 수 있습니다. 여기서 사용된 Label이나 Shell은 같은 이름의 클래스를 사용하고 있습니다. 이름은 같지만 사실 배포되는 Target Platform에 따라 다르게 구현된 Label 또는 Shell이 동작합니다. 이러한 연유로 RCP와 RAP 간의 Single Sourcing이 가능한 것입니다.
Single Sourcing을 위한 전략
그러면 RCP로 개발된 데스크탑 애플리케이션 코드가 그대로 RAP로 이전이 가능할까요? 코드 전부는 불가능합니다. 그것은 데스크탑과 Web이 가지는 태생적인 차이점 때문에 그렇습니다.
우선 데스크탑 기반의 애플리케이션은 사용자가 1명입니다. 그러나 Web은 여러명이 될 수 있습니다. 따라서 Web 기반인 경우에는 사용자별 Session 처리 문제가 발생합니다. 그리고 데스크탑 애플리케이션은 OS 바로 위에서 동작하므로 로컬 자원 접근에 아무런 제약이 없습니다. 반면 Web인 경우 브라우저에서 동작하므로 로컬 자원 접근에 제약이 있습니다. 이를테면 File 이나 그래픽 작업 같은 것들이죠.
그럼에도 불구하고 RCP와 RAP가 공유할 수 있는 코드는 80% ~ 98% 정도 가능합니다. 앞서서 말씀드린데로 RAP가 RCP의 동일한 API를 구현했기 때문입니다. 나머지 2% ~ 20% 의 차이는 왜 발생할까요? File 접근이나 Session 문제와 같이 데스크탑 특성을 가지는 코드와 Web 특성을 가지는 코드때문에 서로 다른 구현의 차이는 어쩔 수 없이 발생합니다.
그러면 이러한 Single Sourcing을 위한 코드관리는 공통의 코드를 잘 유지해야 하는 점이 중요합니다. 우선 코드를 공통코드, RCP 특성코드, RAP 특성코드 이 3가지로 나눕니다. 공통코드는 양 플랫폼에서 모두 동작해야 하는 코드이며 나머지 특성코드는 각각의 플랫폼에서만 동작하는 코드입니다. 그리고 실행환경을 플랫폼 별로 2가지로 유지하고 공통코드는 공유하는 형태로 진행하면 됩니다.
Cross Platform을 위한 대안 : Eclipse RAP
여러분이 만일 동일한 애플리케이션 기능을 데스크탑과 Web에서 중복으로 개발하고 있거나 기존의 데스크탑 제품을 Web에서 구현하고자 할때 Eclipse RAP는 하나의 대안이 될 수 있습니다. 각 플랫폼에서 구현할 화면 로직을 하나로 통합한다면 많은 비용을 줄일 수 있습니다. RAP는 지금도 성장하고 있으며(ver 2.2) 해외의 수많은 개발자들이 주목하고 있는 기술입니다. Eclipse RAP는 한 번 고려해 볼 만한 충분한 가치가 있습니다.
참고 사이트 및 서적
- Eclipse RAP : http://eclipse.org/rap/
- Wikidepia RAP : http://en.wikipedia.org/wiki/Remote_Application_Platform
- Eclipse RCP NASA : http://www.eclipsecon.org/2013/sites/eclipsecon.org.2013/files/NASA_EclipseCon_13.pdf
- Single Sourceing : http://www.slideshare.net/caniszczyk/single-sourcing-rcp-and-rap
- qooxdoo example : http://qooxdoo.org/community/real_life_examples
- Cross-Platform UI Frameworks : http://developer.eclipsesource.com/technology/crossplatform/
- RAP Demo : http://www.youtube.com/watch?v=apomlZbvrZ4
- RAP 서적 : Eclipse Rich Ajax Platform, Fabian Lange, APRESS