타스크: 아키텍처 개념 검증 구성(SOA)
이 타스크에서는 기존의 아키텍처 요구사항과 위험성 프로파일을 기반으로 SOA 솔루션에 필요한 아키텍처 개념 검증 개발 방법을 정의합니다.
목적

중요한 아키텍처 요구사항을 충족하는 표본 솔루션을 동기화하려면 이 표본을 다음과 같이 제한해야 합니다.

  • 결과 솔루션이 개념적일 수 있습니다.
  • 경과 솔루션에서 요구사항 전체의 중요한 형태를 설명할 수 있습니다.
관계
역할기본: 추가: 지원:
입력필수: 선택사항:
  • 없음
외부:
  • 없음
출력
기본 설명

아키텍처 개념 검증 타스크는 타스크: 기존 자산 분석에서 주로 정보를 가져오며 활동: 서비스 스펙 수행에서 정의된 개념: 서비스 포트폴리오를 고려합니다.

또한 기존 응용프로그램 처리 시, 다음 항목을 점검하고 고려해야 합니다.

  • 예외 처리: 현재 예외 처리 방법을 이해해야 합니다. 일괄처리에서 예외가 발생하면 프로그램에서는 이상 종료되고(비정상적 종료) 코어 덤프를 생성합니다. 프로그래머는 코어 덤프를 찾아 처리해야 할 일을 판단해야 합니다. 이는 허용되지 않을 수도 있습니다. 누구든 처리해야 할 일(예: 예외 처리 프레임워크와 통합하는 방법)을 판단해야 합니다.
  • 프로세스 및 데이터 분배: 데이터 및 프로세스가 실행되는 위치를 점검해야 합니다. 하나의 시스템에서 CICS 응용프로그램을 실행하면 다른 시스템에 대한 요청(CICS의 기능 이동으로 알려짐) 또는 다른 시스템의 데이터 원격 호출을 송신할 수 있습니다. JDBC를 통해 DB로 연결되는 커넥터를 사용하는 대신, 프로세스 또는 데이터가 실행 중인 원격 시스템으로 직접 이동하는 것을 고려할 수 있습니다.
  • 데이터 가용성: 예를 들어, 4시간 유지보수 창이 필요한 VSAM에 고객 파일이 있는 경우, 24/7 고객 서비스를 지원할 수 없습니다. 새로운 저장영역 솔루션을 고려해야 합니다.
  • 권한 부여/인증: 많은 레거시 응용프로그램에는 응용프로그램 코드의 권한 부여 및 인증 메커니즘이 있습니다. 이것으로 사용자 액세스 관리를 우수 사례에서 지원되는 연합 관리 환경으로 옮길 수 있습니다.
  • 스테이징 지연: 일반적으로 일괄처리 프로그램은 하루에 한 번, 야간에 실행됩니다. 요구사항이 좀 더 자주 프로그램을 실행한다면, 스케줄 프로그램을 수정하여 빈도를 변경합니다.

위의 목록이 세부적이지는 않으며 여기에서는 안내하기 위해 제공되는 것입니다.

예제

렌트카 예제에서 서비스 실현(realization)은 다음 요구사항을 고려해야 합니다.

  • 원격 클라이언트/서버 간 ,워크스테이션 응용프로그램 및 메인프레임 IMS 응용프로그램 간 완벽한 인터페이스
  • 원격 응용프로그램 보기 지점에서 "화면 스크래핑"을 제거해야 합니다. 이렇게 하면 메시지가 화면 또는 화면의 필드 변경 위치에 추가되기 때문에 원격 응용프로그램 처리를 변경해야 할 필요가 없습니다.
  • 사전 정의되고 수정된 형식인 IMS 응용프로그램의 입출력 메시지를 지원합니다.
  • 메시지 형식화 관련 처리가 IMS 응용프로그램에 대해 투명하게 이루어지므로, 새 원격 응용프로그램을 개발하고 테스트하는 데 필요한 시간이 크게 줄어듭니다.
  • 시간 관련 방법으로(기존 시스템을 향상시키는 데 걸리는 시간을 줄임) 원격 시스템에 대한 새 IMS 응용프로그램 기능 및 새 데이터 필드를 지원합니다.

