IIOP

Development/Common 2012. 1. 16. 18:54

IIOP (Internet Inter-ORB Protocol)

IIOP는 일종의 객체 지향 프로토콜로, 다른 프로그래밍 언어로 쓰여진 분산 프로그램이 인터넷을 통해 서로 통신할 수 있도록 한다. IIOP는 전략적 산업 표준인 CORBA의 핵심 부분이다. CORBA의 IIOP 그리고 관련 프로토콜을 이용하면, 한 회사가 다른 회사의 프로그램에 대해 그들이 어디 있든지 상관없이, 그 서비스의 내용과 이름만을 알고서도 서로 통신할 수 있는 프로그램을 작성할 수 있다. CORBA와 IIOP는 마이크로소프트의 소위 DCOM과 비슷한 전략으로 경쟁하고 있다 (마이크로소프트와 CORBA의 스폰서인 OMG는 두 모델 간에 다리를 놓는 소프트웨어 개발에 동의함으로써, CORBA로 설계된 프로그램이 DCOM으로 설계된 프로그램과 통신할 수 있도록 하였다.)

CORBA와 IIOP는 클라이언트 프로그램이 항상 요구하고 서버 프로그램이 클라이언트의 요구를 기다리는 클라이언트/서버 모델을 가정한다. 프로그램 작성시, GIOP(General Inter-ORB Protocol)라 불리는 인터페이스를 사용하는데, GIOP는 하나 이상의 네트웍 전송 계층을 위해 특화된 매핑으로 구현되었다. GIOP의 가장 중요한 특화 매핑은 IIOP로, 이것은TCP를 이용한 인터넷의 전송 계층에서 요구를 전하거나 응답을 받는 것이다. 다른 가능한 전송 계층으로는 IBM의 SNA와 Novell의 IPX가 있다.

클라이언트가 네트웍 상 어딘가에 있을 어떤 프로그램에 대해 처리요구를 하려면, 그 프로그램의 주소를 가져야 하는데, 이 주소를 IOR (Interoperable Object Reference)이라고 부른다. IIOP를 이용할때, 주소의 일부는 서버의 포트 번호와 IP주소에 기반을 둔다. 클라이언트 컴퓨터에서, IOR을 더 사용하기 쉬운 프럭시(proxy) 이름으로 대응시키는 표가 만들어질 수 있다. GIOP는 프로그램이 IOR과 연결하여 그에게 요청할 수 있도록 한다(그리고 서버가 응답을 보내도록 한다). CDR (Common Data Representation)은 자료를 암호화/복호화 하는 방법을 제공하여 표준 방식으로 교환하도록 한다.

출처 - http://www.terms.co.kr/IIOP.htm 


OMG (Object Management Group) ; 객체 관리 그룹

OMG[오엠지]는 네트웍 내의 분산 객체들 (흔히 "컴포넌트"라고도 알려져 있다)에 표준 아키텍처를 만들기 위한 목적으로 공급 회사들 그룹에 의해 1989년에 결성되었다. 그 결과로 나온 아키텍처가 CORBA이다. CORBA의 핵심요소는 ORB이다. ORB는 서버 객체가 네트웍 내의 어디에 위치하여 있는지, 또한 그것의 인터페이스가 정확히 무엇인지를 알지 못하더라도, 클라이언트 객체가 서버에게 서비스를 요청하는 것이 가능하게 해준다.

이미 많은 수의 미들웨어 제품들이 CORBA를 사용하기 시작했으며, CORBA는 분산 객체들에 대한 전략적 아키텍처가 될 것으로 보인다. OMG에는 현재 500개가 넘는 회원사를 자랑한다.



ORB (Object Request Broker)

1.

CORBA에서 ORB는 분산 객체 또는 컴포넌트에서 제공할 서비스에 대해, 클라이언트가 요구
하는 시점부터 그 요구가 완료될 때까지 마치 "거래 중개인"처럼 동작하는 프로그램을 말한다. 네트웍 상의 ORB 지원이라는 것은, 서버가 분산 네트웍의 어디에 위치해 있는지 또는 정확히 어떤
 서버의 인터페이스가 그런 일을 해주는지 전혀 알지 못하더라도, 클라이언트 프로그램이
