달력

4

« 2021/4 »

  •  
  •  
  •  
  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  •  
2008. 12. 13. 19:08

Google Native Client에 대한 소개 좋아하는 것/Google2008. 12. 13. 19:08


이번 주는 여는 때와 달리 인터넷을 통해서, 몇가지 이슈들을 일으킬 만한 것들이 소개되었다. 특히 Google에서 몇가지 눈여겨 볼만한 것들을 내 놓았는데, 여기도 우리과 같이 한해를 마무리 하기 전에 프로젝트들을 정리하나 보다. (지금 내가 진행하는 프로젝트도 1.0 버전을 다음주까지 마무리 할 계획이다. 많은 우여곡절 끝에 여기까지 왔다. 그러나 높은 점수를 줄 수 없다. 개인저으로 많은 부분이 만족 스럽지 않기 때문이다.)

구글이 이번주에 발표한 내용중에, 특이 사항으로는 "Native Client"라는 것을 발표 하였는데,웹 브라우져를 통해서, OS가 가지고 있는 리소스를 최대한 사용할 수 있도록 도와줄 수 있고, 브라우져 상에서 애플리케이션을 빠르게 실행시키고, 이는 마치 데스크탑 Application 처럼 사용할 수 있다고 한다.

이미 Google의 도구들을 아는 사람은 유사한 것으로 Google Gears를 생각할 것이고 Googl 크롬을 떠 올릴 것이다. 그리고, RIA 관련 기술로는 MS의 Silverlight와 Adobe의 Flash 그리고 또 아직까지는 많은 사람들의 관심을 끌지는 못하고 있는 Sun의 Java FX가 있다.

이들의 유사점은 모두 Web 브라우져를 지원하지만, 웹 브라우져를 벋어 나려고 한다는 것이다. 내가 이전에 작성했던 글들에도 여러차레 언급 하였지만, 현재의 PC시장 보다는 Mobile 시장이 훨씬 크고, 앞으로의 성장가능성도 휠씬 높다.

위에서 언급하였던, RIA 관련 솔루션을 제공하는 MS, Adobe, Sun과 Google의 "Native Client"는 기술적인 관점에서 유사성이 많다. 왜냐하면, MS의 IE 브라워져의 관점에서 보면 Active X 기술을 사용할 수 밖에 없기 때문이다. 좀더 쉽게 설명하면 IE와 같은 웹 브라우져에서 동작할 수 있는 Application Container를 개발자와 개발업체에 제공하고, 이들이 만든 Software를 이 Application Container에서 동작시키는 것이다. 웹 브라우져에 Software를 구동시킬 수 있는 Layer를 두는 것인데, 이는 Adobe의 Flash Player를 생각하면 쉽게 이해가 될 것이다. RIA Application을 개발하고 이를 Adobe의 Flash Player(Application Container)를 통해 동작시키는 것이다. 이는 기술적으로는 다른지 모르겠지만, Layered Design 관점에서 보면, MS의 실버라이트, Adobe의 Flash, 그리고 Sun의 Java FX가 동일하다. 이렇게 한다면, 브러우져의 종속성을 크게 줄일 수 있는데, 만약 웹 브라우져의 스펙에 이러한 부분들이 반영되어 있고 표준화 되어 있다면, 이들 회사가 이러한 Container를 제공할 필요도 없었을 것이다. 

"Native Client"에 대해서 눈여겨 보아야 하는 이유는 어제는 Google의 크롬 브라우져가 정시으로 Release되었다. Google Gears도 그렇지만, 인터넷 또는 netwrok이 되지 않는 환경에서도 Application을 실행하고 사용자가 원하는 작업을 할 수 있도록, Google은 관련 기술들을 만들어 내고 있다. 이러한 연장 선상에서 기술의 흐름을 이해하는 것이 중요하다.

"Native Client"는 지난 3일 전에 발표되었지만, 아직 자세히 살펴 보지는 못하였다. 이번 주말에 짬짬히 살펴볼 예정인데, 아래 몇가지 링크와 동영상이 있다. 이해 하는데 도움이 될 거라 생각한다.

 
 1. ZdNet에 소개된 기사 
  
 2. Google Native Client
 
 3. Google's Reserch Paper
   





 

Posted by 행복상자

댓글을 달아 주세요

일민이가 지난주에 호주에서 한국에 들어왔는데, 아직 얼굴은 보지 못하고 있다.
매번 저녁 약속에 다른 약속들이 잡혀서, 그 모임들에 참가 하는라 바쁘다.

아직도 11월인데, 송년회를 한다나, 여의도에서 만나기로 했는데, 다른 사람들이랑 모임이 시작되어서 힘들다고 한다. 이유도 여러 가지 이지만, 아직도 한국에서 그를 찾는 사람들이 많아서 일거다.

암튼 이번주 토요일에 보기로 했는데, 저녁보다는 아침 일찍이 만나야 할 거 같다. 예전 처럼 아침 먹으면서,  여러 가지 이야기를 할 수 있을 거라 생각이 된다. 이제는 아이들 이야기를 할 수 있을 정도로 일민이도 자격을 갖추었으니까... 얼마전에 일민이 아들이 돌이었다고 한다.