이러한 기술적 실현 가능성 결정 및 고려사항의 요소는 아키텍처의 기능 및 오퍼레이션 형태 모두와 관련됩니다. 위의 요구사항을 설명하려면 다음 접근 방식을 사용합니다.

  • 메시지 브로커/통합 브로커는 IMS 응용프로그램으로(에서) 메시지 형식화를 처리합니다. 메시지 브로커는 다음 기능을 수행합니다.
    • 인바운드 메시지를 메인프레임 IMS 응용프로그램에서 채택 가능한 사전 정의 형식으로 다시 형식화합니다(XML에서 수정된 길이의 형식까지).
    • IMF 키워드 형식에 대한 메인프레임 IMS 출력 응답을 다시 형식화하여(수정된 길이의 형식에서 XML까지) 원래 송신 중인 응용프로그램에서 처리합니다.
    • 인바운드 메시지에 신호를 보내어 데이터 페이로드보다 우선하는 메시지 헤더를 확인함으로써 이 메시지가 IMF 형식인지의 여부를 판별합니다. 헤더는 위치 형식이며 IMF가 올바르게 처리되는 데 필요한 핵심 정보를 포함합니다.
    • 메시지 헤더 및 IMS 트랜잭션 코드의 컨텐츠를 기반으로 한 라우팅과 변환을 수행합니다. 이 IMS 트랜잭션 코드는 IMS 메인프레임 시스템에 있는 해당 트랜잭션을 실행하는 데 필요합니다.
  • IMS-MQ 브릿지는 메시지 브로커와 IMS 시스템 간의 콘딧 역할을 합니다.

메시지/통합 브로커의 사용으로 각 IMS 응용프로그램을 사용자 정의하여 여러 원격 시스템의 트랜잭션 요청을 처리할 필요가 줄어들거나 없어집니다. 메시지 형식화 관련 처리의 대부분은 IMS 응용프로그램에 대해 투명하게 이루어지기 때문에 새 원격 응용프로그램을 개발하고 테스트하는 데 필요한 시간이 크게 줄어듭니다. 또한, 새 IMS 응용프로그램 기능 및 새 데이터 필드가 원격 시스템에서 시간 관련 방법으로 사용 가능하므로 기존 시스템을 향상시키는 데 걸린 시간을 줄이게 됩니다. 이렇게 하면 응용프로그램의 결합이 느슨해지며 이는 SOA의 코어 원칙 중 하나입니다.

단계
구현/구축(Construction) 접근 방식 결정

아키텍처 개념 검증 구현/구축에 사용할 기법을 선택하십시오. 예를 들어 다음과 같습니다.

  • 개념적 모델링
  • '신속한' 프로토타입 생성
  • 시뮬레이션
  • 코딩할 스펙 자동 변환
  • '실행 파일' 스펙
  • '스파이크'를 프로토타입으로 구현/구축 - 계층을 통과하는 세로 조각

소프트웨어 설계자는 문제점과 솔루션 공간에 대한 무언가를 발견하는 과정에서 이런 모델에 대한 추론이 가능해야 합니다.

아키텍처 개념 검증을 위한 자산과 기술 선택

소프트웨어 설계자는 타스크: 아키텍처 분석에서 식별된 자산과 기술 중에서 아키텍처 개념 검증 구현/구축(Construction) 시 사용할 자산과 기술을 선택해야 합니다.

아키텍처 개념 검증 구성

구현/구축을 위해 선택한 기법을 사용하여 소프트웨어 설계자는 아키텍처 개념 검증을 빌드하는데, 선택한 자산과 기술을 사용하여 표준 유스 케이스 실현, 개요 디자인과 배치 모델, 소프트웨어 설계자 문서에 캡처된 구조적으로 중요한 요구사항을 충족(프로젝트의 위험성 프로파일에 필요한 정도로)시킬 수 있도록 합니다.



특성
선행
다중 발생
이벤트로 구동됨
진행 중임
선택사항
계획됨
반복 가능함
자세한 정보