원하는 서비스를 요구할 수 있다는 것을 의미한다. 이러한 것들을 찾고, 실행되면서 서로
인터페이스 정보를 교환하는 것은 
컴포넌트들의 몫이다.

CORBA의 ORB는 RPC, 메시지 기반의 미들웨어, stored procedure, peer to peer 서비스
등과 같은 이전의 미들웨어보다 개념적으로 세련되고 기능이 강화된 전략적 미들웨어로
생각할 수 있다.

ORB는 요구된 컴포넌트를 찾아 통신하기 위해 CORBA 인터페이스 리포지터리(interface
repository)를 사용한다. 컴포넌트를 생성할 때 프로그래머는 CORBA의 IDL을 이용해 public
interface를 선언하거나, 프로그래밍 언어의 컴파일러를 이용해 구문을 적합한 IDL 문장으로
변환한다. 이런 구문들은 인터페이스 리포지터리에 메타 데이터 또는 컴포넌트의 인터페이스
동작 방식에 대한 정의로 저장된다.

클라이언트 요구를 중계할 때 ORB는 다음과 같은 서비스를 제공한다.

  • Life cycle service : 컴포넌트를 어떻게 만들고, 복사하고, 이동하고, 지우는가 등에
    관한 서비스
  • Persistence service : 자료를 객체지향형 데이터베이스, 관계형 데이터베이스 그리고
    보통의 텍스트 파일에 저장하는 능력을 제공
  • Naming service : 컴포넌트가 다른 컴포넌트를 이름으로 찾고 기존 명명규칙(naming
    systems)이나 DCE, X.500, Sun의 NIS 같은 디렉토리 지원을 가능케 함
  • Event service : 컴포넌트가 통보 받을 특정 이벤트를 지정하도록 함
  • Concurrency control service : ORB로 하여금 트랜잭션이나 스레드의 처리가 끝날
    때까지 데이터를 잠그는 것(lock)을 관리하도록 함
  • Transaction service : 트랜잭션이 완료되었을때 데이터베이스 갱신을 확정하거나,
    그렇지 못한 경우 트랜잭션이 발생하기 전 상태로 복귀되는 것을 보증
  • Relationship service : 이전에 "만난" 적이 없는 컴포넌트간의 동적 관계를 설정하고
    이 관계를 지속
  • Externalization service : "스트림"에서 컴포넌트의 입출 자료를 가져오는 방법을 제공 
  • Query service : 컴포넌트가 데이터베이스를 조회할 수 있도록 함. 이 서비스는 SQL3
    규격과 ODMG(Object Database Management Group)의 OQL(Object Query Langua
    ge)에 기반을 둠
  • Licensing service : 사용 대가를 치를 목적으로 컴포넌트의 사용이 측정되도록 함.
    요금 부과는 세션노드, 활성체 생성, 사이트 단위로 가능
  • Properties service : 컴포넌트가 다른 컴포넌트에 사용될 수 있도록 자기 묘사를
    담도록 함

부가적으로, ORB는 보안성과 시간 서비스를 제공할 수 있다. 교역, 수집, 변화 관리도
계획되고 있다. ORB에서 발생한 요청과 응답은 IIOP나 다른 전송 계층 프로토콜을 통해
전달된다.

 

2.

ORB는 객체들 간의 클라이언트/서버 관계를 맺어주는 미들웨어이다. ORB를 사용하면, 클라
이언트는 서버객체에 있는 메쏘드를 그것이 같은 컴퓨터에 있든, 또는 네트웍 상에 있든 상관
없이 투명하게 호출할 수 있다. ORB는 호출을 가로채어 요구를 처리할 객체를 찾고, 매개변수
를 전달하고, 메쏘드를 호출하고, 또 처리결과를 되돌려주는 일 등을 담당한다. 클라이언트는
객체 인터페이스를 제외하고는, 객체의 위치나 그 객체를 개발할 때 사용된 프로그램 언어나 
운영체계, 그 밖의 시스템과 관련된 그 어느 것도 알 필요가 없다. 이렇게 함으로써, ORB는
이질적인 분산 환경에서, 서로 다른 컴퓨터 내에 있는 응용프로그램 간의 상호 운용성과
다중 객체시스템들에 대한 상호연결성을 제공한다.

