2편에 이어...

웹 플랫폼의 확산과 더불와 많은 응용 서비스들이 웹을 기반으로 개발되고 있지만 웹 자체 특히, 웹 브라우져가 갖고 있는 기술적인 한계들로 인해 많은 제약을 받고 있다. 또한 끊임없는 베타 서비스와 무료 서비스에서 벗어나 수익을 창출해야 하는 기로서 있다.

Online-Offline 간의 투명한 통합과 대용량 파일 처리

웹 플랫폼이 안고 있는 가장 큰 문제는 웹 브라우져의 한계이다. 웹 브라우져가 자체가 웹 애플리케이션을 모두 수용하기에는 부족한 점이 많다는 것이다. 실제 모든 웹 브라우져가 OS의 응용 프로그램이기 때문에 내부에서 대용량의 웹 애플리케이션을 수행할 수 없으며 오프라인시 정보를 읽어버리기 일수 있다.

이러한 배경하에서 현재 데스트탑 오피스에 대해 웹 오피스 서비스의 한계로 지적받는 가장 큰 문제가 바로 오프라인 지원과 대용량 파일 처리 문제이다. 현재 웹 오피스 서비스는 오프라인 상태에서는 사용할 수 없으며 대용량 파일도 지원하지 못한다. 따라서 실제 업무에 적용하는 것이 불가능하다고 말할 수 있다. 따라서 현재에는 웹 오피스는 데스크탑 오피스 환경의 보조 역할로 여겨지는 경우가 많다.

사용자 삽입 이미지
그러나 현재 이러한 문제를 해결하기 위해 관련 업체들이 여러 노력을 벌이고 있다. 이중에서 씽크프리는 현재 가장 앞선 기술로 오프라인과 대용량 파일을 지원하고 있다. 씽크프리는 사용자에게 온라인 버전과 오프라인 버전을 모두 제공하며 이들 간에 동기화 서비스를 제공하여 네트웍 환경에 상관없이 두 환경하에서 동일하게 대용량 작업을 할 수 있게 해준다. 가령, 사용자가 문서 편집 작업 중 네트웍이 중단되고 작업을 계속할 수 있으며 이를 동기화 서비스에서 보관한 후 다시 네트웍이 연결되면 이를 웹 오피스에 반영한다.

현재 기반기술로는 WHAT/WG에서 DOM Storage 표준을 만들고 있고 현재 IE , FF , Flash등에서 미약하나마 브라우져에서 오프라인 스토리지를 제공하고 있다.( 오는 29일 2007 Web2.0 Conference 발표에서 이 부분에 대해 설명할 예정입니다.)


SaaS 모델로서의 수익 창출

CRM 분야에서 Salesforce.com이 SaaS(Software As A Service) 모델로 성장을 하면서 서비스 로서의 소프트웨어의 성공이 입증된 이후 여러 분야에서 다양한 SaaS(Software as a Service) 서비스가 출현하였다. 그 중 가장 큰 시장 잠재력을 갖은 것이 웹 오피스 서비스이다. 현재까지 많은 관심을 받고 있지만 실제 관심에서 끝나는 것이 아니라 수익을 창출하면서 기존의 데스크탑 오피스 시장을 온라인 오피스 시장으로 전환할 수 있는 가에 따라 성패가 달려 있다고 말할 수 있다.

본 글들은 소프트웨어진흥원에서 요청한 "웹 오피스의 현황과 미래" 라는 주제의 글에서 일부를 정리해서 소개한 것입니다.



Posted by 박재현

REST Architecture

Architecture 2007.03.25 21:29


                                            REST Architecture

사용자 삽입 이미지
근래 들어 웹 개발 커뮤니티에서 가장 많이 사용하는 용어 중 하나가
REST( Representational State Transfer )
일 것입니다. REST는 많은 웹2.0 회사들이 자신이 개발한 서비스를 외부에 공개하기 위한 Open API의 구현 방법으로 많이 사용되어 있습니다.  실제 구글, 플리커, 아마존 등의 Open API가 REST 방식으로 구현되어 공개되면서 급속히 확산되었습니다. 이러한 Open API 뿐만 아니라 REST는 서비스의 서버 플랫폼 구축에 있어 필수적인 아키텍쳐 입니다.  
 

아키텍쳐(Architecture)
일반적으로 소프트웨어 분야에서 아키텍쳐라 하면 컴포넌트와
데이터 그리고 이들 간의 인터페이스   S/W 구성하는 요소들의 적절히 구성하고 배치하여 원하는 목적을 이뤄내는 것을 말합니다. 원하는 목적에는 기능 , 성능 , 확장성 다양한 이슈들이 포함될 수 있습니다.


