다음을 통해 공유


서비스 지향 솔루션 이해

서비스 지향 솔루션은 서비스로 디자인된 신용 잔액 보고 응용 프로그램을 제공합니다. 이 응용 프로그램은 다시 서비스로 노출되는 세 개의 백 엔드 응용 프로그램을 사용하여 신용 잔액에 필요한 정보를 가져옵니다.

SOA(서비스 지향 아키텍처)는 분산 시스템 빌드와 부분적으로 겹치는 방법입니다. 서비스 지향 방법의 특징은 다음과 같습니다.

  • 느슨하게 연결됩니다. 응용 프로그램의 비즈니스 논리가 서비스 처리 논리와 구분됩니다.

  • 검색 가능합니다. 응용 프로그램에서 서비스를 찾는 메커니즘이 있어야 합니다.

  • 계약적입니다. 서비스에 대한 인터페이스가 사용자와 서비스 간의 계약을 구현합니다.

    홍보 자료에서 서비스 지향 방법을 웹 서비스와 동의어로 처리하는 경우도 많지만 반드시 동의어인 것은 아닙니다. 웹 서비스는 서비스 지향 솔루션을 구현하는 효율적인 방법을 제공하지만 .NET 원격 등의 다른 기술을 사용하여 서비스를 만들 수 있습니다.

독자 지침

이 솔루션에 대한 설명서에서는 BizTalk Server 및 Microsoft Visual Studio에 익숙하다고 가정합니다. 또한 엔터프라이즈 응용 프로그램 통합 및 웹 서비스에 대한 기본 개념을 이해하고 있다고 가정합니다.

또한 개발자 설명서를 읽고 따르려면 Visual Studio를 사용하여 애플리케이션을 빌드하는 방법과 프로젝트 만들기, 참조 설정, BizTalk 솔루션 디버깅 및 테스트 등의 작업을 수행하는 방법을 잘 알고 있어야 합니다.

Woodgrove Bank의 신용 카드 보고

서비스 지향 아키텍처 솔루션은 Woodgrove Bank의 신용 카드 잔액 보고 서비스입니다. 은행은 가상이지만 시나리오는 가상이 아니라 실제 배포된 고객 응용 프로그램을 기반으로 합니다.

시나리오에서 신용 카드 잔액 요청은 다음 두 소스에서 들어옵니다.

  • IVR(Interactive Voice Response) 응용 프로그램

  • 웹 페이지 또는 사용자 지정 클라이언트 응용 프로그램과 같은 대화형 클라이언트

    솔루션은 MQSeries를 통해 IVR 응용 프로그램으로부터 요청을 받습니다. 또한 HTTP 및 SOAP를 사용하여 웹 서비스를 통해 대화형 클라이언트의 요청을 처리합니다.

    새 서비스 지향 아키텍처 응용 프로그램은 대체로 이전 기술을 사용하는 레거시 응용 프로그램뿐 아니라 웹 서비스를 사용하는 웹 사이트 등의 현대적 응용 프로그램에서도 작동해야 합니다. 이 시나리오는 이러한 실제 요구 사항을 모델링합니다. IVR 응용 프로그램은 레거시 응용 프로그램을 나타내고 고객 서비스 클라이언트 응용 프로그램은 현대적 응용 프로그램입니다.

    Woodgrove Bank 응용 프로그램은 다음 세 가지 백 엔드 레거시 시스템의 데이터를 사용하여 요청에 응답합니다.

  • 전체 신용 제한을 제공하는 응용 프로그램. 메인프레임 컴퓨터의 SAP 시스템입니다.

  • 계정에 대해 보류 중인 트랜잭션의 총 금액을 보고하는 보류 중인 트랜잭션 시스템. 이 시스템은 메인프레임 또는 AS/400 시스템입니다. 솔루션은 웹 서비스와 Microsoft HIS(Host Integration Server)를 사용하여 메인프레임 또는 AS/400 시스템과 통신합니다.

  • 시스템에 대한 최종 지불을 제공하는 지불 추적 시스템. MQSeries를 사용하여 지불 추적 시스템에 연결할 수 있습니다.

    솔루션은 레거시 시스템에서 정보를 수집 및 컴파일한 후 원본 응용 프로그램에 다시 응답을 보내 고객에게 응답합니다.

비즈니스 요구 사항

신용 보고 응용 프로그램은 실시간으로 고객 요청에 응답하기 때문에 요청을 신속하게 처리하려면 대기 시간이 낮아야 합니다. 또한 많은 동시 요청 수를 처리할 수 있어야 합니다. 솔루션은 중요한 정보 및 공용 인터페이스를 사용하므로 보안이 중요한 문제입니다. 마지막으로, 서비스가 안정적이어야 합니다.

솔루션이 이러한 요구 사항을 충족하는 방법에 대한 자세한 내용은 서비스 지향 솔루션 개발을 참조하세요.

성능 특징

비즈니스 요구 사항을 충족하기 위해 이 시나리오에는 다음과 같은 성능 특징이 있습니다.

  • 초당 40개의 들어오는 요청을 처리하는 지속 처리량

  • 초당 100개의 들어오는 요청을 처리하는 최대 처리량

  • 1000밀리초 미만에 요청의 90% 처리(BizTalk Server 내부 및 외부)

  • 2000밀리초 미만에 요청의 95% 처리(BizTalk Server 내부 및 외부)

  • 5000밀리초 미만에 요청의 100% 처리(BizTalk Server 내부 및 외부)

참고

이러한 시간에는 백 엔드 시스템의 대기 시간이 포함되지 않습니다.

세 가지 버전의 솔루션

다음 세 가지 버전의 솔루션이 있습니다.

  • 스텁 버전은 모든 백 엔드 시스템을 소프트웨어 스텁으로 대체합니다. 스텁은 백 엔드 시스템을 시뮬레이트합니다. 이 버전은 단일 컴퓨터에서 솔루션을 빠르게 배포 및 실행하는 방법을 제공합니다.

  • 어댑터 버전은 BizTalk 어댑터를 사용하여 백 엔드 시스템에 연결합니다. 이 버전은 솔루션 구현 시 제일 먼저 고려하는 방식입니다. 그러나 어댑터를 사용하여 백 엔드 시스템에 메시지를 보내면 응답을 받을 때 대기 시간이 오래 걸립니다. 어댑터 자체는 낮은 대기 시간을 제공할 수도 있지만 BizTalk Server의 분산 아키텍처에서는 어댑터가 메시지 상자를 사용하여 오케스트레이션 호스트 인스턴스와 통신해야 하므로 데이터베이스에 대한 왕복이 필요하고 대기 시간에 영향을 줍니다.

  • 인라인 버전은 백 엔드 시스템과 직접 통신하는 인라인 코드로 어댑터를 대체합니다. 인라인 버전의 솔루션은 대기 시간이 가장 낮고 처리량이 가장 큽니다.

    배포 가이드는 세 가지 버전의 솔루션을 모두 빌드 및 배포하는 방법에 대한 지침을 제공할 뿐 아니라 각 버전에서 HIS를 통해 보류 중인 트랜잭션 시스템에 연결하는 작업을 시뮬레이트하는 방법을 제공합니다. 솔루션을 빌드하고 배포하는 방법에 대한 자세한 내용은 서비스 지향 솔루션 배포를 참조하세요.

참고 항목

서비스 지향 솔루션