소개
여러 대기업의 업무에 중요한 시스템(일반적으로 "레거시 시스템"이라고 함)은 대부분 산업 표준 인터페이스를 사용하지 않고 COBOL과 같이 오래된 컴퓨터 언어로 개발된 대규모 단일 응용프로그램에 설치됩니다. 이러한
회사는 대부분 경쟁력을 유지하기 위해 인터넷, 인트라넷, 전자상거래 및 기타 신기술을 이용하려고 합니다. 그러나 이러한 주요 "레거시 시스템"을 재작성하는 것은 재무적 관점(너무 비쌈), 기술적 관점(초기
프로그래머가 더 이상 회사에 근무하지 않음) 또는 시간적 관점(기다릴 여유가 없음)에서 바람직한 옵션이 아닙니다. 많은 회사에서 선택하는 대안은 "레거시 시스템"을 새 응용프로그램과 통합하여 최신화하는 것입니다.
이를 위한 가장 일반적인 통합 방법을 EAI(Enterprise Application Integration)라고 합니다. EAI는 다양한 엔터프라이즈 응용프로그램(레거시 및 새 응용프로그램
모두 포함) 간에 통신 하부 구조를 구현합니다.
레거시 통합 전략
레거시 통합은 다음과 같은 두 가지 기본 카테고리로 분류할 수 있습니다.
비침해 전략은 레거시 응용프로그램을 수정하지 않거나 약간만 수정하는 전략입니다. 이 전략은 비용면에서 보다 저렴하지만 유연성이 떨어지는 단점이 있습니다. 이 접근 방식은 일반적으로 EAI 통합을 사용자 인터페이스 레벨, 데이터 레벨 또는 경우에 따라 응용프로그램 인터페이스 레벨에서 수행할 때 사용됩니다.
사용자 인터페이스 레벨에서 통합을 수행하는 경우, 기존 텍스트 기반 화면은 엔터프라이즈 비즈니스 포털에서 통합된 브라우저 기반 화면으로 바뀝니다. 이러한 유형의 통합은 일반적으로 다소 불안정하고 구태의연한 방법으로
간주되지만, 경우에 따라서는 데이터베이스 또는 비즈니스 프로세스 레벨 액세스를 제공하지 않는 레거시 시스템을 통합할 수 있는 가장 실용적인 방법입니다.
데이터 레벨 통합은 기존 레거시 데이터베이스를 재사용하거나, 기존 데이터베이스에서 데이터를 추출하고 ETL(Extract, Transform, Load) 솔루션을 사용하여 새 데이터베이스를 갱신하여 수행할 수
있습니다. 이 접근 방식은 매력적인 방식으로 보이지만, 데이터 변환, 제한조건 및 제어가 일반적으로 레거시 응용프로그램의 비즈니스 로직에서 구현되므로 경우에 따라 구현하기가 어려운 방식입니다.
비침해 응용프로그램 인터페이스 레벨 통합("레거시 랩핑"이라고도 함)은 유연성면에서 약간 더 우수합니다. 이 접근 방식에서는 레거시 트랜잭션에 대해 호출 가능한 응용프로그램 인터페이스(API)를 빌드합니다. 이
접근 방식은 기존 레거시 트랜잭션을 이용하므로 비용면에서 저렴하며 데이터 레벨 통합에 따른 불편함이 없습니다. 트랜잭션을 API에서 변환함으로써 사용자 레벨 통합보다 유연성면에서 우수합니다. 그러나 비침해 상태를
유지하려면 비즈니스 기능을 수정하고 강화하기 위해 이 접근 방식을 사용해서는 안됩니다. 이러한 경우 침해 접근 방식을 사용해야 합니다.
침해 전략에서는 기능 레거시 코드를 수정해야 하는 것으로 가정합니다. 실제로, 이러한 접근 방식의 경우 일반적으로 레거시 코드가 오래되고 올바르게 문서화되지 않았으며 최초 작성한 프로그래머가 계속 근무하는 경우가
거의 없어 위험성이 더 크고 비용도 많이 소요됩니다. 그러나 이러한 유형의 접근 방식은 또한 유연성면에서 우수하여 기존 비즈니스 프로세스 및 기능을 수정하고 강화할 수 있습니다. 이 접근 방식은 일반적으로 기존
레거시 트랜잭션과 일치하지 않는 API가 필요한 경우 EAI 응용프로그램 인터페이스 레벨 통합에서 사용됩니다. 이 접근 방식은 또한 EAI 메소드 레벨 통합에서도 사용할 수 있지만 공유 가능한 메소드를 제공하도록 기존 코드를 리팩토링하는 경우 일반적으로 많은 비용이 소요됩니다.
침해 응용프로그램 인터페이스 레벨 통합 접근 방식 중 "레거시 e-Components"가 있습니다. 이 접근 방식은 레거시 응용프로그램을 자체 비즈니스 컴포넌트 콜렉션으로 분할합니다. 각 컴포넌트는 견고한 프로그램
대 프로그램 연결성에서 덜 견고하게 연결된 메시지 기반 접근 방식으로의 이동을 용이하게 하는 명확하게 정의된 API 세트를 공개합니다. 이러한 API는 여러 플랫폼에 배치할 수 있으며 해당 컴포넌트 모델을 사용하여
전체 아키텍처에 통합할 수 있습니다. 이 접근 방식은 XML 웹 서비스를 사용하여, 각 "레거시 e-Component"를 서비스 지향 아키텍처(SOA)에서 하나 이상의 서비스로 정의하도록 정제할 수 있습니다. 개념: 서비스 지향 아키텍처(SOA) 소개를 참조하십시오.
침해 접근 방식은 일반적으로 비침해 접근 방식보다 많은 비용이 소요되고 구조적인 위험성도 크므로 위험성을 줄이고 초기 반복 시 아키텍처 실현 가능성을 증명하는 반복 접근 방식 채택을 고려해야 합니다.
|