REST 아키텍쳐(Architecture)

REST는 Roy Fielding 의해서 처음 사용된 용어로서 웹의 특성을 활용한 서비스 호출 Architecture를 말합니다. 좀 더 자세히 살펴보면 ,  
웹상이
모든 것들은 URL  표현(Representation)됩니. 이렇게 표현된 URL 클릭하는 순간 다른 URL 이동하게 됩니다. 과정을 달리 표현하면 해당 URL 표현하고 있는 상태(State)에서 다른 URL 상태로 이동(Transfer)하는 것입니다. 이렇게 정의된 URL 통해 애플릿케이션을 구동시키고 결과(상태) 전달(Transfer)받아 처리하는 것이 바로 REST 방식 입니.


REST 실제 표준은 아니지만 HTTP/URL/MIME Type같은 표준을 사용한다. 따라서 실제 표준 기술이기도 합니다. 최근 Sun에서는 JRS311, Java API for RESTful Web services 을 발표하기도 했습니다.




REST에 대해 좀 더 실제 예를 들어 이해해보도록 하겠습니다.

가령, 아래 URL 직원들의 명단을 조회하는 서비스입니다. 서비스를 통해 직원 명단을 받는 클라이언트는 서버측의 구현이 어떻게 되어 있는지 상관할 필요가 없습니다.


http://wisefree.com/employee



클라이언트가 이 서비스를 요청하면 다음과 같은 결과를 받게 됩니.


<?xml version="1.0"?>
<p:
Employee  xmlns:p="http://wisefree.com
" xmlns:xlink="http://www.w3.org/1999/xlink">
<Employee id="603045"  xlink:href="http://wisefree.com/employee/6030
45"/>
<
Employee id="741146" xlink:href="http://wisefree.com/employee/7411
46"/>
</p:
Employee
>


또한 클라이언트는 전달받은 직원 명단 중 603545번의 자세한 내용을 받기 위해 다음과 같이 REST 서비스를 호출합니다.
 

http://wisefree.com/employee/603045 


 

클라이언트는 다음과 같이 보다 자세한 결과를 받게 됩니.

<?xml version="1.0"?>
<p:
Employee xmlns:p="http://wisefree.com
" xmlns:xlink="http://www.w3.org/1999/xlink">
<
Employee-ID>741146</Employee
-ID>
<Name>
jisu park
</Name>
<
Resume xlink:href="http://wisefree.com/employee/741146/resume
/"/>
</p:
Employee
>


이처럼 REST 방식은 "서버 주소 + 서비스 이름 + 자원" 으로 이루어진 URL을 호출하고 이에 대한 자원을 전달받으면서 서비스를 수행하는 구조입니다.
이러한 REST
방식으로 시스템을 디자인할 때는 다음의 사항을 주의해야 합니다.

- 제공하고자 하는 모든 conceptual 리소스(엔티티)들을 서비스로 제공합니다.

- 각 리소스들에 대한 URL 설계합니다. , 주의할 점은 URL 명사로 설계하며 서버 주소 + 서비스 이름 + 자원 방식으로 설계합니다.


http://wisefree.com/employee/getEmployee?id=603045 우울한 설계

http://wisefree.com/employee/603045 , 멋진 설계


- 이 , URL 통해 필요한 자원을 계속해서 추적하여 얻어(HTTP GET) 가거나 삽입(HTTP PUT), 삭제(HTTP DELETE) 있게 분류 설계합니다. 결코 한번에 모든 정보를 제공해서는 안됩니다.


http://wisefree.com/employee 전체 직원 명단을 얻어 온다.

http://wisefree.com/employee/603045 특정 직원의 자세한 정보를 얻어 온다.(HTTP GET)

http://wisefree.com/employee/603045 특정 직원의 해당 정보를 갱신 온다.(HTTP PUT)


- HTTP GET 통해 제공되는 모든 자원은 있는 상태의 정보를 제공하는 것이지 자원의 상태를 변경하고 그에 대한 결과를 제공하는 것은 아닙니다.

- 제공되는 결과는 Ajax RIA 기술을 사용할 경우 반드시 XML 포맷을 사용한다. 외의 경우에는 응용 프로그램의 상태에 따라 적절히 결정합니다.

자! 간략하지만 아주 중요한 사항들입니다. 개발자와 아키텍쳐 분들은 반드시 유의해 주길 바랍니다.




Posted by 박재현
TAG JSR311, REST, Sun

