RIA Framework Appcelerator

1. Ria?
a. Rich Internet Application의 약자로 기술이라기 보다는 사용자의 요구가 다양해짐에 따라 좀더 편리한 인터페이스와 서비스를 제공하고자 하는 패러다임에 가깝습니다.
b. 어렵게 설명한 말도 많이 있지만 간단히 이야기하면 전통적인 Desktop application 같은 web application을 의미합니다.

2. Ria Framework?
a. 대표적인 ria framework로는 위에서 보신 macromedia 사의 adobe air , microsoft의 silver light, google의 gwt, java 진영의 javafx가 있습니다. 각각의 특징은 뒤에서 말씀드리겠습니다.

3. 현재 나와있는 RIA 프레임워크는 크게 3가지 방식으로 구분 할수 있는데요
a. html 생성형
i. 프레임워크에서 제공하는 UI 라이브러리를 이용하여 어플리케이션을 작성하면 프레임워크가 제공하는 자바 스크립트 컴파일러가 컴파일하여 response에 코드를 담아서 보내주는 형태를 제공합니다.
ii. 장점 :
1) swing 과같이 어플리케이션을 만드는 컴포넌트들을 제공하고 그것을 이용해 어플리케이션을 작성하듯이 개발하는 형식으로 이벤트 드리븐 방식의 개발이 가능하게 됩니다.
iii. 단점 :
1) 내부 컴파일러가 스크립트를 생성해서 response write 클라이언트에 직접 뿌려주는 형태가 되기 때문에 개발과 디자인의 분리가 힘들게 되어 결국 개발자가 디자인 요소까지 건드려야 하는 문제점이 있습니다.
2) webwork 나 spring 등의 프레임워크와 통합이 힘들어 현업에 적용이 어려운 문제점이 있습니다.
3) 모든 이벤트 처리를 하기위해서 불필요한 서버와의 통신이 생겨나게 됩니다.
iv. 대표적인 프레임워크로는 Gwt(구글)가 있습니다.
b. plugin 형태
i. 프레임워크가 제공하는 개발킷을 사용하여 어플리케이션을 개발하고 클라이언트에서 요청이 올시 클라이언트 측에 해당 플러그인이 설치 되어있다면 플러그인을 통해서 브라우저에 보여주게 되는 형태를 제공합니다. 쉬운 예로 Adobe Flash를 들 수 있습니다.
ii. 장점 :
1) 플러그인을 사용하기 때문에 실제 데스크탑 어플리케이션처럼 개발이 가능하다.
2) 대용량 데이터 처리에 유리
3) 풍부한 위젯, 컴포넌트 라이브러리 (모두 대형밴더)
4) 위에 나온 3가지 모두 웹 -> 데스크탑 크로스 플랫폼 지원
iii. 단점 :
1) 결국에는 플러그인이 설치하여야 한다는점
2) 플러그인은 웹 브라우저, 플랫폼 dependency 가 존재할 수 밖에 없음
3) 초기 로딩 비용이 크다.
4) 유명 대형 밴더만 가능한 시스템 임 --;
iv. 대표 프레임워크 주소
1) Adobe air : http://www.scrapblog.com/builder/?isLoged=false
2) JavaFx : http://javafx.com/
3) Silverlight : http://www.defiwind.com/

