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 박재현

최근 외부 기관에서 웹 오피스의 현황과 전망에 대해 원고 청탁을 받고 짬짬이 글을 정리하고 있습니다. 글을 정리하다 오피스 문서 표준화에 대한 내용이 여러모로 도움이 될 것 같아 포스팅합니다.

--------------------------

기술 표준은 서로 다른 기술과 제품간 호환성을 높일 수 있고  특정 업체에 의해 시장이 지배되거나 왜곡되는 것을 방지하며, 개인 및 공공 기관들간 자유로운 정보 교환을 가능하게 한다. 국내 오피스 분야를 예로 들면, 그간 개인들은 'MS 오피스'를,  공공기관은 '한컴 오피스'를 주로 사용해왔으며 이로 인해 공공기관에 제출하기 위한 문서는 '한글'로, 개인적인 작업은 주로 'MS 워드'로 문서를 작성하는 불편을 겪고 있다.

또한 MS 오피스 2007 이전 버전과 한컴 오피스 모두 자체의 고유한 바이너리 문서 포맷을 보유하기 때문에 다른 응용 프로그램과 호환되지도 않을 뿐만 아니라 이를 위해서는 많은 비용을 지불할 수 밖에 없었다. 가령, 그룹웨어에 한글 편집기를 연동하기 위해서는 많은 비용을 들여야 하며, MS 오피스 문서를 다른 포맷 등으로 변환하기 위해서는 별도의 서버 비용을 지불해야만 한다. 이러한 문제의 원인은 모두 오피스 파일 포맷이 표준화되지 않았기 때문이다.

이러한 문제점들을 해결할 수 있는 오피스 문서 표준이 있다. 바로 OASIS(Organization for the Advancement of Structured Information Standards)에서 제정한 Open Document  Format(개방형문서포멧, ODF)와 ECMA에서 표준으로 제정한 Open XML 표준이다. 이들은 모두 바이너리가 아닌 XML로 워드 프로세스, 스프레드시트 , 그래픽 문서 문서, 차트  등의 포맷을 정의하고 있다.

ODF는 최초 1999년 독일의 StarDivision이란 회사에서 시작됐다. 2000년 썬마이크로시스템즈에서 이 회사를 인수하고 이를 오픈소스화 하면서 공식 문서 표준으로 ODF를 개발하기 시작했다. 이렇게 시작된 ODF는 썬의 노력으로 OASIS에서 국제 문서 표준으로 인정받았고 국제 표준화 기구인 ISO와 IEC로 부터 정식 승인(ISO/IEC 26300:2006) 받았다.

MS는 초기 오피스 2000에서 XML로 정의된 속성을 갖는 HTML 문서를 소개했고 뒤를 이어 Office XP에서는 SpreadsheetML이라는 첫번째 XML 참조 모델을 제공했다. 그리고 Office 2003에서는 WordprcessingML과 한층 강화된 SpreadsheetML 참조 모델을 통해 문서에 데이타를 저장하고 추출하는 방법을 제공했다. 가장 최근에 출시된 Office 2007은 DOC, XLS, PPT 파일의 기본 포맷을 XML 기반으로 하는 데 이 포맷이 바로 Open XML이다.

Open XML은 6,000 페이지, ODF는 700 페이지 분량에 광범위한 문서 포맷을 명시하고  있다. 이 두 표준의 장,단점을 간략히 비교해 보면 다음과 같다.
       
 
장점
단점
OpenXML
현존하는모든오피스기능을포함한다. 따라서기존의 MS 오피스문서들과호환이된다.
접근제어를제공한다.
ODF 변환플러그인을제공한다.
ISO 인증을받지못했다.
ODF
ISO 인증을받았다.
참여업체가광범위하다.
다양한플랫폼상에서이용할있다.
현존하는모든오피스기능을포함하지못한다.
스프레드시트포뮬라가없다.(V1.2 제공예정)
메타데이타정의가없다.접근제어가없다.(V1.1 예정)
 
Ecma는 2007년에 OpenXML을 ISO 표준으로 제출할 예정이고 표준으로 확정된 것이다.
   
OpenXML을 선도하고 있는 MS와 노벨이 ODF 변환 플러그인을 개발하여 배포하는 것처럼 이 두 문서 표준은 모두 공존할 것이다. 특히, MS와 반 MS 진영의 표준이기에 더욱 그러할 것이다.

그러나 이들 문서가 모두 XML이기 때문에 호환성에 있어 큰 문제는 없을 것이다. 더우기 현재 웹 플랫폼상에서 개발되는 응용 서비스들이 XML 기반의 서비스로 전환되고 있기 때문에 그 사용 범위는 더욱 광범위해질 것이다. Open XML과 ODF 문서 포맷으로 문서를 생성해내는 게시판이나 각종 편집기가 다수 등장하고 이들 XML 문서는 DB나 CMS 등에 저장되어 다양한 복합 데이타와 응용 서비스로 거듭날 것이다.

이미, 현존하는 웹 오피스들은 OpenXML과 ODF로의 저장을 지원하고 있다. 가령, 씽크프리의 경우에도 이미 QuickEdir이라 불리는 Aajx 기반의 웹 에디터의 기본 포맷으로 OpenXML을 사용하고 있으며 이를 통해 데스크톱상의 오피스 문서들과 이미 손실없이 문서를 호환하고 있다. 또한 Open API를 사용하여 Flickr.com의 이미지 DB를 검색하여 문서에 삽입하는 등 다양한 부가 기능을 개발하는 데 이를 활용하고 있다.

이와 관련하여 최근에 국내 정부에서 ODF를 표준으로 한다는 의견을 들은 적이 있다. 개인적으로는 이미 OpenXML이든 ODF든 사실상 국제표준이 된 이상 경쟁은 자유이고 기술력이 중요하다고 생각한다. 물론 정부 차원에서 오피스 문서의 표준화는 중요하다. 나도 과거 문서의 비표준화로 인해 그룹웨어 결제 연동이나 문서전문 검색 등에서 울며 겨자먹기로 많은 비용을 지불하면서 분개했던 적이 있다. 이제 이런 일은 없어지리라 생각한다.

또한 이제 웹상의 문서 편집기 서비스들이 문서 표준화 기반으로 전환될 것이고 특히, 다양한 매시업(mash-up)을 통해 웹2.0 서비스도 고도화되고, 엔터프라이즈2.0에서도 웹 오피스가 보다 진화될 것이다. 이제 웹 스프레드시트에서 SAP의 데이터를 실시간 조회하고 편집하며 여기에 각종 공개된 데이타의 API로 연결된 데이타를 추가한 후 다시 SAP에 반영함과 동시에 자동으로 결제되는 환경이 가능해질 것이다. 이 과정은 현재 BPM2.0이라 불리는 영역에 급속히 퍼지리라 생각한다. 이처럼 오피스 문서의 표준화는 중요한 부분이다.



Posted by 박재현