보통 대부분의 클라이언트 서버 응용프로그램들에서, 개발자는 자신의 고유한 설계를
사용하고, 또 장치들간에 사용될 프로토콜을 정의하기 위한 공인된 표준을 사용하게되는데,
프로토콜 정의는 개발언어, 네트웍 전달계층 등 수많은 요인들에 의존적이다. 그러나 ORB는
이러한 과정을 단순화하고, 언어에 독립적인 IDL이라는 하나의 구현에 의한 응용프로그램
인터페이스를 통해 프로토콜이 정의된다.

ORB는 유연성을 제공한다. ORB는 프로그래머가 가장 적합한 운영체계와 실행환경 그리고 심
지어는 개발중의 각 시스템 컴포넌트에 사용되는 프로그래밍 언어까지 마음대로 선택할 수
있게 한다. 가장 중요한 것은 ORB가 기존의 컴포넌트들의 통합을 허용한다는 것이다. ORB에
기초한 솔루션에서, 개발자는 새로운 객체를 만드는데 사용된 것과 같은 IDL을 써서 기존의
컴포넌트를 단순히 모델하고난 다음, 표준화된 버스와 기존의 인터페이스간에 번역을 해주는
'래퍼' 코드를 작성하면 그뿐이다.



IDL (interface definition language) ; 인터페이스 정의 언어

IDL은 한 언어로 작성된 프로그램이나 객체가, 알려지지 않은 언어로 작성된 다른
프로그램과 통신을 할 수 있도록 해주는 언어를 지칭하는 일반적인 용어이다. 분산 객체
기술에서, 새로운 객체들이 어떠한 플랫폼 환경에도 보내어질 수 있으며, 그 환경에서
어떻게 실행되는지를 알아내는 것은 매우 중요하다. ORB는 한 객체 프로그램과 다른
프로그램 사이에서 브로커 통신을 위해 IDL을 사용하는 프로그램의 예이다.

IDL은 스터브 내에 설명되어야할 프로그램의 인터페이스들, 또는 컴파일 되어지는
프로그램의 경미한 확장을 요구함으로써 동작한다. 각 프로그램 내의 스터브들은,
그들이 서로 통신할 수 있도록 해주는 브로커 프로그램에 의해 사용된다.

 


 

 

'Development > Common' 카테고리의 다른 글

유니코드(UNICODE) & 엔코딩(Encoding)  (1) 2012.01.19
utf-8 & euc-kr  (0) 2012.01.19
CORBA  (0) 2012.01.16
XML  (0) 2012.01.16
용어 정리  (0) 2011.12.07
Posted by linuxism
,

CORBA

Development/Common 2012. 1. 16. 18:45

코바(Common Object Request Broker Architecture; CORBA)는 OMG에서 정의한 규격으로서 소프트웨어 컴포넌트들을 언어와 사용환경에 대한 제약이 없는 통합을 위한 표준을 지칭한다.

