'Sun'에 해당되는 글 2건

  1. 2008.02.10 오피스 문서 표준화에도 국가 전략이 필요하다. 1
  2. 2007.03.25 REST Architecture

사용자 삽입 이미지
구정 연휴 동안 ODF,OOXML 등 문서 표준화를 둘러싼 여러 정황들과 기술들에 대해 심도깊게 살펴보았습니다. 당분간 문서 표준화를 둘러싼 여러 기술들과 정치적인 배경, 경제적인 문제 등에 대해 정리를 해 볼까 합니다.  개인적으로오피스 문서 표준화가 미치는 영향이 일반적으로 생각하는 것보다 큰 파괴력을 갖기 때문입니다.  가령, HWP 바이너리 문서 대신  ODF 나 OpenXML이 표준화가 되다면 기존의 한글 워드프로세스의 주력 시장인 정부 공공기관이나 학교 등에서 더 이상 한글 워드프로세스를 사용하지 않아도 무방하기 때문입니다. 이미 가격적인 면에서  MS는 이미 Student/Teacher 버전의 경우 $60에 공급하고 있고 , 중국 정부에 10$에 공급을 하고 있는 상황입니다.

이처럼 오피스 문서의 표준화의 경우 정치,경제,문화,기술적으로 많은 복합적인 이슈들을 포함하고 있습니다. 민족주의적 관점에서 보면 ODF도 결국 Sun이 배후조정하고 있는 Openoffice.org 를 통해서  MS와 경쟁(?, 실제 경쟁이라기 보다 MS의 오피스 사업을 어떻게된 수익을 줄이고 정부기관이나 교육 기관등에 시장을 만들어 보자라는 전략)하겠다는 것이고 , OOXML의 경우도 MS가 정체되어 있는 오피스 시장을 확대하여 서버기반으로 확대하고 표준화를 통해 각국의 정부 기관과 교육 기관등 취약한 부분을 열겠다는 전략이 숨이 었습니다.  따라서 결국 , 어떤 표준안도 우리나라 입장에서 보면 비슷한 것이죠. 그러나 결국 어떤 표준안이 되도 또 끌려가야 한다는 것이 문제가 아닐 수 없습니다. 전에도 이 부분에 대해 간략히 언급한 적이 있습니다만 자료를 정리하다 보니 중국의 사례가 눈에 띠어 정리해 봅니다.

- 2008/02/02 - [Office2.0] - Open XML VS ODF 표준화의 최종 라운드

혹시 UOF(Uniform Office Format) 라는 오피스 문서 표준을 아시나요?

UOF는 XML 에 기반한 중국 오피스 파일 포맷 명세으로 중국 정부와 SW업체,학교 및 관련 연구소에서 2005년 만든 국가 표준입니다.  한 3년간의 작업을 했다고 합니다.  초기 이 표준은  RedOffice의  요구에 의해서 시작되었다고 합니다. RedOffice는 오픈 오피스에 기반하여 개발된 중국 오피스입니다. 결국 ODF에 기반한 것이죠. 현재 베이징 대학에서 이미 ODF-UOF 변환 필터를 오픈 소스로 개발하여 제공하여 그 기반도 탄탄히 만들어 놓은 셈입니다. 그리고 더욱 중요한 것은 Sun Microsystem의 묵인하에 몇몇 중국 관련 특허가 UOF 에 포함되어 있고 RedOffice에 구현되어 있습니다. 결국 중국 오피스 시장은 UOF를 통해 보호되고 있는 셈이죠. 상황이 이렇다 보니 과거에 빌 게이츠가 중국을 방문하여 윈도우 소스를 제공하고 윈도우를 거의 공짜 수준으로 제공하여 시장을 열려고 하는 노력을 이해할 수 있을 것 같습니다. 그런데 Sun이 ODF 기반으로 UOF를 그냥 놔두는 것은 정말 이해하기 힘든 결정인 것 같습니다. 자바와 오픈 오피스의 지배권을 끝까지 가져가면서 결국 시장을 더 망치치 않나 싶습니다. 아^-^ 피곤한 태양!

이러한 중국 오피스 문서 표준화를 보면서 국내 오피스 시장을 보면 많은 걱정이 됩니다. 특히, 아무런 국내 시장에 대한 보호장치 없이 ODF-OOXML이 국내 표준이 된다면 ( 실제 개인적으로는 이미 ODF는 ISO의 표준이고 OOXML의 ECMA와 산업계 표준이기 때문에 오는 3월 OOXML의 ISO의 표준 투표 결과는 실제적으로는 큰 의미가 없다고 생각합니다.) 실제 그 간 많은 우여곡절끝에 명맥을 유지하고 있는 기존 국내 오피스 회사들은 또다른 생존을 위한 변신을 해야할 것으로 보입니다.  어쩌면 지금이라도 국내 문서 표준화라는 것이 필요할 지 모르겠습니다.

물론,XML 기반 문서 관리,컨텐트 관리를 주력으로 하는 회사들은  이와 반대로 새로운 사업 기회를 얻겠죠. 그런데 재미난 것은 이미 MS의 경우 이러한 서버 기반의 솔루션의 개발을 이미 수년간 해 오고 있다 것 입니다. OOXML을 이미 지원하고 있는 씽크프리도 또 다른 기회를 얻게 될까요!^-^


Posted by 박재현
,

REST Architecture

Architecture 2007. 3. 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 박재현
,