|
OSGi는 무엇이며 Goal은 무엇인가? OSGi(Open Service Gateway initiative) Alliance는 1999년에 썬 마이크로시스템즈, IBM, 에릭손 등에 의해 구성된 개방형 표준 단체로 지능형 분산 컴포넌트와 원격 관리 될 수 있는 자바 기반의 서비스 플랫폼을 제정 해왔다. OSGi 의 핵심은 어플리케이션의 생명 주기를 OSGi 플랫폼 위에서 어플리케이션이나 번들 컴포넌트의 재부팅없이 실시간으로 설치, 시작, 정지, 업데이트, 제거를 할 수 있도록 지원해 주며, OSGi 는 또한 어플리케이션에 포함될 수 있는 형태의 SOA를 구현 하고 있다.<?xml:namespace prefix = o /> OSGi 프레임웍이 제공하고자 하는 환경의 목표는 다음과 같다. - 애플리케이션이 실행 중에도 동적으로 다운로드 및 업그레이드가 가능 - 제한된 메모리 디바이스 사용 가능 - 효율적이고 통합된 컴포넌트 개발환경 제공 - 애플리케이션 간의 의존성에 대한 관리 기능 제공 - 확장 가능성(scalable) |
|
OSGi 플랫폼을 따라야 하는 이유는? - OSGi 는 OS 나 특정 소프트웨어에 제한을 받지 않는다. 어떤 시스템의 플랫폼에도 이식 될 수 있다. 실제로 eclipse equinox (이클립스의 핵심 코어 컴포넌트) 가 OSGi 플랫폼이며 eclipse 에서 동작되는 모든 컴포넌트가 OSGi 번들이다. 이 것 만으로도 앞으로의 소프트웨어 패러다임이 어떻게 진화할지 예상할 수 있을 것이다. - 현재의 JEE 환경은 맘모스라고 표현하고 있다. 이는 정작 해야할 할 범위는 작은데, 너무 많은 것을 포함 해야 하기에 관심이 집중되지 않는 문제점이다. 이에 대한 대안이 OSGi 플랫폼이다. 이미 IT 를 주도하는 벤더는 여기에 역량을 집중하고 있다. - OSGi 로 굳이 할 필요가 있는가? 라는 질문에, 얼마전에 SWT 책을 읽어보았다. 거기에 OSGi 라는 언급만 없었지, SWT 가 Eclipse 위에 플러그인 되기 위해선 OSGi 플랫폼 위에 동작하고 있다. 웹 프레임워크는 어떠한가? 지금 spring 은 S2AP 환경위에, struts 는 Felix 라는 OSGi 환경위에 안착하고자 발빠르게 움직이고 있다. Web-Service 플랫폼, ESB 플랫폼 역시 OSGi 형태로 컴포넌트를 관리하고자 애쓰고 있다. - 하나의 프로젝트에서 사용되고 있는 수많은 jar 파일과 그것들의 의존성을 관리할 수 있는가? OSGi는 의존성이 없는 jar 컴포넌트의 결합과 그 위에서 어플리케이션이 동작되도록 보장 한다. |
|
OSGi 플랫폼을 언제부터 준비해야 하나? - 이미 IT 를 주도하는 업체는 달리고 있다. 늦었다고 생각되면 늦은 것이다. OSGi 를 적용하기가 어렵지 않은가? http://www.eclipsezone.com/eclipse/forums/t90365.html 에 게시된 웹 페이지를 통해 OSGi를 10분 이내에 구현할 수 있고, 잘 동작하는 샘플로 올려져 있다. 하지만, 실제 프로젝트에 적용하기 위해선 많은 부분을 학습 해야 한다. 한 마디로 학습 곡선이 높다. 하지만, 1-2년 안에 대부분의 플랫폼은 OSGi 가 주도할 것이 확실하다.
[출처] OSGi 도입의 필요성 (LOOKNFEEL) |작성자 cuteshim |