다음 동영상은 일민이가 IBM의 DeveloperWorks에 올린 동영상 강좌이다.
올린지 시간이 꽤 지났는데, 최근에서야 보았다.


Posted by 행복상자

댓글을 달아 주세요

며칠전에 SpringSouce에서 새로이 발표한 SpringSource Application Framework에 대해서 글을 소개한 적이 있다. 지난 30일 팀 블러그를 통해 발표 되었었다.
이는 Dynamic Module Kernel(DM-Kernel)을 기반으로 만들어진 현재는 베타버전의 SpringSource의 Application Platform이다.


잘 만든 Architecture도 결국은 어떻게 Deploy하고 관리 할 것이냐에 대한 고민을 하게 되는데, 이는 새로 만든 모듈들과 기존에 동작하는 모듈간에 조화로움이 관건이다.(버전 관리와 Dependency의 문제)

www.springframework.org 에 들어가 보니, Application Platform에 대한 글과 자료들이 새로 올라와 있어서 흩어 보았는데, 리눅스와 윈도우 환경에서 설치와 사용에 대한 Guide와 개발자 매뉴얼이 올라와 있어 새로운 Platform에 대한 이해에 큰 도움이 될거라 생각이 든다.
Web Site에 올라온 자료들의 목록과 링크는 다음과 같다.




각 번들에 필요한 기능들을 어떻게 가져오고 노출 시킬 것인가에 대해해, 요즘 고민 중인데, 분석을 하면서 아이디어를 얻어야 할 것 같다.
현재 내가 하고 있는 프로젝트는 공통 모듈들 개발 해야 하는데, 각 공통 모듈을 이용해서 개발해야 할 솔루션의 내부에도 외부로 노출 시켜야 할 서비스 부분이 분명 존재한다. 이를 어떻게 다른 쪽에 인지 시킬 것인지, 그리고 어떻게 가져다 써야 할 것인지에 대한 고민 중이다.



위와 같이 직접 불러다 사용하거나, 아니면 아래와 같이 공통의 라이브러리를 따로 만들고 각 번들에서 직접 호출해서 사용할 수도 있을 것이다.




Posted by 행복상자

댓글을 달아 주세요

이미 아는 사람들은 알겠지만, Spring Framework를 만들 "로드 존슨"의 회사명은 "Interface21"에서 "SpringSource"로 사명을 바꿨다. 그리고 더욱 왕성한 활동을 보여주고 있다.

오늘 소개하는 SpringSource Application Platform은 SpringSource의 팀 블러그에 올라온 것으로 beta release를 공개한다는 내용이다.
요즘 사내에서 개발하고 있는 Framwork는 OSGi를 기반으로 설계를 진행중이고 이를 위해서 스프링-DM을 사용하려고 한다. 그래서 관심을 갖을 수 밖에 없다.


Tomcat과 Spring을 통해서 lightweight platform을 구성이 가능하지만, modularaty(모듈화)와 non-web application에 대한 지원에 대한 단점을 안고 있다.
이를 개선하기 위한 노력으로 시작된 것이다.

아래는 Application Platform의 구성을 설명해 주는 그림인데, 여기서 중요한 역할을 하는 것은 SpringSource DMK(Dynamic Module Kernel)이다.
SpringSource Application Platform Architecture
DMK가 동작하기 위해서는 최소한의 번들들이 있어야 된다고 한다. MDK는 구동을 위해서 꼭 Tomcat을 필요로 하지도 않지만, Tomcat는 기본적으로 포함되어 있고, 언제든지 설정을 통해 넣거나 뺄수 있다. 그러나 Tomcat을 제거한다는 것은 Web Module의 Deplroy를 하지 않는 다는 것을 의미하므로 이점은 반드시 유의해야 한다.

다음은 Platform에서 지원하는 3가지 패키징 및 Deploy 방법이다.

Building Applications

  • The Platform supports applications packaged in three forms:

    1. Java EE WAR
    2. Raw OSGi bundles
    3. Platform Archive (PAR)

먼저,  WAR파일을 통해서 배포가 가능한데, 이는 배포 시점에 OSG번들과 Tomcat에 설치가 된다.
둘째로, OSGi 번들은 직접 Platform에 배포가 가능하며, Import-Package and Require-Bundle를 이용해서 번들간의 deendency의 선확인이 가능하다.
마지막으로 PAR 포맷은 Platform으로 deploy할 때 수동으로 설치가 쉽고, 로드 될때 다른 서비스와 충돌 또는 이중으로 서비스가 동작하는 것을 막아주고, Application에서 사용되는 모듈들에 대해 로직컬하게 Grouping이 가능하게 만들어 주는 잇점을 가지고 있다.
아래는 모듈간의 RAR Application의 전형적인 예이다.
PAR File Structure
Dependency는 일반적으로 Import-Package & Export-Package를 이용하여 표시한다. 그러나, Third-party 라이브러리를 이용하기 위해서는 이 것말고도 더 많은 라이브러리를 요청하는 경우가 있다. 이를 개선하기 위해서, Platform에서는 Import-Bundle 과 Import-Libary을 이용하여. Import-Bundle 은 추가적으로 다른 third-party 라이브러지를 참조할 수 있게 된다.
 


 

Posted by 행복상자

댓글을 달아 주세요