분산 데이터 관리 아키텍처

Distributed Data Management Architecture

DDM(Distributed Data Management Architecture)은 원격 컴퓨터의 데이터를 생성, 관리 및 액세스하기 위한 IBM의 공개 소프트웨어 아키텍처다. DDM은 처음에는 기록 지향 파일을 지원하도록 설계되었으며, 계층 디렉토리, 스트림 지향 파일, 대기열 및 시스템 명령 처리를 지원하도록 확장되었으며, IBM의 DRDA(Distributed Relational Database Architecture)의 기반으로 확장되었으며, 마지막으로 데이터 설명과 변환을 지원하도록 확장되었다. 1980년부터 1993년까지의 기간에 정의된 DDM은 필요한 구성요소, 메시지 및 프로토콜을 모두 객체 지향의 원칙에 기초하여 규정한다. DDM은 그 자체가 소프트웨어가 아니다. DDM의 구현은 클라이언트와 서버 제품의 형태를 띤다. 개방형 아키텍처로서 제품은 DDM 아키텍처의 하위 세트를 구현할 수 있고 제품은 추가 요구사항을 충족하도록 DDM을 확장할 수 있다. DDM 제품을 종합하면 분산 파일 시스템을 구현한다.

미디어의 DDM 아키텍처.

분산 애플리케이션

분산 애플리케이션 설계자는 데이터 관리, 보안 및 적시성 고려사항과 함께 전송할 데이터의 양과 빈도 측면에서 애플리케이션 프로그램 및 데이터의 최적 배치를 결정해야 한다. 분산 애플리케이션 설계에는 세 가지 클라이언트-서버 모델이 있다.

  1. FTP(File Transfer Protocol)는 파일이나 데이터베이스 테이블을 로컬에서 작동할 수 있도록 각 클라이언트로 복사하거나 이동시킨다. 이 모델은 문서 및 스프레드시트 편집기와 같은 상호 작용성이 높은 응용프로그램에 적합하며, 각 클라이언트는 해당 편집기의 복사본을 가지고 있고 그러한 문서의 공유는 일반적으로 문제가 되지 않는다.
  2. 씬 클라이언트 애플리케이션은 애플리케이션의 컴퓨터 부분이 영향을 받는 파일이나 데이터베이스로 중앙 집중화된 동안 사용자에게 애플리케이션의 인터페이스를 제공한다. 통신은 씬 클라이언트와 고유하게 설계된 메시지가 호출할 절차, 관련 매개변수 및 반환된 값을 지정하는 서버 사이의 원격 프로시저 호출로 구성된다.
  3. Fat 클라이언트 응용프로그램은 클라이언트 시스템에서 모든 응용프로그램 처리 작업을 수행하지만 데이터는 관리될 수 있도록 서버에 중앙 집중화되므로, 인증된 클라이언트 응용프로그램이 액세스할 수 있으며, 모든 클라이언트 응용프로그램이 최신 데이터로 작동하고, 레코드, 스트림 섹션 또는 데이터베이스 테이블만 의 영향을 받는n개의 신청서가 전송된다. 클라이언트 응용 프로그램 프로그램은 중앙 집중식 데이터로 작동하는 모든 클라이언트에 배포되어야 한다.

DDM 아키텍처는 처음에 분산된 애플리케이션의 뚱뚱한 클라이언트 모델을 지원하도록 설계되었다. 또한 전체 파일 전송도 지원한다.

DDM 아키텍처가 제공하는 이점

DDM 아키텍처는 분산된 애플리케이션에 다음과 같은 이점을 제공한다.[1]

  • 로컬/원격 투명성. 응용 프로그램은 로컬 데이터에서 원격 데이터로 쉽게 리디렉션할 수 있다. 원격 시스템에서 데이터에 액세스하고 관리하는 전문 프로그램은 필요하지 않다.
  • 데이터 중복성 감소. 데이터는 네트워크의 한 위치에만 저장되어야 한다.
  • 더 나은 보안. 데이터의 중복된 복사본을 제거함으로써, 네트워크의 데이터에 대한 액세스는 인가된 사용자로 더 잘 제한될 수 있다.
  • 데이터 무결성. 로컬 및 원격 동시 사용자에 의한 업데이트는 충돌로 인해 손실되지 않는다.
  • 시기적절한 정보. 네트워크에 있는 여러 컴퓨터의 사용자는 항상 최신 데이터에 액세스할 수 있다.
  • 리소스 관리 개선. 컴퓨터 네트워크의 데이터 저장 및 처리 리소스를 최적화할 수 있다.

역사

DDM 아키텍처는 컴퓨터 네트워크 전체에 분산된 데이터를 관리하고 액세스할 수 있도록 하는 메시지 및 프로토콜의 사양 집합이다. [2]

초동노력

IBM의 SNA(Systems Network Architecture)는 처음에 워크스테이션이 IBM 메인프레임 컴퓨터에 계층적으로 연결될 수 있도록 설계되었다. 당시 이용 가능한 통신 네트워크는 메인프레임 컴퓨터의 완전한 소프트웨어 제어 하에 있는 메인프레임과 그 워크스테이션 제품군 사이의 고정 연결 관점에서 엄격하게 설계되었다. 메인프레임 사이의 다른 통신도 특정 목적을 위해 정의된 소프트웨어에 의해 사용되는 고정 연결의 측면에서 이루어졌다. 통신망이 유연해지고 동적으로 변화함에 따라, 한 컴퓨터의 프로그램이 다른 컴퓨터의 프로그램과 상호작용을 시작하고 상호작용할 수 있는 일반적인 피어투피어 통신이 바람직하였다.

1980년대 초 IBM의 SNA Advanced Program to Program Communications(APPC) 아키텍처가 정의되었을 때, APPC를 원격 컴퓨터에서 운영 체제 서비스를 제공하는 데 사용할 수 있다는 것도 명백했다. SNA 작업 그룹은 이러한 아이디어를 추구하고 파일 서비스, 프린터 서비스, 시스템 콘솔 서비스와 같은 가능한 분산 서비스를 개략적으로 설명했지만 제품 개발을 시작할 수 없었다. APC 소프트웨어는 메인프레임에서 아직 사용할 수 없었고, 보다 근본적으로 메인프레임은 여전히 주로 독립형 시스템으로 간주되었다. 그 결과, 분산된 서비스에 대한 작업은 SNA 작업 그룹에 의해 중단되었다.

