IT/모바일
제공: 한빛 네트워크
저자: Wayne Beaton, 이대엽 역
원문: http://www.onjava.com/pub/a/onjava/2006/08/23/eclipse-rich-client-platform.html
기술은 일정한 주기를 가진다. 지난 10년 동안의 씬 클라이언트(thin client)의 시대를 지나, 리치 클라이언트(rich client) 기술이 컴백하고 있다. 수많은 조직들이 그들의 애플리케이션을 리치 클라이언트로 구축하고 있으며 그들 중 다수가 그들의 애플리케이션을 이클립스 리치 클라이언트 플랫폼(Eclipse Rich Client Platform; RCP)에 기반하고 있다. "rich client"라는 용어는 첫째로는 애플리케이션이 사용자에게 풍부한 경험을 제공함을, 둘째로는 애플리케이션이 몇몇 서버의 클라이언트임을 의미한다. 반드시 리치 클라이언트가 대응되는 서버 컴포넌트를 가져야 하는 것은 아니지만 대개의 경우에 그러하다.
리치 클라이언트는 팻 클라이언트(fat client)에 비해 많은 점에서 차이가 있다. 둘 모두 사용자에게 씬 클라이언트 기술을 사용해서는 제공하기 곤란하고, 별로 바람직하지 않으며 혹은 아예 불가능한 정보의 표현과 기능을 자연스러운 데스크톱 경험을 통해 제공해 준다. 하지만 리치 클라이언트는 그 이상의 것들을 제공한다. 팻 클라이언트가 배치 및 업데이트가 힘든 커다란 한 덩어리의 애플리케이션이 되려는 경향이 있는 반면, 리치 클라이언트는 좀 더 경량이며 그들 자신을 상대적으로 배치 및 업데이트에 용이한 컴포넌트 모델에 기반한다. 예전부터 팻 클라이언트는 특정한 플랫폼으로서 구축되어 왔는데, 오늘날의 리치 클라이언트 기술들은 아랫단에 위치한 플랫폼의 능력을 외부에 노출시키는 반면 플랫폼의 세부사항은 숨기는데, 이는 개발자로 하여금 어떤 특정한 플랫폼에 국한된 특수한 세부사항 보다는 주어진 과업(task)에 집중할 수 있게끔 해준다.
리치 클라이언트는 또한 팻 클라이언트에 비해 좀더 확장되려는 경향을 띤다. 전통적으로 팻 클라이언트는 데이터베이스에 직접적으로 연결되어 있다. 이것은 팻 클라이언트가 실행될 수 있는(방화벽이 팻 클라이언트로부터 데이터베이스에 이르는 연결을 제한할지도 모른다) 환경을 제약하며 애플리케이션의 확장성(클라이언트로부터 서버에 이르는 전체 연결 개수)이 데이터베이스에 의해 제한될지도 모른다. 리치 클라이언트는 데이터베이스로의 연결 생성에 대한 책임을 맡고 있는 애플리케이션 서버를 이용하려는 경향을 띤다. 이러한 설정은 매우 유연하며(방화벽에 친화적인) 확장성이 높다. 물론 팻 클라이언트에 대한 애플리케이션 서버의 통신을 부득이하게 제한하는 기술은 없으며, 그것은 단지 팻 클라이언트 기술의 전성기때나 그랬던 것이며 현재의 애플리케이션 서버들이 동작하는 방식대로 동작하는 애플리케이션 서버들이 존재하지도 않았다.
리치 클라이언트 애플리케이션이 어떤 대응되는 서버의 클라이언트가 되어야 한다는 것에 대한 규정은 없다. 리치 클라이언트 기술을 이용하는 많은 조직들은 강건하고(robust), 확장가능하며(extendable), 업데이트 가능하며(updatable), 지역화된(localized), 독립적인(standalone) 애플리케이션을 구축하고 있다. 비슷하게 리치 클라이언트도 애플리케이션 서버를 이용하려는 경향을 띠는데, 이것을 사실화시키는 어떠한 강제적인 규약이나 기술적인 제약은 없다는 것이다. 즉, 리치 클라이언트 애플리케이션이 왜 데이터베이스에 직접적으로 접근할 수 없는지에 대한 이유는 없다.
리치 클라이언트 기술은 팻 클라이언트 기술과 씬 클라이언트 기술의 강점만을 결합한 것임을 나타내는데, 이러한 강점들에는 풍부한 사용자 경험, 높은 확장성, 플랫폼 독립성, 그리고 매우 용이한 배치와 업데이트가 있다.
이클립스 RCP는 이클립스 플랫폼의 핵심부분에 위치한 기능이다. 대부분의 사람들이 이클립스를 떠올릴 때 자바 통합 개발 환경(IDE)으로 생각한다. IDE를 구성하는 이클립스의 각 구성요소를 떼어 버리고 나면, 메뉴, 도구바, 푸시 버튼, 테이블, 트리, 그리고 그 외의 많은 이동가능하고(movable) 차곡차곡 쌓아 올릴 수 있는(stackable) 윈도 컴포넌트(편집기와 뷰)에 대한 지원을 포함하는 가장 기본적인 워크벤치(workbench) 기능만이 제공되는 핵심 요소만이 남게 된다. 바로 이 핵심기능이 이클립스 RCP이다.
이클립스 RCP는 애플리케이션 개발자에게 다음과 같은 것들을 제공한다:
컴포넌트
이클립스 RCP는 수많은 컴포넌트로 구성되며, 그리고 각각의 컴포넌트는 개발 환경의 전체 기능 중 각 부분에 대해 기여한다. 사실 거의 모든 이클립스 RCP는 컴포넌트로 구성되는데 부트스트랩에 관련된 소량의 코드를 제외한 RCP의 모든 부분은 컴포넌트이다. 컴포넌트는 보통 이클립스 테두리(혹은 OSGi 용어로는 번들)내의 플러그-인으로 알려져 있다. "플러그-인"이라는 용어는 컴포넌트 내에 포함된 기능은 아무래도 부차적인 기능 혹은 내장된 기능에 대한 애드온(add-on) 정도임을 내포한다. 하지만 사실은 그렇지 않다. 이클립스 RCP는 모든 플러그인에 대하여 동일하게 취급하며 어디에도 내장된 기능과 커스텀 기능에 대한 명시적인 구분이 없다. 즉 여러분의 애플리케이션의 움직임을 보조하기 위해 직접 작성한 플러그인은 이클립스 RCP를 구성하는 것과 나란히 실행된다.
리치 클라이언트 애플리케이션을 개발하기 위한 자연스러운 방법은 하나의 플러그인을 개발하는 것부터 시작하는 것이다. 하나의 플러그인 안에 여러분의 애플리케이션을 위한 전체 인터페이스, 비즈니스 로직, 그리고 객체 모델을 정의할 수 있다. 새로운 이클립스 리치 클라이언트 플랫폼(RCP) 애플리케이션을 작성하는 것은 단순히 File>New>Project의 메뉴 항목을 선택하는 것만큼이나 쉬우며, new Plug-in Project를 선택한 다음, 마법사에서 나타나는 몇 가지 단계를 따라가기만 하면 된다. 마법사 중간의 Content Page 부분에서 나타나는 질문인 "리치 클라이언트 애플리케이션을 작성하시겠습니까?(Would you like to create a rich client application?)"라는 질문에는 반드시 "예(Yes)"를 선택해야 한다. 마법사 중 템플릿 페이지에 관한 것이 그림 1에 나타나 있는데, 여기에서는 뷰를 가진 RCP 애플리케이션 작성을 위해 "RCP application with a view"를 선택한다.
그림 1 New Plug-in Project 마법사의 템플릿 페이지
이것은 워크벤치(메뉴 바와 도구 바)와 테이블을 하나 가지는 한 개의 뷰에 대한 설정을 포함하는 RCP 애플리케이션을 만드는데 필요한 부분들을 포함하는 새로운 플러그인을 생성할 것이다.(그림 2 참조)
그림 2. 마법사는 완전한 기능을 갖춘 RCP 애플리케이션을 생성한다.
마법사는 다음의 클래스들을 생성한다.
발전된 애플리케이션 구축
이러한 방식으로 애플리케이션을 구축하는 것은 개발자에게 많은 유용한 하부구조(infrastructure)를 노출시켜 준다. 단순히 윈도 컴포넌트의 집합 이상으로 RCP 애플리케이션은 여러분의 애플리케이션의 에디터와 뷰(위치를 재설정하고 쌓아 올릴 수 있는 능력을 포함한), 도구 바, 메뉴, 선택사항 관리, 그리고 더욱 더 많은 것들에 대한 높은 수준의 관점을 포함하는 사용자 인터페이스를 관리하기 위한 프레임워크를 제공한다. 하지만 이러한 방식으로 애플리케이션을 구축하는 것은 이클립스에서 가능케 해주는 힘에 대한 겉핥기에 불과하다. 이것은 처음으로 이클립스 애플리케이션 구축에 파고들어 보는 데에는 더할 나위 없으며 자연스럽게 다음 단계는 실제 컴포넌트 구축을 시작해 보는 것이다.
플러그인은 이클립스 플랫폼의 강력한 기능이다. 사실 이클립스 SDK 자체는 플러그인의 집합일 뿐이다. 이클립스 내부에는 플러그인이 아닌 것이 거의 없다(단지 상대적으로 적은 양의 부트스트랩 코드만이 있을 뿐). 이것이 이클립스를 매우 확장성있게 만든다. 새로운 기능은 프레임워크에 의해 동적으로 발견되고 설치되는 하나 혹은 그 이상의 플러그인을 생성함으로써 SDK에 추가된다. 플러그인은 존재하는 것 자체만으로 발견되며 플러그인 안에는 플러그인을 추가할 때 업데이트를 필요로 하는 manifest 파일조차 없다.
이클립스 SDK처럼 RCP 애플리케이션은 플러그인의 집합이다. 플러그인은 다양한 모양과 크기를 띠고 애플리케이션 내에 포함된다. 위에서 본 것과 같이 여러분은 RCP 자체를 구현하는 플러그인의 집합에 추가된 하나의 플러그인을 이용하여 완전한 이클립스 RCP 애플리케이션을 구축할 수 있다. 아니면 애플리케이션의 일부분들을 각각 구현하는 많은 플러그인의 집합으로서의 RCP 애플리케이션을 구축할 수 있다.
많은 플러그인들의 집합으로서의 RCP 애플리케이션을 구축하는 것은 많은 이점을 가지는 데 그러한 이점에는 다음과 같은 것들이 있다:
이클립스 컴포넌트 모델은 이러한 방식의 아키텍처상에서 탁월한 서비스를 제공한다. 가시성 모델을 강제함으로써 이클립스는 능동적으로 개발자로 하여금 사용자 인터페이스 코드를 모델(물론 진짜 프로그래머들은 전후 좌우를 살펴 해결할 수 있다)에 포함시키지 않도록 해준다. 사용자 인터페이스 플러그인의 집합은 모두 비즈니스 로직 플러그인(그리고 다른)들을 의존성으로서 가지고 있는데, 뷰는 모델을 볼 수 있지만, 그 반대는 볼 수 없다. 이러한 방식의 분리를 권장함으로써 코드 내의 결합정도가 줄어들며 이것은 코드를 변화에 대해 훨씬 덜 불안정하며 영구적으로 더 재사용 가능하게 만든다.
컴포넌트 조립
여러분의 애플리케이션 코드가 여러 플러그인으로 분할되어 있다면 RCP 애플리케이션을 작성하는 것은 그러한 플러그인들을 연결된 하나의 완전한 애플리케이션으로 조립하는 과정이다. 애플리케이션이 필요로 하는 플러그인들의 집합을 정의하는 것은 제품 설정의 역할 중 하나이다. 제품 설정은 스플래시 화면(splash screen), 윈도 아이콘, about 대화상자 이미지와 텍스트, 그리고 그 밖의 여러 가지에 대한 브랜드 정보가 위치하는 곳이기도 하다.
플러그인의 집합으로부터 애플리케이션을 조립하는 것은 간단한 과정이다. 사실 그 과정의 가장 큰 문젯거리는 애플리케이션 브랜드화에 관련된 예술적인 과정인데, 그러한 과정은 브랜드화 과정의 일부분으로서 여러분은 스플래시 스크린, 윈도 아이콘, 실행 아이콘, 그리고 about 대화상자 그림을 추가할 수 있다. 메뉴의 File > New > Product Configuration을 차례로 선택함으로써 여러분의 애플리케이션에 대한 제품 설정을 작성할 수 있다. 제품 설정 마법사가 그림 3에 나타나 있다.
그림 3. "새 제품 설정" 마법사
신규 제품 설정 작성의 일부분으로써 여러분은 부모 플러그인 프로젝트를 지정할 필요가 있다. 일반적으로 이것은 애플리케이션을 정의하는 플러그인이다. 아래에 3가지 서로 다른 초기 설정을 작성하는 방법이 나열되어 있다:
제품 설정 편집기(그림 4 참조)의 Configuration 탭에서 여러분의 애플리케이션이 필요로 하는 플러그인의 이름을 지정하도록 하는 것을 볼 수 있다.
그림 4. 제품 설정 편집기의 설정 페이지
플러그인 목록은 여러분의 애플리케이션이 필요로 하는 다른 플러그인과 함께 애플리케이션 플러그인을 포함할 필요가 있다. 편집기는 여러분에게 어떤 플러그인이 필요할지를 선별하는 것을 도와준다. 여러분 애플리케이션의 플러그인을 목록에 추가한 다음, Add Required Plug-ins라고 표시된 버튼을 누르면 그러한 플러그인 등에 필요한 플러그인인 여러분의 플러그인에 참조된 모든 플러그인을 추가할 것이다. 이 설정은 이클립스 플랫폼 자체로부터 많은 플러그인들을 포함할 것이다. 이 버튼을 사용하면 여러분은 최상위 레벨의 플러그인만을 포함하면 되며 편집기가 알아서 최상위 레벨의 플러그인이 의존하고 있는 플러그인들을 검색하여 추가함으로써 나머지 작업을 처리할 것이다. 이 기능을 이용하여 제품을 설정하는 것도 가능한데, 사실 여러분은 업데이트 매커니즘을 이용하기 위해 이 기능을 이용할 필요가 있다.
실행기(launcher)는 여러분의 애플리케이션을 시작시키는 실행파일과 관련되어 있다. 이 페이지에서 여러분은 파일 브라우저에서 보여지는 아이콘과 이름을 지정할 수 있다. 브랜드 페이지는 애플리케이션 브랜드화에 관련되어 있다. 이것은 스플래시 스크린, 시작시의 진행율 표시바의 위치(선택사항), 윈도 아이콘, 그리고 about 대화상자에 대한 설정을 포함한다. 이 페이지에서 지정한 정보는 프로젝트를 내보낼 때(export) 사용된다.
여러분의 애플리케이션이 내보내어질 때, 설정 페이지에 나열된 모든 플러그인들은 브랜드 정보와 여러분의 파일 시스템상의 디렉토리에 대한 필수 이클립스 설정과 함께 (만약 필요하다면) 빌드되어 복사된다. 여러분의 애플리케이션을 구동시키는 데 필요한 것은 Java 가상머신과 결합된 이 디렉토리 뿐이다.
여러분의 애플리케이션을 단지 실행시키기 위해 내보내기 할 필요는 없는데, 여러분은 워크벤치내에서 직접 실행시킬 수 있다. 이것은 여러분의 설정을 테스트하고 문제들을 확인하고 해결하기 위해 디버거를 사용하기 위한 최적의 방법이다. "Launch the product"와 "Launch the product in Debug mode"라고 하이퍼링크되어 표시되어 있는 옵션들은 실행모드나 디버그 모드 중에서 실행 설정을 생성하고 구동시킨다.
플랫폼 구축하기
지금까지의 내용들은 몇몇의 매우 잘 정의된 플러그인의 집합으로 구성되는 애플리케이션에 초점을 맞추었다. 이클립스의 좀 더 우수한 강점 중 하나는 컴포넌트를 동적으로 탐색하고 불러들이는 능력이다. 이 능력은 개발자가 매우 확장성있는 애플리케이션을 구축하는데 있어 상당한 힘을 실어준다. 극단적으로 여러분의 RCP 애플리케이션을 여러분 자신만의 공개 API를 가진 파운데이션으로서 구축할 수도 있다.
Contributing to Eclipse: Principles, Patterns, and Plug-Ins 책에서 저자는 확장성에 관련된 몇 가지 규칙에 대해 다루고 있는데, 가장 처음에 "가능할 때마다, 다른 이가 여러분이 기여하는 것에 기여하게 하라"라는 "초대 규칙"(Invitation Rule)에 대해 언급되어 있다. 다른 이가 기여토록 하기 위해 여러분은 다른 개발자가 그들만의 행위를 통해 여러분의 애플리케이션을 증대시킬 수 있도록 해주는 여러분만의 확장점(extension point)의 집합을 정의할 수 있다. 이클립스 워크벤치는 이러한 메커니즘을 집중적으로 이용하여 개발자가 그들만의 뷰, 에디터, 메뉴 항목, 그리고 그 밖의 것들을 추가하도록 허용한다.
할일(to do) 목록을 관리하는 RCP 애플리케이션을 생각해 보자. 이 애플리케이션의 핵심 기능은 할일 태스크에 대한 객체 표현을 제공하는 것과 태스크 목록을 시각화하는 능력이다. 목록의 시각적인 표현은 그림 5에 나타나 있다.
그림 5. 할일 목록 뷰
이 애플리케이션은 그 자체로서도 다소 흥미롭다. 하지만 이 애플리케이션을 확장에 개방함으로써 중요한 기능들이 더 폭넓은 커뮤니티에 양도된다. 태스크 정보를 저장하는 메커니즘을 하드코딩하여 이 애플리케이션을 개발하는 것이 상대적으로 쉽긴 하다. 하지만 하드코딩하는 대신 여러분은 다른 개발자가 그들만의 저장 메커니즘을 확장점을 통해 여러분의 코드에 후킹하도록 애플리케이션을 개방하는 것에 대해 고려할지도 모른다. 여러분의 초기 구현은 로컬 데이터베이스에 정보를 저장하는 능력을 제공하기 위해 확장점을 이용할 수 있다. 또 다른 개발자는 웹 서비스나 다른 어떤 메커니즘을 사용하여 원격 서버에 정보를 제공하기 위해 여러분의 애플리케이션을 확장할지도 모른다.
또한 여러분의 애플리케이션이 어떠한 방식으로 데스크톱과 상호작용할지에 대해 생각해 보라. 애플리케이션에 드래그 앤 드롭 지원을 제공하는 것이 상대적으로 쉽다. 하지만 어디서부터 드래그 할 것인가? 여러분의 초기 구현에서 여러분은 탐색기에서 여러분의 애플리케이션으로 텍스트를 드래그하는 기능을 제공할지도 모른다. 만약 여러분의 애플리케이션에 확장점을 구축하면 여러분은 다른 개발자가 마이크로소프트 아웃룩(Microsoft Outlook)이나 모질라 썬더버드(Mozilla thunderbird)와 같은 다른 애플리케이션으로부터 드래그하도록 여러분의 애플리케이션을 확장할 수 있게끔 할 수 있다.
확장점을 생성함으로써 여러분은 여러분 자신과 다른 개발자들에게 여러분의 애플리케이션을 변경하지 않고도 확장할 수 있게끔 할 수 있다. 동적으로 사용가능한 확장기능을 탐색하는 확장점을 이용하여 여러분의 애플리케이션을 완전히 커스터마이즈가 가능하게 할 수 있다. 그렇지 않을 수도 있지만 예를 들어 리눅스용으로 구축해 놓은 여러분의 애플리케이션에 아웃룩으로부터 드래그 앤 드롭 할 수 있는 기능을 포함시키는 것은 현명한 일인데, 그러한 설정을 위해 여러분은 단순히 아웃룩에 대한 지원을 제공하는 플러그인만을 포함하는 것만으로 가능하지는 않다.
물론 확장점 메커니즘을 효과적으로 사용하는 것은 연습이 필요하다.
결론
이클립스 RCP는 리치 클라이언트 애플리케이션과 그 이상의 것들을 구축하는 데 있어 강력한 프레임워크이다. RCP에 대해 처음에 살펴봤던 것은 네이티브 룩 앤 필, 윈도 관리, 쌓아 올릴 수 있는(stackable) 에디터와 뷰로써 특화되어 있는 커스터마이즈 가능함, 그리고 이상의 것들을 포함하여 호스트 플랫폼에 밀접하게 통합되어 있음을 보여준다. 하지만 이것은 단지 수박 겉핥기에 불과하다. RCP의 중심부에는 강력함과 유연함의 세계로 인도해주는 OSGi 규격을 따르는 컴포넌트 모델이 놓여있다. 컴포넌트는 필요할 때 동적으로 발견되어 불러들여지며 그것들은 업데이트 및 확장 가능하다.
이클립스 RCP를 도입하는 발전된 접근방법은 당연한 것이다. 여러분이 처음 이클립스 RCP에 진입하게 되면 사용자 인터페이스 측면과 같은 것에 집중하게 될 것이다. 여러분이 컴포넌트 모델에 점점 더 익숙해질수록 애플리케이션 코드를 여러 개의 플러그인으로 분할하게 된다. 궁극적으로 다수의 확장가능한 플러그인에 기반한 도메인 특징적인 플랫폼을 통해 개발함으로써 이클립스의 진정한 강력함이 밝혀질 것이다.
리소스 Wayne Beaton는 에반젤리스트로서 활동하고 있는 이클립스 재단에 고용되어 기술을 전도하고 이클립스 기술을 도입하는 사람들에게 도움을 주고 있다.
저자: Wayne Beaton, 이대엽 역
원문: http://www.onjava.com/pub/a/onjava/2006/08/23/eclipse-rich-client-platform.html
기술은 일정한 주기를 가진다. 지난 10년 동안의 씬 클라이언트(thin client)의 시대를 지나, 리치 클라이언트(rich client) 기술이 컴백하고 있다. 수많은 조직들이 그들의 애플리케이션을 리치 클라이언트로 구축하고 있으며 그들 중 다수가 그들의 애플리케이션을 이클립스 리치 클라이언트 플랫폼(Eclipse Rich Client Platform; RCP)에 기반하고 있다. "rich client"라는 용어는 첫째로는 애플리케이션이 사용자에게 풍부한 경험을 제공함을, 둘째로는 애플리케이션이 몇몇 서버의 클라이언트임을 의미한다. 반드시 리치 클라이언트가 대응되는 서버 컴포넌트를 가져야 하는 것은 아니지만 대개의 경우에 그러하다.
리치 클라이언트는 팻 클라이언트(fat client)에 비해 많은 점에서 차이가 있다. 둘 모두 사용자에게 씬 클라이언트 기술을 사용해서는 제공하기 곤란하고, 별로 바람직하지 않으며 혹은 아예 불가능한 정보의 표현과 기능을 자연스러운 데스크톱 경험을 통해 제공해 준다. 하지만 리치 클라이언트는 그 이상의 것들을 제공한다. 팻 클라이언트가 배치 및 업데이트가 힘든 커다란 한 덩어리의 애플리케이션이 되려는 경향이 있는 반면, 리치 클라이언트는 좀 더 경량이며 그들 자신을 상대적으로 배치 및 업데이트에 용이한 컴포넌트 모델에 기반한다. 예전부터 팻 클라이언트는 특정한 플랫폼으로서 구축되어 왔는데, 오늘날의 리치 클라이언트 기술들은 아랫단에 위치한 플랫폼의 능력을 외부에 노출시키는 반면 플랫폼의 세부사항은 숨기는데, 이는 개발자로 하여금 어떤 특정한 플랫폼에 국한된 특수한 세부사항 보다는 주어진 과업(task)에 집중할 수 있게끔 해준다.
리치 클라이언트는 또한 팻 클라이언트에 비해 좀더 확장되려는 경향을 띤다. 전통적으로 팻 클라이언트는 데이터베이스에 직접적으로 연결되어 있다. 이것은 팻 클라이언트가 실행될 수 있는(방화벽이 팻 클라이언트로부터 데이터베이스에 이르는 연결을 제한할지도 모른다) 환경을 제약하며 애플리케이션의 확장성(클라이언트로부터 서버에 이르는 전체 연결 개수)이 데이터베이스에 의해 제한될지도 모른다. 리치 클라이언트는 데이터베이스로의 연결 생성에 대한 책임을 맡고 있는 애플리케이션 서버를 이용하려는 경향을 띤다. 이러한 설정은 매우 유연하며(방화벽에 친화적인) 확장성이 높다. 물론 팻 클라이언트에 대한 애플리케이션 서버의 통신을 부득이하게 제한하는 기술은 없으며, 그것은 단지 팻 클라이언트 기술의 전성기때나 그랬던 것이며 현재의 애플리케이션 서버들이 동작하는 방식대로 동작하는 애플리케이션 서버들이 존재하지도 않았다.
리치 클라이언트 애플리케이션이 어떤 대응되는 서버의 클라이언트가 되어야 한다는 것에 대한 규정은 없다. 리치 클라이언트 기술을 이용하는 많은 조직들은 강건하고(robust), 확장가능하며(extendable), 업데이트 가능하며(updatable), 지역화된(localized), 독립적인(standalone) 애플리케이션을 구축하고 있다. 비슷하게 리치 클라이언트도 애플리케이션 서버를 이용하려는 경향을 띠는데, 이것을 사실화시키는 어떠한 강제적인 규약이나 기술적인 제약은 없다는 것이다. 즉, 리치 클라이언트 애플리케이션이 왜 데이터베이스에 직접적으로 접근할 수 없는지에 대한 이유는 없다.
리치 클라이언트 기술은 팻 클라이언트 기술과 씬 클라이언트 기술의 강점만을 결합한 것임을 나타내는데, 이러한 강점들에는 풍부한 사용자 경험, 높은 확장성, 플랫폼 독립성, 그리고 매우 용이한 배치와 업데이트가 있다.
이클립스 RCP는 이클립스 플랫폼의 핵심부분에 위치한 기능이다. 대부분의 사람들이 이클립스를 떠올릴 때 자바 통합 개발 환경(IDE)으로 생각한다. IDE를 구성하는 이클립스의 각 구성요소를 떼어 버리고 나면, 메뉴, 도구바, 푸시 버튼, 테이블, 트리, 그리고 그 외의 많은 이동가능하고(movable) 차곡차곡 쌓아 올릴 수 있는(stackable) 윈도 컴포넌트(편집기와 뷰)에 대한 지원을 포함하는 가장 기본적인 워크벤치(workbench) 기능만이 제공되는 핵심 요소만이 남게 된다. 바로 이 핵심기능이 이클립스 RCP이다.
이클립스 RCP는 애플리케이션 개발자에게 다음과 같은 것들을 제공한다:
- 애플리케이션과 기능에 대한 일관성 있는 네이티브 룩 앤 필(native look and feel)
- 윈도 관리, 업데이트 관리, 도움말 그리고 선택(selection) 관리와 같은 공통 애플리케이션 서비스
- Windows, Mac OSX, Linux, Solaris, HP-UX, AIX, 그리고 임베디드 장치상의 실제 플랫폼 위젯을 이용하는 네이티브 룩 앤 필
- 표준화된 컴포넌트 모델
- 편재되어 있는 확장가능성
- 통합 업데이트 메커니즘
- 최고 수준의 개발 도구(이클립스 SDK는 세계적 수준의 소프트웨어 개발 환경임)
컴포넌트
이클립스 RCP는 수많은 컴포넌트로 구성되며, 그리고 각각의 컴포넌트는 개발 환경의 전체 기능 중 각 부분에 대해 기여한다. 사실 거의 모든 이클립스 RCP는 컴포넌트로 구성되는데 부트스트랩에 관련된 소량의 코드를 제외한 RCP의 모든 부분은 컴포넌트이다. 컴포넌트는 보통 이클립스 테두리(혹은 OSGi 용어로는 번들)내의 플러그-인으로 알려져 있다. "플러그-인"이라는 용어는 컴포넌트 내에 포함된 기능은 아무래도 부차적인 기능 혹은 내장된 기능에 대한 애드온(add-on) 정도임을 내포한다. 하지만 사실은 그렇지 않다. 이클립스 RCP는 모든 플러그인에 대하여 동일하게 취급하며 어디에도 내장된 기능과 커스텀 기능에 대한 명시적인 구분이 없다. 즉 여러분의 애플리케이션의 움직임을 보조하기 위해 직접 작성한 플러그인은 이클립스 RCP를 구성하는 것과 나란히 실행된다.
리치 클라이언트 애플리케이션을 개발하기 위한 자연스러운 방법은 하나의 플러그인을 개발하는 것부터 시작하는 것이다. 하나의 플러그인 안에 여러분의 애플리케이션을 위한 전체 인터페이스, 비즈니스 로직, 그리고 객체 모델을 정의할 수 있다. 새로운 이클립스 리치 클라이언트 플랫폼(RCP) 애플리케이션을 작성하는 것은 단순히 File>New>Project의 메뉴 항목을 선택하는 것만큼이나 쉬우며, new Plug-in Project를 선택한 다음, 마법사에서 나타나는 몇 가지 단계를 따라가기만 하면 된다. 마법사 중간의 Content Page 부분에서 나타나는 질문인 "리치 클라이언트 애플리케이션을 작성하시겠습니까?(Would you like to create a rich client application?)"라는 질문에는 반드시 "예(Yes)"를 선택해야 한다. 마법사 중 템플릿 페이지에 관한 것이 그림 1에 나타나 있는데, 여기에서는 뷰를 가진 RCP 애플리케이션 작성을 위해 "RCP application with a view"를 선택한다.
그림 1 New Plug-in Project 마법사의 템플릿 페이지
이것은 워크벤치(메뉴 바와 도구 바)와 테이블을 하나 가지는 한 개의 뷰에 대한 설정을 포함하는 RCP 애플리케이션을 만드는데 필요한 부분들을 포함하는 새로운 플러그인을 생성할 것이다.(그림 2 참조)
그림 2. 마법사는 완전한 기능을 갖춘 RCP 애플리케이션을 생성한다.
마법사는 다음의 클래스들을 생성한다.
- Application.java
- 생성된 Application 클래스는 run이라는 하나의 메소드를 포함하는데, run(Object args) 메소드는 애플리케이션을 실행하는 것을 책임진다. 이 메소드는 부트스트랩을 수행하며 워크벤치 창을 연다. 이 메소드가 종료되면 애플리케이션 역시 종료된다.
- ApplicationActionBarAdvisor.java
- ApplicationActionBarAdvisor 클래스는 메뉴 바, 도구 바, 그리고 상태표시줄을 생성하는 것을 책임진다. 생성된 클래스는 하나의 File 메뉴에 Exit 메뉴 항목을 가진 메뉴바를 생성한다. 여러분의 워크벤치 창에 도구바를 추가하기 위해 fillCoolBar(ICoolBarManager coolBar)를 추가할 수도 있다. 비슷한 방법으로 워크벤치 창에 상태표시줄을 추가하기 위해 fillStatusLine(IStatusLineManager statusLine)을 추가할 수 있다.
- ApplicationWorkbenchAdvisor.java
- ApplicationWorkbenchAdvisor 클래스는 수많은 훅을 애플리케이션 라이프 사이클(application life cycle) 동안 제공한다. 예를 들어, 여러분은 애플리케이션이 시작하거나 종료될 때 호출되는 메소드를 추가할 수 있다. 하지만 생성된 구현은 사용자에게 보여지는 최초 퍼스펙티브를 지정하는 것에 비해 그다지 낫진 않다.
- ApplicationWorkbenchWindowAdvisor.java
- ApplicationWorkbenchAdvisor와 같이 ApplicationWorkbenchWindowAdvisor 클래스는 워크벤치 라이프 사이클(workbench life cycle) 동안 훅을 제공한다. 여러분은 워크벤치가 생성되거나, 열리거나, 이전 크기로 복원되거나, 혹은 닫힐 때 호출되는 메소드를 추가할 수 있다. 생성된 구현은 preWindowOpen() 메소드를 제공하는데 이 메소드는 도구바와 상태표시줄(둘 모두 보이지 않는다)의 가시성뿐만 아니라 창의 최초 크기와 제목을 설정한다.
- Perspective.java
- 이클립스 SDK는 수많은 퍼스펙티브(perspectives)를 제공한다. 생성된 애플리케이션은 하나를 포함하는데, 여러분은 추가적으로 필요한 만큼 퍼스펙티브를 지정할 수 있다. 생성된 퍼스펙티브는 편집 영역을 숨기며(즉, 퍼스펙티브에는 아무런 편집기도 보여지지 않는다) 마법사에 의해 생성된 뷰를 추가한다. 퍼스펙티브는 고정되도록 설정되는데, 퍼스펙티브의 뷰는 친숙한 제목 표시줄 없이 보여지며 이동이 불가능하다. 설정값을 false에서 true로 변경함으로써(그리고 뷰를 몇 개 더 애플리케이션에 추가함으로써) 사용자는 자신의 구미에 맞게 뷰의 위치를 지정할 수 있다.
- View.java
- 생성된 View 클래스는 몇 개의 직접 입력된(hardcoded) 입력사항들을 가진 테이블을 하나 포함하고 있다. 이것이 여러분의 애플리케이션의 외관을 변경시킬 수 있는 부분이다. 만약 테이블이 여러분이 필요로 하는 것이라면 여러분은 여러분의 객체 모델에 맞게 후킹함으로써 제공된 것을 커스터마이즈할 수 있거나 혹은 완전히 그 테이블을 하나 혹은 그 이상의 위젯(widget)들로 대체할 수 있다.
발전된 애플리케이션 구축
이러한 방식으로 애플리케이션을 구축하는 것은 개발자에게 많은 유용한 하부구조(infrastructure)를 노출시켜 준다. 단순히 윈도 컴포넌트의 집합 이상으로 RCP 애플리케이션은 여러분의 애플리케이션의 에디터와 뷰(위치를 재설정하고 쌓아 올릴 수 있는 능력을 포함한), 도구 바, 메뉴, 선택사항 관리, 그리고 더욱 더 많은 것들에 대한 높은 수준의 관점을 포함하는 사용자 인터페이스를 관리하기 위한 프레임워크를 제공한다. 하지만 이러한 방식으로 애플리케이션을 구축하는 것은 이클립스에서 가능케 해주는 힘에 대한 겉핥기에 불과하다. 이것은 처음으로 이클립스 애플리케이션 구축에 파고들어 보는 데에는 더할 나위 없으며 자연스럽게 다음 단계는 실제 컴포넌트 구축을 시작해 보는 것이다.
플러그인은 이클립스 플랫폼의 강력한 기능이다. 사실 이클립스 SDK 자체는 플러그인의 집합일 뿐이다. 이클립스 내부에는 플러그인이 아닌 것이 거의 없다(단지 상대적으로 적은 양의 부트스트랩 코드만이 있을 뿐). 이것이 이클립스를 매우 확장성있게 만든다. 새로운 기능은 프레임워크에 의해 동적으로 발견되고 설치되는 하나 혹은 그 이상의 플러그인을 생성함으로써 SDK에 추가된다. 플러그인은 존재하는 것 자체만으로 발견되며 플러그인 안에는 플러그인을 추가할 때 업데이트를 필요로 하는 manifest 파일조차 없다.
이클립스 SDK처럼 RCP 애플리케이션은 플러그인의 집합이다. 플러그인은 다양한 모양과 크기를 띠고 애플리케이션 내에 포함된다. 위에서 본 것과 같이 여러분은 RCP 자체를 구현하는 플러그인의 집합에 추가된 하나의 플러그인을 이용하여 완전한 이클립스 RCP 애플리케이션을 구축할 수 있다. 아니면 애플리케이션의 일부분들을 각각 구현하는 많은 플러그인의 집합으로서의 RCP 애플리케이션을 구축할 수 있다.
많은 플러그인들의 집합으로서의 RCP 애플리케이션을 구축하는 것은 많은 이점을 가지는 데 그러한 이점에는 다음과 같은 것들이 있다:
- 게으른 로딩(lazy-loading)
- 이클립스는 플러그인이 필요할 때가 되면 그것을 로딩할 것이다. 만약 여러분이 애플리케이션을 여러 개의 플러그인으로 분할해 놓으며 이 기능을 이용하여 애플리케이션의 시작시간을 줄이고 메모리 사용을 향상시킬 수 있다. 시작시에는 전체 애플리케이션이 로딩되는 것이 아니라 초기에 필요한 만큼의 플러그인 집합이 로딩될 것이며 이렇게 함으로써 애플리케이션 시작시 필요로 하는 시간과 메모리의 양을 줄일 수 있다.
- 업데이트
- 이클립스는 업데이트를 필요로 할 때 개별 플러그인의 업데이트가 가능하다. 여러분의 애플리케이션이 여러 플러그인으로 나누어져 있으며 실질적으로 필요한 플러그인들만 다운로드하여 설치할 수 있다. 이렇게 함으로써 애플리케이션을 업데이트할 때 필요로 하는 시간과 자원의 양을 줄일 수 있다.
- 확장성
- 애플리케이션을 다수의 플러그인으로 나누는 것은 확장점을 생성하는 것을 촉진시키는데, 이러한 확장점은 현 시점에서 생각하지 못할 수 있는 것으로서 차후에 이용할 수 있다.
- 재사용
- 여러분의 애플리케이션을 컴포넌트의 집합으로서 작성하는 것은 여러분에게 이러한 컴포넌트들을 다른 애플리케이션에서 코드의 변경없이 재사용할 수 있는 기회를 제공해 준다.
- 더 나은 설계
- 다수의 컴포넌트를 만드는 것은 더 나은 설계를 하도록 도와준다. 여러분의 애플리케이션을 분할하면 여러분은 컴포넌트들간의 인터페이스를 어떻게 정의할 것이며 컴포넌트들간의 소통을 어떻게 용이하게 할 수 있는지에 대한 주요한 문제들에 대해 생각해 보아야 한다. 불행히도 여러분이 멋진 설계로 마무리할지에 대해 보장해 주는 것은 아무것도 없지만, 이러한 방법은 확실히 권장된다.
이클립스 컴포넌트 모델은 이러한 방식의 아키텍처상에서 탁월한 서비스를 제공한다. 가시성 모델을 강제함으로써 이클립스는 능동적으로 개발자로 하여금 사용자 인터페이스 코드를 모델(물론 진짜 프로그래머들은 전후 좌우를 살펴 해결할 수 있다)에 포함시키지 않도록 해준다. 사용자 인터페이스 플러그인의 집합은 모두 비즈니스 로직 플러그인(그리고 다른)들을 의존성으로서 가지고 있는데, 뷰는 모델을 볼 수 있지만, 그 반대는 볼 수 없다. 이러한 방식의 분리를 권장함으로써 코드 내의 결합정도가 줄어들며 이것은 코드를 변화에 대해 훨씬 덜 불안정하며 영구적으로 더 재사용 가능하게 만든다.
컴포넌트 조립
여러분의 애플리케이션 코드가 여러 플러그인으로 분할되어 있다면 RCP 애플리케이션을 작성하는 것은 그러한 플러그인들을 연결된 하나의 완전한 애플리케이션으로 조립하는 과정이다. 애플리케이션이 필요로 하는 플러그인들의 집합을 정의하는 것은 제품 설정의 역할 중 하나이다. 제품 설정은 스플래시 화면(splash screen), 윈도 아이콘, about 대화상자 이미지와 텍스트, 그리고 그 밖의 여러 가지에 대한 브랜드 정보가 위치하는 곳이기도 하다.
플러그인의 집합으로부터 애플리케이션을 조립하는 것은 간단한 과정이다. 사실 그 과정의 가장 큰 문젯거리는 애플리케이션 브랜드화에 관련된 예술적인 과정인데, 그러한 과정은 브랜드화 과정의 일부분으로서 여러분은 스플래시 스크린, 윈도 아이콘, 실행 아이콘, 그리고 about 대화상자 그림을 추가할 수 있다. 메뉴의 File > New > Product Configuration을 차례로 선택함으로써 여러분의 애플리케이션에 대한 제품 설정을 작성할 수 있다. 제품 설정 마법사가 그림 3에 나타나 있다.
그림 3. "새 제품 설정" 마법사
신규 제품 설정 작성의 일부분으로써 여러분은 부모 플러그인 프로젝트를 지정할 필요가 있다. 일반적으로 이것은 애플리케이션을 정의하는 플러그인이다. 아래에 3가지 서로 다른 초기 설정을 작성하는 방법이 나열되어 있다:
- 기본 설정을 가진 설정 파일을 생성한다. 이 옵션을 선택하면 여러분 자신이 완성해야만 하는 빈 설정 파일이 생성된다.
- 이미 존재하는 제품을 사용한다. 이 옵션을 선택하면 여러분은 기존의 이미 존재하는 제품 설정내의 값에 기초하여 새로운 설정 파일이 생성된다.
- 실행 설정을 사용한다. 이 옵션을 선택하면 초기 설정은 이미 존재하는 실행 설정에 참조된 플러그인들의 집합에 기초하게 된다. 여러분이 이미 이전에 Run As > Eclipse Application 메뉴 항목을 사용하여 여러분의 애플리케이션을 구동시켜 본적이 있다면 이 옵션을 사용하는 것이 좋다.
제품 설정 편집기(그림 4 참조)의 Configuration 탭에서 여러분의 애플리케이션이 필요로 하는 플러그인의 이름을 지정하도록 하는 것을 볼 수 있다.
그림 4. 제품 설정 편집기의 설정 페이지
플러그인 목록은 여러분의 애플리케이션이 필요로 하는 다른 플러그인과 함께 애플리케이션 플러그인을 포함할 필요가 있다. 편집기는 여러분에게 어떤 플러그인이 필요할지를 선별하는 것을 도와준다. 여러분 애플리케이션의 플러그인을 목록에 추가한 다음, Add Required Plug-ins라고 표시된 버튼을 누르면 그러한 플러그인 등에 필요한 플러그인인 여러분의 플러그인에 참조된 모든 플러그인을 추가할 것이다. 이 설정은 이클립스 플랫폼 자체로부터 많은 플러그인들을 포함할 것이다. 이 버튼을 사용하면 여러분은 최상위 레벨의 플러그인만을 포함하면 되며 편집기가 알아서 최상위 레벨의 플러그인이 의존하고 있는 플러그인들을 검색하여 추가함으로써 나머지 작업을 처리할 것이다. 이 기능을 이용하여 제품을 설정하는 것도 가능한데, 사실 여러분은 업데이트 매커니즘을 이용하기 위해 이 기능을 이용할 필요가 있다.
실행기(launcher)는 여러분의 애플리케이션을 시작시키는 실행파일과 관련되어 있다. 이 페이지에서 여러분은 파일 브라우저에서 보여지는 아이콘과 이름을 지정할 수 있다. 브랜드 페이지는 애플리케이션 브랜드화에 관련되어 있다. 이것은 스플래시 스크린, 시작시의 진행율 표시바의 위치(선택사항), 윈도 아이콘, 그리고 about 대화상자에 대한 설정을 포함한다. 이 페이지에서 지정한 정보는 프로젝트를 내보낼 때(export) 사용된다.
여러분의 애플리케이션이 내보내어질 때, 설정 페이지에 나열된 모든 플러그인들은 브랜드 정보와 여러분의 파일 시스템상의 디렉토리에 대한 필수 이클립스 설정과 함께 (만약 필요하다면) 빌드되어 복사된다. 여러분의 애플리케이션을 구동시키는 데 필요한 것은 Java 가상머신과 결합된 이 디렉토리 뿐이다.
여러분의 애플리케이션을 단지 실행시키기 위해 내보내기 할 필요는 없는데, 여러분은 워크벤치내에서 직접 실행시킬 수 있다. 이것은 여러분의 설정을 테스트하고 문제들을 확인하고 해결하기 위해 디버거를 사용하기 위한 최적의 방법이다. "Launch the product"와 "Launch the product in Debug mode"라고 하이퍼링크되어 표시되어 있는 옵션들은 실행모드나 디버그 모드 중에서 실행 설정을 생성하고 구동시킨다.
플랫폼 구축하기
지금까지의 내용들은 몇몇의 매우 잘 정의된 플러그인의 집합으로 구성되는 애플리케이션에 초점을 맞추었다. 이클립스의 좀 더 우수한 강점 중 하나는 컴포넌트를 동적으로 탐색하고 불러들이는 능력이다. 이 능력은 개발자가 매우 확장성있는 애플리케이션을 구축하는데 있어 상당한 힘을 실어준다. 극단적으로 여러분의 RCP 애플리케이션을 여러분 자신만의 공개 API를 가진 파운데이션으로서 구축할 수도 있다.
Contributing to Eclipse: Principles, Patterns, and Plug-Ins 책에서 저자는 확장성에 관련된 몇 가지 규칙에 대해 다루고 있는데, 가장 처음에 "가능할 때마다, 다른 이가 여러분이 기여하는 것에 기여하게 하라"라는 "초대 규칙"(Invitation Rule)에 대해 언급되어 있다. 다른 이가 기여토록 하기 위해 여러분은 다른 개발자가 그들만의 행위를 통해 여러분의 애플리케이션을 증대시킬 수 있도록 해주는 여러분만의 확장점(extension point)의 집합을 정의할 수 있다. 이클립스 워크벤치는 이러한 메커니즘을 집중적으로 이용하여 개발자가 그들만의 뷰, 에디터, 메뉴 항목, 그리고 그 밖의 것들을 추가하도록 허용한다.
할일(to do) 목록을 관리하는 RCP 애플리케이션을 생각해 보자. 이 애플리케이션의 핵심 기능은 할일 태스크에 대한 객체 표현을 제공하는 것과 태스크 목록을 시각화하는 능력이다. 목록의 시각적인 표현은 그림 5에 나타나 있다.
그림 5. 할일 목록 뷰
이 애플리케이션은 그 자체로서도 다소 흥미롭다. 하지만 이 애플리케이션을 확장에 개방함으로써 중요한 기능들이 더 폭넓은 커뮤니티에 양도된다. 태스크 정보를 저장하는 메커니즘을 하드코딩하여 이 애플리케이션을 개발하는 것이 상대적으로 쉽긴 하다. 하지만 하드코딩하는 대신 여러분은 다른 개발자가 그들만의 저장 메커니즘을 확장점을 통해 여러분의 코드에 후킹하도록 애플리케이션을 개방하는 것에 대해 고려할지도 모른다. 여러분의 초기 구현은 로컬 데이터베이스에 정보를 저장하는 능력을 제공하기 위해 확장점을 이용할 수 있다. 또 다른 개발자는 웹 서비스나 다른 어떤 메커니즘을 사용하여 원격 서버에 정보를 제공하기 위해 여러분의 애플리케이션을 확장할지도 모른다.
또한 여러분의 애플리케이션이 어떠한 방식으로 데스크톱과 상호작용할지에 대해 생각해 보라. 애플리케이션에 드래그 앤 드롭 지원을 제공하는 것이 상대적으로 쉽다. 하지만 어디서부터 드래그 할 것인가? 여러분의 초기 구현에서 여러분은 탐색기에서 여러분의 애플리케이션으로 텍스트를 드래그하는 기능을 제공할지도 모른다. 만약 여러분의 애플리케이션에 확장점을 구축하면 여러분은 다른 개발자가 마이크로소프트 아웃룩(Microsoft Outlook)이나 모질라 썬더버드(Mozilla thunderbird)와 같은 다른 애플리케이션으로부터 드래그하도록 여러분의 애플리케이션을 확장할 수 있게끔 할 수 있다.
확장점을 생성함으로써 여러분은 여러분 자신과 다른 개발자들에게 여러분의 애플리케이션을 변경하지 않고도 확장할 수 있게끔 할 수 있다. 동적으로 사용가능한 확장기능을 탐색하는 확장점을 이용하여 여러분의 애플리케이션을 완전히 커스터마이즈가 가능하게 할 수 있다. 그렇지 않을 수도 있지만 예를 들어 리눅스용으로 구축해 놓은 여러분의 애플리케이션에 아웃룩으로부터 드래그 앤 드롭 할 수 있는 기능을 포함시키는 것은 현명한 일인데, 그러한 설정을 위해 여러분은 단순히 아웃룩에 대한 지원을 제공하는 플러그인만을 포함하는 것만으로 가능하지는 않다.
물론 확장점 메커니즘을 효과적으로 사용하는 것은 연습이 필요하다.
결론
이클립스 RCP는 리치 클라이언트 애플리케이션과 그 이상의 것들을 구축하는 데 있어 강력한 프레임워크이다. RCP에 대해 처음에 살펴봤던 것은 네이티브 룩 앤 필, 윈도 관리, 쌓아 올릴 수 있는(stackable) 에디터와 뷰로써 특화되어 있는 커스터마이즈 가능함, 그리고 이상의 것들을 포함하여 호스트 플랫폼에 밀접하게 통합되어 있음을 보여준다. 하지만 이것은 단지 수박 겉핥기에 불과하다. RCP의 중심부에는 강력함과 유연함의 세계로 인도해주는 OSGi 규격을 따르는 컴포넌트 모델이 놓여있다. 컴포넌트는 필요할 때 동적으로 발견되어 불러들여지며 그것들은 업데이트 및 확장 가능하다.
이클립스 RCP를 도입하는 발전된 접근방법은 당연한 것이다. 여러분이 처음 이클립스 RCP에 진입하게 되면 사용자 인터페이스 측면과 같은 것에 집중하게 될 것이다. 여러분이 컴포넌트 모델에 점점 더 익숙해질수록 애플리케이션 코드를 여러 개의 플러그인으로 분할하게 된다. 궁극적으로 다수의 확장가능한 플러그인에 기반한 도메인 특징적인 플랫폼을 통해 개발함으로써 이클립스의 진정한 강력함이 밝혀질 것이다.
리소스 Wayne Beaton는 에반젤리스트로서 활동하고 있는 이클립스 재단에 고용되어 기술을 전도하고 이클립스 기술을 도입하는 사람들에게 도움을 주고 있다.
TAG :
이전 글 : 태블로(Tableau)로 데이터베이스 정보 시각화
다음 글 : 뉴라인(newlines)에 대한 이해
최신 콘텐츠