c. Message 통신 형태
i. 기존 ajax 통신 방식을 사용하면서 server단과 client단사이의 메시지 프로토콜역할을 프레임워크가 해줌으로써 개발자는 편리하게 사용할 수 있게 해주는 형태로 좀더 편리한 RIA 구축이 가능하도록 서포트 해주는 형태이나 최근 위젯이나 이벤트드리븐개발 형식까지 지원해주는 프레임워크가 많이 출시 되어있다.
ii. 장점 :
1) 기존의 현업에서 사용중인 자바 웹 어플리케이션 개발 방식을 크게 벗어나지 않는 형태로 적용하기 쉽다.
2) 이벤트 드리븐 개발 방식 + 웹 어플리케이션 개발 방식 모두 사용이 가능하다.
3) 디자인작업과 비즈니스 로직작업의 분리가 용이하다.
4) 클라이언트단의 프레임워크만 분리하여 독립적으로 사용이 가능하다.
5) 필요요소 추가 및 불필요한 요소 삭제로 기능 추가및 퍼포먼스 튜닝이 가능하다.
6) 스프링 웹워크 스트러츠 등과 연동이 쉬운 형태이다.
iii. 단점 :
1) 초기 스크립트 파일 로딩이 코스트가 존재한다.
2) 스크립트에 의해 클라이언트에서 다시 컴파일되어 보여주는 형태로 스크립트 튜닝이 필요하다.
3) 대부분 자바스크립트 프레임워크로 구성되어있어 디버깅을 지원하지 않는이상 디버그가 힘들다.

d. RIA 비교
i. 개발 속도는 데스크탑 어플리케이션 gui 개발 지원툴이 존재하지 않는한 gui 방식의 개발은 느릴수 밖에 없습니다. 플러그인 방식은 데스크 탑 어플리케이션 개발용 통합툴이 잘 되어있어서 편리하구요 메시지 통신 방식은 기존의 방식을 그대로 따르나 스크립트 코딩이나 ajax 관련 변환작업이 없어서 개발 속도가 빠릅니다.
ii. 단위테스트는 Gwt 나 Echo의 경우 스크립트 생성 형태이기 때문에 클래스 혹은 메소드 단위테스트가 힘듭니다 반면에 에어나 실버라이트 자바 에프엑스의 경우 각각 ide 툴에서 단위테스트를 지원합니다. Appcelerator 와 wicket 은 POJO 기반이므로 클래스 단위 메소드 단위 테스트가 가능합니다.
iii. 디버깅은 GWT는 디버깅 툴을 자체 통합 개발툴에서 제공하므로 용이한 편이나 에코의 경우에는 그런 툴이 존재하지 않아 디버깅이 어렵습니다. 에어나 실버라이트 자바에프엑스의 경우는 각각 밴더가 개발한 디버거들이 존재하여 디버깅이 용이합니다. Appcelerator는 서버단은 물론 디버깅용 자바스크립트를 제공하므로 편리한편입니다 반면 wicket의 경우에는 디버깅용 자바 스크립트가 없어 불편한점이 있습니다.
iv. 모델 뷰 방식의 개발 가능성부분인데요 gwt 나 에코는 개발자가 레이아웃 버튼 등 전부 서버단에서 개발해야하므로 디자인 분리가 힘듭니다 에어나 실버라이트 자바 에프엑스 역시 iframe 형태로 개발하거나 전체 화면을 해당 프레임워크로 개발하지 않는 이상 어렵습니다. 반면 appcererator 나 wicket의 경우 둘 모두 을 그대로 사용하거나 각 태그 사이에 스크립트나 HTML이 생성되는 형태이기 때문에 디자인과 비즈니스 로직의 분리가 쉽습니다.
v. 성능인데요 GWT , ECHO의 경우 불필요한 요청이 서버로 많이 유입되고 자바스크립트를 생성하는 형태로 서버부하가 큰편입니다. 플러그인의 경우에는 셋모두 첫 로딩이 길지만 이후에는 빠른 동작을 보여줍니다. App. 나 wicket 은 메시지만으로 통신하므로 빠르나 프레임워크 스크립트 양이 많아서 첫로딩에 시간이 좀 걸릴수 있습니다.
vi. 플랫폼 독립성 입니다. 플러그인을 제외하고는 브라우저나 운영체제같은 플랫폼의 영향을 거의 받지 않습니다.
vii. 설치가 필요한가 그렇지 않은가 인데요 마찬가지로 플러그인 형태를 제외하면 설치는 필요없습니다. 다만 adobe air 의경우에는 전세계 데스크 톱의 97%가 플래시가 설치되어있다고 하니 설치 필요정도가 작아지는 잇점이 있습니다만 아이폰이나 기타 모바일 기기등을 제외한 수치이므로 강점이라고 보기 힘듭니다.
viii. 유연성 html 제너레이터 형식의 프레임워크는 제공하는 gui 라이브러리를 사용해야 하므로 코드 변경이나 퍼포먼트 튜닝등이 힘듭니다 플러그인형태 역시 그렇구요 다만 메시지 기만의 경우 appcelerator 는 완전히 html 형태이기 때문에 유연하지만 위켓의 경우 레이어에 html 을 채워 넣는 형태이기때문에 유연성이 조금 떨어지는 점이 있습니다. 뿐만 아니라 자바스크립트 변경이나 메시지 핸들러의 변경이 용이합니다.


