2011년 5월 23일 월요일

Direct Ajax - Goodbye to Ajax Deadly Sins


원문 : http://www.theserverside.com/tt/articles/article.tss?l=DirectAjax

Rich Internet Application의 대죄!

Robbie Cheng의 친구가 Ajax Application을 개발하는데 3개월 계획했지만 Ajax의 대죄(大罪) - Rich Internet Application의 큰 문제 -로 6개월이 걸렸다.
  • 브라우저 호환성 - 그는 UI 위한 JavaScript 개발을 결정하였고 초안을 2개월에 걸처 완성하였다. 하지만 다른 브라우저에서 화면 layout이 엉키는 문제를 발견한다. JavaScript에 대한 충분한 지식이 없었기 때문에 이 문제를 해결하기 위해 Ajax Widget Framework 도입을 결정하고 UI 재개발에 들어간다.
  • 장황한 클라이언트와 서버간 통신 코드 - 그의 팀이 JavaScript의 문제를 해결했을 때 쯤, UI와 Server 사이 즉 JavaScrip Framewok의 RPC 호출에서 서버에서 가저온 데이터를 수동적으로 핸들링해줘야 하는 문제로 클라이언트와 서버사이의 통신에 많은 파일이 제작되었다. 순수 자바로 개발하였지만, 그의 팀은 통합을 끝내는 몇 달간 그일에 매달렸고 점점 지쳐갔다.
  • 느린 성능 - 통합이 끝나고 사용자 테스트를 하는 동안, 성능은 납득할 수 없을 정도였다. 사용자는 10000 레코드를 보기 위해 10초 이상을 기다려야 했다. 심지어 구형 컴퓨터에서는 말도 할수 없는 상황이었다. 불행하게도 사용자는 성능 향상을 원했고, 성능 향상 방법은 요원하기만 했다. 클라이언트의 가시적인 영역에서 브라우저 랜더링시에 서버에 요청할 필수 Data 결정이 필요하였고 성능 문제를 해결하기 위해 그 팀은 몇 개월의 추가 작업이 해야만 했다.
  • 유지보수의 골치거리 - 프로젝트가 끝날 때 즘, 고객에은 UI에 보여질 Data가 추가 원했고, back-end code을 수정할수 없었던 그의 팀은 다시 악몽에 빠져들었다. 클라이언트와 서버 코드 사이의 비즈니스 로직의 일관성을 유지하기위해 그 팀은 또 한달 간의 시간을 보내야 했다.

Trouble Maker : Primitive Programming Model
위와 같은 문제의 대부분은 UI와 Back-end을 분리하는 Two-side Programming Model에서 발생한다.

Two-Side Programming Model은 개발자가 주의해야할 많은 문제가 있다.
  • 브라우저 호환성 - 최근 Ajax Framework에 의해 어느정도 해결된 문제
  • 클라이언트 서버간 통신 - 서버로 부터 Data을 받아 클라이언트에 출력
  • 느린 성능 - 개발자들이 클라이언트에 너무 많은 데이터를 넣을려는 경향
  • 클라이언트 비즈니스 로직 요청과 클라이언트 사이의 비즈니스 로직 불일치

이 상적은 Programming Model은 개발자이 고민해야할 많은 일로부터 해방시켜준다. 중요한 것은 UI와 Back-end 어블리케이션을 분리하려 하면 안된다는 것이다. 대신 서버 측이든 클라이언트 측이든 한쪽에서 실행되어야 하며, 개발생산성이나 서버 Resourece 접근을 위해선 서버 측에서만 실행되어야 한다.

개발자는 선택된 프레임워크의 핸들링 작업으로 부터 자유로워야 하며 어플리케이션의 비즈니스 로직에 단순히 집중할수 있어야 한다. 궁극적으로는, Ajax를 사용하는 최선은 방법은 그 존재를 알지 못하는 것이다.
가 장 좋은 Programming Model은 Application이 사용자 인터페이스, 데이터베이스, 모든 종류의 리소스를 직접적으로 접근 할수 있어야 하며 때문에 Direct Ajax라 명명하였다. 이는 개발과 무관한 작업을 없애 개발자가 쉽게 Rich Internet Application을 구축할수 있게 해준다.
Direct Ajax
Direct Programming은 어플리케이션의 UI와 Back-end을 원활하게 통합시켜주고, 클라이언트 컨텐츠의 랜더링을 책임지며, 자동으로 클라이언트와 서버사이를 동기화 시켜준다. Direc Programming은 아래 3가지 기준을 충족해한다.
  • Direct UI Access - 어플리케이션은 직접 UI로 부터 값을 가져오거나 설정 할수 있어야 한다.
  • Direct Database Access - 어플리케이션은 직접 Database에 접근 할수 있어야 한다.
  • Direct Live Data - 개발자들이 View로 부터 Data을 분리할 수 있어야 하고, ListModel 인터페이스를 구현하여 직접적으로 Grid를 다루어 Data을 제공 하여야 한다. Visible한 Data만 클라이언트에 Grid에 출력한다면 Data양이 아주 많아도 네트워크 트래픽을 많이 절약할 수 있다.

위 Direct UI Access, Direct DataBase Access, Direct Live Data면 몇가지 골치거리를 해결할 수 있다.
  • 느린 성능
  • 장황한 서버와 클라이언트 사이의 커뮤니케이션 코드
  • 유지보수의 골치거리

Which framework to use

Ajax Frameworks 비교 Matrix

Direct Ajax를 사용해야만 하는 5가지 이유
  • 개발자 생산성 향상
  • 빠른 프로토타입 생산
  • 쉽고 빠른 습득
  • 안전한 커뮤니케이션
  • 쉬운 유지보수

댓글 없음:

댓글 쓰기

ETL 솔루션 환경

ETL 솔루션 환경 하둡은 대용량 데이터를 값싸고 빠르게 분석할 수 있는 길을 만들어줬다. 통계분석 엔진인 “R”역시 하둡 못지 않게 관심을 받고 있다. 빅데이터 역시 데이터라는 점을 볼때 분산처리와 분석 그 이전에 데이터 품질 등 데이...