3월 29일날 삼성동에서 열리는 "웹2.0 코리아 2007 컨퍼런스"에서 발표를 하게 되었습니다. 당일 발표는 주제가 " 웹 플랫폼화에 따른 애플릿케이션의 개발,배포"에 관한 내용입니다.

사용자 삽입 이미지

그 간 웹 개발 기술은 서버 플랫폼을 중심으로 발전해 왔습니다. 초기 CGI에서 Servlet, EJB 등 많은 서버 기술들이 출현했고 이에 따라 많은 발전을 거듭해 왔습니다. 그러나 현재에는 웹의 서버측의 플랫폼 기술만이 아니라 RIA(Rich Internet Application)으로 불리는 웹의 클라이언트측 플랫폼 기술이 발전하면 개발 뿐만 아니라 초기 기획,디자인,코딩에 이르기 까지 많은 변화가 불어왔고 , 또한 서비스의 아케텍쳐 또한 변하게 되었습니다.

본 발표에서는 이러한 것들을 살펴보고 현재 웹 플랫폼하에서 개발할 때 고려해여 할 사안들과 현재 가장 이슈가 되고 있는 웹 애플릿케이션의 오프라인 지원 기술에 대해 정리하려고 합니다.

발표가 마치고 나면 자료와 발표 내용을 정리해서 올리도록 하겠습니다.





Posted by 박재현

씽크프리에 합류하기 전에 오랜 시간 동안 검색엔진, 지식관리 시스템, 지식 포털, 기업 포털 시스템 개발과 구축 분야에서 일을 했었습니다. 아마 대략 짐작해도 100여 곳 이상의 기업과 공공 기관의 지식관리 포털을 구축한 것 같습니다. 그래서 인지 씽크프리에서 웹 오피스를 개발하며 Web2.0에 대해 고민하기 시작할 때 기업에서의 적용에 대해 무척 관심이 많았습니다. 지난 글들 중에 "Web2.0과 기업 인트라넷 시스템" 이란 글에서 언급했던 것처럼 기존의 기업 시스템들은 공통적인 특징이 있습니다.

바로 Web2.0의 철학인 "자발적인 참여와 공유"와 절대적으로 반대인 경우가 대부분이라는 것 입니다. 다시 말해, 기존의 기업 시스템들은 "강제에 의한 참여와 공유"라는 것 입니다. 물론 국내 기업의 현실입니다.
 
사용자 삽입 이미지
한 때를 풍미했고 현재에도 공공기관에서 지식 관리 시스템 도입은 필수적인 사항으로 기관과 개인의 업적 평가에도 포함됩니다. 이러한 현실에서 얼마나 자율적으로 지식 관리 시스템을 이용하고 참여할까요? 제 경험으로는 대부분 어쩔 수 없이 하는 경우가 대부분입니다. 결론적으로 현재 거의 대부분의 국내 지식관리 시스템은 거의 쓸모가 없다 라는게 제 생각입니다. 물론 시스템이 낙후된 것이 아니라 시스템에 있는 데이터가 의미가 없는 것이죠!!!!
 
이러한 이유가 바로 "강제에 의한 참여와 공유"이기 때문입니다. 이러한 문제 때문에 Web2.0을 기업에서 도입하여 현재의 문제를 극복하는 것이 필요하다고 생각했습니다. 이러한 생각이 바로 요즘 대두되고 있는 Enterprise2.0 입니다.
 
Enterprise2.0은 하버드 대학 앤드류 맥아피 교수가 최초 제시한 것으로 알려져 있습니다. 먼저 떠들어 대는 사람이 임자겠죠.. Web2.0도 오렐리가 냉큼 챙긴 것 보면 작명과 도장찍기가 동.서양을 막론하고 무지 중요한 것 같습니다.
하여간 맥아피 교수의 Enterprise2.0은 웹2.0 의 기술과 사상(참여,공유)을 기업적 측면에서 활용하자는 것을 강조하면서 등장했습니다.
 
맥아피 교수는 Enterprise2.0을 이루기 위해서는 6가지 구성요소(SLATES)가 필요하다고 했습니다.
 
  • Search - 강력한 기업 내부의 통합 지식 검색 기능
  • Links - 사용자의 평가 등을 통해 유용한 정보 등을 쉽게 연결하여 다양한 지식 체계를 구성함
  • Authoring - 블러그나 위키 등을 통해 개인이 스스로 지식을 제작,축적할 수 있는 제작 도구 제공
  • Tags - 기존의 정적인 카테고리에서 탈피하여 사용자가 스스로 태그를 통해 분류할 수 있게 해줌
  • Extension - 사용자가 스스로 지식을 평가하고 공유하도록 함으로써 새로운 지식을 창조하여 확장함
  • Signals - 새로 생성되거나 변경된 정보를 자동으로 RSS 등을 통해 자동으로 알려줌
 
