JSR을 보면 자바의 미래가 보인다
자바에 대해 잘 아는 사람들이라면 JCP와 JSR이 무엇인지는 알고 있을 것이다. 필자는 언젠가 기회가 한 번 되면 JSR에서 리뷰되고 있는 자바와 관련된 무수한 기술적인 논의를 전체적으로 정리하는 작업을 하려고 했는데, 그 동안 손을 대지 못하다가 못 다한 숙제를 하는 기분으로 시도해 보기로 했다. 지면 관계상 자칫 수박 겉핥기처럼 제목과 내용에 대한 간단한 소개로 끝나버릴 수도 있다는 걱정이 앞서지만 기회가 닿으면 각론을 다룰 것을 약속하면서 JCP와 JSR의 큰 틀을 소개한다.
정지훈 (마이크로소프트웨어)
2002/02/19
JSR(Java Specification Requests)은 자바 플랫폼에 대한 규격을 제안하거나 기술한 것을 말한다. 현재 수많은 JSR이 만들어지고 리뷰되고 이를 기반으로 플랫폼이 추가되고 있으며, 이미 많은 JSR이 구현되어 J2EE·J2SE·J2ME 등에 포함되어 있다. 따라서 JSR에 어떠한 내용이 논의되고 있으며, 어떻게 논의가 진행되고 있는지 파악하면 미래의 자바의 모습을 자연스럽게 유추해 볼 수 있다.
JCP와 JSR
1998년 12월 5일, 썬 마이크로시스템즈는 자바의 원천 소스 코드를 공개하겠다고 발표하고, 12월 8일 새로운 자바 소스의 라이선스 정책과 함께 자바 표준화에 관한 권리를 '자바 공동체'에 이양하겠다고 발표했다. SCSL(Sun Community Source Licence)과 JCP(Java Community Process)는 각각 라이선스와 표준화에 대한 썬의 자바 정책에 대한 공식적인 입장 표명이었다.
JCP는 자바 플랫폼의 표준화를 진행하기 위한 표준적인 절차다. JCP 집행위원회는 자바 명세서, 레퍼런스 구현, 호환성 검사 툴의 개발을 담당하는 커뮤니티이고 이 커뮤니티는 JCP 2.0이 발표됨과 동시에 J2SE, J2EE와 같은 데스크톱, 서버 환경의 자바 기술을 감독하는 위원회와 소비자, 임베디드 환경의 자바 기술인 J2ME의 자바 기술을 감독하는 위원회로 나뉘어졌다. 현재 JCP 집행위원회에는 세계 굴지의 기업들이 참여하고 있으며, 자바의 표준화는 이 회원사들 간의 협력을 통해 진행되고 있다.
JSR은 가장 처음 제기되는 요구 사항을 바탕으로 초기 투표를 통해 논의할 것인지 결정하고, 이어서 커뮤니티 리뷰 일자를 정해 이때까지 만들어진 규격을 커뮤니티에 가입된 사람들을 대상으로 리뷰하게 된다. 그리고 나서 퍼블릭 리뷰에 들어가는데, 이때 피드백을 받아 채택하는 단계를 거친다.
그러면, 먼저 채택되어 개발됐거나, 개발되고 있는 JSR의 목록부터 살펴보자. JSR-000001인 'Real-time Specification for Java'에서 JSR-000150인 'Internationalization Service for J2EE'까지 모두 150개 중에서 중복되거나 투표에서 거부된 열다섯 개를 제외한 135개의 JSR이 채택됐다. 이들을 모두 나열하는 것은 책 한 권을 써도 모자라는 분량이므로, 이들 몇 가지 카테고리로 나눠 설명하겠다. 참고로 카테고리는 필자가 개인적으로 나눈 것이므로 틀린 점이 있다면 언제라도 지적해주기 바란다.
자바의 차기 버전을 예측한다.
JSR의 상당 부분은 J2EE, J2SE, J2ME 표준 플랫폼에 포함될 내용을 정의하는 것이다. J2ME를 별개로 하고 J2SE와 J2EE의 차기 플랫폼 표준을 정하는 범주에 속하는 것이 가장 많은데, 그 중에서 앞으로 설명할 카테고리에 들어가지 않은 것들 중에서 중요한 것들로 J2SE에는 JSR-6(Java Print Service API), JSR-12(Java Data Objects Specification), JSR-53(Java Servlet 2.3 and JavaServer Pages 1.3), JSR-54(JDBC 3.0 Specification), JSR-59(J2SE Merlin Contents), JSR-74(PKCS 1.0), JSR-76(RMI Security for J2SE) 등이 있다.
J2EE 쪽에는 대부분 J2SE의 것들과 겹치지만 그렇지 않은 것들만 나열하면 JSR-16(J2EE Connector Architecture), JSR-19(Enterprise JavaBeans 2.0), JSR-77(J2EE Management), JSR-88(J2EE Application Deployment) 등이 있다.
사실 JSR의 대부분은 플랫폼의 차기 모습을 예측할 수 있는 지표가 되며, 여기에서 가장 중요하다고 논의되는 것들을 구현해 새로운 자바 플랫폼을 구현하므로, 새로운 JSR이 어떤 것들이 등장하고 있는지 알아보는 것만큼 앞으로의 자바 플랫폼의 변화를 예측하기 좋은 것도 없다.
XML과 웹 서비스
XML이 최근에 각광받는 만큼 JSR에도 XML과 관련된 것이 대단히 많다. JSR-5(XML Parsing Specification, JAXP)를 시작으로 JSR-31(XML Data Binding Specification), JSR-67(Java APIs for XML Messaging, JAXM), JSR-93(Java APIs for XML Registries, JAXR), JSR-101(Java APIs for XML based RPC), JSR-102(JDOM 1.0) 등이 XML과 관련한 것들이며, XML 보안과 관련한 것이 JSR-104, 105, 106이다. XML을 이용한 웹 서비스와 관련해서는 JSR-109(Implementing Enterprise Web Services), JSR-110(Java APIs for WSDL) 등이 있다.
이러한 XML과 관련한 JSR 중에서 실제로 구현을 끝낸 것들이 속속 등장하고 있으며, 최근의 웹 서비스 열풍에 힘입어, 이들을 엮어서 자바 XML 팩이라는 형태로 이러한 클래스들을 모아 설치하고, 사용할 수 있게 하고 있다. 현재 XML 팩은 Winter01 번들까지 나와 있으며http://java.sun.com/xml/downloads/javaxmlpack.html에서 받을 수 있다. 이 번들에는 JSR-5(JAXP), JSR-67(JAXM), JSR-93(JAXR), JSR-101(JAX-RPC)이 구현되어 포함되어 있다. 이러한 자바 API는 크게 나누어 다음과 같이 문서지향(document-oriented)적인 것과 처리지향(process-oriented)적인 것이 있다.
문서지향적
◆JAXP(Java API for XML Processing) : 다양한 파서를 이용해 XML 문서를 처리한다.
◆JAXB(Java Architecture for XML Binding) : XML 엘리먼트를 자바 프로그래밍 언어의 클래스와 매핑한다.
처리지향적
◆JAXM(Java API for XML Messaging) : 인터넷을 통해 표준적인 방법으로 SOAP 메시지를 전송한다.
◆JAXR(Java API for XML Registries) : 비즈니스 레지스트리에 접근하고, 정보를 공유하는 표준적인 방법을 제공한다.
◆JAX-RPC(Java API for XML-based RPC) : SOAP 메소드 호출을 원격지에 전송하고 결과를 받아온다.
아마도 XML에 대한 자바 API의 기능 중에서 가장 중요한 것은 W3C나 OASIS(Organization for the Advancement of Structured Information Standards) 등의 산업계 표준을 지원하고 상호 운용성을 확보하는 것이라고 생각한다.
XML에 대한 자바 API의 다른 기능으로는 유연성을 확보하는 것이다. 사용자들은 JAXP 코드를 이용해 XML 문서를 처리할 수 있는 다양한 도구를 이용할 수 있고, JAXM 코드를 이용해 SOAP 위에 다양한 메시징 프로토콜을 이용할 수 있다. 구현하는 쪽에서도 상당한 유연성이 생긴다. XML에 대한 자바 API들은 엄격한 호환성에 대한 요구 사항을 정의하고 있기 때문에, 이를 구현하는 측에서는 표준적인 기능을 제공해야 하며, 동시에 특정 기능에 이용할 수 있게 변경할 수 있는 유연성을 개발자들에게 제공해야 한다.
임베디드·리얼타임과 관련한 규격
임베디드 자바 및 J2ME와 관련한 규격으로는 먼저 차세대 J2ME 플랫폼 규격에 관한 JSR-68과 J2ME의 컨피규레이션(configuration)과 관련한 JSR-30(J2ME Connected, Limited Device Configuration), JSR-36(J2ME Connected Device Configuration), JSR-139(Connected Limited Device Configuration Next Generation), 그 밖에 수많은 프로파일을 정의하는 JSR-37, 46, 62, 66, 68, 75, 118, 129, 134와 J2ME 멀티미디어 API에 대한 JSR-135 등이 모두 J2ME에 관한 것이다.
J2ME에 대해서는 본지에서도 여러 차례 언급된 적이 있으므로, 자세한 설명은 생략하고, JSR을 이해하는 데 꼭 필요한 자바 플랫폼에 대한 내용과 컨피규레이션과 프로파일에 대해서만 잠깐 설명하겠다. <그림 1>은 현재 자바 플랫폼을 전반적으로 나타낸 것으로 J2ME가 차지하는 영역이 어느 부분인지 알 수 있다.
보통 디바이스라고 하면 휴대전화나 PDA를 떠올리지만 이들 말고도 수많은 디바이스에는 제 각각의 인터페이스와 하드웨어 리소스가 있으며, 사람들은 이들을 각기 다른 목적으로 사용한다. 휴대전화의 예만 들어도 흑백에 작은 LCD 화면을 장착한 것부터 PDA 급 기능을 갖춘 것까지 다양하다. 이와 같이 여러 장비의 특성을 감안해 분류하는 기준이 컨피규레이션과 프로파일이다.
컨피규레이션은 VM의 특성을 규정하는 것으로 디바이스의 지원 능력에 따라 자바 언어의 명세서인 자바 언어 스펙(Java Language Specification)과 자바 VM의 명세서인 자바 VM 스펙(Java Virtual Machine Specification)에서 지원할 것인지 규정한다.
그리고 네트워크나 보안 같은 필수 자바 라이브러리 지원 여부에 대한 최소한의 범위도 규정한다. J2ME의 컨피규레이션에는 CLDC와 CDC가 있으며, 최근에는 JSR-139에서 차세대 CLDC 컨피규레이션(CLDC-NG)을 정의하고 있다. 프로파일은 이런 컨피규레이션에서 사용자 인터페이스 등을 포함하는 추가 API를 규정한다. 이것은 작은 틀의 범위를 정하는 것이라는 점에서 컨피규레이션이 정해놓은 큰 틀 안에서 각각의 디바이스에 맞도록 세부적인 범위를 정하는 것이라고 볼 수 있다.
VM과 관련된 규정들은 전부 컨피규레이션에서 정해지며, VM의 종류도 컨피규레이션에 의해 분류된다. 하지만 UI나 추가적인 라이브러리를 규정하는 나머지 영역은 전부 프로파일에서 규정되므로 본격적인 프로그래밍을 하려면 프로파일에 속하는 API를 사용해야만 한다. 현재 가장 주목받고 있는 프로파일은 역시 휴대전화 단말기 쪽에서 채택을 하고 있는 JSR-37인 MIDP(Mobile Information Device Profile)다.
이미 국내에서는 여러 단말기들이 MIDP 규격의 KVM을 탑재하고 있다. 그리고 최근에 가장 주목받는 프로파일은 역시 뭐니 뭐니 해도 MIDP의 차기 버전이라고 할 수 있는 JSR-118 MID-NG(Mobile Information Device Next Generation)일 것이다.
이번 테크니컬 컬럼에서는 주로 JSR의 전체적인 줄기와 앞으로의 자바의 발전 방향에 초점을 맞추고 있으므로 이 중에서 JSR-118 MID-NG와 JSR-139 CLDC-NG가 어떻게 진행되고 있는지 정도만 간단하게 소개한다.
CLDC-NG
먼저 CLDC-NG에 대해 소개하면, 현재 전문가 그룹이 결성되고 올해 2월 중에 커뮤니티 리뷰가 수행된 이후에 상반기 중에 발표할 예정이다. 기본적인 특징으로는 최소한 자바 플랫폼에 대해 160KB의 메모리가 할당되며, CPU는 8~32MHz 정도의 16·32비트 프로세서, 그리고 파워는 주로 배터리이며, 대역폭 9600bps 수준의 네트워크 접속이 가능하다. 사용자 인터페이스는 매우 다양하게 가져갈 수 있으며, CLDC-NG에서 주된 타겟으로 생각하고 있는 것은 휴대전화와 양방향 페이저, PDA 등과 작은 가전기기들이다.
새로운 규격에서 제안한 일반적인 목표는 부동소수점 연산이나 클래스 로드나 verification 등의 에러 처리 기능을 지원하는 것이다. 그에 비해 기존의 CLDC 타겟 디바이스에 의해 요구되는 엄격한 메모리 크기에 대한 제한을 맞추기 위한 것들은 다소 완화하게 되며, 기본적인 보안 관리자와 클래스 언로딩을 지원하기 위해 고민하고 있다.
CLDC-NG가 이렇게 변화할 것으로 예상되는 가운데, 휴대전화에서 가장 많이 이용될 MID-NG 프로파일 역시 올해 2월내에 커뮤니티 리뷰를 하고, 상반기 중에 발표할 예정이다. 주요 기능으로는 도메인 보안 모델을 지원해 애플리케이션 사인이나 증명서 확인 등이 가능하게 하고, HTTPS를 비롯한 안전한 네트워크 구성, 소켓과 데이터그램을 모두 지원하는 네트워크 접속 등을 지원할 예정이다.
그 밖에도 푸시 아키텍처를 지원해 외부 이벤트나 메시지를 적절한 MIDlet에 쉽게 라우팅할 수 있게 하고, 과거의 저수준의 LCD UI를 게임 등이 가능하도록 더 큰 스크린 크기를 지원하며, 작고 효율적인 XML 파서를 지원해 플랫폼 독립적으로 데이터를 교환할 수 있게 하는 것이 목표다. 마지막으로 기본적인 사운드 API도 지원할 예정이라고 한다.
리얼타임
리얼타임 관련 규격으로는 JSR-1(Real-time Specification for Java), JSR-50(Distributed Real-Time Specification)이 있다.
JSR-50에서 가장 중요하게 강조하는 부분은 프로그램이 하나 이상의 컴퓨팅 환경에 분산되어 있을 때 이들을 물리적 노드의 경계를 넘어 동시에 실행할 수 있도록 하는 컨트롤 플로우를 결정하자는 것이다. 이를 위해 액티비티(activity)라는 개념을 도입해 하나의 일관된 프로세스로 관리하게 했다.
참고로, 액티비티(activity)라는 개념은 미국에서 주로 국방·우주항공과 관련된 IT 사업을 주력으로 하는 MITRE라는 회사의 시니어 엔지니어인 E. Douglas Jensen이라는 사람(필자와는 OMG 활동 등을 통해 개인적인 친분이 있다)이 주창한 개념이다.
중요한 것은 이 사람이 실제 JCP 2.0의 리얼타임 자바와 관련된 프로세스를 지휘하는 총책임자로서 자신의 이론을 규격에 추가했다는 것이다. 어쨌든, JSR-50에서 발표한 규격에 대해 조금 더 설명하면, 객체 인스턴스 내부에서는 컨트롤의 플로우가 정상적인 쓰레드 수행 절차를 밟게 되는데, 분산 프로그램의 경우 동시에 여러 개의 액티비티가 동작하게 되고, 자바에서는 이러한 액티비티를 각각의 노드에 있는 RMI를 수행하는 로컬 쓰레드를 순차적으로 통합하는 것으로 구현한다고 한다.
각각의 액티비티에는 하나 이상의 실행 스케쥴링 속성(예 : priority, deadline, importance 등)이 있으며, 이를 이용해 여러 개의 노드에 존재하는 전체 객체가 순차적으로 수행을 완료할 수 있도록 타임라인(timeliness)을 구성할 수 있게 된다. 이러한 타임라인 속성을 애플리케이션에서 정의하면 이를 지키게 되는 것이다.
이를 구현하기 위해 가장 중요한 기본적인 요구 사항은 액티비티의 타임라인 프로퍼티와 기대되는 실행시간, 시간제한 등의 데이터가 로컬과 원격 객체 간에 원활하게 전달되어야 한다는 것이다. 이를 위해 해당되는 JVM과 RMI의 수정이 불가피하게 된다. 그렇기 때문에, 리얼타임 RMI라는 RMI의 확장된 프로토콜을 JSR-50에서는 새롭게 정의하고 있다.
참고로, RMI와 함께 표준으로 사용되는 IIOP에 대한 리얼타임 버전은 정의되지 않았는데, 필자가 이 부분에 대해 질문한 적이 있는데 IIOP와의 관계 정립에 대해 아직 고려하고 있지 않다는 답변을 받았다.
JAIN과 관련한 규격들
전체 JSR 중에서 JAIN(Java for the Advanced Intelligent Network)과 관련된 것이 의외로 대단히 많다. 여기에 대한 것이 JSR-11(JAIN TCAP Specification), JSR-17(JAIN ISUP Specification), JSR-18(JAIN OAM API Specification)을 비롯해 JSR-21~24, JSR-29, 32, 35, 79, 81, 98, 100, 103, 116, 119, 122, 125, 132, 137, 145 등이 모두 이 범주에 속한다.
JAIN과 관련한 JSR들은 모두 차세대 통신과 관련한 제품이나 서비스를 자바 플랫폼을 이용해 쉽게 개발할 수 있도록 하는 API들을 정의하는 것들이다. 다시 말하면 JAIN API들은 서비스의 이식성과 통합성, 안전한 네트워크 접근을 기존 전화망과 데이터 네트워크를 통해 가능하도록 도와준다.
가장 중요한 것은 PSTN(Public Switched Telephone Network)과 기존 패킷 방식의 IP(Internet Protocol) 또는 ATM(Asynchronous Transfer Mode) 네트워크, 무선 네트워크에서 서비스를 만들어내는 데 필요한 자바 인터페이스들을 추상화하고 IP를 중심으로 한 인터넷 프로토콜과 IN(Intelligent Network) 프로토콜을 통합하는 것이다.
이렇게 통합된 네트워크를 통합 네트워크(Integrated Network)이라고 한다. 더 나아가서 자바 애플리케이션들이 네트워크에 있는 리소스에 접근할 때 보안을 유지하는 등의 추가적인 내용을 통해 지속적으로 업그레이드하고 있다.
JAIN의 목표는 통신 사업자들과 네트워크 장비 제공자, 컴퓨터 장비 제조사와 통신 서비스 사용자, 3rd 파티 서비스 제공자 등에 이르는 가치사슬(value chain)을 만드는 것이다. 이를 위해 <그림 2>와 같이 PSTN, 무선, IP 기반의 프로토콜을 통합할 수 있는 인터페이스를 규정해야 하며, 이들을 프로토콜 API 형태로 추상화하는 API 세트와 단일 호출 컨트롤, 서비스를 이용할 때의 여러 트랜잭션 모델 등에 대한 기본적인 애플리케이션 API 세트가 존재해야 한다.
<그림 2> 유무선 네트워크의 구조와 통합
JAIN은 기본적으로 Parlay라는 표준화 단체에서 작성한 서비스 프레임워크를 중심으로 자바 클래스 인터페이스로 변환한 것이다. Parlay의 홈페이지(http://www.parlay.org)를 방문하면 더 자세한 내용과 CORBA IDL로 되어 있는 인터페이스들도 받을 수 있다. 국내에서는 개방형네트워크 포럼(Next-generation Open Network Forum) 홈페이지(http://www.nonf.or.kr)를 방문하면 관련 자료를 얻을 수 있다. 참고로 NONF에는 가입해야 각종 자료를 얻을 수 있는 것으로 알고 있다.
JMX와 각종 관리와 관련한 규격들
JAIN과 함께 통신 영역에서 가장 중요한 프레임워크로 생각되고 있는 것이 관리 프레임워크(Management Framework)다. 여기에 관련된 JSR로는 JSR-3(Java Management Extensions, JMX), JSR-9(Federated Management Architecture Specification), JSR-48(WBEM Services Framework), JSR-70(IIOP Protocol Adapter for JMX Specification) 등을 비롯해 JSR-71, 77, 138, 146 등의 JSR이 이 범주에 해당한다.
JMX는 관리와 관련한 단일하면서도 개방된 기술로 모든 산업에 곧바로 배포해 적용할 수 있도록 정의한 규격으로 기본적으로 레거시 시스템에 적용하기 쉽고, 새로운 관리 솔루션을 구현한 뒤에 이를 추가하기 좋은 확장성을 가지고 있다.
JMX는 사실 썬에서 JDM(Java Dynamic Management) 키트를 만들면서 쌓은 노하우를 바탕으로 하고 있으며, DMTF(Distributed Management Task Force)라는 표준화 단체에서 정의하는 WBEM(Web-Based Enterprise Management) 표준을 충실히 지키고 있다.
관리와 관련해서는 DMTF가 사실상의 유일한 표준화 단체이므로 이 분야에 관심이 많은 독자들은 DMTF의 홈페이지(http://www.dmtf.org)를 방문하면 이와 관련한 많은 정보를 얻을 수 있을 것이다. 어쨌든 JMX는 웹 기반 분산, 모듈화 관리 장치나 애플리케이션·네트워크 관리 등에 대한 소프트웨어를 쉽게 구축할 수 있는 도구를 제공한다.
JMX는 J2SE의 옵션 패키지로 현재 썬 웹 사이트에서 받을 수 있으며, 레퍼런스 구현에 대한 소스 코드도 공개되어 있으므로 관심이 있는 독자들은 JMX의 홈페이지 (http://java.sun.com/products/JavaManagement/index.html)에서 다운로드를 받을 수 있다.
자바 기술 기반의 애플리케이션을 만드는 개발자라면 자바 소프트웨어를 관리 가능하게 만드는 표준적인 방법이 있었으면 좋겠다는 생각을 한 번쯤 해 보았을 것이다. 이러한 관리에 대한 필요성은 사실 전체 산업 영역에서 모두 제기되는 것으로 그 중에서도 대용량 스토리지 벤더나 엔터프라이즈 비즈니스 애플리케이션 공급자, 통신 장비 사업자 등과 같은 산업 영역에서는 가장 중요한 프레임워크로 인정받고 있다.
JMX 아키텍처는 기본적으로 세 개의 레벨로 구성되어 있다. 첫 번째 레벨은 장비 레벨(instrumentation level)로 어떠한 자바 기반의 객체이든 즉각적인 관리가 가능하도록 하며, 이 레벨을 통해 모든 개발자가 자바 기술을 이용하도록 할 수 있다. 그 다음 레벨은 에이전트 레벨(agent level)로 관리 에이전트를 제공한다.
JMX 에이전트는 핵심 관리 서비스를 제공하는 컨테이너다. 마지막 레벨은 관리자 레벨(manager level)이다. 이 레벨은 관리 컴포넌트를 분산해 관리하며 실제 관리가 수행되는 레벨이다.
이러한 기본적인 아키텍처 위에 기존에 널리 쓰이는 레거시 시스템과 연동을 위해 추가적인 관리 프로토콜 API들을 제공한다. 지금까지의 내용을 그림으로 표현하면 <그림 3>과 같다.
<그림 3> JMX 아키텍처
먼저 JMX에서 관리가 가능한 리소스를 정의해야 하는데, 리소스는 장비나 특정 서비스, 정책을 구현한 소프트웨어 등이 될 수 있으며 자바로 작성했거나 최소한 자바로 작성된 래퍼(wrapper) 가 있어야 한다. MBean은 JMX 리소스에 대한 자바 객체를 대표하는 것으로 자바 빈 컴포넌트와 직접적인 매핑을 통해 JMX 에이전트에 플러그인될 수 있다.
그러므로 JMX 에이전트는 MBean의 서버가 되며 여러 MBean과 하나 이상의 프로토콜 어댑터, 커넥터, 자바 빈들에 대한 컨테이너로 구성된다. 마지막으로 JMX 관리자는 에이전트와 상호 작용을 할 수 있는 관리 애플리케이션의 인터페이스를 제공하며, 보안 등과 같은 분산 인프라 구조를 제공한다.
OSS와 통신 운영 관련 규격
JAIN이 네트워크 통합, JMX가 관리를 담당했다면 OSS(Operation Support System)는 서비스의 QoS(Quality of Service), 과금(Billing), 서비스 활성화(Service Activation) 등과 관련한 규격이다.
이 카테고리에 들어가는 JSR로는 JSR-89(OSS Service Activation API), JSR-90(OSS Quality of Service API), JSR-91(OSS Trouble Ticket API)을 포함해 JSR-130, 142, 144까지 모두 여섯 개의 JSR이 있다.
OSS는 원래 IMT-2000으로 알려져 있는 표준안 중에서 특히 비동기식인 W-CDMA 쪽에서 표준화를 주도하는 3GPP에서 운영과 관련한 규격을 정하고 있는 것으로 여기에 대한 더 자세한 정보를 원하는 독자는 3GPP의 홈페이지(http://www.3gpp.org)를 참고하기 바란다.
마치며
이 밖에도 지금까지 나열한 카테고리에 포함시킬 수 없는 재미있는 JSR이 많다. 대표적인 것들로는 JSR-40(Java Metadata Interface Specification), JSR-47(Logging API Specification), JSR-56(Java Network Launching Protocol and API), JSR-69(Java OLAP Interface), JSR-87(Java Agent Service), JSR-94(Java Rule Engine API) 등이 있다.
이들 각각에 대해서도 다뤄볼 수 있으면 좋겠지만, 지면 관계상 이 정도로 마칠까 한다. 마지막으로 지금까지의 내용을 표로 정리한 것을 독자들에게 제공하면서, 이번 달의 테크니컬 컬럼을 마치고자 한다. 여유가 되면 다음번에는 이번에 다루지 않은 JSR들 중에서 재미있고, 유용한 것들을 골라 소개하고자 한다.@
<표1> 각 분야별 주요 JSR
카테고리 설명 주요JSR
차세대 자바 플랫폼 J2SE, J2EE의 차기 플랫폼들에 탑재될 기본적인 기능들에 대한 규격 6,12,53,56,59,74,76
XML과 웹 서비스 XML과 관련한 여러 API규격과 웹 서비스와 관련한 규격들 5,31,67,93,101,102,109,110
임베디드·리얼타임 J2ME 플랫폼을 중심으로 임베디드·리얼타임 시스템에 필요한 규격들 1,30,36,37,46,50,62,66,67,68,75,118,129,134,139
JAIN Java Advanced Intelligent Networt API와 관련한 규격들 11,18,21,22,23,24,29,32,35,79,81,98
JMX/WBEM Java Management Extension, WBEM과 같은 각종 관리와 관련한 규격들 3,9,48,70,71,77,138,146
OSS 통신 영역의 Operation Support System과 관련한 규격들 89,90,91,130,142,144
기타 JOLAP,Java Agent Service 등을 포함한 여러 가지 요구 사항 40,47,56
자바에 대해 잘 아는 사람들이라면 JCP와 JSR이 무엇인지는 알고 있을 것이다. 필자는 언젠가 기회가 한 번 되면 JSR에서 리뷰되고 있는 자바와 관련된 무수한 기술적인 논의를 전체적으로 정리하는 작업을 하려고 했는데, 그 동안 손을 대지 못하다가 못 다한 숙제를 하는 기분으로 시도해 보기로 했다. 지면 관계상 자칫 수박 겉핥기처럼 제목과 내용에 대한 간단한 소개로 끝나버릴 수도 있다는 걱정이 앞서지만 기회가 닿으면 각론을 다룰 것을 약속하면서 JCP와 JSR의 큰 틀을 소개한다.
정지훈 (마이크로소프트웨어)
2002/02/19
JSR(Java Specification Requests)은 자바 플랫폼에 대한 규격을 제안하거나 기술한 것을 말한다. 현재 수많은 JSR이 만들어지고 리뷰되고 이를 기반으로 플랫폼이 추가되고 있으며, 이미 많은 JSR이 구현되어 J2EE·J2SE·J2ME 등에 포함되어 있다. 따라서 JSR에 어떠한 내용이 논의되고 있으며, 어떻게 논의가 진행되고 있는지 파악하면 미래의 자바의 모습을 자연스럽게 유추해 볼 수 있다.
JCP와 JSR
1998년 12월 5일, 썬 마이크로시스템즈는 자바의 원천 소스 코드를 공개하겠다고 발표하고, 12월 8일 새로운 자바 소스의 라이선스 정책과 함께 자바 표준화에 관한 권리를 '자바 공동체'에 이양하겠다고 발표했다. SCSL(Sun Community Source Licence)과 JCP(Java Community Process)는 각각 라이선스와 표준화에 대한 썬의 자바 정책에 대한 공식적인 입장 표명이었다.
JCP는 자바 플랫폼의 표준화를 진행하기 위한 표준적인 절차다. JCP 집행위원회는 자바 명세서, 레퍼런스 구현, 호환성 검사 툴의 개발을 담당하는 커뮤니티이고 이 커뮤니티는 JCP 2.0이 발표됨과 동시에 J2SE, J2EE와 같은 데스크톱, 서버 환경의 자바 기술을 감독하는 위원회와 소비자, 임베디드 환경의 자바 기술인 J2ME의 자바 기술을 감독하는 위원회로 나뉘어졌다. 현재 JCP 집행위원회에는 세계 굴지의 기업들이 참여하고 있으며, 자바의 표준화는 이 회원사들 간의 협력을 통해 진행되고 있다.
JSR은 가장 처음 제기되는 요구 사항을 바탕으로 초기 투표를 통해 논의할 것인지 결정하고, 이어서 커뮤니티 리뷰 일자를 정해 이때까지 만들어진 규격을 커뮤니티에 가입된 사람들을 대상으로 리뷰하게 된다. 그리고 나서 퍼블릭 리뷰에 들어가는데, 이때 피드백을 받아 채택하는 단계를 거친다.
그러면, 먼저 채택되어 개발됐거나, 개발되고 있는 JSR의 목록부터 살펴보자. JSR-000001인 'Real-time Specification for Java'에서 JSR-000150인 'Internationalization Service for J2EE'까지 모두 150개 중에서 중복되거나 투표에서 거부된 열다섯 개를 제외한 135개의 JSR이 채택됐다. 이들을 모두 나열하는 것은 책 한 권을 써도 모자라는 분량이므로, 이들 몇 가지 카테고리로 나눠 설명하겠다. 참고로 카테고리는 필자가 개인적으로 나눈 것이므로 틀린 점이 있다면 언제라도 지적해주기 바란다.
자바의 차기 버전을 예측한다.
JSR의 상당 부분은 J2EE, J2SE, J2ME 표준 플랫폼에 포함될 내용을 정의하는 것이다. J2ME를 별개로 하고 J2SE와 J2EE의 차기 플랫폼 표준을 정하는 범주에 속하는 것이 가장 많은데, 그 중에서 앞으로 설명할 카테고리에 들어가지 않은 것들 중에서 중요한 것들로 J2SE에는 JSR-6(Java Print Service API), JSR-12(Java Data Objects Specification), JSR-53(Java Servlet 2.3 and JavaServer Pages 1.3), JSR-54(JDBC 3.0 Specification), JSR-59(J2SE Merlin Contents), JSR-74(PKCS 1.0), JSR-76(RMI Security for J2SE) 등이 있다.
J2EE 쪽에는 대부분 J2SE의 것들과 겹치지만 그렇지 않은 것들만 나열하면 JSR-16(J2EE Connector Architecture), JSR-19(Enterprise JavaBeans 2.0), JSR-77(J2EE Management), JSR-88(J2EE Application Deployment) 등이 있다.
사실 JSR의 대부분은 플랫폼의 차기 모습을 예측할 수 있는 지표가 되며, 여기에서 가장 중요하다고 논의되는 것들을 구현해 새로운 자바 플랫폼을 구현하므로, 새로운 JSR이 어떤 것들이 등장하고 있는지 알아보는 것만큼 앞으로의 자바 플랫폼의 변화를 예측하기 좋은 것도 없다.
XML과 웹 서비스
XML이 최근에 각광받는 만큼 JSR에도 XML과 관련된 것이 대단히 많다. JSR-5(XML Parsing Specification, JAXP)를 시작으로 JSR-31(XML Data Binding Specification), JSR-67(Java APIs for XML Messaging, JAXM), JSR-93(Java APIs for XML Registries, JAXR), JSR-101(Java APIs for XML based RPC), JSR-102(JDOM 1.0) 등이 XML과 관련한 것들이며, XML 보안과 관련한 것이 JSR-104, 105, 106이다. XML을 이용한 웹 서비스와 관련해서는 JSR-109(Implementing Enterprise Web Services), JSR-110(Java APIs for WSDL) 등이 있다.
이러한 XML과 관련한 JSR 중에서 실제로 구현을 끝낸 것들이 속속 등장하고 있으며, 최근의 웹 서비스 열풍에 힘입어, 이들을 엮어서 자바 XML 팩이라는 형태로 이러한 클래스들을 모아 설치하고, 사용할 수 있게 하고 있다. 현재 XML 팩은 Winter01 번들까지 나와 있으며http://java.sun.com/xml/downloads/javaxmlpack.html에서 받을 수 있다. 이 번들에는 JSR-5(JAXP), JSR-67(JAXM), JSR-93(JAXR), JSR-101(JAX-RPC)이 구현되어 포함되어 있다. 이러한 자바 API는 크게 나누어 다음과 같이 문서지향(document-oriented)적인 것과 처리지향(process-oriented)적인 것이 있다.
문서지향적
◆JAXP(Java API for XML Processing) : 다양한 파서를 이용해 XML 문서를 처리한다.
◆JAXB(Java Architecture for XML Binding) : XML 엘리먼트를 자바 프로그래밍 언어의 클래스와 매핑한다.
처리지향적
◆JAXM(Java API for XML Messaging) : 인터넷을 통해 표준적인 방법으로 SOAP 메시지를 전송한다.
◆JAXR(Java API for XML Registries) : 비즈니스 레지스트리에 접근하고, 정보를 공유하는 표준적인 방법을 제공한다.
◆JAX-RPC(Java API for XML-based RPC) : SOAP 메소드 호출을 원격지에 전송하고 결과를 받아온다.
아마도 XML에 대한 자바 API의 기능 중에서 가장 중요한 것은 W3C나 OASIS(Organization for the Advancement of Structured Information Standards) 등의 산업계 표준을 지원하고 상호 운용성을 확보하는 것이라고 생각한다.
XML에 대한 자바 API의 다른 기능으로는 유연성을 확보하는 것이다. 사용자들은 JAXP 코드를 이용해 XML 문서를 처리할 수 있는 다양한 도구를 이용할 수 있고, JAXM 코드를 이용해 SOAP 위에 다양한 메시징 프로토콜을 이용할 수 있다. 구현하는 쪽에서도 상당한 유연성이 생긴다. XML에 대한 자바 API들은 엄격한 호환성에 대한 요구 사항을 정의하고 있기 때문에, 이를 구현하는 측에서는 표준적인 기능을 제공해야 하며, 동시에 특정 기능에 이용할 수 있게 변경할 수 있는 유연성을 개발자들에게 제공해야 한다.
임베디드·리얼타임과 관련한 규격
임베디드 자바 및 J2ME와 관련한 규격으로는 먼저 차세대 J2ME 플랫폼 규격에 관한 JSR-68과 J2ME의 컨피규레이션(configuration)과 관련한 JSR-30(J2ME Connected, Limited Device Configuration), JSR-36(J2ME Connected Device Configuration), JSR-139(Connected Limited Device Configuration Next Generation), 그 밖에 수많은 프로파일을 정의하는 JSR-37, 46, 62, 66, 68, 75, 118, 129, 134와 J2ME 멀티미디어 API에 대한 JSR-135 등이 모두 J2ME에 관한 것이다.
J2ME에 대해서는 본지에서도 여러 차례 언급된 적이 있으므로, 자세한 설명은 생략하고, JSR을 이해하는 데 꼭 필요한 자바 플랫폼에 대한 내용과 컨피규레이션과 프로파일에 대해서만 잠깐 설명하겠다. <그림 1>은 현재 자바 플랫폼을 전반적으로 나타낸 것으로 J2ME가 차지하는 영역이 어느 부분인지 알 수 있다.
보통 디바이스라고 하면 휴대전화나 PDA를 떠올리지만 이들 말고도 수많은 디바이스에는 제 각각의 인터페이스와 하드웨어 리소스가 있으며, 사람들은 이들을 각기 다른 목적으로 사용한다. 휴대전화의 예만 들어도 흑백에 작은 LCD 화면을 장착한 것부터 PDA 급 기능을 갖춘 것까지 다양하다. 이와 같이 여러 장비의 특성을 감안해 분류하는 기준이 컨피규레이션과 프로파일이다.
컨피규레이션은 VM의 특성을 규정하는 것으로 디바이스의 지원 능력에 따라 자바 언어의 명세서인 자바 언어 스펙(Java Language Specification)과 자바 VM의 명세서인 자바 VM 스펙(Java Virtual Machine Specification)에서 지원할 것인지 규정한다.
그리고 네트워크나 보안 같은 필수 자바 라이브러리 지원 여부에 대한 최소한의 범위도 규정한다. J2ME의 컨피규레이션에는 CLDC와 CDC가 있으며, 최근에는 JSR-139에서 차세대 CLDC 컨피규레이션(CLDC-NG)을 정의하고 있다. 프로파일은 이런 컨피규레이션에서 사용자 인터페이스 등을 포함하는 추가 API를 규정한다. 이것은 작은 틀의 범위를 정하는 것이라는 점에서 컨피규레이션이 정해놓은 큰 틀 안에서 각각의 디바이스에 맞도록 세부적인 범위를 정하는 것이라고 볼 수 있다.
VM과 관련된 규정들은 전부 컨피규레이션에서 정해지며, VM의 종류도 컨피규레이션에 의해 분류된다. 하지만 UI나 추가적인 라이브러리를 규정하는 나머지 영역은 전부 프로파일에서 규정되므로 본격적인 프로그래밍을 하려면 프로파일에 속하는 API를 사용해야만 한다. 현재 가장 주목받고 있는 프로파일은 역시 휴대전화 단말기 쪽에서 채택을 하고 있는 JSR-37인 MIDP(Mobile Information Device Profile)다.
이미 국내에서는 여러 단말기들이 MIDP 규격의 KVM을 탑재하고 있다. 그리고 최근에 가장 주목받는 프로파일은 역시 뭐니 뭐니 해도 MIDP의 차기 버전이라고 할 수 있는 JSR-118 MID-NG(Mobile Information Device Next Generation)일 것이다.
이번 테크니컬 컬럼에서는 주로 JSR의 전체적인 줄기와 앞으로의 자바의 발전 방향에 초점을 맞추고 있으므로 이 중에서 JSR-118 MID-NG와 JSR-139 CLDC-NG가 어떻게 진행되고 있는지 정도만 간단하게 소개한다.
CLDC-NG
먼저 CLDC-NG에 대해 소개하면, 현재 전문가 그룹이 결성되고 올해 2월 중에 커뮤니티 리뷰가 수행된 이후에 상반기 중에 발표할 예정이다. 기본적인 특징으로는 최소한 자바 플랫폼에 대해 160KB의 메모리가 할당되며, CPU는 8~32MHz 정도의 16·32비트 프로세서, 그리고 파워는 주로 배터리이며, 대역폭 9600bps 수준의 네트워크 접속이 가능하다. 사용자 인터페이스는 매우 다양하게 가져갈 수 있으며, CLDC-NG에서 주된 타겟으로 생각하고 있는 것은 휴대전화와 양방향 페이저, PDA 등과 작은 가전기기들이다.
새로운 규격에서 제안한 일반적인 목표는 부동소수점 연산이나 클래스 로드나 verification 등의 에러 처리 기능을 지원하는 것이다. 그에 비해 기존의 CLDC 타겟 디바이스에 의해 요구되는 엄격한 메모리 크기에 대한 제한을 맞추기 위한 것들은 다소 완화하게 되며, 기본적인 보안 관리자와 클래스 언로딩을 지원하기 위해 고민하고 있다.
CLDC-NG가 이렇게 변화할 것으로 예상되는 가운데, 휴대전화에서 가장 많이 이용될 MID-NG 프로파일 역시 올해 2월내에 커뮤니티 리뷰를 하고, 상반기 중에 발표할 예정이다. 주요 기능으로는 도메인 보안 모델을 지원해 애플리케이션 사인이나 증명서 확인 등이 가능하게 하고, HTTPS를 비롯한 안전한 네트워크 구성, 소켓과 데이터그램을 모두 지원하는 네트워크 접속 등을 지원할 예정이다.
그 밖에도 푸시 아키텍처를 지원해 외부 이벤트나 메시지를 적절한 MIDlet에 쉽게 라우팅할 수 있게 하고, 과거의 저수준의 LCD UI를 게임 등이 가능하도록 더 큰 스크린 크기를 지원하며, 작고 효율적인 XML 파서를 지원해 플랫폼 독립적으로 데이터를 교환할 수 있게 하는 것이 목표다. 마지막으로 기본적인 사운드 API도 지원할 예정이라고 한다.
리얼타임
리얼타임 관련 규격으로는 JSR-1(Real-time Specification for Java), JSR-50(Distributed Real-Time Specification)이 있다.
JSR-50에서 가장 중요하게 강조하는 부분은 프로그램이 하나 이상의 컴퓨팅 환경에 분산되어 있을 때 이들을 물리적 노드의 경계를 넘어 동시에 실행할 수 있도록 하는 컨트롤 플로우를 결정하자는 것이다. 이를 위해 액티비티(activity)라는 개념을 도입해 하나의 일관된 프로세스로 관리하게 했다.
참고로, 액티비티(activity)라는 개념은 미국에서 주로 국방·우주항공과 관련된 IT 사업을 주력으로 하는 MITRE라는 회사의 시니어 엔지니어인 E. Douglas Jensen이라는 사람(필자와는 OMG 활동 등을 통해 개인적인 친분이 있다)이 주창한 개념이다.
중요한 것은 이 사람이 실제 JCP 2.0의 리얼타임 자바와 관련된 프로세스를 지휘하는 총책임자로서 자신의 이론을 규격에 추가했다는 것이다. 어쨌든, JSR-50에서 발표한 규격에 대해 조금 더 설명하면, 객체 인스턴스 내부에서는 컨트롤의 플로우가 정상적인 쓰레드 수행 절차를 밟게 되는데, 분산 프로그램의 경우 동시에 여러 개의 액티비티가 동작하게 되고, 자바에서는 이러한 액티비티를 각각의 노드에 있는 RMI를 수행하는 로컬 쓰레드를 순차적으로 통합하는 것으로 구현한다고 한다.
각각의 액티비티에는 하나 이상의 실행 스케쥴링 속성(예 : priority, deadline, importance 등)이 있으며, 이를 이용해 여러 개의 노드에 존재하는 전체 객체가 순차적으로 수행을 완료할 수 있도록 타임라인(timeliness)을 구성할 수 있게 된다. 이러한 타임라인 속성을 애플리케이션에서 정의하면 이를 지키게 되는 것이다.
이를 구현하기 위해 가장 중요한 기본적인 요구 사항은 액티비티의 타임라인 프로퍼티와 기대되는 실행시간, 시간제한 등의 데이터가 로컬과 원격 객체 간에 원활하게 전달되어야 한다는 것이다. 이를 위해 해당되는 JVM과 RMI의 수정이 불가피하게 된다. 그렇기 때문에, 리얼타임 RMI라는 RMI의 확장된 프로토콜을 JSR-50에서는 새롭게 정의하고 있다.
참고로, RMI와 함께 표준으로 사용되는 IIOP에 대한 리얼타임 버전은 정의되지 않았는데, 필자가 이 부분에 대해 질문한 적이 있는데 IIOP와의 관계 정립에 대해 아직 고려하고 있지 않다는 답변을 받았다.
JAIN과 관련한 규격들
전체 JSR 중에서 JAIN(Java for the Advanced Intelligent Network)과 관련된 것이 의외로 대단히 많다. 여기에 대한 것이 JSR-11(JAIN TCAP Specification), JSR-17(JAIN ISUP Specification), JSR-18(JAIN OAM API Specification)을 비롯해 JSR-21~24, JSR-29, 32, 35, 79, 81, 98, 100, 103, 116, 119, 122, 125, 132, 137, 145 등이 모두 이 범주에 속한다.
JAIN과 관련한 JSR들은 모두 차세대 통신과 관련한 제품이나 서비스를 자바 플랫폼을 이용해 쉽게 개발할 수 있도록 하는 API들을 정의하는 것들이다. 다시 말하면 JAIN API들은 서비스의 이식성과 통합성, 안전한 네트워크 접근을 기존 전화망과 데이터 네트워크를 통해 가능하도록 도와준다.
가장 중요한 것은 PSTN(Public Switched Telephone Network)과 기존 패킷 방식의 IP(Internet Protocol) 또는 ATM(Asynchronous Transfer Mode) 네트워크, 무선 네트워크에서 서비스를 만들어내는 데 필요한 자바 인터페이스들을 추상화하고 IP를 중심으로 한 인터넷 프로토콜과 IN(Intelligent Network) 프로토콜을 통합하는 것이다.
이렇게 통합된 네트워크를 통합 네트워크(Integrated Network)이라고 한다. 더 나아가서 자바 애플리케이션들이 네트워크에 있는 리소스에 접근할 때 보안을 유지하는 등의 추가적인 내용을 통해 지속적으로 업그레이드하고 있다.
JAIN의 목표는 통신 사업자들과 네트워크 장비 제공자, 컴퓨터 장비 제조사와 통신 서비스 사용자, 3rd 파티 서비스 제공자 등에 이르는 가치사슬(value chain)을 만드는 것이다. 이를 위해 <그림 2>와 같이 PSTN, 무선, IP 기반의 프로토콜을 통합할 수 있는 인터페이스를 규정해야 하며, 이들을 프로토콜 API 형태로 추상화하는 API 세트와 단일 호출 컨트롤, 서비스를 이용할 때의 여러 트랜잭션 모델 등에 대한 기본적인 애플리케이션 API 세트가 존재해야 한다.
<그림 2> 유무선 네트워크의 구조와 통합
JAIN은 기본적으로 Parlay라는 표준화 단체에서 작성한 서비스 프레임워크를 중심으로 자바 클래스 인터페이스로 변환한 것이다. Parlay의 홈페이지(http://www.parlay.org)를 방문하면 더 자세한 내용과 CORBA IDL로 되어 있는 인터페이스들도 받을 수 있다. 국내에서는 개방형네트워크 포럼(Next-generation Open Network Forum) 홈페이지(http://www.nonf.or.kr)를 방문하면 관련 자료를 얻을 수 있다. 참고로 NONF에는 가입해야 각종 자료를 얻을 수 있는 것으로 알고 있다.
JMX와 각종 관리와 관련한 규격들
JAIN과 함께 통신 영역에서 가장 중요한 프레임워크로 생각되고 있는 것이 관리 프레임워크(Management Framework)다. 여기에 관련된 JSR로는 JSR-3(Java Management Extensions, JMX), JSR-9(Federated Management Architecture Specification), JSR-48(WBEM Services Framework), JSR-70(IIOP Protocol Adapter for JMX Specification) 등을 비롯해 JSR-71, 77, 138, 146 등의 JSR이 이 범주에 해당한다.
JMX는 관리와 관련한 단일하면서도 개방된 기술로 모든 산업에 곧바로 배포해 적용할 수 있도록 정의한 규격으로 기본적으로 레거시 시스템에 적용하기 쉽고, 새로운 관리 솔루션을 구현한 뒤에 이를 추가하기 좋은 확장성을 가지고 있다.
JMX는 사실 썬에서 JDM(Java Dynamic Management) 키트를 만들면서 쌓은 노하우를 바탕으로 하고 있으며, DMTF(Distributed Management Task Force)라는 표준화 단체에서 정의하는 WBEM(Web-Based Enterprise Management) 표준을 충실히 지키고 있다.
관리와 관련해서는 DMTF가 사실상의 유일한 표준화 단체이므로 이 분야에 관심이 많은 독자들은 DMTF의 홈페이지(http://www.dmtf.org)를 방문하면 이와 관련한 많은 정보를 얻을 수 있을 것이다. 어쨌든 JMX는 웹 기반 분산, 모듈화 관리 장치나 애플리케이션·네트워크 관리 등에 대한 소프트웨어를 쉽게 구축할 수 있는 도구를 제공한다.
JMX는 J2SE의 옵션 패키지로 현재 썬 웹 사이트에서 받을 수 있으며, 레퍼런스 구현에 대한 소스 코드도 공개되어 있으므로 관심이 있는 독자들은 JMX의 홈페이지 (http://java.sun.com/products/JavaManagement/index.html)에서 다운로드를 받을 수 있다.
자바 기술 기반의 애플리케이션을 만드는 개발자라면 자바 소프트웨어를 관리 가능하게 만드는 표준적인 방법이 있었으면 좋겠다는 생각을 한 번쯤 해 보았을 것이다. 이러한 관리에 대한 필요성은 사실 전체 산업 영역에서 모두 제기되는 것으로 그 중에서도 대용량 스토리지 벤더나 엔터프라이즈 비즈니스 애플리케이션 공급자, 통신 장비 사업자 등과 같은 산업 영역에서는 가장 중요한 프레임워크로 인정받고 있다.
JMX 아키텍처는 기본적으로 세 개의 레벨로 구성되어 있다. 첫 번째 레벨은 장비 레벨(instrumentation level)로 어떠한 자바 기반의 객체이든 즉각적인 관리가 가능하도록 하며, 이 레벨을 통해 모든 개발자가 자바 기술을 이용하도록 할 수 있다. 그 다음 레벨은 에이전트 레벨(agent level)로 관리 에이전트를 제공한다.
JMX 에이전트는 핵심 관리 서비스를 제공하는 컨테이너다. 마지막 레벨은 관리자 레벨(manager level)이다. 이 레벨은 관리 컴포넌트를 분산해 관리하며 실제 관리가 수행되는 레벨이다.
이러한 기본적인 아키텍처 위에 기존에 널리 쓰이는 레거시 시스템과 연동을 위해 추가적인 관리 프로토콜 API들을 제공한다. 지금까지의 내용을 그림으로 표현하면 <그림 3>과 같다.
<그림 3> JMX 아키텍처
먼저 JMX에서 관리가 가능한 리소스를 정의해야 하는데, 리소스는 장비나 특정 서비스, 정책을 구현한 소프트웨어 등이 될 수 있으며 자바로 작성했거나 최소한 자바로 작성된 래퍼(wrapper) 가 있어야 한다. MBean은 JMX 리소스에 대한 자바 객체를 대표하는 것으로 자바 빈 컴포넌트와 직접적인 매핑을 통해 JMX 에이전트에 플러그인될 수 있다.
그러므로 JMX 에이전트는 MBean의 서버가 되며 여러 MBean과 하나 이상의 프로토콜 어댑터, 커넥터, 자바 빈들에 대한 컨테이너로 구성된다. 마지막으로 JMX 관리자는 에이전트와 상호 작용을 할 수 있는 관리 애플리케이션의 인터페이스를 제공하며, 보안 등과 같은 분산 인프라 구조를 제공한다.
OSS와 통신 운영 관련 규격
JAIN이 네트워크 통합, JMX가 관리를 담당했다면 OSS(Operation Support System)는 서비스의 QoS(Quality of Service), 과금(Billing), 서비스 활성화(Service Activation) 등과 관련한 규격이다.
이 카테고리에 들어가는 JSR로는 JSR-89(OSS Service Activation API), JSR-90(OSS Quality of Service API), JSR-91(OSS Trouble Ticket API)을 포함해 JSR-130, 142, 144까지 모두 여섯 개의 JSR이 있다.
OSS는 원래 IMT-2000으로 알려져 있는 표준안 중에서 특히 비동기식인 W-CDMA 쪽에서 표준화를 주도하는 3GPP에서 운영과 관련한 규격을 정하고 있는 것으로 여기에 대한 더 자세한 정보를 원하는 독자는 3GPP의 홈페이지(http://www.3gpp.org)를 참고하기 바란다.
마치며
이 밖에도 지금까지 나열한 카테고리에 포함시킬 수 없는 재미있는 JSR이 많다. 대표적인 것들로는 JSR-40(Java Metadata Interface Specification), JSR-47(Logging API Specification), JSR-56(Java Network Launching Protocol and API), JSR-69(Java OLAP Interface), JSR-87(Java Agent Service), JSR-94(Java Rule Engine API) 등이 있다.
이들 각각에 대해서도 다뤄볼 수 있으면 좋겠지만, 지면 관계상 이 정도로 마칠까 한다. 마지막으로 지금까지의 내용을 표로 정리한 것을 독자들에게 제공하면서, 이번 달의 테크니컬 컬럼을 마치고자 한다. 여유가 되면 다음번에는 이번에 다루지 않은 JSR들 중에서 재미있고, 유용한 것들을 골라 소개하고자 한다.@
<표1> 각 분야별 주요 JSR
카테고리 설명 주요JSR
차세대 자바 플랫폼 J2SE, J2EE의 차기 플랫폼들에 탑재될 기본적인 기능들에 대한 규격 6,12,53,56,59,74,76
XML과 웹 서비스 XML과 관련한 여러 API규격과 웹 서비스와 관련한 규격들 5,31,67,93,101,102,109,110
임베디드·리얼타임 J2ME 플랫폼을 중심으로 임베디드·리얼타임 시스템에 필요한 규격들 1,30,36,37,46,50,62,66,67,68,75,118,129,134,139
JAIN Java Advanced Intelligent Networt API와 관련한 규격들 11,18,21,22,23,24,29,32,35,79,81,98
JMX/WBEM Java Management Extension, WBEM과 같은 각종 관리와 관련한 규격들 3,9,48,70,71,77,138,146
OSS 통신 영역의 Operation Support System과 관련한 규격들 89,90,91,130,142,144
기타 JOLAP,Java Agent Service 등을 포함한 여러 가지 요구 사항 40,47,56
Rss Feed