목차

  [숨기기

[편집]개요

코바는 응용프로그램 객체 간의 메소드 호출을 표준화하기 위한 목적을 두고 있다. 각 객체의 위치는 로컬과 원격(네트워크 간)에 구애받지 않는다. CORBA는 응용프로그램 객체를 외부에 노출시키는 방법으로써 '인터페이스정의언어'(IDL)을 사용하고 있는데 이는 각 응용프로그램 객체를 IDL을 이용해 필요한 부분만 노출시키겠다는 의도에서이다. 초창기의 코바는 IDL 대 C++ / 자바 프로그래밍 언어와 매핑시켰으나 현재는 다수의 언어(에이다파이썬루비 등)를 공식적으로 지원한다. 이외에도 비공식적으로 비주얼 베이직 등의 언어도 지원한다.

코바의 사양에서 객체요청브로커를 통해서 응용프로그램이 다른 객체들과 상호작용 하게 한다고 구술하고 있다. 실제로 응용프로그램은 객체요청브로커를 초기화 하는 과정은 아래와 같이 간결하게 이루어져있다.

먼저, 생성코드클래스를 작성해야 한다. 이는 개발자가 IDL로 작성한 코드를 IDL 컴파일러를 통해 배포환경에 최적화시켜 컴파일 한 결과물이다. 이를 통해서 생성코드클래스의 생성이 완성되면 객체연결자에 등록시켜야 하는 데 이 객체연결자의 용도는 객체에 대한 참조수 확인, 객체(혹은 참조)초기화 정책, 객체에 대한 생명주기 정책 등이다.

이러한 과정은 코바에 있어서 꼭 필요한 과정이다.

프로그래밍 언어의 일부는 IDL과 매핑시키기 어렵다. 예를 들어 자바의 경우에는 IDL과의 조화가 잘 이루어지지만 C++의 경우는 매핑이 단순하지가 않다. 게다가 C언어의 경우에는 매우 생소하기까지 하다.(C언어의 경우 객체지향언어가 아니다)

프로그래밍 언어와의 매핑은 개발자가 실객체의 메소드를 얼마나 잘 노출시킬 수 있는지에 달려있다. 이를 위해 대부분의 코바 구현체는 IDL을 컴파일러와 툴을 가지고 있다. 전통적으로 IDL 컴파일러는 응용프로그램에서 사용가능한 오브젝트 파일로 IDL파일을 컴파일한다. 이 구조를 아래의 관계도에서 표현하고 있다.

[편집]배경

분산 시스템은 원격 시스템 간의 자원 공유, 개방성병렬성확장성내구성투명성 등을 제공해야 한다. 또한 80년대부터 대두 되었던객체지향 기술의 객체는 데이터와 그 데이터를 조작할 수 있는 메소드(method)로 구성되어 있으며, 프로그램은 메시지에 의한 객체 간의 상호 작용을 기술함으로서 여러 문제를 해결할 수 있게 됐다.

분산 객체 기술은 이러한 두 기술의 장점을 효과적으로 통합하는 기술이며, 개발자에게 애플리케이션 개발의 생산성을 향상시켜주고, 사용자에게 분산 환경에 투명하게 통합된 정보를 제공한다.

이를 위해 OMG(Object Management Group)에서는 분산 컴퓨팅과 객체지향 기술을 하나로 합친 표준 아키텍처를 제안하게 되는데, 그것이 바로 CORBA이다.

[편집]특징

CORBA는 애플리케이션들끼리 어느 위치든, 누가 만들었든 상관없이 상호간 통신을 보장하고 분산 객체 간의 상호 운용을 위한 통신 미들웨어 역할을 하며, 분산 객체 소프트웨어의 기본 틀로서 서비스를 제공하는 부분과 제공받는 부분간의 투명한 정보 교환이 가능하도록 하며 분산 환경에서 응용 소프트웨어를 쉽게 개발할 수 있도록 지원한다.

분산 환경에서 클라이언트와 서버 간의 인터페이스만 정의되면 이들 서로 간의 서비스 요구나 결과 값의 전달이 하부 통신 메커니즘에 반영될 수 있다.

CORBA를 이용한 응용 소프트웨어 개발은 각종 투명성이 보장되기 때문에 사용자의 특정 응용 업무 개발 환경에 적합하고 개발 과정이 간단하고 효율적이다.

[편집]CORBA 애플리케이션 개발

CORBA 애플리케이션 디자인은 다른 기계에 존재하는 객체와 네트워크에서 통신할 수 있도록 추가 계층(layer)을 포함해야 한다. 이런 추가 계층은 스텁(stub)과 스켈레톤(skeleton)이라는 특수한 객체에 의해 조절한다.

CORBA 클라이언트에서 스텁은 서버에 실제로 구현한 객체에 대한 프록시(proxy) 역할을 한다. 클라이언트는 인터페이스를 구현한 객체와 직접 상호 작용하듯이 스텁에 접근하여, ORB(Object Request Broker) 소프트웨어를 통해 인터페이스를 호출한다.

CORBA 서버에서 ORB 소프트웨어는 인터페이스 호출을 생성된 스켈레톤에 자동으로 넘겨준다. 스켈레톤은 Portable Object Adapter(POA)를 통해 ORB 소프트웨어와 통신한다. 스켈레톤은 POA를 사용해 객체를 등록하고, 여기에 객체의 범위와 객체가 인스턴스화해 클라이언트에 반응할 수 있게 되는 시기등을 결정한다.

[편집]CORBA의 구조

  • ORB의 구성 (클라이언트 사이드)
    • IDL 스텁 : 클라이언트의 정적 통신을 담당
    • 동적 호출 인터페이스(DII: Dynamic Invocation Interface) : 동적 통신을 담당
    • 인터페이스 저장소(interface repository): 인터페이스들을 저장하고 동적 호출시 참조
    • ORB 인터페이스 : 클라이언트측과 서버측에서 모두 이용할 수 있는 의사 객체(pseudo object) 관련 서비스 제공
  • ORB의 구성 (서버 사이드)
    • 객체 어댑터(Object Adapter) : 디스크에 적재된 응용 서버의 활성화 및 비활성화 등을 담당
    • IDL 스켈레톤 : 서버 측에서의 정적 통신을 담당
    • 동적 스켈레톤 인터페이스(DSI:Dynamic Skeleton Interface) : 동적 통신을 담당
    • 구현 저장소(Implementation Repository) : 서버 측 객체와 관련한 각종 정보를 저장
  • ORB 코어
    • 선택 가능한 컴포넌트에 ORB의 커널 기능을 제공
    • 최소한의 기능
      • 객체 레퍼런스의 생성, 해석 등의 객체의 기능적인 표현 기능
      • 클라이언트와 객체 구현 사이의 요청(Request)의 통신 기능
    • ORB 서비스 : 보안 컨텍스트를 요청(Request)와 함께 전송
  • 서버측과 클라이언트간의 정보 전달 경로
    • 클라이언트의 요구 메시지가 클라이언트 스텁(또는 DSI)을 통해 ORB core를 지나 서버측의 객체 어댑터로 전달며, 객체 어댑터는 요구한 서버의 위치를 구현 저장소를 통해 확인한 후 서버 활성화를 한다. 서버 실행이 끝나면 생성된 결과 값은 요구가 전달된 역순으로 클라이언트에게 전달된다.

[편집]CORBA 구현체 목록

[편집]상용

[편집]오픈소스

[편집]관련 항목

[편집]참고문헌

[편집]바깥 고리


'Development > Common' 카테고리의 다른 글

유니코드(UNICODE) & 엔코딩(Encoding)  (1) 2012.01.19
utf-8 & euc-kr  (0) 2012.01.19
IIOP  (0) 2012.01.16
XML  (0) 2012.01.16
용어 정리  (0) 2011.12.07
Posted by linuxism
,

XML

Development/Common 2012. 1. 16. 18:14

Markup Language

마크업 언어(markup 言語, markup language)는 태그 등을 이용하여 데이터의 구조를 명기하는 언어의 한 가지이다.

프로그래밍 언어와 구별하여 일반적으로 데이터 언어라고 하지만, {\mathrm{T\!_{\displaystyle E} \! X}}처럼 프로그래밍이 가능한 것도 있기 때문에 명확하게 구분되지는 않는다.

마크업은 그 파일이 프린터로 출력되거나 화면에서 어떻게 보여야할 것인지를 나타내기 위해, 또는 그 문서의 논리적인 구조를 묘사하기 위해서, 텍스트나 워드프로세싱 파일의 특정 위치에 삽입되는 일련의 문자들이나 기호들을 말한다. 마크업에 사용되는 표지를 흔히 "태그"라고 부른다. 예를 들어 다음의 태그는 문단을 나누는데 사용된다.

<p>

문서의 구조에 관한 마크업 정의 표준은 SGML에 있다. 마크업은 문서 작성자가 부호를 직접 쳐 넣거나, 편집기를 사용하여 미리 마련된 마크업 부호들(키보드를 덜 칠 수 있도록)을 사용하거나, 또는 그 문서가 실제로 나타낼 모양 그대로 만들 수 있는 보다 정교한 편집기(흔히 이를 WYSIWYG 편집기라고 한다)를 이용함으로써, 삽입될 수 있다.

====================================================================================

XML

위키백과, 우리 모두의 백과사전.

XML(Extensible Markup Language)은 W3C에서 다른 특수 목적의 마크업 언어를 만드는 용도에
서 권장되는 다목적 마크업 언어이다. XML은 SGML의 단순화된 부분집합이지만, 수많은 종류의
데이터를 기술하는 데 적용할 수 있다. XML은 주로 다른 시스템, 특히 인터넷에 연결된 시스템끼리
데이터를 쉽게 주고 받을 수 있게 하여 HTML의 한계를 극복할 목적으로 만들어졌다.

목차

  [숨기기

[편집]XML 기반 언어

XML 기반 언어는 다음과 같다.

이들 언어들은 단일하게 규정된 방식으로 정의되었기 때문에, 사전 정보가 없어도 이들 언어로
작성된 문서에 대해 수정이나 유효성 검사를 하는 프로그램도 제작할 수 있다.

[편집]기본 개념

XML에서의 기본 개념에는 10가지가 있다.

  • XML은 구조적인 데이터를 위한 것이다.
  • XML은 다소 HTML 같이 보인다.
  • XML은 텍스트이며, 읽혀지는 것만을 뜻하지 않는다.
  • XML은 크기가 커진다.
  • XML은 기술의 집합이다.
  • XML은 새로운 기술이 아니라 발전한 기술이다.
  • XML은 HTML에서 XHTML로 이끌었다.
  • XML은 모듈식이다.
  • XML은 RDF와 시맨틱 웹의 토대이다.
  • XML은 라이선스 제약이 없으며, 플랫폼이 독립적이고, 많은 지원이 있다.

[편집]웰 폼(Well-formed) 문서와 유효 XML 문서

XML 문서에는 두 가지 수준의 수정 절차가 있다:

  • 웰 폼(Well-formed) : 웰 폼 문서는 모든 XML의 구문을 허용한다. 예를 들어, 한 요소가 닫기
    태그와 자체 닫기 없이 열기 태그를 가지고 있으면, 웰 폼이라고 부르지 않는다. 웰 폼이 아닌
    문서는 XML이 된다고 말하지 않는다. 순응 파서(역자 주 - 파서: 컴퓨터에 입력된 정보를 번역,
    처리하는 프로그램의 하나)는 이를 처리하도록 허용하지 않는다.
  • 유효 : 유효 문서는 추가적으로 몇 가지 의미적 규칙을 허용한다. 이러한 규칙들은 사용자 정의로
    되어 있거나, XML 계획 또는 DTD로 포함된다. 예를 들어, 어느 문서가 정의되지 않은 태그를
    포함하고 있으면, 유효한 것이 아니다. 유효화 파서는 이를 처리하도록 허용하지 않는다.

[편집]같이 보기

[편집]바깥 고리

'Development > Common' 카테고리의 다른 글

유니코드(UNICODE) & 엔코딩(Encoding)  (1) 2012.01.19
utf-8 & euc-kr  (0) 2012.01.19
IIOP  (0) 2012.01.16
CORBA  (0) 2012.01.16
용어 정리  (0) 2011.12.07
Posted by linuxism
,