사실 방법이 다를 뿐이지 이미 국내에서 많은 기업들이 도입한 지식관리 시스템에는 이런 구성요소가 포함되어 있습니다. 물론 강제에 의해 운용되는 것이고 표준이 아니라는 것이 큰 차이입니다만.
 
결론적으로 맥아피 교수의 Enterprise2.0을 요약하면 참여와 공유를 지향하는 웹2.0의 기본 패러다임과 RSS,Wiki,Folksnomy 등 주요한 참여와 공유의 기술을 기업에 적용하여 지식을 창조,공유하며 이를 통한 협업을 통해 기업의 가치(수익) 창출을 이루어 내자라는 것으로 이해할 수 있습니다.
 
  • 사용자(기업) 입장에서의 Enterprise2.0의 도입 적용 및 효과
분명 기업 입장에서 Enterprise2.0은 도입시 많은 효과를 보게 됩니다. 어떤 효과들이 있을까요? 실제 도입 사례를 제 경험으로 비교해 보겠습니다.
 
국민의 혈세로 운영되는 국민의 정부의 한부처 , 정부의 강력한 지식경영의 지침에 따라 전체 10억원의 예산을 잡고 시스템을 구축하였다. 시스템에는 강력한 통합 검색 기능과 다중 지식 맵, Drag&Drop 기반의 지식 업로드 , 지식 포인트 , 각종 커뮤니티, 개인화 페이지 등 내로라 하는 서비스가 모두 포함되어 있고 , 요즘 포탈의 추세처럼 그룹웨어와도 SSO를 통해 통합되어 있다. 짠~~ 개발이 끝나고 시범 운용을 마친 후 본격적인 운영이 시작되었다. 운영 후 첫 주, 강력한 사내 홍보와 각종 사은 행사 등이 연달아 이어지고 지식 모으기 행사 등이 개최되면서 시스템에 지식이 시스템이 다운될 정도로 저장되었다. 았싸.. 담당자에게 격려가 이어지고 성공적인 첫 달을 보냈다.
운영 2개월 후, 행사도 시들해지고 사내 홍보도 시들해지고 당연히 지식 업로드도 급격히 줄어들고 모은 지식을 검색해 보면 오래된 정보만 검색되어 실제 업무에는 도움이 되지 않는 정보뿐…---Enterprise1.0 환경
 
웹 오피스를 열심히 개발하고 있는 씽크프리라는 IT 회사 , 개인들은 모두 개인 블로그를 운영하고 이들 블로거는 RSS feed summary를 통해 모아져 있어 매일 신규 작성된 문서를 RSS 리더를 통해 공유하고 있다. 또한 mediawiki라는 opensource를 이용하여 개발팀과 프로젝트별로 각종 개발 지식을 공유하여 작성하고 있다. 모든 직원은 수행한 업무는 wiki에 기록해야 한다. 또한 각종 주제별 공용 게시판이 있어 다양한 정보를 수시로 올려 공유하고 신규 정보는 RSS를 통해 자동 구독된다. 이러한 환경을 구축하는 데 든 비용은 서버 300만원 1대 --- Enterprise2.0 환경

경제적인 이점만이 아니라 기업내에서 살아있는 시스템을 만들 것인가가 무척 중요합니다. 이렇듯 표준화되고 개발화된 철학과 기술 기반의 시스템을 사용하는 것이 중요합니다. 이를 위해선 현재 기업의 지식경영 시스템을 개발하고 있는 업체분들도 많은 고민이 있어야 합니다. 가령, 현재 각 부처의 지식관리 시스템을 연결하기 위해서는 중앙에 지식관리 시스템 연계해야 합니다. 만약 RSS를 지원하면 그냥 RSS 구독을 통해서 모든 게 해결됩니다. 가령, 자동정보수집에이전트 및 통지 시스템을 RSS Feed로 대체하고 지식 카테고리(맵)을 지식 태그로 대체하며 지식 업로드를 블러그 및 WIkI로 대체 및 확장하는 것이 필요하겠죠.
 
사실 국내의 기업과 정부 부처를 보면 다른 나라의 어떤 기업들 보다도 지식경영에 많은 관심과 투자를 해오고 있습니다. 무척 고무적이죠.. 그런데 이러한 투자는 장기적이고 문화를 만드는 것이어야 합니다. 이를 위해 기존의 생각(Enterprise1.0)을 버리고 새로운 생각(Enterprise2.0)으로 전환하길 간절히 바랍니다.



Posted by 박재현