IBM의 로체스터, 미네소타 개발 연구소의 SNA 작업 그룹 멤버들은 로체스터에서 생산된 중거리 컴퓨터 시스템들 사이에 분산된 서비스를 위한 비즈니스 사례가 존재한다고 확신했다. IBM System/3, IBM System/34IBM System/36 Minicomputers를 연결하기 위해 DDFF(Distributed Data File Facility)라고 불리는 원시 형태의 분산 파일 서비스가 구현되었다. 또한, IBM System/36과 IBM System/38 컴퓨터는 고객에게 배수로 판매되고 있었고, 예를 들어, 기업의 본사 컴퓨터가 자사의 다양한 창고에 있는 컴퓨터와 상호작용을 할 수 있도록 해야 할 분명한 필요성이 있었다. APC는 이러한 시스템에서 구현되었으며 다양한 고객 애플리케이션에서 사용되었다. 그리고 나서 분산 운영 체제 서비스에 대한 생각은 골든 게이트 프로젝트와 그것의 개발을 정당화하려는 시도로 부활되었다. 이 시도는 또한 실패했다; 분산된 서비스에 대한 전체 아이디어는 IBM 제품 기획자들이 이기종 컴퓨터를 상호연결하는 소프트웨어의 가치를 계량화할 수 있기에는 너무 새로운 것이었다.

그러나 골든 게이트 기획자인 존 본디는 사전 정의된 비즈니스 사례가 당장 필요하지 않도록 로체스터 실험실의 정상적인 통제 밖의 부서를 만들도록 경영진을 설득하고 설득했다. 나아가 DDM(Distributed Data Management) 지원, 특히 기록 지향 파일 지원만 포함하도록 사명을 좁혔다. 그리고 나서 그는 경험이 많은 소프트웨어 설계자인 Richard A를 설득했다. DDM 아키텍처를 정의하고 DDM 아이디어를 IBM 시스템 하우스에 판매하는 작업에 참여하십시오.

이러한 노력의 첫 해에는 IBM 시스템 하우스가 초기 비즈니스 사례를 계속 요구했고, 로컬 파일 시스템의 제어 블록 인터페이스에 대해 이형화된 메시지 형식을 고집했기 때문에 대부분 성과가 없었다. 나아가 퍼스널 컴퓨터가 메인프레임 컴퓨터에 연결된 단말기로 이용되기 시작하면서 3270개의 데이터 스트림을 단순히 강화하면 PC가 메인프레임 데이터에 접근할 수 있다는 주장이 제기됐다.

이 기간 동안, Demers는 DDM 클라이언트와 서버, 구성요소의 아키텍처 모델과 통신 컴퓨터 사이의 상호작용을 설계했다. 또한, 그는 Smalltalk 프로그래밍 언어와 IBM System/38에 의해 개척된 객체 지향 원리에 기초하여 DDM 메시지의 일반 형식을 정의했다. 이 모델은 DDM 제품이 다양한 시스템에서 구현될 수 있는 방법을 명확히 했다. DDM 작동 방식을 참조하십시오.

1982년, 시스템/36 기획자들은 DDM 레코드 중심 파일 서비스를 위한 충분한 시장이 있다고 확신하게 되었다.[3]

DDM 레벨 1: 레코드 지향 파일

DDM 메시지의 일반 형식은 이미 설계되었지만, 구체적으로 어떤 메시지를 정의해야 하는가? System/36 파일 시스템은 Fortran, COBOL, PL/I, IBM RPG와 같은 3세대 프로그래밍 언어(3GL)의 기록 지향적 요구를 충족하도록 정의되었으며, IBM 메인프레임 컴퓨터의 System/38 파일 시스템과 VSAM(Virtual Storage Access Method) 파일 시스템도 이에 적합했다. 그러나 실제 시설과 인터페이스는 상당히 다양했다. 그렇다면 DDM 아키텍처는 어떤 시설과 인터페이스를 지원해야 하는가? 레코드 지향 파일을 참조하십시오.

Golden Gate 프로젝트의 DDM에 대한 초기 작업은 분산 파일에 대한 FTAM(File Transfer Access and Management) 국제 표준의 선례를 따랐지만, 로컬 파일 서비스에 매핑하는 것은 매우 추상적이고 어려웠다. 사실, 이것은 IBM 시스템 하우스의 수용을 가로막는 장애물 중 하나였다. 시스템/36 파일 서비스를 담당하는 시스템 설계자인 케네스 로렌스는 적어도 하나의 IBM 시스템이 쉽게 구현할 수 있는 메시지를 정의한 다음 다른 시스템이 필요한 변경사항을 요청하도록 하는 것이 더 낫다고 주장했다. 당연히, 그는 시스템/36 요건의 지지를 주장했다. DDM의 아이디어를 다른 IBM 시스템 하우스에 팔지 못한 지 1년 만에 로렌스의 주장이 우세했다.

Richard Sanders는 DDM 아키텍처 팀에 합류하여 Lawrence 및 Demers와 협력하여 System/36 DDM에 필요한 구체적인 메시지를 정의했다. DDM 정의의 진행은 System/38도 참여하도록 장려했다. 이를 통해 DDM 레코드 파일 지원의 범위가 확대되어 시스템/38의 고급 파일 시스템의 많은 요구사항을 충족시켰다.

파일은 파일 구성, 동시 사용자와 공유 및 무단 액세스로부터 파일 보호를 위한 서비스를 제공하는 운영 체제에서 제공하는 컨텍스트에 존재한다. DDM 레벨 1에서는 사용할 파일의 정규화된 이름의 전송을 넘어 원격 파일 디렉토리에 대한 액세스가 지원되지 않았다. 그러나 보안과 공유가 필요했다. 샌더스는 이 지역에서 디자인 작업을 했다. 샌더스 대변인은 또 DDM 대화통신관리자(DDM Talking Communications Manager)라는 컴포넌트에 통합돼 있는 통신설비 사용과 관련한 구체적인 프로토콜도 정의했다. 처음에 APC를 사용하여 구현되었으며, 나중에 TCP/IP를 사용하여 구현되었다.

With the completion of the System/36 DDM product, Lawrence worked with programmers from the IBM Hursley Park, UK laboratory to adapt much of the System/36 DDM server programming for use in the IBM Customer Information Control System (CICS) transaction processing environment, thereby making CICS a DDM server for both the MVS and VSE mainframe operat잉그 [4]시스템 로렌스는 또한 IBM Cary, North Carolina 연구소의 프로그래머들과 함께 IBM PC DOS용 DDM 레코드 중심 클라이언트를 구현했다.

