네이버 블로거 휴이님 글 펌
OSGi(Open Service Gateway initiative) Alliance는 1999년에 선 마이크로시스템즈, IBM, 에릭손 등에 의해 구성된 개방형 표준 단체이다. (OSGi Alliance는 처음에 Connected Alliance라고 불렸음) 그 후 몇 년 동안 OSGi Alliance는 원격 관리 될 수 있는 자바 기반의 서비스 플랫폼을 제정해왔다. 이 표준 사양의 핵심은 어플리케이션의 생명주기(Life cycle) 모델과 서비스 레지스트리(Service Registry)를 정의하는 프레임워크(Framework)이다. OSGi 표준 사양에는 이 프레임워크에 기반하여 매우 다양한 OSGi 서비스가 정의되어 있다.
OSGi 프레임워크는 독립적인 Java/VM 환경에서 제공하고 있지 못한 세련되고, 완전하며 동적인 컴포넌트 모델을 구현한다. 어플리케이션 또는 컴포넌트(번들, Bundle)은 재부팅 없이 원격지를 통해 설치(installed), 시작(started), 정지(stopped), 업데이트(updated) 그리고 제거(uninstalled)될 수 있다
OSGi는 Embeddable(어플리케이션 내부로 포함될수 있는) SOA를 구현하고 있다. 이를 통해 어플리케이션 개발에 있어 가장 복잡하고 관리하기가 어려운, 모듈간의 동적(Dynamic) 관계와 의존을 매우 효과적으로 관리할수 있게 한다. (Web service based SOA가 네트워크를 중심으로 하는 SOA라면 OSGi는 Java Object based SOA이다.)
1. Technology Problem
현재 홈 네트워크를 구성하는데 있어 해결해야 할 많은 난제들이 있으나 기술적으로 가장 우선시 되어야 할 사항은 바로 홈 네트워크를 구성하는 기술의 표준화 이다. 실제 홈 네트워크를 구성하는데 있어 다음과 같은 문제가 있다.
- 서로 다른 적용 분야 (데이터, 엔터테이먼트, 제어 네트워크 등)에
- 서로 다른 통신 방식 (고속, 저속, 유선, 무선, 전력선, CAT5, 2-Wire 등)
- 서로 다른 네트워크 (Ethernet, HomePNA, Bluetooth, HomeRF, IEEE1394, LonWorks 등)과
- 다양한 방법(ADSL, Cable, Phone, PSTN, 위성 등)으로 접속할 수 있어야 하고
- 그럼에도 일관된 홈 네트워크 서비스 (정보검색, 검침, 의료, 보안, 에너지 관리 등) 를 제공할 수 있어야 할 뿐만 아니라.
- 현존하지 않는 새로운 네트워크 기술과 새로운 홈 네트워크 서비스가 등장하더라도 모두 수용할 수 있어야 한다.
이를 가능하게 하는 홈 네트워크 시스템의 핵심은 주거용 게이트웨이(=홈 게이트웨이)이다. 하지만 현재의 주거용 게이트웨이들은 몇 가지의 고정된 기술과 네트워크 기술을 지원하거나 특정 회사의 독점적 기술들을 사용하고 있다. 또한 홈 네트워크 서비스도 고정되어 있거나 자사의 제품에서만 동작한다. 따라서 각기 다른 제조사들의 홈 네트워크 시스템과 제품들은 호환되지 않으며 미래에 등장할 새로운 기술과 서비스를 수용할 방법이 없다.
2. OSGi 설명
OSGi 표준은 번들(Bundle)이라고 불리는 모듈화 된 소프트웨어를 동작하도록 하는 소프트웨어적 프레임워크(Framework)와 번들이 프레임워크와 통신하도록 하는 인터페이스(Interface)를 정의하고 있다. OSGi 프레임워크는 게이트웨이 상의 이기종 기술 또는 타 벤더의 서비스 간에도 통신이 가능하게 하는 표준 기술을 제공한다. 이는 새로운 기술이나 서비스를 제공하는 장치가 추가 되더라도 장치 설비자의 요구 또는 거주자에 의한 간섭 없이도 인터넷을 통해 새로운 소프트웨어 모듈을 손쉽게 설치 및 업그레이드, 교환 시키는 것을 가능하게 한다. 따라서 소비자는 얼마든지 다른 제조사의 이기종 기술을 사용하는 기기를 구입해도 문제 없이 사용할 수 있다. 단지 이것을 가능하게 하기 위해 그 장치에 해당하는 번들을 원격지에서 전송 받기만 하면 되며, 새 장치를 설치하더라도 이전의 이기종 기술을 사용하는 장치들과도 통신 할 수 있다. 이와 같은 특징 때문에 OSGi는 외부망과 내부망, 각 기술과 서비스들간의 “교량”이자 “관문”의 역할을 수행하게 된다.
OSGi를 구성하는 중요 엔터티는 다음과 같다.
RCP 타겟 설정.
이클립스 사이트에 들어가서 RCP 파일을 받아야 되는데 스크롤을 내려보면
RCP runtime Binary 와 RCP SDK 가 있다.
스클롤에 바로 RCP 보인다고 다운 받지 말고 좀더 내려서 밑에 있는 RCP SDK를 받아서
타켓으로 설정하면 사용가능 하다.
이클립스 다운로드 페이지
자바 빈즈 컴포넌트 설계 규약
2. 자바 빈즈 컴포넌트의 속성(Property)들은 읽기, 쓰기 중 적어도 하나 이상의 기능을 수행 할 수 있어야 한다.
3. getXXX()는 파라미터를 받지 않은 구조이어야 한다.
4. setXXX()는 반다시 하나의 파라미터를 받는 구조이어야 한다.
JSP 공부중..
프로세스와 쓰레드의 관계는 플랫폼의 차이점(OS나 하드웨어의 차이)에 의해서 크게 달라집니다. 플랫폼이 같아도 자바 가상 머신(Java Virtual Machine, JVM)의 구현 방법에 따라 프로세스와 쓰레드의 관계는 달라집니다. 그러나 일반적으로는 하나의 프로세스 안에서 복수의 쓰레드가 구축된다고 해도 맞는 말이 되겠지요.
쓰레드는 메모리를 공유한다.
프로세스와 쓰레드의 가장 큰 차이점은 메모리 공유의 유무입니다.
프로세스는 각각 독립된 메모리 공간을 가지고 있는 것이 보통입니다. 어떤 프로세스가 다른 프로세스의 메모리를 마음대로 읽는다든지 메모리에 쓴다든지 하는 것은 아닙니다. 프로세스의 메모리 공간은 각각 독립되어있기 때문에 어던 프로세스가 다른 프로세스 때문에 망가질 위험이 없는 겂입니다.
쓰레드는 메모리를 공유합니다.[주] 하나의 쓰레드가 메모리 상에 정보를 쓰고 그것을 다른 쓰레드가 읽는 것은 자주 일어나는 일입니다. 『메모리를 공유하고 있다』라는 것은 자바에서 말하면 『인스턴스를 공유하고 있다』라는 의미입니다. 자바의 인스턴스는 메모리 상에 있고 복수의 쓰레드가 그 인스턴스를 읽고 쓸 수 있도록 되어 있습니다.
[주] 자바의 메모리 모델에서는 메인 메모리와 워킹 메모리라는 두 종류의 메모리가 등장합니다. 이 때에 쓰레드가 공유하는 것은 메인 메모리 쪽입니다.
쓰레드가 메모리를 공유하고 있기 때문에 쓰레드 간의 통신은 매우 자연스럽고 간단히 실현될 수 있습니다. 어떤 쓰레드가 인스턴스에 정보를 써서 다른 쓰레드가 그 인스턴스에서 정보를 읽으면 되는 것입니다. 한편 같은 인스턴스에 복수의 쓰레드에서 접근하기 때문에 배타 제어를 바르게 해야 합니다.
쓰레드는 콘텍스트스위치(context-swith)가 가볍다.
프로세스와 쓰레드의 또 하나의 차이점은 콘텍스트 스위치의 무게입니다.
동작중인 프로세스가 바뀔 대 프로세스는 현재 자기의 상태(콘텍스트 정보)를 일단 보존합니다. 그리고 새롭게 동작 개시하는 프로세스는 이전에 보전해 두었던 자신의 콘텍스트 정보를 다시 복구합니다. 이와 같은 정보의 바꿈(context-switch)에는 시간이 걸립니다.
동작중인 쓰레드가 바뀔 때 쓰레드는 프로세스와 같이 콘텍스트 스위치를 행합니다. 그러나 쓰레드가 관리하고 있는 콘텍스트 정보는 프로세스보다도 적기 때문에[주] 쓰레드의 콘텍스트 스위치는 프로그램의 콘텍스트 스위치보다도 가볍게 행해지는 것이 보통입니다.
[주] 이것은 어디까지나 일반적인 이야기 입니다. 쓰레드와 프로세스의 실제의 관계는 자바 실행 처리계의 구현에 크게 의존합니다.
그러므로 빽빽히 연달아 쉬고 있는 복수의 작업을 행하는 경우에는 프로세스보다도 쓰레드쪽이 좋은 경우가 많이 있겠지요.
사람을 위한 자동화.
이클립스 플러그인 설정.
SWT/JFace 이벤트 처리.
GUI 프로그래밍을 할때는 각 컴포지트의 구성도 중요하지만 이벤트의 처리도 중요한것 같다.
SWT/JFace in action 책을 보면.
복잡한 사용자 인터페이스는 이 두가지 이벤트 처리 수단을 모두 사용해야 한다.
JFace가 메뉴, 툴바, 버튼에 대한 빠른 인코딩이 가능한 한편, SWT는 키보드 작동 및 Shell과 테이블 같은 위젝과 관련한 이벤트에 필요하다.또한 JFace 클래스는 오른쪽 클릭과 왼쪽 클릭을 구분해야 할 때는 별 쓸모가 없다.
그러므로 GUI 개발자가 최소의 코드량으로 최대의 성능을 내고자 한다면 양쪽 툴셋에 모두 익숙해 져야한다.
위의 내용을 항상 명시하며 가볍고 깔끔한 코드를 가지는 프로그래밍을 하도록 하자.
SWT/JFace in action.
이 책이 쓰여졌던 버젼과 현재 이클립스 버젼이 다르기 때문에 책대론 해서는 실행이 안된다.
classdef 어쩌구~~~ IProgress~ 어쩌구 하면서안될시.
//
Visual Editor를 설치하셨다면 손쉽게 SWT/JFace User Library를 선택하는 것만으로 설정할 수 있습니다.
만일 직접 설정하고 싶으시다면 책에 설명한 플러그인 대신 다음의 플러그인들을 클래스경로에 직접 추가해주시면 됩니다.
물론 배포할때도 같이 해야겠죠~
org.eclipse.swt.win32.win32.x86
org.eclipse.jface
org.eclipse.core.commands
org.eclipse.equinox.common
//
이클립스 버젼이 3.2 일 경우에만 해당하는 사항.
org.eclipse.equinox.common_3.2.0.v20060603.jar 안에 IProgressMonitor.class 가 존재 한다고 한다.
