천객만래 [千客萬來] (It has an interminable succession of visitors)






RIA(Rich Internet Apllication)이란?

 
 
RIA란 데스크톱 응용 프로그램의 특징과 기능을 가지는 웹 응용 프로그램
 
일반적으로 페이지의 새로 고침 없이 한 페이지에서 동작하는 웹 응용 프로그램

웹 2.0이 인터넷 기술의 새로운 이슈로 등장하고 있다. 웹 2.0과 관련된 여러 기술들 중 RIA는 웹 2.0을 완성하기 위한 사용자와의 접점으로서 많은 주목을 받고 있다.
백문이 불여일견! 우선 RIA로 구현된 사이트를 간단히 살펴보도록 하자. 
RIA가 적용된 첫 번째 사례는 2002년 TravelClick(
http://www.travelclick.net)에 의해 제작된 BroadMoor 호텔(http://www.broadmoor.com)의 OneScreen이라는 예약 시스템이다. 


[브로드무어 호텔의 OneScreen 예약 시스템]

플래시와 콜드퓨전(CFML)로 만들어진 이 시스템은 기존의 5단계 페이지를 거쳐서 진행되었던 예약 업무를 플래시의 화려한 그래픽 사용자 인터페이스를 이용하여 한 페이지로 구현한 것이었다. 이것은 그 당시까지의 여러 페이지를 거쳐 시스템을 구현하던 웹 사용자 인터페이스의 새로운 전환을 가져오게 한 사건이었다.
국내 사례를 한번 살펴보자. Adobe의 플래시(flash)를 이용하여 구현된 CGV 영화관(http://www.cgv.co.kr)의 예매 서비스로 페이지의 전환 없이 한 페이지에서 영화 정보 확인 및 예매를 할 수 있다.


[CGV 극장 영화 예매 시스템]
사용자 인터페이스의 향상과 더불어 사용의 편리성까지 제공할 수 있는 것이 바로 RIA의 가장 강력한 힘인 것이다.

RIA를 구현하려면
RIA를 구현하기 위해 다양한 웹 브라우저에서 동작하면서 개발자의 편의를 제공하려는 시도는 여러 업체들에 의해 지금도 계속 중이다. RIA를 구현할 수 있는 기술들을 살펴보면 다음과 같다.

  • AJAX/DHTML: 자바 스크립트와 XML을 이용한 비동기 호출을 사용하는 방식으로 웹 2.0에서 많은 주목을 받고 있는 기술의 조합이다. 현재 많은 업체에 의해 AJAX를 쉽게 개발할 수 있도록 툴 킷들이 공개되고 있다.
  • 플래시(Flash): Adobe(이전 Macromedia)의 대표적인 벡터 방식의 그래픽 환경으로 현재 대부분의 브라우저에서 동작한다. 화려한 사용자 인터페이스를 구현하고, 액션스크립트(ActionScript)를 이용하여 비즈니스 로직을 구성할 수 있다.
  • 플렉스(Flex): Adobe가 소개한 엔터프라이즈 개발을 위한 플랫폼으로 플래시의 SWF로 그 결과물을 출력하나 플래시와는 완전히 다른 새로운 기술이다.
  • 오픈라즐로(OpenLaszlo): Laszlo System에 의해 시작된 오픈소스 플랫폼으로 RIA 구현을 위해 사용할 수 있으며, LZX라는 새로운 인터페이스 언어를 사용한다. 그 결과물은 플래시 플레이어에서 동작하는 SWF 파일로 출력된다.
  • WPF: Microsoft에서 새롭게 소개하는 차세대 벡터 방식의 그래픽 환경으로WPF/E를 활용하여 RIA를 구현할 수 있으며, XAML과 Jscript의 기반한 프로그래밍 모델을 가진다. 
  • XUL: XML 기반의 사용자 인터페이스 마크업 언어(User Interface Markup Language)로 모질라(Mozilla) 기반의 웹 브라우저에서 HTML/XHTML을 대신하여 사용할 수 있다. 
  • 액티브X(ActiveX): 윈도우 응용 프로그램을 웹 페이지상에 실행할 수 있는 기술로 마이크로소프트에 의해 소개되었다. 인터넷 익스플로러(IE)에만 동작하는 단점을 가지고 있다. 또한 다른 방식의 RIA 구현과는 다르게 일반적으로 클라이언트에 설치되어 실행하기 위해서는 공인 인증서를 발급(유료)받아야 하는 번거로움이 있다. 물론 브라우저 설정에 따라 이런 과정 없이 설치 및 실행할 수 있으나 클라이언트의 자원을 제어할 수 있는 보안의 취약성이 큰 문제를 발생하기도 한다. 
  • 스마트클라이언트(SmartClient): Microsoft의 닷넷(.NET) 기반의 윈도우 프로그램을 웹 상에서 실행할 수 있는 기술이다. 보안설정과 클라이언트에 닷넷 프레임워크의 설치가 필수이다. 
  • 자바 애플릿(Java applet): 자바 응용 프로그램을 웹 페이지 상에서 실행할 수 있는 기술로 오래 전부터 사용되었다. 다양한 클라이언트의 제어를 할 수 있는 장점에도 불구하고, 느린 속도와 대체 가능한 기술들에 의해 그 사용이 점점 줄어들고 있는 상황이다. 
  • 자바 응용프로그램(Java application): 자바 웹 스타트(Java Web Start)는 자바 응용 프로그램 자체를 웹을 통해 클라이언트에서 실행할 수 있도록 허용한다. 웹을 통해 자바 응용 프로그램을 실행하는 방식으로 RIA를 구현할 수 있다.
이들 중 현재 주류를 이루는 RIA 기술로는 HTML 기반의 RIA 구현에 주로 사용하고 있는 AJAX/DHTML과 화려한 사용자 인터페이스를 구현할 수 있는 플래시가 있다. 새로운 RIA 시장을 선도하기 위해 경쟁적으로 펼치고 있는 새로운 개발 툴의 출시는 정말 흥미진진하게 보인다. 어떤 RIA 기술이 일반 사용자들에게 매력을 줄 것인지, 어떤 개발 툴이 가장 많이 선택 받을지 관심을 가지고 지켜보도록 하자.

RIA(Rich Internet Application)란?
Rich Internet Application(RIA)이란 전통적인 데스크톱 응용 프로그램의 특징과 기능을 가지는 웹 응용 프로그램이다. 웹 응용 프로그램의 많은 장점에도 불구하고 웹 초창기부터 서버/클라이언트 환경의 윈도우 프로그램에 비해 사용자 인터페이스가 부족하다고 지적되어왔다. 이런 단점을 극복하기 위해 Macromedia(현재 Adobe)는 2002년 리치 인터넷 애플리케이션(RIA)을 처음으로 소개하였다.
RIA를 한 마디로 표현한다면 ‘한 페이지로 구현된 웹 응용 프로그램’이라 할 수 있다. 실제 많은 비즈니스 로직이 존재하지만 사용자는 한 페이지를 이용하여 모든 기능을 이용하게 된다. 일반적인 웹 페이지의 페이지 이동과 새로 고침의 깜박임 없이 모든 내용의 확인과 기능을 이용할 수 있는 RIA. 매력적이지 않은가?

왜 RIA인가?
그러면 RIA를 왜 사용하는 것일까? 그 첫 번째로 우리는 웹 응용 프로그램이 가지는 한계점에 대해서 먼저 이해해야 한다. 전통적인 웹 응용 프로그램의 모델은 서버를 중심으로 모든 처리가 수행되고, 사용자의 웹 브라우저를 통해 그 결과를 출력하는 구조로 이루어진다. 우리는 이를 씬 클라이언트(thin client)라 부른다. 즉 클라이언트는 단순히 결과의 디스플레이에만 사용하는 것이다. 그렇기 때문에 서버에서 많은 작업 프로세스가 있는 경우 사용자는 결과가 처리될 때 무작정 기다려야만 하고, 서버의 처리시간이 길어지는 경우 서버와의 통신이 끊어져 더 이상 프로그램을 이용할 수 없는 상황이 발생할 수 있다. 이런 단점을 보안하고, 사용자 인터페이스를 향상하기 위한 시도가 바로 RIA인 것이다.
그렇다면 RIA를 사용하여 얻을 수 있는 장점이 과연 무엇일까?
대표적으로 리치(rich)한 클라이언트 사용자 인터페이스 제공이 있다. RIA 방식으로 구현하면 사용자에게 HTML 위젯(widget)을 사용하는 효과 이상의 보다 그래픽적인 사용자 인터페이스를 공급할 수 있다. 예를 들어, 웹 페이지에서 드래그 & 드롭(drag & drop)이 가능하고, 슬라이드 바를 이용하여 데이터 변경이 가능하게 된다. 또한 클라이언트에 비즈니스 로직 부분을 구현하여 복잡한 계산을 서버가 아닌 클라이언트에서 수행할 수 있다. 그렇기 때문에 일반적으로 보다 향상된 서버의 응답을 구현.할 수 있는 것이다.
이처럼 RIA를 사용하면 사용자 인터페이스의 향상뿐만 아니라 성능 향상의 장점을 가질 수 있다. 즉 RIA에서는 서버와 클라이언트 사이의 부하의 분산이 가능하게 되어 서버의 성능 향상에 도움을 주는 것이다. 또한 비동기 통신(asynchronous communication)을 이용하여 사용자에게 보다 빠른 응답속도를 보이는 것처럼 구현할 수 있다. 사용자가 클릭 하였을 때 그 결과를 미리 비동기 통신으로 저장한 뒤 바로 보여줄 수 있으므로 사용자가 느끼는 체감 속도는 상당히 빨라지고, 서버의 응답 이전에 다른 작업을 수행할 수 있다. 이는 구글 맵(Google Maps)에서 쉽게 확인할 수 있는 방식으로 사용자가 지도를 드래그하면 바로 처리가 되는 것을 확인할 수 있다. 


[구글 맵 서비스 (http://maps.google.com/)]

마지막으로 네트워크 효율성이 있다. 전통적인 웹 응용 프로그램의 방식은 새로운 결과를 표현하기 위해 전체 페이지의 정보를 전달하고 그 결과를 클라이언트에 다시 보여준다. 하지만 RIA 방식을 이용하면 해당 페이지에서 실제 필요한 일부분의 데이터만 서버로 전달하고, 그 결과를 클라이언트 페이지의 일부 영역에 반영할 수 있기 때문에 네트워크 자원의 사용량도 감소하는 것이다.
더불어 RIA 방식은 초기 프로그램 구동에 시간이 소요된다는 단점이 있지만, 반면에 프로그램 설치가 필요 없다는 장점을 갖고 있다. 그렇기 때문에 사용자들은 어디에서나 쉽게 사용할 수 있고, 프로그램의 버전이 올라가더라도 쉽게 배포할 수 있는 것이다.
이처럼 RIA는 사용자 인터페이스 개선 및 성능 향상이라는 두 마리의 토끼를 잡을 수 있는 현재 진행형의 기술이다. 물론 개발의 난이도가 높아지는 문제가 있지만 사용자들은 이런 개발자들의 고충은 모른다. 자신들이 사용하기 쉽고, 매력적인 프로그램을 선택할 것은 뻔한 이야기라는 것이다. 

RIA의 역사
RIA는 2002년 Macromedia에 의해 소개되었지만 개념적으로 유사한 내용들은 이전에도 있었다. 1998년 Microsoft는 Remote Scripting을 소개하였고, 2000년 Forrester Research는 X Internet을 소개하였다. 더불어 리치 클라이언트, 리치 웹 클라이언트 또한 RIA와 유사한 기술적인 분류로 이야기할 수 있다.
그러던 중 2002년에야 비로서 RIA의 실제 적용사례가 소개된다. 앞서 이야기한 플래시와 콜드퓨전(CFML)을 이용한 TravelClick의 Broadmoor 호텔의 OneScreen이라는 예약 시스템이었다.
2004년에는 Macromedia는 플렉스를 엔터프라이즈 개발자를 위한 새로운 플랫폼으로 소개하였다. 기존 플래시가 가졌던 단점을 해결하고 새로운 RIA 개발 환경을 위해 새로운 서버 제품으로 출시하였다. 현재 2.0 버전까지 출시되었으며, 국내외 여러 적용 사례들이 있다.
이러던 중 RIA는 2005년 구글에 의해 사용자들에게 강렬한 인상을 남기게 된다. 바로 구글 맵(http://maps.google.com) 서비스를 통해 웹 지도에서 드래그, 줌 인/줌 아웃이 구현하였고, 부드러운 화면 전환 및 스크롤을 제공하였다. 이는 마치 윈도우 프로그램을 사용하고 있다는 착각을 가지게 한 아주 충격적인 사건이었다.
이후 웹 2.0에 대한 소개와 실제 구현 사례들을 통해 RIA는 웹 비즈니스의 중요한 요소로 성장하였다. ‘사용자의 눈을 만족시키지 못하는 서비스는 성공하기 힘들다’는 이야기처럼 지금도 사용자들에게 새로운 모습을 보여주기 위하여 여러 웹 사이트들이 RIA를 채택하고 발전을 위한 노력을 계속하고 있는 것이다.
도스 환경에서 윈도우 프로그램을 처음 사용하였을 때의 GUI 변화에 대한 충격을 기억하는가? 내년에는 윈도우 XP에서 윈도우 Vista로의 새로운 GUI 환경 변화가 우리를 기다리고 있다. 또 얼마나 많은 충격과 변화가 일어날지 아직까지는 느낄 수 없을 것이다. 하지만 분명 변화는 이미 시작되었다는 것이다.
사용자에게 보다 멋진 GUI 환경을 제공하려는 시도는 운영체제, 웹의 구분 없이 계속 될 것이다. 이와 함께 사용자 경험에 밀접한 관계가 있는 RIA는 향후 웹 비즈니스 구현에 가장 중요한 기술로 거듭 자리매김을 할 것이다. 지금의 RIA는 과도기의 모습이다. AJAX와 같은 기술은 잠시 스쳐 지나가는 하나의 흐름일 뿐이다. 앞으로 웹 환경은 벡터 그래픽 환경이 기본이 되고, 3D를 이용한 실제 체험이 가능한 모습으로 변화할 것으로 필자는 확신한다. 쇼핑몰을 이용하면서 자기의 3D 캐릭터에 직접 옷을 입혀본 뒤 제품 구매를 선택하고, 다양한 각도에서 실제 물건 보듯이 살펴볼 수 있는 서비스가 바로 눈앞에 있는 것이다. 여러분들은 RIA와 웹의 미래 모습이 어떨 것이라 생각하는가?

(작성자: 네오비스)


Posted by SB패밀리

출처 : http://www.datanet.co.kr/market/read.html?cd=3202&N_cate1=2&N_cate2=17&tk=1178598980

 

웹 2.0의 대표 주자, RIA에 ‘관심 집중’

 

생산성·민첩성·의사결정 능력 향상 … ‘보안·관리·확장성’ 유의해야

RIA(Rich Internet Application)는 차세대 웹의 기반을 형성하며, 생산성, 민첩성, 의사결정 능력 및 지원의 편의를 향상시켜 줄 수 있다. 그리고 어도비, 도조 파운데이션 및 구글은 데이터를 보다 효율적으로 지원하는 데 있어 각자 다른 방식으로 접근하고 있다. 이들에 대해 알아야 할 것들을 정리해 보았다.


웹2.0에는 수많은 차세대 인터넷 기술들이 포함돼 있다. 그리고 그 가운데서도 보다 두드러지는 개념으로 RIA(Rich Internet Application)가 있다. 적절히 이행되기만 하면 RIA는 캐싱에 의해 제공되는 효율성을 넘어 웹 브라우저가 웹 서버와 보다 동등한 파트너가 될 수 있게 해준다.
사용자는 서버에 의해 데이터 페이지 전체가 전송이 되고, 브라우저에 의해 디스플레이되기를 기다릴 필요가 없다. 대신 데이터는 필요에 따라 검색 및 디스플레이된다. 웹 브라우저 이용은 이제 데스크톱 애플리케이션을 사용하는 것과 보다 비슷해졌다. 기업에서 RIA는 보다 확실하고 응답성이 뛰어난 인터페이스로 인한 생산성 향상 등 많은 혜택을 약속하고 있다.
하지만 RIA는 덕트 테이프와 달리 어두운 면도 갖고 있는데, 바로 RIA의 성공을 가로막고 있는 보안, 관리 및 확장성 문제다. 데이터를 공급하기 위해 서버가 더 부지런히 돌아가기 때문에 메시징과 자원에서 오버헤드가 늘어날 것이다. 또한 웹 서버로 더 많은 접속이 필요하기 때문에 로딩 문제가 야기될 수도 있다.
RIA 프로젝트가 성공하기 위해 처리돼야 할 브라우저들간의 차이도 많으며 이들은 알아차리기 힘든 경우도 많다. 다행히도 어도비, 도조 파운데이션 및 구글 등 업체들이 이러한 부담을 덜어주기 위한 제품을 내놓고 있는데, 이들이 문제에 접근하는 방식은 각자 다르다.
구시대 인터넷에서는 웹 서핑이 대부분 웹 브라우저와 서버간을 오가는 간단한 춤추기 정도였다. 일반적으로 브라우저가 서버로 요청을 하면 서버가 자원을 모으고, 데이터를 조작하고, 텍스트를 포맷팅하고, 이미지를 로딩해서, 최종적으로 결과물을 브라우저로 보내며, 그러면 브라우저는 이것을 보여주기 위해 렌더링될 수 있었다.

과거와 현재
사용자는 가끔씩 무료함을 달래기 위해 쓸데없이 마우스에 놓인 손가락을 퉁기며 인내심을 갖고 기다린다. 그러다 결국 사용자는 어떤 항목이나 링크가 새로 고침이 필요하다고 판단하기도 한다. 이럴 때는 브라우저가 다시 요청을 포맷해서 이것을 서버로 보낸다. 그리고 서버는 또 다시 자원을 모으고, 데이터를 조작하고, 텍스트를 포맷하고, 이미지를 로딩한 다음 그 결과를 전송한다. 그리고 역시 사용자도 다시 앉아서 기다린다. 이러한 ‘페이지별’ 브라우징 모델은 많은 인터넷 사이트에 최적화된 그래픽(어떤 사람들은 이것을 사라진 예술이라고도 한다), 간단한 데이터, 그리고 정적 HTML 콘텐츠가 포함됐던 시절에는 잘 통했으며, 최소한 견딜만 했다.
하지만 웹 페이지가 복잡해지고 데이터 전송량이 늘어나면서, 사용자들은 과도한 대기시간에 참을성을 잃어가고 있다. 광대역조차 이러한 고통을 덜어주는 데는 역부족이다. 웹 페이지는 하나의 항목이 서버에서 업데이트될 때마다 매번 전체 페이지가 갱신되도록 하기에는 너무 덩치가 커졌다.
궁극적으로 사용자들이 원하는 것은 데스크톱 애플리케이션과 같은 속도와 응답성, 그리고 느낌을 주는 웹 브라우징 경험이다. 이러한 목표를 달성하기 위한 최초의 노력으로 마이크로소프트의 액티브X, 마이크로미디어(현재는 어도비)의 플래시, 넷스케이프의 라이브커넥트, 자바 애플릿 등이 있었으나 이들은 절반의 성공에 그치고 말았다.
기술과 기법의 통합을 통해 개발자에게는 웹 브라우징 속도를 높이는 데 필요한 몇 가지 툴이 주어졌다. 주로 자바스크립트를 이용한 클라이언트쪽 스크립팅과 DOM(Document Object Model)은 넷스케이프 내비게이터의 초창기 시절부터 브라우저에서 사용돼 온 것들이다. CSS(Cascading Style Sheets)는 이 개발자들에게 웹 페이지를 표현하는 데 대한 훨씬 세부적인 제어 능력을 주고 있다. 이런 기술들에 DHTML(Dynamic HTML)이 결합되면, 웹 페이지는 훨씬 더 생기를 띠며, 사용자 입력에 대한 응답성이 향상된다. 하지만 지금까지는 핵심적인 부분이 빠져 있다.
XML과 XMLHTTRequest 객체의 채택으로, 오늘날 우리가 알고 있는 RIA 개발에 지평이 열렸다. DOM, CSS, HTML 및 자바스크립트 등을 포함한 DHTML에다 XML까지 가세를 하여 표준 에이잭스(Ajax) 툴박스가 구성됐다. 이런 기술들이 함께 모이면 웹 페이지가 한번에 모두가 아니라 섹션별로 업데이트될 수 있다. 다시 말해 개발자는 페이지의 작은 섹션을 바꿀 수 있으며, 그 변화에 필요한 데이터만 웹 서버로 요청할 수가 있다. 더 이상 사용자는 웹 서버에 의해 중복되는 부분이 많은 전체 페이지가 함께 모여서 전송되고, 브라우저에 의해 디스플레이될 때를 필요가 없게 됐다.
RIA가 엔터프라이즈에 의해 채택이 되면, 어떤 개발 방안이 사용돼야 할까? 불행히도 이행안들간에는 호환성이 거의 없기 때문에 하나를 선택하면 오랫동안 그 솔루션만 사용해야 할 것이다. 각 방안의 이점과, 어디서 내 시스템과 맞을지, 얼마나 성숙한지, 그리고 이것이 사용자와 백 오피스에 얼마나 많은 영향을 미치게 될지 등을 고려해야 한다. 분명 서로 다른 툴키트가 같은 개발 환경과 같은 웹 서버에 함께 존재할 수는 있지만, 각각에서 만들어진 코드는 역시 호환되지 않을 것이다.

공통의 라이브러리
지금까지 개발자들의 마음을 사로잡은 방안으로는 세 가지가 있다. 첫 번째는 도조 파운데이션의 도조 툴키트가 대표적이며, 브라우저에 의해 제공되는 툴들, 즉 자바스크립트, DOM, DHTML 및 CSS만 사용한다. 도조 툴킷은 가장 일상적인 웹 개발 툴인 HTML과 자바스크립트를 기반으로 하며, 클라이언트 측 데이터 스토리지와 몇 가지 표준 준수 데이터 전송 메커니즘도 또한 제공하고 있다. 게다가 도조 툴키트는 많은 주요 인터넷 및 엔터프라이즈 업체들의 지지를 받고 있다.
자바스크립트와 HTML을 이용한 개발이기 때문에 결과적으로 브라우저에 의한 변경이 없이 실행되는 코드가 만들어진다. 이러한 방법론은 오픈에이잭스 얼라이언스(OpenAjax Alliance)에서 받아들이고 있는데, 이 동맹의 멤버들로는 BEA시스템즈, 볼랜드소프트웨어, IBM, 라즐로시스템즈, 모질라, 노벨, 오라클, SAP 등이 있다. 이 집단은 상호운용이 가능한 에이잭스 기술의 채택을 장려하기 위해 만들어졌다. 공통의 자바스크립트 라이브러리 세트에 대한 주장이 나오고 있기 때문에, 라이브러리가 업체 전용성과 이행의 전용성을 벗어남에 따라 에이잭스 개발도 활기를 띠게 될 것으로 기대된다. 도조 파운데이션은 오픈에이잭스 얼라이언스의 일원으로서 대표적인 툴키트를 이행하고 있다.
도조 툴킷은 브라우저의 기능성과 개발 니즈를 중심으로 한 자바스크립트 라이브러리로 구성돼 있다. 라이브러리에는 기본적인 필요를 위한 코어 라이브러리와 사용자 인터페이스 엘러먼트, 데이터 인터페이싱, 그래픽, 도표, 국제화, 이벤트 프로세싱 등을 전담하는 추가 라이브러리가 있다. 도조 툴키트는 표준 HTML에 대한 익스텐션인 도조ML을 사용하는데, 이것은 자바스크립트 라이브러리가, 그리고 익스텐션에 따라 개발자가 조작할 수 있는 위젯을 규정한다.
도조 툴키트는 비교적 간편하게 사용할 수 있다. 원하는 자바스크립트 라이브러리는 태그를 이용해 웹 페이지에 추가되며, 필요에 따라 도조ML이 삽입된다. 이 단계까지만 가도 많은 기능성을 사용할 수 있다. 그리고 개발자는 데이터 검색 및 조작이나 사용자 입력 프로세싱 같은 특수 기능을 수행하기 위해 자바스크립트 코드를 추가할 수 있다. 개발이 완료되면 그 결과물인 라이브러리와 HTML이 최종 애플리케이션의 일부로 배포가 된다.
개발을 한층 수월하게 하기 위해 이클립스(Eclipse) 같이 기존의 환경에 맞는 플러그인이나 몇 가지 IDE(Integrated Development Environment)가 만들어졌다. 여기서 언급된 모든 툴키트는 간단한 문서 편집기를 이용해 코딩이 가능하지만, 현명한 개발자라면 정지점(breakpoints), 변수 주시(variable watching), 스택 추적(stack trace) 같은 수법을 이용해 코드를 만들 것이다.
원격 데이터 접속은 XML 오버 HTTP를, 혹은 RPC 요청으로 이뤄진다. 로컬에서 툴키트는 사용자가 플래시 셰어드오브젝트(Flash SharedObjects) 코드나 파이어폭스용 왓 WG 스토리지 프로바이더(WHAT WG Stroage Provider for Firefox)를 이용해 데이터를 저장할 수 있게 해준다. 로컬 데이터 스토리지는 비록 RIA 패러다임에 속하지는 않지만 로컬 구성 설정, 서버로부터 대신해서 다시 로딩될 객체 카피들, 그리고 문서나 이미지 같은사용자 전용 데이터 등을 저장하는 데 유용하다.

선택의 언어
두 번째 RIA 방안은 GWT(Google Web Toolkit)로 대표되는 것으로 자바 지식을 활용하며, RIA가 자바스크립트와 HTML을 이용해 배치되는 동안 개발자가 자바로 코딩을 할 수 있게 해준다. 코딩은 구글이 제공하는 특수 툴을 이용해 보다 쉽게 이뤄질 수 있다. GWT는 보다 편리한 애플리케이션 유니트 테스팅을 위해 자바 기반의 제이유니트(JUnit) 테스트 프레임워크를 통합시켰다. 하지만 데이터 전송은 RPC와 JSON으로 제한되며, 로컬 데이터 스토리지도 전혀 사용할 수 없다.
GWT에서도 자바스크립트는 역시 DOM, DHTML 및 CSS에 연관된 호출을 이용해 브라우저에서 실행되지만, RIA를 만드는 데 사용되는 툴은 자바스크립트 라이브러리가 아니다. 여기서는 RIA 저작에 다른 언어로 다른 툴세트가 사용되고 있다. 어떤 경우에는 선택의 언어가 자바가 될 수도 있고, ASP.NET이 되는 경우도 있다. 툴세트가 무엇이든 관계없이 코드는 자바스크립트로 컴파일링이 되며, 이것이 클라이언트로 배포돼 실행된다.
GWT로 작업하는 RIA 개발자들은 자바 언어의 서브세트를 이용해 브라우저 인터페이스 엘러먼트를 만들고, 데이터 요청을 처리하며, 이벤트를 다룬다. 구글은 또한 사용자 인터페이스 엘러먼트를 만드는 데 쓸 수 있는 위젯 세트도 제공하고 있다. 특수 브라우저가 JRE(Jaa Runtime Environment)에서 자바 코드를 실행하기 때문에 간단한 디버깅과 테스팅이 가능하다.
IDE를 이용하자(우리는 이클립스를 사용했다) 개발 속도가 빨라지고 훨씬 편리해졌다. 제이유니트도 또한 코드기반에 포함돼 있어 코스 테스팅 및 디버깅이 향상된다. 코딩이 완료됐을 때, 혹은 원하는 때 언제든 포함된 컴파일러를 통해 소스 자바가 실행될 수 있기 때문에 자바를 자바스크립트나 HTML로 전환할 수 있다.
한 가지 주의의 말을 덧붙이자면, 구글이 많은 코어 자바 라이브러리를 복제하긴 했지만 아직 남은 게 많다는 것이다. java.lang과 java.util 패키지는 표준 자바 라이브러리와 거의 완벽하게 호환이 된다. 하지만 다른 자바 클래스들은 컴파일러에 의해 번역이 되지 않을 수 있으며, 따라서 RIA를 만들 때 사용돼서는 안 된다.
GWT 웹 페이지를 보면 어떤 클래스가 번역이 가능한지, 그리고 어떤 것을 피해야 하는지에 대해 상세히 나와 있다. 포함된 자바 클래스에서 필요한 기능성을 제공하지 않을 경우, 개발자는 개발 과정에서 자바 코드에 자바스크립트가 포함될 수 있게 해주는 기법인 JSNI(JavaScript Native Interface)를 활용할 수 있다.
자바스크립트는 개발 과정에서 자바 코드와, 그리고 컴파일링될 때 결과물인 자바스크립트 코드와 상호작동할 수 있기 때문에, 기능을 불러오고 예외적인 것들을 버린다. 하지만 이것은 신중하게 사용돼야 한다. 결과물 코드는 브라우저들간에 이식성이 떨어지는 경우가 많고, 메모리 노출을 발생시킬 수 있으며, 컴파일러가 최적화하기에 힘이 들기 때문이다.
GWT는 JSON(JavaScript Object Notation)과 (JSNI를 통해) RPC 데이터 접속을 제공한다. 개발 작업을 단순화시키고, 실행 속도를 높이기 위해 생성되는 데이터 접속의 수는 낮게 유지된다. 웹 서비스로 액세스를 제공하는 방법이 제공되거나, 직접 코딩할 수도 있다.

플렉스 툴킷
세 번째 방안은 어도비에서 앞장서고 있는 것으로 CSS, DOM, DHTML 및 자바스크립트가 전혀 필요 없다. 어도비의 플렉스 툴킷은 플래시 객체를 만들며, 이 객체가 RIA를 봉입(encapsulate)한다. 개발은 액션스크립트(ActionScript)와 특수 마크업(markup) 코드를 이용해 이루어지며, 데이터 액세스는 전용을 포함한 많은 메쏘드를 통해 제공이 된다.
배치가 완료되면 코드는 브라우저 안에서 실행되는 바이트 코드로 컴파일링되며, 이는 CSS, DHTML 및 DOM에 매우 독립적이다. 이러한 방식은 ‘순수’ 에이잭스로부터는 가장 멀리 일탈된 것이지만, RIA 범주 안에는 해당이 된다.
어도비는 최근의 매크로미디어(Macromedia) 인수에서 얻은 기술을 기반으로, 플렉스 툴키트를 발표했다. 이 키트에서 개발자는 액션스크립트, ECMA 스키립트 준수 언어, 그리고 XML 기반의 마크업 언어인 MXML을 이용해 코딩해야 한다. 코딩은 명령어 라인에서, 혹은 다른 툴키트에서 우리가 선호했던 것처럼 IDE(그렇다. 여기서도 이클립스다)에서 수행될 수 있으며, 결과물 코드는 플래시 객체로 컴파일링 및 변환된다. 그러면 이 플래시 객체는 RIA로서 웹 플래시 객체로 배포가 된다.
이 객체는 모든 플래시 콘텐츠와 마찬가지로 웹 브라우저에 의해 호스팅되는 플레시 플레이어(Flash Player) 안에서 실행이 된다. 사용자 인터페이스 엘러먼트, 그래픽, 이미지 프로세싱, 이벤트 처리 및 다른 대부분의 작업들이 플래시 플레이어에 의해 처리된다. 플래시 플레이어는 거의 모든 웹 브라우저용으로 사용 가능하기 때문에 RIA 배포는 대부분의 경우 브라우저의 종류나 버전에 방해받지 않는다.
이것은 자바스크립트 기반의 RIA용으로는 문제가 될 수도 있겠지만, 자바스크립트가 성숙해지고 업체들이 웹 표준을 보다 완벽히 준수함에 따라 자바 스크립트를 사용해 실행되는 RIA와 플래시를 사용해 실행되는 RIA들간의 실질적인 차이는 거의 사라질 것으로 기대된다.
배치를 간소화하고 유니트 테스팅 자동화를 도모하기 위해, 제이유니트를 본떠 만든 테스팅 프레임워크인 플렉스 유니트(Flex Unit)를 포함시켰다.
플렉스 툴키트는 데이터 접속용으로 가장 많은 옵션을 제공하고 있다. 표준 플렉스 툴키트는 다른 툴키트와 유사한 데이터 전송 방식을 제공하긴 하지만, 별도 가격을 붙여 어도비에서는 플렉스 데이터 서비스(Flex Data Services) 2 애플리케이션을 판매하고 있다. 이 패키지는 자바 EE 애플리케이션 서버에 놓이며, 원격 객체(액션 메시지 포맷), MS, 혹은 플래시 플레이어에 의해 지원되는 맞춤 프로토콜인 RTMP(RealTime Message Protocol)를 이용해 플렉스로 데이터를 공급한다.

Posted by SB패밀리