DDM 아키텍처의 레벨 1은 1986년에 정식으로 출판되었다. 이 발표 당시 IBM은 케네스 로렌스에게 우수 기술 공로상, 리처드 샌더스에게는 우수 공로상, 리처드 데머스에게는 우수 혁신상을 수여했다.

  • In this article, System/38 will be henceforth used to refer to the System/38 and its successors: the IBM AS/400 (which merged the functionality of the System/36 and the System/38), the IBM iSeries, and the IBM Power Series[5] (which merged the iSeries with the IBM RS/6000, IBM's RISC/UNIX-based server and workstation product line).

DDM 레벨 2: 계층형 디렉토리 및 스트림 지향 파일

네트워크 환경에서 IBM PC와 Unix 운영체제의 중요성이 증대됨에 따라, IBM PC DOS를 실행하는 IBM Personal ComputerIBM AIX(IBM의 Unix 버전)를 실행하는 IBM RS/6000의 계층적 디렉토리 및 스트림 지향 파일에도 DDM 지원이 필요했다. 스트림 지향 파일을 참조하십시오.

DDM 건축 레벨 2는 1988년에 출판되었다. Jan Fisher와 Sunil Geitonde는 대부분의 아키텍처 작업을 디렉토리 및 스트림 파일에 대한 DDM 지원에 대해 수행했다.

DDM 레벨 3: 관계형 데이터베이스 서비스

1986년에 IBM은 각각 특정 IBM 운영 체제를 위해 구축된 4개의 서로 다른 관계형 데이터베이스(RDB) 제품을 판매했다. IBM의 Almaden 연구소의 과학자들은 분산된 RDB의 원형인 System/R*를 개발했고 그들은 이제 그것을 시장성 있는 제품으로 바꿀 때가 되었다고 느꼈다. 그러나 System/R*는 RDB의 연구 시제품인 System/R을 기반으로 하여 IBM RDB 제품에 쉽게 추가할 수 없었다. 분산 처리 환경의 RDB에 대한 자세한 내용은 을 참조하십시오[6].

IBM Santa Tesa Programming Center의 Roger Renech는 DRDA(Distributed Relational Database Architecture)를 정의하기 위해 교차 제품 팀을 이끌고 있다. 그는 다음과 같이 입대했다.

  • 4개의 IBM RDB 제품 각각에 대한 담당자.
  • 시스템/R* 연구원인 브루스 린제이는
  • FD(Formated Data: Object Content Architecture: FD:OCA).
  • 적절한 모델, 메시지 및 프로토콜을 정의하기 위해 DDM 아키텍처 팀의 Richard Sanders와 Richard Demers.

1990년에는 DDM 아키텍처 레벨 3과 DRDA가[7] 동시에 발표되었다. DDM과 DRDA 모두 IBM의 SAA(Systems Application Architecture)의 전략적 구성요소로 지정되었다. DRDA는 IBM RDB 제품 4개와 다른 공급업체에 의해 구현되었다.

DRDA 설계의 주요 참가자들에게 상이 수여되었다. Richard Sanders는 우수 공로상을, Roger Renech와 Richard Demers는 우수 혁신상을 받았다.

DDM 레벨 4: 추가 서비스

DFM([8]Distributed File Management) 프로젝트는 원격 컴퓨터의 프로그램이 VSAM 파일을 생성, 관리 및 액세스할 수 있도록 하기 위해 IBM의 MVS 운영 체제에 DDM 서비스를 추가하기 위해 시작되었다. DFM 프로젝트의 관리자 John Hufferd는 DDM Architecture 팀에게 기록의 데이터 필드가 시스템 간에 흐를 때 변환할 수 있는 방법을 찾아보았다. Richard Demers는 DFM 프로젝트에서 야마구치 고이치 감독의 도움을 받아 이 문제를 주도했다. 자세한 내용은 데이터 설명변환을 참조하십시오.

Richard Sanders, Jan Fisher 및 Sunil Gietonde가 레벨 4 DDM 아키텍처에서 정의한 추가 서비스는 다음과 같다.

  • DFM의 경우 스토리지 관리 및 사용자 정의 파일 속성.
  • DRDA의 경우, 애플리케이션 지향 분산 작업 단위에 대한 2상 약속 제어 프로토콜.
  • 원격 서버에서 생성, 삭제 또는 삭제할 수 있는 대기열. 대기열 항목은 대기열에 추가되거나 대기열에서 수신되는 응용 프로그램 정의 레코드 입니다. DDM 대기열을 참조하십시오.
  • 서버의 호스트 시스템에 의해 정의된 명령을 실행하기 위해 전송할 수 있는 관리자인 시스템 명령 프로세서.
  • 여러 클라이언트 에이전트가 클라이언트와 서버 시스템 간의 단일 대화를 사용하여 해당 서버 에이전트와 통신할 수 있도록 하는 다중 태스크 통신 관리자.
  • Sync Point 매니저는 여러 DDM 서버에서 논리적인 작업 단위를 조정한다. 2단계 약속 프로토콜은 논리적 작업 단위가 실패할 때 조정된 자원 복구를 보장한다.

DDM 아키텍처 레벨 4는 1992년에 발표되었다.

DDM 레벨 5: 라이브러리 서비스

DDM 레벨 5에 대한 아키텍처 작업 지원으로 구성

  • 메인프레임 분할된 데이터 세트(Mainfline Partitioned Data Set)는 내부 디렉토리와 여러 구성원으로 구성된 파일이다. 사실상, 그것들은 유사한 파일의 라이브러리들이다.
  • 단일 라이브러리의 여러 폴더에 있는 파일에 대한 액세스를 통합하는 개인 컴퓨터 라이브러리
  • DRDA에 대한 추가 개선.

얀 피셔는 IBM이 아닌 오픈 그룹이 발행한 DDM 레벨 5를 담당한 건축가였다. 그 직후 IBM DDM 아키텍처 그룹은 해체되었다.

DDM 내부

DDM 아키텍처는 공식적으로 정의되고 고도로 구조화된 규격 집합이다. 이 절에서는 DDM의 기초가 되는 주요 기술 개념을 소개한다.[2]

DDM 작동 방식

Overview of DDM Processing

DDM 아키텍처는 클라이언트/서버 프로토콜을 정의한다. 즉, 클라이언트는 요청된 서비스를 수행하기 위해 로컬 리소스와 상호 작용하는 서버로부터 서비스를 요청하며, 그 결과는 데이터 및 상태 표시기가 클라이언트로 반환된다. 위의 도표는 로컬 자원과 관련하여 DDM 클라이언트와 서버의 역할을 보여준다. (여기에서 클라이언트와 서버의 일반적인 용어를 사용하지만, DDM 아키텍처에서는 클라이언트를 소스 서버, 서버를 대상 서버라고 부른다.)

  1. 응용 프로그램은 로컬 리소스 관리자(LRM)가 제공하는 프로그래밍 인터페이스를 통해 파일과 같은 로컬 리소스와 상호 작용하지만, 원하는 리소스가 원격 컴퓨터에 있으면 DDM을 사용하여 상호 작용을 중재한다. 응용 프로그램은 LRM에서 제공하는 인터페이스를 계속 사용하지만 DDM 클라이언트로 리디렉션된다. DDM 아키텍처는 원격 리소스의 디렉토리를 지원하지 않기 때문에 이 리디렉션의 발생 방법을 지정하지 않는다. 여러 DDM 파일 지향 제품에서 사용하는 리디렉션 방법 중 하나는 원격 파일에 대한 위치 및 액세스 정보를 제공하는 시스템/38에 의해 DDM 파일이라는 특수한 로컬 파일을 응용 프로그램으로 여는 것이다. 그런 다음 DDM 클라이언트로 리디렉션하십시오.
  2. DDM 아키텍처는 파일, 관계형 데이터베이스, 액세스 방법 등에 대한 관리자 수준 엔티티를 정의한다. CRM(Client Resource Manager)은 클라이언트 시스템의 LRM에 의해 정의된 기능 인터페이스를 다각적으로 지원한다. 주요 기능은 각 기능 인터페이스에 적합한 선형화된 DDM 명령과 데이터 객체를 생성하는 것이다. (DDM 메시지를 참조하십시오.) 이러한 개체는 원격 DDM 서버의 SRM(서버 리소스 관리자)으로 전송된다. 그러나 실제로는 DDM 클라이언트와 서버 에이전트 및 통신 관리자를 통해 라우팅된다.
  3. DDM Client 에이전트는 선형화된 명령을 RQSDSS 봉투에 넣고 선형화된 객체를 연결된 OBJDS 봉투에 넣는다. (DDM 메시지를 참조하십시오.) 클라이언트 에이전트는 서버 에이전트와 상호 작용하여 CRM에서 수신한 메시지가 SRM으로 흐를 수 있는 경로를 생성한다. 애플리케이션 프로그램이 단일 원격 리소스와만 상호 작용해야 하는 경우 이는 간단하다. 그러나 애플리케이션 프로그램은 여러 원격 시스템에 존재하는 다양한 종류의 여러 리소스와 동시에 상호작용할 수 있다. 클라이언트 에이전트는 모든 경우에 애플리케이션 프로그램을 나타내며 각 리소스로 별도의 가상 경로에 있는 메시지를 라우트한다.
  4. Client Communications Manager는 ServerCommunications Manager와 상호 작용하여 "당신이 들을 때 내가 말하고, 내가 들을 때 당신이 말한다"라는 형식의 대화 프로토콜을 구현한다. IBM의 SNA APPC, 인터넷의 TCP/IP 프로토콜을 포함한 다양한 통신 프로토콜을 사용할 수 있다.
  5. 서버 Communications Manager로 전송된 DDM 메시지는 메시지가 지정한 경로에 있는 서버 에이전트로 전달되며, 동일한 경로에 있는 SRM으로 메시지를 전달한다. 서버 에이전트가 단일 경로에서 단일 클라이언트와 상호 작용하는 경우, 이는 간단하다. 그러나 서버 에이전트는 여러 경로에서 여러 클라이언트와 상호 작용할 수 있다.
  6. SRM(Server Resource Manager)은 DDM 메시지를 구문 분석하여 요청을 수행하기 위해 수행해야 할 작업을 결정한다. 서버 시스템의 해당 LRM(Local Resource Manager)의 기능 인터페이스를 하나 이상 사용할 수 있다.
  7. SRM은 LRM에서 데이터와 상태 표시기를 누적하고 적절한 선형화된 개체와 응답 메시지를 생성하며, 이 메시지가 서버 에이전트로 전달된다.
  8. 서버 에이전트는 회신 및 객체를 RPYDSS 및 OBJDSS 봉투에 패키징하여 서버 Communication Manager에 전달하며, 서버 Communication Manager는 이를 원래 명령과 동일한 경로로 클라이언트 Communication Manager 및 클라이언트 에이전트로 전송한다.
  9. 클라이언트 에이전트는 각 RPYDSS 및 OBJDSS 봉투에서 회신과 개체를 제거하고 클라이언트 리소스 관리자에게 전달한다.
  10. 클라이언트 리소스 관리자는 반환된 객체를 구문 분석하여 회신하고 애플리케이션 프로그램으로 반환하기 위해 원래 LRM의 기능 인터페이스에서 예상한 대로 메시지를 매핑한다.

객체 지향

DDM 아키텍처는 객체 지향적이다. DDM에 의해 정의된 모든 엔티티는 자체 정의 클래스 객체에 의해 정의된 객체다. 시스템 간에 흐르는 메시지, 응답, 데이터는 직렬화된 객체다. 각 물체는 길이를 지정하고 DDM 코드로 클래스를 식별하며 클래스에 의해 정의된 데이터를 포함한다. 또한, 클래스는 개체가 DDM 클라이언트 또는 서버에 있을 때 해당 인스턴스에 전송할 수 있는 명령을 지정하여 제한된 작업 집합에 의해 개체를 캡슐화한다.

구조적으로, DDM 아키텍처는 점점 더 높은 수준에서 출현하는 특성을 나타내는 각 수준의 개체 계층적 수준으로 구성된다.

  • 필드는 숫자, 문자 또는 기타 데이터 엔티티를 인코딩하는 비트 문자열이다. 필드 하위 클래스의 인스턴스는 해당 클래스에 의해 수행될 수 있는 연산(예: 정수 필드의 산술 연산)에 의해 캡슐화된다.
  • 개체는 정의된 운영 집합에 의해 캡슐화된 하나 이상의 필드로 구성된 자체 식별 개체다. 이 수준의 개체는 Smalltalk 프로그래밍 언어의[9] 커널 객체 클래스에서 영감을 받았다.
    • 스칼라 객체는 객체의 클래스에 의해 인코딩되고 설명되는 단일 필드로 구성된다. 스칼라 객체는 명령 및 응답 객체의 매개변수 값으로 사용된다. DDM 설명서의 개체 길이와 같이 개체 속성의 값으로도 사용된다. 이러한 스칼라 객체의 값에 사용되는 인코딩 방법은 DDM 아키텍처에 의해 완전히 정의된다.
    • 매핑된 오브젝트는 응용프로그램 정의 레코드의 필드와 같은 하나 이상의 필드로 구성된다. 인코딩 방법과 이러한 필드의 정렬은 DDM 아키텍처에 의해 정의되지 않고, 대신 응용 프로그램 선언문과 프로그래밍 언어의 인코딩 및 정렬 방법에 의해 정의된다.
    • 컬렉션 오브젝트는 컬렉션의 클래스에 의해 정의된 오브젝트용 컨테이너 입니다. 수집 개체의 예로는 DDM 명령 및 응답이 있다.
  • 매니저는 객체의 저장과 처리를 위한 환경을 제공하는 주체다. 관리자는 클래스에 의해 정의된 작업에 의해 캡슐화된다. 관리자 집합이 함께 DDM 클라이언트 또는 서버의 전체 처리 환경을 구현한다. 이 수준의 관리자 엔티티는 시스템/38 운영 체제의 시스템 오브젝트에서 영감을 받았다.[10] DDM에 의해 정의된 관리자: 사전, 감독자, 에이전트, 디렉터리, 파일, 액세스 방법, 관계형 데이터베이스, SQL Application Manager, 대기열, 잠금 관리자, 보안 관리자, 복구 관리자, 시스템 명령 프로세서, 통신 관리자
  • 서버는 분산 처리 환경에서 클라이언트나 서버로서 관리자의 저장 및 처리를 위한 환경을 제공하는 자체 식별 실체다. 분산 파일 또는 분산 관계형 데이터베이스 관리에 특화된 클라이언트 및 서버를 예로 들 수 있다.

DDM 아키텍처는 객체 지향적이지만 DDM 제품은 호스트 시스템의 일반적인 언어와 방법을 사용하여 구현되었다. IBM PC용 DDM은 Object Technology International에 의해 개발되었으며, DDM 참조 매뉴얼에서 적절한 Smalltalk 클래스가 자동으로 작성되었다.

하위 집합 및 확장

DDM은 개방형 아키텍처다. DDM 제품은 DDM 아키텍처의 하위 세트를 구현할 수 있으며, 자체 확장을 생성할 수도 있다. [11]

DDM 'Exchange Server Attributes' 명령은 클라이언트가 서버에 연결되었을 때 전송되는 첫 번째 명령어다. 클라이언트를 식별하고 클라이언트가 요구하는 관리자 및 지원이 필요한 DDM 아키텍처의 수준을 지정한다. 서버는 자신을 식별하고 요청된 관리자를 지원하는 수준을 명시함으로써 응답한다. 일반적으로 DDM 관리자의 레벨 X를 지원하는 제품은 새로운 서버 제품이 이전 클라이언트 제품과 연결되도록 레벨 X-1도 지원해야 한다.

DDM 하위 세트를 구현하여 다양한 제품 요구 사항 충족:

  • 클라이언트, 서버 또는 둘 다. 예를 들어 DDM/PC는 클라이언트일 뿐이고, CICS/DDM은 서버일 뿐이며, System/38 DDM은 클라이언트일 뿐 서버일 뿐이다.
  • 레코드 지향 파일, 스트림 지향 파일, 관계형 데이터베이스(DRDA의 일부) 또는 이들의 조합과 같은 특정 관리자를 지원한다. 예를 들어, MVS Database 2는 DRDA가 요구하는 DDM의 서브셋에 대해서만 클라이언트와 서버 지원을 제공한다.
  • 순차 파일에서 레코드를 로드 및 언로드할 수 있는 기능과 같은 관리자의 선택된 명령만 지원
  • 'Return Inactive Records' 명령의 'Return Inactive Records' 매개변수와 같은 명령의 선택된 매개변수를 지원한다.

DDM 클라이언트가 시스템/38 클라이언트와 같이 알려진 DDM 서버에 연결되었을 때 DDM 아키텍처를 추가하여 확장할 수도 있다.

  • 새로운 제품별 관리자
  • 기존 DDM 관리자에 대한 새 명령.
  • DDM 명령 또는 응답 메시지에 대한 새 매개 변수.

이러한 확장은 DDM의 객체 지향 프레임워크 내에서 정의되어 기존의 DDM 메시지 처리 설비를 사용할 수 있다.

DDM 메시지

DDM의 순전히 객체 지향적인 구현에서는 클라이언트와 서버, 그리고 그 안에 포함된 모든 관리자와 객체가 메모리 힙에 존재하며, 포인터(메모리 주소)를 사용하여 이들을 상호 연결한다. 예를 들어 명령 개체는 각 매개 변수 개체를 가리킨다. 그러나 명령어는 이런 방식으로 클라이언트에서 서버로 전송될 수 없다. 명령어의 이형성 복사본은 비트의 연속적인 단일 문자열로 생성되어야 한다. 힙에서 명령은 힙의 명령 크기, 명령 클래스에 대한 포인터 및 각 명령의 매개 변수 개체에 대한 포인터로 구성된다. 선형화된 명령어는 선형화된 명령의 총 길이, 명령의 클래스를 식별하는 코드 포인트 및 각 선형화된 파라미터 객체로 구성된다. DDM 아키텍처는 각 객체 클래스에 고유한 코드 포인트를 할당한다. 이 간단한 기술은 명령, 기록, 응답 메시지를 포함하여 클라이언트와 서버 간에 전송되는 모든 개체에 사용된다.

이 모든 선형화된 오브젝트는 클라이언트와 서버 에이전트가 처리를 조정할 수 있도록 봉투에 넣는다. DDM 아키텍처에서는 이러한 봉투를 DSS(Data Stream Structures)라고 부른다. 명령은 Request DSS(RQSDSS)에, 응답은 Response DSS(RPYDSS)에, 다른 개체는 OBJDSS(Object DSS)에 넣는다. RQSDSS에는 하나의 명령만 있을 수 있고 RPYDSS에는 하나의 응답만 있을 수 있지만, 기록과 같은 많은 객체를 OBJDSS에 넣을 수 있다. 또한 많은 OBJDSS를 RQSDSS 또는 PREDSS에 체인으로 연결하여 필요한 만큼 많은 물체를 수용할 수 있다. DSS는 DSS의 총 길이, DSS의 유형을 식별하는 플래그 바이트, 요청 식별자 및 DSS의 선형화된 객체로 구성된다. 요청 식별자는 RQSDSS를 Load File 명령에 의해 파일에 로드되는 기록과 같이 클라이언트의 후속 OBJDSS와 연결한다. 요청 식별자는 또한 클라이언트에서 RQSDSS를 RPYDSS 또는 서버에서 클라이언트로 OBJDSS와 연결한다.

문서화

DDM 참조 설명서는[12][13] 이름이 지정된 메뉴, 도움말 및 클래스 개체로 구성되어 있다. DDM Class의 하위 클래스는 지정된 변수에 의해 설명된다.

  • 반의 최상급 클래스는 상속 계층에 의해 정의된다. 예를 들어, 레코드 파일은 관리자의 하위 클래스인 파일의 하위 클래스로서 데이터와 명령을 상속한다. Class Exlass 및 그 하위 클래스는 다음과 같은 Class 명령과 클래스 변수에 의해 자체 설명된다.
  • 반을 간략하게 설명하는 제목
  • DDM 아키텍처에 대한 진행 중인 작업에 대한 클래스 상태
  • 클래스를 구성 요소 및 환경과 관련된 설명 텍스트 및 그래픽
  • 클래스의 인스턴스에 의해 캡슐화된 데이터(필드, 객체, 관리자 등)
  • 해당 인스턴스에 전송할 수 있는 명령

이러한 오브젝트는 텍스트와 사양에 다른 명명된 오브젝트에 대한 참조를 포함할 수 있으므로 DDM 참조 매뉴얼의 페이지 사이에 하이퍼텍스트 연결을 작성할 수 있다. 메뉴 및 도움말 페이지는 DDM에 대한 통합 자습서를 형성한다. DDM 참조 매뉴얼 레벨 3의 종이 버전은 부피가 크고 1400페이지가 넘으며 다소 사용하기 거북하지만, IBM 내부 통신 시설을 사용하여 인터랙티브 버전도 제작되었다. 이러한 통신 설비의 속도가 상대적으로 느린 점을 감안할 때, 주로 IBM Rochester 연구소 내에서 사용하였다.

DDM 참조 매뉴얼 외에도 일반 정보[1] 문서는 DDM에 대한 임원급 정보를 제공하며, 프로그래머 가이드는[11] 클라이언트와 서버를 구현하는 프로그래머를 위한 DDM 개념을 요약한다.

DDM 파일 모델

레코드 지향 파일, 스트림 지향 파일, 계층적 디렉토리 등 세 가지 일반 파일 모델이 DDM 아키텍처에 의해 정의된다.

원격 파일 관리를 위해 DDM 아키텍처에서 제공하는 서비스는 다음과 같다.

  • 파일 만들기, 지우기 및 삭제,
  • 파일의 데이터 복사, 로드 및 언로드
  • 파일 잠금 및 잠금 해제,
  • 파일 속성 가져오기 및 변경,

레코드 지향 파일

기록 지향 파일은 포트란, 코볼, PL/I, RPG 등 3세대(3GL) 프로그래밍 언어의 데이터 입력, 출력, 저장 요건을 충족하도록 설계되었으며, 각 언어가 이러한 기능에 대한 자체적인 지원을 제공하는 것이 아니라 운영체제가 제공하는 서비스에 통합되었다.

레코드는 한 직원의 이름, 주소, 식별 번호 및 급여와 같은 일련의 관련 데이터 필드로, 각 필드가 연속적인 바이트 문자열로 인코딩되고 매핑된다. 초기 컴퓨터들은 입력과 출력 기능이 제한되어 있었는데, 일반적으로 80개의 기둥으로 된 펀치된 카드의 스택 형태나 종이나 자석 테이프의 형태로 되어 있었다. 직원 데이터 기록과 같은 신청 기록은 순차적으로 한 번에 기록을 읽거나 작성해 일괄 처리했다. 다이렉트 액세스 저장 장치를 사용할 수 있게 되자 프로그래밍 언어는 핵심 필드의 값이나 파일의 레코드 위치에 의한 액세스와 같이 프로그램이 한 번에 하나씩 레코드에 임의로 액세스하는 방법을 추가했다. 파일의 모든 레코드는 동일한 형식(급여 파일) 또는 다양한 형식(이벤트 로그)일 수 있다. 일부 파일은 일단 파일에 쓰여진 레코드는 읽기 전용인 반면, 다른 파일은 레코드를 업데이트할 수 있도록 허용한다.

DDM 레코드 지향 파일 모델은 생성 날짜, 마지막 업데이트 날짜, 레코드의 크기, 레코드를 저장할 수 있는 슬롯 등의 파일 속성으로 구성된다. 레코드는 파일의 레코드를 저장하는 데 사용되는 미디어에 따라 고정되거나 길이가 다를 수 있다. DDM은 네 가지 종류의 레코드 지향 파일을 정의한다.

  • 연속된 슬롯에 레코드가 저장되는 순차 파일.
  • 개별 레코드가 레코드 필드 값에 의해 결정된 파일의 슬롯에 저장되는 직접 파일.
  • 연속된 슬롯에 레코드가 저장되고 레코드에 포함된 키 필드 값의 색인을 통해 보조 순서가 유지되는 키 파일.
  • 키 필드 값의 개별 인덱스가 기존 순차, 직접 또는 키 파일에 기반하는 대체 인덱스 파일.

또한 DDM 아키텍처는 다양한 방법으로 레코드 지향 파일과의 작업을 위한 다양한 접근 방법을 정의한다. 액세스 방법은 클라이언트가 파일을 사용할 수 있는 권한이 있는지 확인한 후 파일에 자신을 연결하는 OPEN 명령을 통해 생성된 파일을 사용하는 예다. 접근 방법은 CLOSE 명령을 통해 파일에서 분리된다.

액세스 방법은 커서를 통해 현재 처리 중인 레코드를 추적한다. 다양한 SET 명령을 사용하여 커서는 파일의 시작 또는 끝, 파일의 다음 또는 이전 순차적 레코드, 특정 키 값을 가진 레코드 또는 키에 의해 순서가 정해진 다음 또는 이전 레코드를 가리키도록 만들 수 있다.

하나의 파일에서 여러 액세스 방법 인스턴스를 동시에 열 수 있으며, 각 인스턴스는 하나의 클라이언트에 제공된다. 업데이트 액세스를 위해 파일을 열면 여러 클라이언트가 동일한 레코드를 액세스하고 있을 때 충돌이 발생할 수 있다. 이러한 충돌을 방지하기 위해 전체 파일에 대한 잠금을 얻을 수 있다. 또한 업데이트를 위해 파일을 여는 경우, 첫 번째 클라이언트가 파일을 읽은 레코드에 잠금을 가져와서 해당 클라이언트가 파일을 업데이트할 때 릴리스한다. 다른 모든 고객들은 자물쇠가 풀릴 때까지 기다려야 한다.

스트림 지향 파일

스트림 지향 파일은 프로그램이 원하는 대로 응용 프로그램 데이터를 매핑할 수 있는 바이트의 단일 시퀀스로 구성된다. 스트림 파일은 유닉스 및 유닉스 유사 운영 체제와 윈도우즈에서 지원하는 기본 파일 모델이다. DDM은 단일 스트림 파일 모델과 단일 스트림 액세스 방법을 정의한다.

DDM 스트림 파일 모델은 생성 날짜 및 스트림의 크기와 같은 파일 속성과 바이트의 연속 스트림으로 구성된다. 스트림 접근법에 의해 스트림에 접근할 수 있다. 애플리케이션 프로그램은 데이터가 기록으로 구성되더라도 스트림의 일부에 데이터를 기록한다. 그들은 그들이 원하는 방식으로 스트림에서 데이터 항목의 위치를 추적한다. 예를 들어 문서 파일의 데이터 스트림은 Microsoft Word와 같은 텍스트 처리 프로그램과 Microsoft Excel과 같은 프로그램에서 스프레드시트 파일의 데이터 스트림을 정의한다.

스트림 액세스 방법은 단일 클라이언트가 스트림 파일을 사용하는 인스턴스다. 커서는 클라이언트가 사용 중인 서브스트림의 현재 바이트 위치를 추적한다. 다양한 SET 명령을 사용하여 커서는 파일의 시작 또는 끝, 파일의 특정 위치 또는 현재 위치에서 양 또는 음의 오프셋을 가리키도록 만들 수 있다.

스트림 액세스 방법의 여러 인스턴스를 한 파일에서 동시에 열 수 있으며, 각 인스턴스는 하나의 클라이언트에 서비스를 제공한다. "업데이트" 액세스를 위해 파일을 열면 여러 클라이언트가 동일한 하위 스트림을 액세스하고 있을 때 충돌이 발생할 수 있다. 이러한 충돌을 방지하기 위해 전체 파일에 대한 잠금을 얻을 수 있다. 또한 업데이트를 위해 파일을 여는 경우 첫 번째 클라이언트가 파일을 "읽기" 위해 하위 스트림에서 파일을 가져와서 클라이언트가 "업데이트"할 때 릴리스한다. 다른 모든 고객들은 자물쇠가 풀릴 때까지 기다려야 한다.

계층 디렉토리

계층 디렉토리는 각 레코드가 이름과 위치를 연결하는 파일이다. 계층은 디렉토리 레코드가 다른 디렉토리의 이름과 위치를 식별할 때 발생한다. DDM 클라이언트와 서버 제품을 사용하여 프로그램은 원격 컴퓨터에서 디렉터리를 만들고 삭제하고 이름을 바꿀 수 있다. 또한 원격 디렉토리의 파일 특성을 나열하고 변경할 수 있다. 디렉토리의 레코드는 DDM 디렉토리 접근 방법을 사용하여 순차적으로 읽을 수 있다. 디렉토리 레코드로 식별된 파일의 이름을 변경, 복사, 다른 디렉토리로 이동시킬 수 있다.

DDM 대기열

큐는 일반적으로 기록을 통해 프로그램 간의 단기 통신을 가능하게 하는 통신 메커니즘이다. DDM 대기열은 단일 시스템에 존재하지만 여러 시스템의 프로그램에서 액세스할 수 있다. DDM 대기열의 하위 클래스는 구분 생성 명령을 통해 대상 시스템에 생성할 수 있는 세 가지 클래스가 있다.

  • 선입선 대기열, 대기열 차단 프로그램과 대기열 사이의 비동기식 파이프.
  • 마지막 인퍼스트 아웃 대기열, 푸시다운 스택.
  • 선택한 항목을 키 값으로 디큐레이션할 수 있는 팬 아웃 메커니즘인 키 대기열.

DDM 대기열 모델은 작성 날짜, 대기열이 포함할 수 있는 레코드 수, 레코드 길이 등의 대기열 속성으로 구성된다. 대기열의 레코드는 고정되거나 길이가 다를 수 있다.

DDM 파일 모델과 달리 큐에서 액세스 방법을 열 필요가 없다. 프로그램은 큐에 레코드를 추가하고 큐의 클래스에 따라 큐에서 레코드를 수신할 수 있다. 또한 프로그램은 대기열에서 레코드를 지우고, 대기열에서 작업을 중지하며, 대기열의 속성을 나열하고, 대기열의 속성을 변경할 수 있다. 또한 프로그램은 다른 프로그램의 경합을 억제하기 위해 대기열 또는 개별 레코드를 대기열에 잠글 수 있다. 다른 모든 고객들은 자물쇠가 풀릴 때까지 기다려야 한다.

관계형 데이터베이스

관계형 데이터베이스(RDB)는 데이터 테이블의 생성, 관리, 쿼리, 업데이트, 색인화 및 상호관계를 지원하는 구조화된 질의 언어(SQL)의 구현이다. 대화형 사용자나 프로그램은 SQL 문을 RDB에 발급하고 응답으로 데이터 및 상태 표시기 표를 수신할 수 있다. 그러나 SQL 문을 컴파일하여 RDB에 패키지로 저장한 다음 패키지 이름으로 호출할 수도 있다. 이것은 복잡한 고주파 쿼리를 발행하는 응용 프로그램의 효율적인 운영을 위해 중요하다. 접근할 테이블이 원격 시스템에 위치할 경우 특히 중요하다.

객체 지향에서 설명한 바와 같이, DRDA(Distributed Relational Database Architecture)는 전체 DDM 프레임워크에 잘 적합하다. (단, DDM은 다른 사양도 요구되기 때문에 DDA의 구성요소 아키텍처로도 볼 수 있다.) DRDA를 지원하는 DDM 관리자 수준 객체의 이름은 RDB(관계형 데이터베이스)와 SQL Application Manager(SQL Application Manager)의 이름이다.

데이터 설명 및 변환

투명성은 DDM 아키텍처의 핵심 목표다. 재컴파일 없이 기존 애플리케이션 프로그램을 원격 컴퓨터의 데이터 관리 서비스로 리디렉션할 수 있어야 한다. 파일의 경우, 이는 주로 인터페이스/기능 수준에서 DDM 클라이언트에 의해 수행되었지만, 레코드의 데이터 필드는 어떠한가? 완전한 투명성을 위해서는 클라이언트 응용 프로그램 프로그램이 원격 서버가 필드를 인코딩하는 방법에 관계없이 로컬 데이터 관리 시스템에 의해 인코딩된 필드를 쓰고 읽을 수 있어야 하며, 이는 자동 데이터 변환을 의미한다.

예를 들어 IBM 메인프레임 시스템은 부동소수점 번호를 16진수 형식으로, 문자 데이터는 EBCDIC로 인코딩하고, IBM Personal 시스템은 IEEE 형식과 ASCII 형식으로 인코딩한다. 다양한 프로그래밍 언어 컴파일러들이 레코드 필드를 비트, 바이트, 그리고 메모리의 단어의 문자열로 매핑하는 방법 때문에 더욱 복잡해졌다. 레코드를 투명하게 변환하려면 레코드의 클라이언트 보기와 서버 보기 모두에 대한 자세한 설명이 필요하다. 이러한 설명에 따라, 클라이언트와 서버 보기의 필드를 필드 이름별로 일치시킬 수 있으며, 적절한 변환을 수행할 수 있다.

핵심 쟁점은 충분한 상세 기록 설명을 얻는 것이지만, 일반적으로 프로그램 프로그램에서는 언어 컴파일러가 인코딩을 처리하고 매핑 세부사항을 다루는 것과 함께 프로그래밍 언어로 정의된 선언문에 의해 기록 설명이 추상적으로 지정된다. 분산 처리 환경에서 필요한 것은 모든 프로그래밍 언어와 독립된 레코드를 표준화된 단일 방식이며, 기존 파일에서 발견되는 다양한 고정 및 다양한 길이 레코드 형식을 설명할 수 있다.

그 결과 데이터 레코드의 클라이언트 및 서버 뷰를 기술하고 변환을 지정하기 위한 새로운 특수 프로그래밍 언어인 A 데이터 언어(ADL)[15]에 기반한 포괄적인 데이터 설명 변환 아키텍처(DD&C)의 정의가 이루어졌다.[14] 컴파일된 ADL 프로그램은 레코드가 서버로 전달되거나 서버에서 전송될 때 필요한 변환을 수행하기 위해 서버에 의해 호출될 수 있다.

DD&C 아키텍처는 더 나아가 프로그래밍 언어 선언문을 ADL로 자동 변환할 수 있는 수단을 정의했고, 따라서 한 프로그래밍 언어에서 다른 프로그래밍 언어로 변환할 수 있다. 이 기능은 복잡성과 비용 때문에 구현된 적이 없다. 그러나, ADL 컴파일러가 만들어졌고, 가능한 경우, DFM과 IBM 4680 Store System에 의해 변환을 수행하기 위해 ADL 프로그램을 호출한다.[16] 그러나 응용 프로그램 프로그래머는 ADL 프로그램을 수동으로 작성할 필요가 있다.

제품 구현

IBM의 DDM 제품

다음 IBM 제품은 DDM 아키텍처의 다양한 하위 세트를 구현했다.

  • IBM 시스템/370
    • MVS(MVS/SP, MVS/ESA)
      • 데이터베이스 2 - DRDA 클라이언트 및 서버
      • CICS - CICS 트랜잭션 처리 환경 내에 파일 서버를 기록하십시오. z/[17]OS V5.2 이상용 CICS에서 중단됨
    • VM(운영 체제)(VM/SP, VM/ESA)
      • SQL/DS - DRDA 클라이언트 및 서버
    • DOS/VSE
      • CICS - CICS 트랜잭션 처리 환경 내에 파일 서버를 기록하십시오. z/[18][19]VSE V2.1 이상용 CICS에서 중단됨
    • z/OS
      • 분산 파일 관리 - 파일 서버 기록
      • 데이터베이스 2 - DRDA 클라이언트 및 서버
  • 시스템/36
  • 시스템/38 및 후속 제품: AS/400, iSeries 및 Power Series
    • 파일 클라이언트 및 서버 기록
    • 디렉터리 및 스트림 파일 클라이언트 및 서버
    • DRDA 클라이언트 및 서버
  • IBM 개인용 컴퓨터
    • PC DOS
      • Netview/PC - 파일 클라이언트 및 서버 디렉토리 및 스트림
      • DDM/PC - 파일 클라이언트 디렉터리 및 스트림
      • PC 지원/36 - 파일 클라이언트 디렉터리 및 스트림
      • PC 지원/400 - 파일 클라이언트 디렉터리 및 스트림
    • 개인 시스템/2 - OS/2
      • PC/Support/400 - 파일 및 디렉터리 클라이언트 및 서버 스트리밍
      • DRDA 클라이언트 및 서버
  • IBM 4680IBM 4690 스토어 시스템
    • 파일 클라이언트 및 서버 기록
    • 디렉터리 및 스트림 파일 클라이언트 및 서버
  • RS/6000 AIX
    • DRDA 클라이언트 및 서버

다른 공급업체의 DDM 제품

DRDA를 구현한 제품의 전체 목록은 오픈 소스 DRDA 제품 식별자 표를 참조하십시오.

참고 항목

참조

  1. ^ a b Distributed Data Management Architecture Level 3: General Information. IBM Corp. GC21-9527-02. July 1990.
  2. ^ a b c Demers, R. A., J. D. Fisher, S. S. Gaitonde, and R. R. Sanders (1992). "Inside IBM's Distributed Data Management architecture". IBM Systems Journal. 31 (3): 459–487. doi:10.1147/sj.313.0459.CS1 maint: 여러 이름: 작성자 목록(링크)
  3. ^ Demers, R. A. (1988). "Distributed files for SAA". IBM Systems Journal. 27 (3): 348–361. doi:10.1147/sj.273.0348.
  4. ^ Deinhart, K. (1992). "SAA distributed file access to the CICS environment". IBM Systems Journal. 31 (3): 516–534. doi:10.1147/sj.313.0516.
  5. ^ iSeries Distributed Data Management (PDF). IBM Corp. 2001.
  6. ^ Reinsch, R. (1988). "Distributed database for SAA". IBM Systems Journal. 27 (3): 362–389. doi:10.1147/sj.273.0362.
  7. ^ Distributed Relational Database Architecture Reference. IBM Corp. SC26-4651-0. 1990.
  8. ^ "z/OS DFSMS DFM Guide and Reference" (PDF).
  9. ^ Goldberg, A.; Robson, D (1983). Smalltalk-80, The language and its implementation. Addison-Wesley. ISBN 0-201-11371-6.
  10. ^ "OS/400 Objects".
  11. ^ a b Distributed Data Management Architecture Level 3: Programmer's Guide. IBM Corp. SC21-9529. 1990.
  12. ^ Distributed Data Management Architecture Level 3: Reference. IBM Corp. SC21-9526-03. 1990.
  13. ^ Distributed Data Management Architecture Level 4: Reference. IBM Corp. SC21-9526-05. 1990.
  14. ^ Demers, R. A.; Yamaguchi, K. (1992). "Data Description and Conversion Architecture". IBM Systems Journal. 31 (3): 488–515. doi:10.1147/sj.313.0488.
  15. ^ Distributed Data Management Architecture: Specifications for A Data Language. IBM Corp. SC21-8286. 1992.
  16. ^ "4680 DDM User's Guide" (PDF). IBM Corp. 1991.
  17. ^ "IBM CICS Transaction Server for z/OS, V5.2 takes service agility, operational efficiency, and cloud enablement to a new level". IBM. 2014-04-07. Retrieved 2016-04-14. CICS DDM is no longer available from IBM and support was discontinued, as of December 31, 2003. CICS DDM is no longer available in CICS TS from Version 5.2 onwards.
  18. ^ "IBM z/VSE Central Functions Version 9.2 - z/VSE Version 5.2". IBM. April 7, 2014. Retrieved 2016-04-14. Support for CICS Distributed Data Management (DDM) is stabilized in CICS TS for VSE/ESA V1.1.1. In a future release of CICS TS for z/VSE, IBM intends to discontinue support for CICS DDM.
  19. ^ "IBM CICS Transaction Server for z/VSE V2.1 delivers enhancements for future workloads". IBM. October 5, 2015. Retrieved 2016-04-14. CICS Distributed Data Management (CICS/DDM) is not supported with CICS TS for z/VSE V2.1.