4. 그럼 Appcelerator 란 무엇인가?
a. 메시지 방식 프레임워크입니다.
b. 서버단 컴파일러등이 없이 단순 메시지만 처리하기 때문에 가볍고 기존 개발방식을 따르기 때문에 빠르고 쉽습니다.
c. 스크립트 컴파일러를 이용한 이벤트 드리븐 개발 방식을 지원하기 때문에 자바스크립트가 필요없습니다.
d. 서버단 개발역시 POJO 와 어노테이션 기반으로 개발하게 되어있어 쉽습니다.
e. 많은 종류의 위젯을 제공하며 직접 위젯 빌더를 제공하여 직접 위젯을 만들어 사용할 수도 있습니다.
f. 기존 서비스와 통합하여 사용이 쉽습니다.


5. Appcelerator 구조 입니다.
a. 메시지 브로커 와 서비스 브로커가 있습니다.
b. 메시지 브로커는 클라이언트단 이벤트 핸들러 역할과 서비스 브로커에 메시지를 전달하는 역할을 하고요 서비스 브로커는 클러이언트에서 넘어온 데이터를 루시의 params 를 이용하는 것처럼 처리할 수 있도록 해줍니다.
c. 디펜던시입니다. 클라이언트 사이드에서는 app 의 커스텀 태그들을 빌드해주는 빌더가 있구요 여러가지 사용할 수 있는 위젯들도 위젯들은 ext scriptaculous 자바 스크립트로 만들어져서 제공됩니다. 앞에서 말씀드린 메시지 브로커도 있구요 prototype 의 Json 을 이용하며 메시지를 전달합니다.
d. 서버사이드에서는 서비스 브로커만 존재합니다. Json lib를 이용하여 메시지 브로커와 연동하고 app. 에서 제공하는 서블릿으로 어너테이션으로 선언된 메소드를 호출해 줍니다
e. 이그림은 동작 방식을 보여줍니다. 첫번째 그림은 클라이언트 단의 메시지 전달 방식을 보여주는데 click then … 은 app 의 문법인데 자바스크립트에 의해서 이벤트 처리 함수로 빌드 됩니다. 클릭시 클라이언트 내에서 이벤트를 일으키는 동작을합니다. l:,, 의경우 해당 이벤트 리스너 역할을 하여 동작을 하게됩니다.
f. 두번째 그림은 서버로 요청을 하는 과정을 보여줍니다. R 은 리모트를 의미하구요 이벤트를 받으면 메시지 브로커가 서비스 브로커에게 전달하고 처리후 서비스 브로커가 메시지 브로커에게 전달하면 이벤트를 발생시키고 그 이벤트 리스너가 동작을 하게 되는 형태입니다.

6. Appcelerator 어떻게 개발하는 예제를 보여드리겠습니다.
<textarea id="my_comment" fieldset="my_form">
</textarea>
<input type="button" value="click me" on="click then r:test.message.request" fieldset="my_form" />
<div style="display: none;background-color: #ccc;padding:5px; width: 30% " on="r:test.message.response then effect[Appear] and value[comment]" />
</div>

@Service(request = "test.message.request", response = "test.message.response")
protected void simpleTest(Message request, Message response)
throws Exception {
response.getData().put("comment",
"You said " + request.getData().getString("my_comment"));
}

rich_internet_application-justis1.pptx