인디고 소개: 초기 모습

 

데이비드 샤펠
샤펠 & 어소시에이츠

2005년 2월

요약: 서비스 지향 애플리케이션을 빌드하기 위한 Microsoft의 통합 프로그래밍 모델인 "Indigo"에 대한 아키텍처 개요를 제공합니다. 이 문서에서는 .NET Framework 기존 분산 애플리케이션 기술과 Indigo의 관계, Indigo 서비스 생성 및 사용의 기본 사항, 보안, 신뢰할 수 있는 메시징 및 트랜잭션 지원을 포함한 Indigo의 기능에 대한 개요를 다룹니다. (24페이지 인쇄)

참고 이 문서는 Indigo의 첫 번째 CTP(Community Technology Preview)의 시험판 버전을 기반으로 합니다. Indigo가 제품 주기를 진행함에 따라 기능 및 구현 세부 정보가 변경될 수 있습니다.

콘텐츠

인디고란?
Indigo에서 제공하는 내용
Indigo 서비스 만들기
Indigo 클라이언트 만들기
인디고의 다른 측면
공존 및 마이그레이션
결론
저자 정보

인디고란?

소프트웨어를 빌드하는 데 가장 적합한 추상화는 진행 중인 프로세스입니다. 개체는 현재 애플리케이션의 비즈니스 논리를 빌드하기 위한 주요 접근 방식이지만 개체를 사용하여 애플리케이션 간 통신을 모델링하는 것은 성공하지 못했습니다. 더 나은 방법은 개별 소프트웨어 청크 간의 상호 작용을 서비스로 명시적으로 모델링 하는 것입니다. 개체 지향 애플리케이션을 빌드하기 위한 많은 지원이 이미 있지만 서비스를 기본 소프트웨어 구성 요소로 생각하는 것이 더 최근의 아이디어입니다. 이 때문에 서비스 지향 애플리케이션을 만들도록 명시적으로 설계된 기술은 널리 제공되지 않았습니다.

서비스 지향 애플리케이션을 빌드하기 위한 Microsoft의 프레임워크인 코드 이름 Indigo는 이를 변경합니다. Indigo를 사용하면 현재 .NET Framework 사용하여 개체 지향 애플리케이션을 만드는 개발자가 익숙한 방식으로 서비스 지향 애플리케이션을 빌드할 수 있습니다. 또한 이러한 애플리케이션이 Windows 및 다른 플랫폼에서 실행되는 소프트웨어와 효과적으로 상호 작용할 수 있도록 Indigo는 SOAP 및 기타 웹 서비스 기술을 구현하여 개발자가 모든 시스템에서 실행되는 소프트웨어와 상호 운용할 수 있는 안정적이고 안전한 트랜잭션 서비스를 만들 수 있도록 합니다.

위의 그림은 Indigo 클라이언트 및 서비스의 간단한 보기를 보여줍니다. Indigo는 클라이언트에서 액세스하는 서비스를 만들기 위해 CLR(공용 언어 런타임)에서 실행되는 클래스 집합으로 주로 구현되는 기초를 제공합니다. 클라이언트와 서비스는 INdigo의 네이티브 프로토콜인 SOAP를 통해 상호 작용하므로 그림에 Indigo를 기반으로 구축된 두 당사자가 모두 표시되어 있더라도 필수는 아닙니다.

인디고는 2005년에 출시될 예정인 .NET Framework 2.0을 기반으로 합니다. Indigo 자체는 2006년으로 예정된 Windows 릴리스 코드 이름 Longhorn의 일부로 제공되며 Windows XP 및 Windows Server 2003에서도 사용할 수 있습니다. 이 설명은 Indigo의 첫 번째 커뮤니티 기술 미리 보기의 시험판 버전을 기반으로 합니다. 최종 버전이 출시되기 전에 일부 변경 내용이 (사실상 거의 확실함) 가능성이 높다는 점에 유의하세요.

Indigo에서 제공하는 내용

Microsoft의 많은 사람들은 인디고를 만드는 데 수년간 헌신해 왔습니다. 해결된 문제가 간단하거나 솔루션이 명백한 경우 이러한 수준의 노력이 필요하지 않았을 것입니다. 따라서 인디고는 상당한 기술입니다. 그러나 Indigo의 가장 중요한 측면인 여러 기존 Microsoft 기술의 통합, 공급업체 간 상호 운용성에 대한 지원 및 명시적 서비스 지향이라는 세 가지가 두드러집니다. 이 섹션에서는 이러한 각 사항을 살펴봅합니다.

Microsoft의 분산 컴퓨팅 기술 통합

.NET Framework 초기 릴리스에는 분산 애플리케이션을 만들기 위한 여러 가지 기술이 포함되어 있습니다. 아래 그림은 개발자가 일반적으로 해당 기술을 사용하는 주된 이유와 함께 각각을 나열합니다. 예를 들어 상호 운용 가능한 기본 웹 서비스를 빌드하기 위해 가장 좋은 선택은 ASMX라고 하는 웹 서비스를 ASP.NET 것이었습니다. 두 .NET Framework 기반 애플리케이션을 연결하기 위해 .NET 원격은 경우에 따라 올바른 접근 방식이었습니다. 애플리케이션에 분산 트랜잭션 및 기타 고급 서비스가 필요한 경우 작성자는 .NET Framework COM+의 후속 기업인 Enterprise Services를 사용할 가능성이 높습니다. WS-Addressing 및 WS-Security와 같은 최신 웹 서비스 사양을 활용하기 위해 개발자는 이러한 새로운 사양의 Microsoft 초기 구현인 WSE(Web Services Enhancements)를 사용하는 애플리케이션을 빌드할 수 있습니다. 그리고 대기 중인 메시지 기반 애플리케이션을 만들기 위해 Windows 기반 개발자는 MSMQ(Microsoft Message Queuing)를 사용합니다.

	ASMX	.NET Remoting	엔터프라이즈 서비스	WSE	MSMQ	Indigo
상호 운용 가능한 웹 서비스	X					X
.NET – .NET 통신		X				X
분산 트랜잭션 등			X			X
WS-* 사양 지원				X		X
큐에 대기 중인 메시징					X	X

이러한 모든 옵션은 가치가 있었지만 다양성은 개발자에게 확실히 혼란스러웠습니다. 왜 그렇게 많은 선택이 있습니까? 더 나은 해결책은 이러한 모든 문제를 해결하는 하나의 기술을 갖는 것입니다. 인디고의 도착과 함께, 그 기술이 나타났다. 개발자가 여러 가지 가능성 중 하나를 선택하도록 강요하는 대신 Indigo를 사용하면 하위 기술로 해결된 모든 문제를 해결하는 분산 애플리케이션을 만들 수 있습니다. Microsoft는 이러한 이전 기술을 계속 지원하지만, 이전에 사용했던 대부분의 새로운 애플리케이션은 대신 Indigo에 빌드됩니다.

비 Microsoft 애플리케이션과의 상호 운용성

서로 다른 기술을 통합하여 Windows 개발자의 삶을 더 쉽게 만드는 것은 좋은 일입니다. 그러나 웹 서비스 공급업체 간의 범용 계약을 통해 애플리케이션 상호 운용성의 오랜 문제도 해결할 수 있습니다. Indigo의 기본 통신 메커니즘은 SOAP이므로 Indigo 애플리케이션은 다양한 컨텍스트에서 실행되는 다른 소프트웨어와 통신할 수 있습니다. 아래 그림과 같이 Indigo를 기반으로 하는 애플리케이션은 다음 모두와 상호 작용할 수 있습니다.

• 동일한 Windows 컴퓨터에서 다른 프로세스에서 실행되는 Indigo 애플리케이션입니다.
• 다른 Windows 컴퓨터에서 실행되는 Indigo 애플리케이션입니다.
• 표준 웹 서비스를 지원하는 Java 2, Enterprise Edition(J2EE)를 기반으로 하는 애플리케이션 서버와 같은 다른 기술을 기반으로 하는 애플리케이션. 이러한 애플리케이션은 Windows 컴퓨터 또는 Sun Solaris, IBM의 z/OS 또는 Linux와 같은 다른 운영 체제가 있는 컴퓨터에서 실행할 수 있습니다.

Indigo 애플리케이션은 나중에 설명한 대로 Indigo와 같은 indigo 이전의 .NET Framework 기술을 기반으로 구축된 애플리케이션과 상호 운용할 수도 있습니다.

Indigo는 기본적인 통신 이상의 것을 허용하기 위해 WS-* 사양이라고 하는 최신 웹 서비스 기술 그룹을 구현합니다. 이러한 문서는 SOAP 기반 웹 서비스에 신뢰할 수 있는 메시징, 보안, 트랜잭션 등을 추가하는 다중 공급업체 방법을 정의합니다. 이러한 모든 사양은 원래 Microsoft, IBM 및 함께 작동하는 다른 공급업체에 의해 정의되었습니다. 안정되면 OASIS(구조적 정보 표준 발전 조직)와 같은 표준 기관에 소유권이 전달되는 경우가 많습니다. Indigo의 첫 번째 릴리스에서 지원되는 웹 서비스 사양에는 WS-Addressing, WS-Policy, WS-MetadataExchange, WS-ReliableMessaging, WS-Security, WS-Trust, WS-SecureConversation, WS-Coordination, WS-AtomicTransaction 및 SOAP MTOM(메시지 전송 최적화 메커니즘)이 포함됩니다.

Indigo 애플리케이션이 비 Windows 시스템에서 실행되는 애플리케이션과 통신하는 경우 사용되는 프로토콜은 일반적인 텍스트 기반 XML 인코딩에서 와이어에 표시되는 표준 SOAP(아마도 일부 WS-* 확장)입니다. 그러나 한 Indigo 기반 애플리케이션이 다른 Indigo 기반 앱과 통신하는 경우 이 통신을 최적화하는 것이 좋습니다. 신뢰할 수 있는 메시징, 보안 및 트랜잭션을 포함하여 동일한 기능이 모두 제공되지만 사용되는 와이어 인코딩은 최적화된 이진 버전의 SOAP입니다. 메시지는 여전히 INFOset이라고 하는 SOAP 메시지의 데이터 구조를 따르지만, 인코딩은 XML의 표준 꺾쇠 괄호 및 텍스트 형식이 아닌 해당 Infoset의 이진 표현을 사용합니다.

Service-Oriented 개발에 대한 명시적 지원

애플리케이션을 서비스를 제공하고 소비하는 것으로 생각하는 것은 거의 새로운 아이디어가 아닙니다. 새로운 점은 개체와 구별되는 서비스에 대한 명확한 초점입니다. 이를 위해 Indigo의 제작자는 이 기술을 디자인하는 동안 다음과 같은 네 가지 신조를 염두에 두었습니다.

• 클래스가 아닌 스키마 공유: 이전 분산 개체 기술과 달리 서비스는 잘 정의된 XML 인터페이스를 통해서만 클라이언트와 상호 작용합니다. 서비스 경계를 넘어 전체 클래스, 메서드 및 모두를 전달하는 등의 동작은 허용되지 않습니다.
• 서비스는 자율적입니다. 서비스와 해당 클라이언트는 둘 사이의 인터페이스에 동의하지만 그렇지 않으면 독립적입니다. 다른 언어로 작성되고, CLR 및 Java Virtual Machine과 같은 다른 런타임 환경을 사용하고, 다른 운영 체제에서 실행하고, 다른 방법으로 다를 수 있습니다.
• 경계는 명시적입니다. DCOM(Distributed COM)과 같은 분산 개체 기술의 목표는 원격 개체를 로컬 개체처럼 최대한 보이게 하는 것이었습니다. 이 방법은 일반적인 프로그래밍 모델을 제공하여 몇 가지 방법으로 개발을 간소화하지만 로컬 개체와 원격 개체 간의 피할 수 없는 차이점도 숨겼습니다. 서비스는 서비스와 클라이언트 간의 상호 작용을 보다 명시적으로 만들어 이 문제를 방지합니다. 배포를 숨기는 것은 목표가 아닙니다.
• 정책 기반 호환성 사용: 가능하면 WS 정책 기반 메커니즘을 사용해야 하는 시스템 간에 사용할 옵션을 결정합니다.

서비스 지향은 서비스 지향 애플리케이션과 SOA(서비스 지향 아키텍처)의 보다 일반적인 개념을 포함하는 광범위한 영역입니다. Indigo는 Windows에서 빌드된 서비스 지향 애플리케이션의 기초가 되므로 많은 조직의 SOA 노력의 기본이 될 것입니다.

Indigo 서비스 만들기

아래 그림과 같이 모든 Indigo 서비스는 다음 세 가지로 구성됩니다.

• 하나 이상의 메서드를 구현하는 C# 또는 VB.NET 또는 다른 CLR 기반 언어로 구현되는 서비스 클래스입니다.
• 서비스가 실행되는 호스트 환경(애플리케이션 도메인 및 프로세스)
• 클라이언트가 서비스에 액세스할 수 있도록 하는 하나 이상의 엔드포인트 입니다.

Indigo 서비스와의 모든 통신은 서비스의 엔드포인트를 통해 수행됩니다. 각 엔드포인트는 이 엔드포인트를 통해 액세스할 수 있는 메서드를 식별하는 계약 , 클라이언트가 이 엔드포인트와 통신하는 방법을 결정하는 바인딩 및 이 엔드포인트를 찾을 수 있는 위치를 나타내는 주소를 지정합니다.

Indigo를 이해하려면 이러한 모든 개념을 파악해야 합니다. 이 섹션에서는 서비스 클래스부터 시작하여 각각에 대해 설명합니다.

서비스 클래스 만들기

Indigo 서비스 클래스는 다른 클래스와 마찬가지로 몇 가지 추가가 있습니다. 이러한 추가를 통해 클래스의 작성자는 이 클래스가 구현하는 하나 이상의 계약을 정의할 수 있습니다. 각 Indigo 서비스 클래스는 이 서비스가 노출하는 작업을 정의하는 하나 이상의 서비스 계약을 구현합니다. 또한 서비스 클래스는 해당 작업이 전달하는 데이터를 정의하는 데이터 계약을 명시적으로 구현할 수도 있습니다. 이 섹션에서는 서비스 계약부터 두 가지 모두를 살펴봅니다.

서비스 계약 정의

모든 Indigo 서비스 클래스는 클라이언트에서 사용할 메서드를 구현합니다. 서비스 클래스의 작성자는 서비스 계약에 포함시켜 클라이언트 호출 가능 작업으로 노출되는 메서드를 결정합니다. 서비스 계약을 정의하는 것은 실제로 일반적으로 서비스와 명시적으로 작업하는 것입니다. Indigo의 제작자는 CLR과 이를 기반으로 하는 프로그래밍 언어를 기반으로 이 아이디어를 접목할 방법을 찾아야 했습니다. 다행히 CLR의 작성자는 이와 같은 확장의 필요성을 예상했기 때문에 특성에 대한 지원을 제공했습니다. 개발자가 볼 수 있듯이 특성은 클래스 정의, 메서드 정의 및 다른 위치에 나타날 수 있는 연결된 속성과 같은 문자 문자열입니다. 특성이 표시되는 위치마다 연결된 항목의 동작에 대한 일부 측면이 변경됩니다.

.NET Framework 초기 릴리스 이후 다양한 항목에 대한 특성을 사용했습니다. 예를 들어 프레임워크의 ASMX 기술에서 메서드를 SOAP 호출 가능 웹 서비스로 표시하려면 해당 메서드 앞에 특성이 WebMethod 있습니다. 마찬가지로 Enterprise Services는 특성을 사용하여 Transaction 메서드에 트랜잭션이 필요함을 나타냅니다. Indigo는 서비스에 이 아이디어를 적용하여 서비스를 정의하고 제어하는 특성 범위를 정의합니다.

Indigo에서 가장 기본적인 특성은 입니다 ServiceContract. 실제로 Indigo 서비스 클래스는 특성으로 표시된 클래스이거나 이 특성으로 ServiceContract 표시된 인터페이스를 구현하는 클래스일 뿐입니다. 다음은 첫 번째 방법을 사용하는 간단한 C# 예제입니다.

using System.ServiceModel;

[ServiceContract]
class Calculator
{
 [OperationContract]
 private int Add(int a, int b)
 {
   return a + b; 
 }
   
 [OperationContract]
 public int Subtract(int a, int b)
 {
   return a - b;
 }
   
 public int Multiply(int a, int b)
 {
    return a * b;
 }
} 

ServiceContract Indigo에서 사용하는 특성 및 기타 모든 특성은 에 System정의되어 있습니다.ServiceModel 네임스페이스이므로 이 예제는 이 네임스페이스를 참조하는 문으로 using 시작합니다. 클라이언트에서 호출할 수 있는 서비스 클래스의 각 메서드는 라는 OperationContract다른 특성으로 표시되어야 합니다. 특성 앞에 OperationContract 오는 서비스 클래스의 모든 메서드는 Indigo에서 SOAP 호출 가능 작업으로 자동으로 노출됩니다. 이 예제 Add 에서 및 Subtract 는 모두 이 특성으로 표시되므로 둘 다 이 서비스의 클라이언트에 노출됩니다. 위의 예제와 OperationContract같이 Multiply 로 표시되지 않은 서비스 클래스의 메서드는 서비스 계약에 포함되지 않으므로 이 Indigo 서비스의 클라이언트에서 호출할 수 없습니다.

인디고에서는 두 가지 아주 별도의 추상화, 서비스 및 개체가 함께 제공됩니다. 둘 다 명시적으로 또는 암시적으로 계약에 의존하여 외부 세계에 노출되는 것을 정의하는 것을 이해하는 것이 중요합니다. 일부 클래스에서 지정한 개체는 동일한 애플리케이션의 다른 개체에서 호출할 수 있는 메서드를 결정하는 계약을 효과적으로 정의합니다. 이러한 메서드에 대한 액세스는 및 private와 같은 public 언어 키워드에 의해 제어됩니다. 예를 들어 위에 표시된 클래스 Calculator 에서 동일한 애플리케이션의 다른 개체는 및 를 호출 Subtract 할 Multiply수 있습니다. 이 클래스의 두 공용 메서드는 입니다. 이 클래스가 노출하는 개체 ** 계약에는 이러한 두 가지 메서드만 포함됩니다.

Indigo의 특성을 Calculator 사용하면 설명한 대로 서비스 계약도 정의됩니다. 이 계약에는 두 가지 메서드도 있지만 개체 계약의 메서드와 동일하지는 않습니다. 이 Indigo 서비스의 클라이언트에서 메서드를 호출할 수 있는지 여부는 및 private 키워드가 아닌 특성에 public 의해 OperationContract 제어됩니다. 이 특성은 및 Subtract에만 표시되므로 클라이언트에서 Add 이러한 두 메서드만 호출할 수 있습니다. 개체 계약 및 서비스 계약은 서로 완전히 구별되므로 와 같은 Add 메서드는 특성을 계속 전달하는 OperationContract 동안일 private 수 있습니다.

방금 보여 주는 예제에서는 Indigo 서비스 클래스를 만드는 가장 간단한 방법을 보여 줍니다. 클래스를 로 직접 ServiceContract표시합니다. 이 작업이 완료되면 클래스의 서비스 계약은 로 표시된 OperationContract해당 클래스의 모든 메서드로 구성되도록 암시적으로 정의됩니다. 언어 interface 유형을 사용하여 명시적으로 서비스 계약을 지정할 수도 있습니다(대부분의 경우 더 나은 경우). 이 방법을 사용하면 클래스가 Calculator 다음과 같이 표시될 수 있습니다.

using System.ServiceModel;

[ServiceContract]
interface ICalculator
{
 [OperationContract]
 int Add(int a, int b);

 [OperationContract]
 int Subtract(int a, int b);
}

class Calculator : ICalculator
{
 public int Add(int a, int b) // private methods aren't 
 {                            // allowed in interfaces
   return a + b; 
 }
      
 public int Subtract(int a, int b)
 {
   return a - b;
 }
      
 public int Multiply(int a, int b)
 {
   return a * b;
 }
}

이 예제 ServiceContract 에서 및 OperationContract 특성은 클래스 자체가 아닌 인터페이스 및 해당 인터페이스에 포함된 메서드에 Calculator 할당됩니다ICalculator. 그러나 결과는 동일하므로 이 버전의 서비스는 이전 버전과 동일한 서비스 계약을 노출합니다. 이와 같은 명시적 인터페이스를 사용하는 것은 약간 더 복잡하지만 더 많은 유연성을 허용합니다. 예를 들어 클래스는 둘 이상의 인터페이스를 구현할 수 있습니다. 즉, 둘 이상의 서비스 계약을 구현할 수도 있습니다. 서로 다른 서비스 계약을 가진 여러 엔드포인트를 노출하면 클래스가 서로 다른 클라이언트에 서로 다른 서비스 그룹을 표시할 수 있습니다.

마지막 점: 를 사용하여 서비스 클래스 ServiceContract 를 표시하고 OperationContract WSDL(Web Services Description Language)에서 서비스 계약 정의를 자동으로 생성할 수도 있습니다. 따라서 모든 Indigo 서비스 계약의 외부에 표시되는 정의는 해당 계약의 작업을 지정하는 표준 WSDL 문서로 액세스할 수 있습니다. 여기서는 설명하지 않지만 외부에 정의된 WSDL 인터페이스를 구현하는 데 특히 유용한 접근 방식인 WSDL 문서에서 직접 Indigo 서비스 클래스를 만들 수도 있습니다.

데이터 계약 정의

Indigo 서비스 클래스는 서비스 클라이언트에 노출되는 메서드를 정의하는 서비스 계약을 지정합니다. 이러한 각 작업은 일반적으로 일부 데이터를 전달합니다. 즉, 서비스 계약은 교환될 정보를 설명하는 일종의 데이터 계약도 의미합니다. 경우에 따라 이 데이터 계약은 서비스 계약의 일부로 암시적으로 정의됩니다. 예를 들어 위에 표시된 클래스에서 Calculator 각 메서드는 두 개의 입력 매개 변수(정수)를 모두 사용하고 단일 정수를 반환합니다. 이러한 매개 변수는 이 서비스에서 교환되는 모든 데이터를 정의하므로 서비스의 데이터 계약을 구성합니다. 모든 작업이 단순 형식만 사용하는 이와 같은 서비스의 경우 서비스 계약 내에서 계약의 데이터 측면을 암시적으로 정의하는 것이 합리적입니다. 다른 것은 필요하지 않습니다.

그러나 서비스에는 구조와 같은 더 복잡한 형식의 매개 변수가 있을 수도 있습니다. 이와 같은 경우 명시적 데이터 계약이 필요합니다. 데이터 계약은 메모리 내 형식을 직렬화라고 하는 프로세스인 와이어 간 전송에 적합한 형식으로 변환하는 방법을 정의합니다. 실제로 데이터 계약은 데이터가 직렬화되는 방식을 제어하는 메커니즘입니다.

Indigo 서비스 클래스에서 데이터 계약은 특성을 사용하여 DataContract 정의됩니다. 로 표시된 DataContract 클래스, 구조체 또는 기타 형식에는 특성 앞에 DataMember 하나 이상의 멤버가 있을 수 있으며, 이는 이 멤버가 이 형식의 직렬화된 값에 포함되어야 함을 나타냅니다. 다음은 간단한 예제입니다.

[DataContract]
struct Customer {
 [DataMember] public string Name; 
 int public age;
 [DataMember] private int CreditRating;
}

이 Customer 형식의 instance 로 표시된 OperationContract메서드에서 매개 변수로 전달되면 및NameCreditRating특성으로 DataMember 표시된 필드만 전달됩니다.

필드의 레이블이 로 public 지정되었는지 여부 private 가 해당 필드가 serialize되는지 여부에 영향을 주지 않습니다. 메서드 public 와 마찬가지로 및 private 키워드는 동일한 애플리케이션의 다른 개체에서 이 형식에 액세스할 수 있는 방법을 정의하는 계약의 일부입니다. DataMember와 같이 OperationContract는 이 클래스가 구현하는 서비스의 클라이언트에서 형식에 액세스할 수 있는 방법을 정의합니다. 다시 한번, 두 사람은 완전히 구별된다.

Indigo 계약에 대해 강조할 가치가 있는 마지막 한 가지 점은 기본적으로 서비스 계약 또는 데이터 계약의 일부가 되는 것은 없다는 것입니다. 대신 개발자는 및 DataContract 특성을 명시적으로 사용하여 ServiceContract Indigo 정의 계약이 있는 형식을 지정한 다음, 및 DataMember 특성을 사용하여 OperationContract 이 서비스의 클라이언트에 노출되는 형식의 일부를 명시적으로 지정해야 합니다. 디자이너의 신조 중 하나는 서비스에 명시적 경계가 있어야 한다는 것이었기 때문에 Indigo는 옵트인 기술입니다. 서비스에서 클라이언트에서 사용할 수 있는 모든 항목은 코드에 명시적으로 지정됩니다.

계약 및 이를 정의하는 특성은 Indigo의 주요 측면이며, 이 간단한 설명은 하이라이트만 다룹니다. OperationContract 예를 들어 서비스에 대한 호출에 회신이 없는 단방향 작업을 정의하는 데 특성을 사용할 수 있습니다. 또한 양면이 클라이언트 및 서비스 역할을 할 수 있는 상호 작용을 정의할 수 있으며, 각 작업은 작업을 호출하고 다른 쪽이 호출하는 작업을 노출하여 이중 계약이라고 하는 것을 만들 수 있습니다. 특성에는 DataContract 몇 가지 추가 옵션도 있으며, 기본적으로 라는 MessageContract특성을 사용하여 SOAP 메시지로 직접 작업할 수도 있습니다. 계약은 Indigo가 제공하는 많은 것을 표현하는 데 사용되므로 가장 기본적인 개념 중 하나입니다.

호스트 선택

Indigo 서비스를 구현하는 클래스는 일반적으로 라이브러리로 컴파일됩니다. 정의에 따라 모든 라이브러리는 호스트 애플리케이션 도메인 및 Windows 프로세스를 실행해야 합니다. Indigo는 서비스를 구현하는 라이브러리를 호스팅하는 두 가지 옵션을 제공합니다. 하나는 WAS(Windows 정품 인증 서비스)에서 제공하는 호스트 앱 도메인 및 프로세스를 사용하는 반면, 다른 하나는 임의 프로세스에서 실행되는 모든 앱 도메인에서 서비스를 호스트할 수 있도록 하는 것입니다. 이 섹션에서는 WAS부터 두 가지 모두를 설명합니다.

Windows 정품 인증 서비스를 사용하여 서비스 호스팅

Indigo 서비스를 호스트하는 가장 간단한 방법은 WAS를 사용하는 것입니다. (WAS는 Indigo의 첫 번째 커뮤니티 기술 미리 보기에서 지원되지 않습니다. 대신 Indigo 서비스는 Windows Server 2003 및 Windows XP의 인터넷 정보 서버에서 호스트할 수 있지만 이 구성에서는 HTTP를 통한 SOAP만 지원됩니다.) WAS를 사용하는 것은 ASMX용 IIS에서 제공하는 호스팅 메커니즘을 사용하는 것과 비슷합니다. 무엇보다도 둘 다 Windows 파일 시스템의 실제 디렉터리 경로에 대한 더 짧은 별칭인 가상 디렉터리의 개념에 의존합니다.

WAS 호스팅의 작동 방식을 확인하려면 이전에 표시된 클래스 중 Calculator 하나가 calc.dll 라는 라이브러리로 컴파일된 다음 Windows Server 2003을 실행하는 시스템의 가상 디렉터리 계산기에 배치되었다고 가정합니다. calc.dll 구현된 Indigo 서비스가 WAS에서 호스트되어야 함을 나타내기 위해 개발자는 확장명 .svc(물론 "서비스"의 경우)를 사용하여 계산기 가상 디렉터리에 파일을 만듭니다. 간단한 예제에서는 이 파일을 calc.svc라고 할 수 있으며 전체 내용은 다음과 같습니다.

%@Service language=c# class="Calculator" %

이 작업이 완료되고 다음 섹션에 표시된 대로 엔드포인트가 정의되면 클라이언트에서 서비스의 메서드 중 Calculator 하나에 대한 요청이 이 클래스의 instance 자동으로 만들어 지정된 작업을 실행합니다. 이 instance WAS가 제공하는 표준 프로세스 내에서 만든 애플리케이션 도메인에서 실행됩니다.

임의 프로세스에서 서비스 호스팅

WAS를 사용하여 Indigo 서비스를 호스팅하는 프로세스를 제공하는 것이 가장 간단한 선택입니다. 그러나 애플리케이션은 Windows에서 제공하는 서비스에 의존하지 않고 자체 프로세스에서 서비스를 노출해야 하는 경우가 많습니다. 다행히도, 이것은 할 어렵지 않다. 다음 예제에서는 앞에서 정의한 클래스 중 Calculator 하나를 호스트하는 프로세스를 만드는 방법을 보여 줍니다.

using System.ServiceModel;

public class CalculatorHost
{
  public static void Main()
  {
    ServiceHost<Calculator> s1 = 
      new ServiceHost<Calculator>();
    s1.Open();
    Console.Writeline("Press ENTER to end service");
    Console.Readline();    
  }
}

클래스 CalculatorHost 는 메서드를 Main 포함하므로 고유한 프로세스로 실행됩니다. 예제 Calculator 서비스를 호스트하려면 이 메서드가 클래스에 전달 Calculator 되는 클래스ServiceHost<T>의 새 instance 만들어야 합니다. (이 표준 Indigo 클래스는 매개 변수를 묶는 및 > 로 표시된 <제네릭입니다. 제네릭은 C#의 버전 2.0, Visual Basic .NET 및 .NET Framework 버전 2.0을 기반으로 하는 기타 언어의 새로운 언어 기능입니다.) 이 클래스의 instance 만들어지면 서비스를 사용할 수 있도록 하는 데 필요한 유일한 방법은 해당 instance 메서드를 호출 Open 하는 것입니다. 이제 Indigo는 클라이언트의 요청을 클래스의 적절한 메서드 Calculator 로 자동으로 전달합니다.

Indigo 서비스가 클라이언트의 요청을 처리할 수 있도록 하려면 호스트하는 프로세스가 계속 실행 중이어야 합니다. WAS가 제공하는 표준 프로세스는 이를 보장하기 때문에 WAS 호스팅 서비스에서는 문제가 되지 않습니다. 그러나 호스팅 애플리케이션은 이 문제를 자체적으로 해결해야 합니다. 이 간단한 예제에서는 콘솔 사용자의 입력을 기다리는 간단한 메커니즘을 통해 프로세스가 계속 실행됩니다.

엔드포인트 정의

Indigo 서비스 클래스에서 작업을 정의하고 해당 작업을 실행할 호스트 프로세스를 지정하는 것과 함께 Indigo 서비스는 하나 이상의 엔드포인트도 노출해야 합니다. 모든 엔드포인트는 다음 세 가지를 지정합니다.

• 이 Indigo 서비스 클래스가 이 엔드포인트를 통해 노출하는 서비스 계약을 나타내는 계약 이름입니다. 앞에서 보여 준 첫 번째 예제와 ServiceContract 같이 Calculator 명시적 인터페이스를 구현하지 않는 로 표시된 클래스는 하나의 서비스 계약만 노출할 수 있습니다. 이 경우 모든 엔드포인트는 동일한 계약을 노출합니다. 그러나 클래스가 로 표시된 ServiceContract두 개 이상의 인터페이스를 명시적으로 구현하는 경우 다른 엔드포인트가 서로 다른 계약을 노출할 수 있습니다.
• 이 엔드포인트를 찾을 수 있는 위치를 나타내는 주소 입니다. 주소는 해당 컴퓨터의 컴퓨터 및 특정 엔드포인트를 식별하는 URL입니다.
• 이 엔드포인트에 액세스할 수 있는 방법을 결정하는 바인딩 입니다. 바인딩은 통신이 신뢰할 수 있는지 여부 및 사용할 수 있는 보안 메커니즘과 같은 다른 것들과 함께 이 엔드포인트에 액세스하는 데 사용할 수 있는 프로토콜 조합을 결정합니다. instance 경우 서비스 작성자가 클라이언트가 HTTP를 통한 SOAP 또는 TCP를 통한 SOAP를 사용하여 해당 서비스에 액세스할 수 있도록 허용하려고 합니다. 이러한 각 바인딩은 고유한 바인딩이므로 서비스는 SOAP over-HTTP 바인딩이 있는 엔드포인트와 SOAP over-TCP 바인딩을 사용하는 엔드포인트를 두 개 노출해야 합니다.

바인딩은 통신을 수행하는 방법의 중요한 부분입니다. 더 쉽게 사용할 수 있도록 Indigo에는 미리 정의된 바인딩 집합이 포함되어 있으며, 각 바인딩은 특정 옵션 그룹을 지정합니다. 이 집합에는 다음이 포함됩니다.

• BasicProfileHttpBinding: HTTP를 통한 SOAP를 지정하는 WS-I(웹 서비스 상호 운용성 조직) 기본 프로필 1.0을 준수합니다. 명시적으로 지정되지 않은 경우 엔드포인트의 기본 바인딩입니다.
• BasicProfileHttpsBinding: HTTPS를 통해 SOAP를 지정하는 WS-I 기본 보안 프로필 1.0을 준수합니다.
• WsHttpBinding: WS-ReliableMessaging를 사용하여 신뢰할 수 있는 메시지 전송, WS-Security를 사용한 보안 및 WS-AtomicTransaction을 사용한 트랜잭션을 지원합니다. 이 바인딩은 이러한 사양을 지원하는 다른 웹 서비스 구현과의 상호 운용성을 허용합니다.
• WsDualHttpBinding: WsHttpBinding과 마찬가지로 이중 계약을 사용하는 상호 작용도 지원합니다. 이 바인딩을 사용하면 서비스와 클라이언트 모두 메시지를 받고 보낼 수 있습니다.
• NetTcpBinding: TCP를 통해 직접 신뢰할 수 있는 메시지 전송, 보안 및 트랜잭션 지원을 포함하여 이진 인코딩 SOAP를 보냅니다. 이 바인딩은 Indigo-Indigo 통신에만 사용할 수 있습니다.
• NetNamedPipeBinding: 명명된 파이프를 통해 이진 인코딩 SOAP를 보냅니다. 이 바인딩은 동일한 Windows 컴퓨터의 프로세스 간 Indigo 간 통신에만 사용할 수 있습니다.
• NetMsmqBinding: 나중에 설명한 대로 MSMQ를 통해 이진 인코딩 SOAP를 보냅니다. 이 바인딩은 Indigo-Indigo 통신에만 사용할 수 있습니다.

위의 그림에서는 앞에서 보여 준 첫 번째 Calculator 서비스에 대한 엔드포인트의 세 요소 각각에 대한 예제 값을 보여 있습니다. 서비스의 계약 Calculator이름은 이 서비스를 구현하는 클래스의 이름이고 바인딩은 입니다 BasicProfileHttpBinding. 이 서비스가 WAS를 사용하여 호스트되고, 앞에서 설명한 대로 가상 디렉터리 계산기에 설치되고, qwickbank.com 컴퓨터에서 실행한다고 가정하면 해당 주소는 http://www.qwickbank.com/calculator/calc.svc일 수 있습니다.

계약과 달리 엔드포인트는 특성을 사용하여 정의되지 않습니다. 프로그래밍 방식으로 엔드포인트를 만들 수 있지만 가장 일반적인 방법은 서비스와 연결된 구성 파일을 사용하는 것입니다. WAS 호스팅 서비스는 web.config 파일을 사용하지만 실행 중인 애플리케이션과 연결된 구성 파일을 사용하여 독립적으로 호스트되는 파일(일반적으로 실제 파일 이름은 다르지만 app.config이라고 함). 앞에서 보여 준 첫 번째 Calculator 서비스 클래스에만 사용되는 경우 이 구성 파일은 다음과 같습니다.

<configuration>
  <system.serviceModel>
    <services>
      <service serviceType="Calculator">
           <endpoint 
          contractType="Calculator"
          bindingType="basicProfileHttpBinding />
      </service>
    </services>
  </system.serviceModel>
</configuration>

Indigo 애플리케이션이 구현하는 모든 서비스에 대한 구성 정보는 요소 내에 system.serviceModel 포함되어 있습니다. 이 요소에는 services 하나 이상의 service 요소를 포함할 수 있는 요소가 포함되어 있습니다. 이 간단한 예제에는 단일 서비스만 있으므로 은 한 번만 발생합니다 service. 요소의 특성은 serviceType 이 구성이 적용되는 서비스를 구현하는 서비스 클래스를 식별합니다. 이 경우 입니다Calculator.service 각 service 요소에는 하나 이상의 endpoint 요소가 포함될 수 있으며, 각 요소는 이 Indigo 서비스에 액세스할 수 있는 특정 엔드포인트를 지정합니다. 이 예제에서 서비스는 단일 엔드포인트만 노출하므로 하나의 endpoint 요소만 나타납니다. 엔드포인트 Calculator계약의 이름은 를 구현하는 클래스의 이름인 입니다. 이 구성 파일이 명시적 인터페이스를 사용하여 서비스 계약을 정의한 이전에 표시된 두 번째 Calculator 서비스 클래스에 대한 경우 특성 값 serviceType 은 동일하게 유지되지만 값 contractType 은 대신 ICalculator이 명시적 인터페이스의 이름입니다. 여기에 지정된 바인딩은 이지만 basicProfileHttpBinding기본값이므로 생략되었을 수 있습니다. WAS 호스팅 서비스라고 가정 Calculator 하면 주소가 자동으로 만들어지므로 이 구성 파일에 주소를 지정할 필요가 없습니다.

Indigo 클라이언트 만들기

기본 Indigo 서비스를 만드는 것은 특별히 복잡하지 않습니다. Indigo 클라이언트를 만드는 것이 더 간단합니다. 필요한 것은 대상 서비스의 특정 엔드포인트에 연결된 프록시라고 하는 서비스에 대한 로컬 스탠드인을 만든 다음 이 프록시를 통해 서비스의 작업을 호출하는 것입니다. 아래 그림에서는 이 모양이 어떻게 보이는지 보여 주세요.

프록시를 만들려면 대상 엔드포인트에서 노출되는 계약을 정확히 알고 이 계약의 정의를 사용하여 프록시를 생성해야 합니다. Indigo에서 이 프로세스는 svcutil이라는 도구에 의해 수행됩니다. Indigo를 사용하여 서비스를 구현하는 경우 svcutil은 서비스의 DLL에 액세스하여 계약에 대해 알아보고 프록시를 생성할 수 있습니다. 서비스의 WSDL 정의만 사용할 수 있는 경우 svcutil은 이를 읽어 프록시를 생성할 수 있습니다. 서비스 자체만 사용할 수 있는 경우 svcutil은 WS-MetadataExchange 또는 간단한 HTTP GET을 사용하여 직접 액세스하여 서비스의 WSDL 인터페이스 정의를 획득한 다음 프록시를 생성할 수 있습니다.

그러나 클라이언트는 프록시의 새 instance 만든 다음 이를 사용하여 서비스의 메서드를 호출할 수 있습니다. 다음은 클래스에 대한 클라이언트의 간단한 예입니다.Calculator

using System.ServiceModel;
using Indigo.Example; // namespace for generated proxy class

public class CalculatorClient
{
  public static void Main()
  {
    CalculatorProxy p = new CalculatorProxy();
    Console.WriteLine("7 + 2 = {0}", p.Add(7, 2));
    Console.WriteLine("7 - 2 = {0}", p.Subtract(7, 2));
    p.Close();
  }
} 

클라이언트에서 지정해야 할 한 가지는 작업을 호출하려는 정확한 엔드포인트입니다. 서비스와 마찬가지로 클라이언트는 엔드포인트의 계약, 바인딩 및 주소를 지정해야 하며 일반적으로 구성 파일에서 수행됩니다. 실제로 충분한 정보를 사용할 수 있는 경우 svcutil은 대상 서비스에 대한 적절한 클라이언트 구성 파일을 자동으로 생성합니다.

인디고의 다른 측면

서비스와 클라이언트의 기본 사항은 모든 Indigo 애플리케이션의 기본 사항입니다. 그러나 대부분의 애플리케이션은 이 기술의 다른 측면도 사용합니다. 이 섹션에서는 Indigo가 빌드된 애플리케이션에 제공하는 몇 가지 추가 기능을 살펴봅니다.

로컬 동작 제어

계약, 바인딩 등 Indigo의 많은 측면은 서비스와 클라이언트 간의 통신과 관련이 있습니다. 그러나 기본적으로 로컬인 서비스 동작의 일부도 있습니다. 예를 들어 서비스 instance 수명은 어떻게 제어되며 해당 instance 대한 동시 액세스는 어떻게 관리하나요? 개발자가 이와 같은 동작을 제어할 수 있도록 Indigo는 두 가지 기본 특성을 정의합니다. 두 특성 모두에 여러 속성이 있습니다. 이러한 특성 중 하나인 는 ServiceBehavior특성으로도 표시된 클래스에 ServiceContract 적용할 수 있습니다. 다른 하나는 OperationBehavior특성으로 표시된 서비스 클래스의 메서드에 OperationContract 적용할 수 있습니다.

특성에는 ServiceBehavior 서비스 전체의 동작에 영향을 주는 다양한 속성이 있습니다. 예를 들어 라는 ConcurrencyMode 속성을 사용하여 서비스에 대한 동시 액세스를 제어할 수 있습니다. 로 Single설정하면 Indigo는 한 번에 하나의 클라이언트 요청만 이 서비스에 전달합니다. 즉, 서비스는 단일 스레드가 됩니다. 이 속성이 로 Multiple설정된 경우 Indigo는 각각 다른 스레드에서 실행되는 서비스에 한 번에 둘 이상의 클라이언트 요청을 제공합니다. 마찬가지로 ServiceBehavior의 InstanceMode 속성을 사용하여 서비스 인스턴스를 만들고 삭제하는 방법을 제어할 수 있습니다. 가 로 PerCall설정된 경우 InstanceMode 각 클라이언트 요청을 처리하기 위해 서비스의 새 instance 생성된 다음 요청이 완료되면 제거됩니다. 그러나 로 PrivateSession설정된 경우 서비스의 동일한 instance 특정 클라이언트의 모든 요청을 처리하는 데 사용됩니다.

예를 들어 작성자가 클래스를 Calculator 다중 스레드로 만들고 특정 클라이언트의 각 호출에 대해 동일한 instance 사용하도록 결정했다고 가정합니다. 그런 다음 클래스의 정의는 다음과 같습니다.

using System.ServiceModel;

[ServiceContract] 
[ServiceBehavior(
  ConcurrencyMode=Multiple, 
  InstanceMode=PrivateSession)]
class Calculator { ... } 

마찬가지로 특성의 OperationBehavior 속성을 사용하면 이 작업을 구현하는 메서드의 가장 동작, 트랜잭션 요구 사항(나중에 설명) 및 기타 항목을 제어할 수 있습니다.

메시징 옵션

이 문서에 표시된 간단한 예제에서는 클라이언트/서비스 상호 작용에 대한 동기 RPC(원격 프로시저 호출) 접근 방식을 가정합니다. Indigo는 이 옵션을 지원하지만 유일한 선택은 아닙니다. SOAP는 메시지 지향 프로토콜로, 다양한 프로그래밍 모델을 지원할 수 있습니다. 실제로 Indigo는 다음을 포함하여 몇 가지 가능성을 지원합니다.

• 형식화된 매개 변수 목록을 전달하는 차단 호출이 있는 기존 RPC;
• 비동기 RPC, 형식화된 매개 변수 목록을 전달하는 비차단 호출 사용;
• 단일 메시지 매개 변수를 전달하는 비차단 호출이 있는 기존 메시징
• 단일 메시지 매개 변수를 전달하는 차단 호출이 있는 메시지 기반 RPC입니다.

대부분의 분산 애플리케이션이 필요하지만 SOAP 사양은 안정성에 대해 아무 말도 하지 않습니다. 안정성을 보장하는 한 가지 일반적인 방법은 TCP를 사용하여 요청 및 응답 배달을 보장하는 지점 및 지점 시나리오에서만 SOAP를 사용하는 것입니다. 이는 경우에 따라 충분하며 BasicProfileHttpBinding을 사용할 때 수행됩니다.

그러나 이것으로 충분하지 않은 경우가 많이 있습니다. 예를 들어 여러 SOAP 중간자를 통해 서비스에 액세스하는 경우 어떻게 해야 할까요? 이 경우 TCP에서 제공하는 안정성 보장만으로는 엔드 투 엔드 안정성을 보장할 수 없습니다. 이 문제를 해결하기 위해 Indigo는 WS-ReliableMessaging 사양을 구현합니다. WS-ReliableMessaging를 사용하는 WsHttpBinding과 같은 바인딩을 선택하면 서비스와 클라이언트는 여러 SOAP 중간자를 통해서도 안정적인 엔드투엔드 통신을 보장할 수 있습니다.

보안

네트워크, 심지어 내부 네트워크에서도 서비스를 노출하려면 일반적으로 일종의 보안이 필요합니다. 서비스는 클라이언트의 ID를 어떻게 확신할 수 있나요? 악의적인 변경 및 캐고 눈으로부터 서비스를 주고 받는 메시지를 안전하게 보관하려면 어떻게 해야 할까요? 그리고 서비스에 대한 액세스는 어떻게 서비스 사용 권한이 부여된 사용자로만 제한될 수 있나요? 이러한 문제에 대한 해결 방법이 없으면 다양한 종류의 서비스를 노출하는 것은 너무 위험합니다. 그러나 보안 애플리케이션을 빌드하는 것은 복잡해질 수 있습니다. 이상적으로 일반적인 보안 시나리오를 해결하는 간단한 방법과 필요한 애플리케이션에 대한 보다 세분화된 제어가 있어야 합니다.

이를 위해 Indigo는 인증, 메시지 무결성, 메시지 기밀성 및 권한 부여의 핵심 보안 기능을 제공합니다. 이들 중 처음 세 가지에 대한 Indigo의 접근 방식은 주로 바인딩에 의존하며 개발자의 선택에는 다음이 포함됩니다.

• 보안을 지원하는 표준 바인딩을 선택합니다. 예를 들어 전송 기반 보안만 필요한 애플리케이션은 BasicProfileHttpsBinding과 같은 바인딩을 사용할 수 있습니다. 이 방법은 HTTP 프록시 또는 기타 SOAP 노드와 같은 중간자를 트래버스하지 않고 클라이언트에서 서비스로 직접 이동하는 요청에 충분합니다. 여러 SOAP 중간자를 통과하는 메시지에 엔드투엔드 보안이 필요한 애플리케이션은 WsHttpBinding과 같은 WS-Security를 지원하는 바인딩을 대신 사용할 수 있습니다.
• 보안을 지원하는 표준 바인딩을 선택한 다음 하나 이상의 기본값을 변경하여 사용자 지정합니다. 예를 들어 WsHttpBinding과 같은 바인딩에서 사용하는 인증 메커니즘은 원하는 경우 변경할 수 있습니다.
• 개발자가 필요로 하는 보안 기능을 정확하게 제공하는 사용자 지정 바인딩을 만듭니다. 이렇게 하는 것은 희미한 마음을 위한 것이 아니지만 일부 고급 시나리오에 적합한 솔루션이 될 수 있습니다.
• BasicProfileHttpBinding과 같은 보안을 지원하지 않는 표준 바인딩을 선택합니다. 보안을 사용하지 않는 것은 일반적으로 위험한 일이지만 일부 상황에서는 여전히 최선의 옵션이 될 수 있습니다.

Indigo 서비스는 서비스를 사용할 권한이 있는 클라이언트를 제어할 수도 있습니다. 대부분의 경우 Indigo는 .NET Framework 기존 권한 부여 메커니즘만 지원합니다. 예를 들어 서비스는 표준 PrincipalPermission 특성을 사용하여 액세스할 수 있는 사용자를 정의할 수 있습니다.

개발자가 압도적인 복잡성에 노출하지 않고 보안 애플리케이션을 빌드하도록 하는 것은 과거에 어려운 것으로 입증되었습니다. Indigo는 가장 일반적인 사례에 대한 간단한 접근 방식과 보다 복잡한 상황에 대한 세분화된 제어를 모두 제공하여 사용 가능하고 효과적인 방법으로 이 목표를 달성하는 것을 목표로 합니다.

트랜잭션

트랜잭션 처리는 다양한 종류의 비즈니스 논리를 빌드하는 데 중요한 측면입니다. 그러나 서비스 지향 세계에서 트랜잭션을 사용하는 것은 문제가 될 수 있습니다. 분산 트랜잭션은 참가자 간에 높은 수준의 신뢰를 가정하므로 트랜잭션이 서비스 경계에 걸쳐 있는 것이 적절하지 않은 경우가 많습니다. 그러나 트랜잭션과 서비스를 결합하는 것이 좋은 상황이 있으므로 Indigo에는 애플리케이션 디자인의 이 중요한 측면에 대한 지원이 포함됩니다.

.NET Framework 2.0의 트랜잭션

Indigo의 트랜잭션 지원은 .NET Framework 버전 2.0에서 제공하는 향상된 기능을 기반으로 합니다. 다음 릴리스에는 트랜잭션 동작 제어에만 초점을 맞춘 새로운 네임스페이스인 System.Transactions가 포함되어 있습니다. 개발자는 .NET Framework 버전 2.0의 새로운 구문인 실행 컨텍스트와 함께 System.Transactions의 서비스를 가장 자주 사용합니다. 실행 컨텍스트를 사용하면 정의된 scope 포함된 모든 코드에 적용되는 트랜잭션과 같은 일반적인 정보를 지정할 수 있습니다. 다음은 애플리케이션이 이 방법을 사용하여 작업 집합을 단일 트랜잭션으로 그룹화할 수 있는 방법의 예입니다.

using System.Transactions;

using (TransactionScope ts 
   = new TransactionScope(TransactionScopeOption.Required)) {
   // Do work, e.g., update different DBMSs
   ts.Complete();
}

블록 내 using 의 모든 작업은 정의하는 트랜잭션 실행 컨텍스트를 공유하기 때문에 단일 트랜잭션의 일부가 됩니다. 이 예제의 Complete 마지막 줄에서 의 메서드를 TransactionScope호출하면 블록이 종료될 때 트랜잭션을 커밋하라는 요청이 발생합니다. 이 방법은 예외가 발생하는 경우 트랜잭션을 중단하는 기본 제공 오류 처리도 제공합니다.

이 예제와 같이 새 TransactionScope를 지정하면 Required 이 코드는 항상 트랜잭션의 일부로 실행됩니다. 호출자의 트랜잭션이 있는 경우 해당 트랜잭션에 조인하고, 그렇지 않으면 새 코드를 만듭니다. Enterprise Services에서와 마찬가지로 , Supported및 NotSupported를 비롯한 RequiresNew다른 옵션도 지정할 수 있습니다.

Enterprise Services 및 선행 MTS 및 COM+와 달리 Systems.Transactions는 트랜잭션 동작을 제어하는 데 전적으로 중점을 줍니다. 예를 들어 트랜잭션과 개체의 내부 상태 간에는 필수 연결이 없습니다. Enterprise Services는 트랜잭션을 종료할 때 개체를 비활성화해야 하지만 Systems.Transactions는 이러한 요구를 하지 않습니다. Indigo는 Systems.Transaction을 기반으로 하므로 Indigo 애플리케이션은 트랜잭션 및 개체 상태를 독립적으로 관리할 수 있습니다.

인디고의 트랜잭션

Indigo 애플리케이션은 System.Transactions를 명시적으로 사용하거나, 커버 아래의 System.Transactions에 의존하는 특성을 사용하여 트랜잭션을 제어할 수 있습니다. 한 가지 옵션은 특성으로 표시된 클래스 내의 메서드가 ServiceContract 방금 설명한 대로 를 사용하여 TransactionScope트랜잭션에서 작업을 래핑하는 것입니다. 예를 들어 이 메서드에는 트랜잭션 scope 설정한 다음 해당 트랜잭션 내에서 두 개의 독립 데이터베이스를 업데이트하는 문이 포함될 using 수 있습니다.

서비스의 메서드는 특성을 사용하여 트랜잭션 동작을 제어할 수도 있습니다. Service는 System.Transactions를 명시적으로 사용하는 대신 앞에서 설명한 OperationBehavior 특성을 사용할 수 있습니다. 예를 들면 다음과 같습니다.

using System.ServiceModel;

[ServiceContract]
class XactOperations
{
 [OperationContract]
    public int Add(int value1, int value2)
    {
       return value1 + value2;
    }

 [OperationContract] 
 [OperationBehavior(RequireTransaction=true,
                    AutoCompleteTransaction=true)]
 int Update(int value1, int value2)
 {
       // Insert value1 and value2 into
    // two different databases
 }
}

이 예제의 첫 번째 메서드인 Add는 트랜잭션을 사용하지 않으므로 이전과 마찬가지로 간단한 작업이 수행됩니다. 그러나 두 번째 메서드인 Update은 속성이 OperationBehavior true로 RequireTransaction 설정된 특성 앞에 입니다. 이 때문에 이 메서드 내에서 수행된 모든 작업은 이전에 표시된 블록의 using 트랜잭션 scope 내부에 있는 것처럼 트랜잭션 내에서 수행됩니다. AutoCompleteTransaction 또한 속성도 지정되므로 예외가 발생하지 않으면 트랜잭션이 자동으로 커밋에 투표합니다.

이 메서드를 호출하는 클라이언트가 트랜잭션 내에서 실행되고 있지 않으면 메서드는 Update 자체 트랜잭션에서 실행됩니다. 다른 선택은 없습니다. 그러나 클라이언트가 를 호출 Update할 때 이미 기존 트랜잭션의 일부라고 가정해 보겠습니다. 메서드에서 수행된 Update 작업이 클라이언트의 트랜잭션에 조인되나요, 아니면 자체 독립 트랜잭션 내에서 계속 실행되나요? 대답은 이 서비스가 클라이언트에서 전달한 트랜잭션 컨텍스트를 허용할 수 있는지 여부에 따라 달라집니다. 이 옵션은 특성의 OperationContract 속성을 사용하여 TransactionFlowAllowed 제어됩니다. 위에 표시된 예제와 같이 가 서비스의 메서드에 연결되지 않은 경우 TransactionFlowAllowed 이 메서드 내에서 수행된 작업은 기존 트랜잭션에 조인할 수 없습니다. 그러나 이 특성이 있는 경우 메서드는 클라이언트의 트랜잭션을 조인할 수 있습니다.

또한 Indigo에서 빌드된 애플리케이션이 비 Indigo 플랫폼에서 실행되는 애플리케이션을 포함하는 트랜잭션에 참여할 수 있음을 강조할 가치가 있습니다. 예를 들어 Indigo 애플리케이션은 트랜잭션을 시작하고 로컬 SQL Server 데이터베이스에서 레코드를 업데이트한 다음 J2EE 애플리케이션 서버에서 구현된 웹 서비스를 호출하여 다른 데이터베이스의 레코드를 업데이트할 수 있습니다. 이 서비스가 트랜잭션이고 실행 중인 플랫폼이 WS-AtomicTransaction 사양을 지원하는 경우 두 데이터베이스 업데이트 모두 동일한 트랜잭션의 일부가 될 수 있습니다. 보안 및 신뢰할 수 있는 메시징과 마찬가지로 Indigo 트랜잭션은 웹 서비스가 가능하게 하는 이질적인 환경에서 작동합니다.

큐

Indigo 애플리케이션은 WsHttpBinding과 같은 바인딩을 사용하여 Indigo에 빌드된 다른 애플리케이션 또는 WS-ReliableMessaging를 구현하는 다른 웹 서비스 플랫폼과 안정적으로 통신할 수 있습니다. 그러나 이 사양이 정의하는 기술은 SOAP 메시지의 신뢰할 수 있는 엔드투엔드 배달을 보장하지만 메시지 큐를 처리하지는 않습니다. 큐를 사용하면 애플리케이션이 다른 애플리케이션에 직접 메시지를 보내는 대신 큐에 메시지를 보냅니다. 수신 애플리케이션이 준비되면 큐에서 메시지를 읽고 처리할 수 있습니다. 이러한 종류의 상호 작용을 허용하는 것은 예를 들어 메시지 발신자와 수신자가 동시에 실행되지 않을 수 있는 경우에 유용합니다.

이에 따라 Indigo는 메시지 큐에 대한 지원을 제공합니다. 이 지원은 MSMQ를 기반으로 구축됩니다. 즉, 신뢰할 수 있는 메시징, 보안 및 트랜잭션과 같은 Indigo의 대부분의 다른 측면과 달리 Indigo 큐는 공급업체 경계를 넘어 직접 상호 운용되지 않습니다(MSMQ-MQSeries 브리지를 사용할 수 있음).

Indigo 큐를 사용하기 위해 개발자는 표준 Indigo 서비스 클래스를 만듭니다. 이 클래스는 로 평소와 ServiceContract같이 표시됩니다. 그러나 이 클래스의 서비스 계약의 작업에는 몇 가지 제한 사항이 있습니다. 특히 모두 단방향으로 표시되어야 합니다. 즉, 응답이 반환되지 않습니다. 큐에 대기 중인 작업을 호출하면 최종 수신자가 아닌 큐로 메시지를 전송하므로 즉각적인 응답을 기다리는 것은 별로 의미가 없습니다. 그리고 다른 서비스 클래스와 마찬가지로 대기 중인 Indigo 애플리케이션은 엔드포인트를 노출합니다. 이러한 엔드포인트는 대기 중인 다른 Indigo 애플리케이션과의 통신을 허용하는 NetMsmqBinding 또는 MsmqIntegrationBinding과 같은 바인딩을 사용하므로 대기 중인 Indigo 애플리케이션이 Indigo를 사용하지 않는 표준 MSMQ 애플리케이션과 상호 운용할 수 있습니다. 인디고 큐는 배달 못한 편지 큐 및 포이즌 메시지 처리와 같은 대기 중인 환경의 다른 기존 기능도 지원합니다.

큐는 중요한 분산 애플리케이션 집합에 적합한 방법입니다. 이 통신 스타일에 대한 Indigo의 지원을 통해 개발자는 완전히 별도의 큐 기술을 학습하지 않고도 큐에 대기 중인 애플리케이션을 빌드할 수 있습니다.

공존 및 마이그레이션

Indigo는 안정적이고 안전한 트랜잭션 서비스 시대에 분산 애플리케이션을 만드는 최신 접근 방식을 나타냅니다. 그러나 이해해야 할 핵심은 Indigo를 설치해도 기존 애플리케이션이 중단되지 않는다는 것입니다. ASMX, .NET Remoting에서 실행되는 현재 코드 및 Indigo에서 기능이 하위화된 다른 기술은 계속 실행되므로 Indigo로 이동할 필요가 없습니다. 그러나 현재 Microsoft 기술에 투자한 조직의 경우 인디고 이전의 기술을 사용하여 작성된 기존 코드는 어떻게 되나요?

Indigo의 출현으로 인해 미래가 깊은 영향을 받는 현재의 각 기술에 대해 개발자는 이 기술을 기반으로 구축된 애플리케이션이 Indigo를 기반으로 하는 애플리케이션과 상호 운용되는지 여부와 이 기술에서 Indigo 환경으로 애플리케이션을 이식하는 데 얼마나 많은 작업이 필요한지를 이해해야 합니다. 각 기술이 이러한 문제를 해결하는 방법에 대한 간단한 설명은 다음과 같습니다.

• asMX(ASP.NET 웹 서비스): ASMX로 빌드된 웹 서비스는 Indigo 애플리케이션과 상호 운용됩니다. ASP.NET 웹 서비스와 Indigo는 모두 표준 SOAP를 지원하므로 놀라운 일이 아닙니다. 기존 ASP.NET 웹 서비스 코드를 Indigo로 이동하려면 약간의 기계적 작업이 필요하지만 여전히 간단해야 합니다. 두 기술의 기본 구조는 매우 유사하므로 대부분의 경우 특성 및 구성 파일만 변경해야 합니다. 그러나 SOAP 확장과 같은 고급 기능은 Indigo로 직접 이식할 수 없습니다. 대신 Indigo에서 제공하는 확장성 옵션을 사용하여 다시 작성해야 합니다.
• .NET Remoting: .NET Remoting을 기반으로 하는 애플리케이션은 Indigo에서 빌드된 애플리케이션과 상호 운용되지 않습니다. 해당 유선 프로토콜은 호환되지 않습니다. 기존 .NET 원격 코드를 Indigo로 이동하려면 약간의 노력이 필요하지만 가능할 것입니다. 그러나 채널 및 싱크와 같은 사용자 지정 .NET 원격 확장을 빌드한 사람은 이 코드가 새 세계로 포팅되지 않는다는 것을 알게 됩니다. Indigo에서도 비슷한 확장이 가능하지만 이를 위한 인터페이스는 .NET 원격의 인터페이스와 일치하지 않습니다.
• Enterprise Services: 기존 Enterprise Services 애플리케이션이 Indigo 클라이언트(또는 다른 웹 서비스 기반 소프트웨어)와 상호 운용되도록 허용하기 위해 개발자는 해당 애플리케이션에서 노출해야 하는 인터페이스를 정확하게 식별할 수 있습니다. Indigo에서 제공하는 도구를 사용하여 해당 인터페이스에 대한 서비스 계약을 자동으로 만들고 Indigo를 통해 노출할 수 있습니다. .NET Framework 빌드되지 않은 Enterprise Services 애플리케이션의 기존 클라이언트(및 다른 순수 COM 기반 클라이언트의 경우)의 경우 웹 서비스에 대한 간단한 액세스를 허용하도록 Indigo 모니커가 제공됩니다. Indigo에서 직접 실행되도록 기존 Enterprise Services 애플리케이션을 포팅하는 데 필요한 노력은 ASMX 애플리케이션을 포팅하는 데 필요한 작업과 유사합니다. 대부분의 작업은 전부는 아니지만 특성 및 네임스페이스에 대한 간단한 기계적 변경이 될 것입니다.
• WSE(웹 서비스 향상): WSE는 WS-* 사양에서 제공하는 기능의 일부 또는 전부가 필요한 웹 서비스 애플리케이션을 구현하기 위한 Microsoft의 전술적 솔루션입니다. WSE 1.0 및 WSE 2.0을 사용하여 빌드된 애플리케이션은 Indigo에서 빌드된 애플리케이션과 상호 운용되지 않습니다. 그러나 Indigo가 출시되기 전에 배송될 WSE 3.0을 기반으로 하는 애플리케이션은 Indigo 애플리케이션과 상호 운용됩니다. 이식성을 위해 기존 코드를 WSE에서 Indigo로 이동하는 데 약간의 노력이 필요하지만 최종 WSE 버전을 사용하는 애플리케이션의 경우 이러한 노력이 최소화됩니다.
• MSMQ: Indigo의 큐 함수는 MSMQ를 기반으로 하므로 Indigo에서 빌드된 큐에 대기 중인 애플리케이션은 MSMQ에서 직접 빌드된 큐에 대기 중인 애플리케이션과 상호 운용할 수 있습니다. 이 이전 인터페이스는 Indigo에서 제공하는 것과 다르기 때문에 원래 .NET Framework 제공된 System.Messaging 네임스페이스에서 애플리케이션을 포팅하려면 약간의 작업이 필요합니다. Indigo가 출시되면 개발자는 System.Messaging 대신 이를 사용하여 대부분의 MSMQ 기반 큐 애플리케이션을 만들어야 합니다.

Indigo를 사용할 수 있기 전에 큐가 필요하지 않은 분산 .NET 애플리케이션에 가장 적합한 기술은 아마도 ASMX일 것입니다. 사용하기 쉽고 Indigo로의 가장 원활한 마이그레이션 경로도 제공합니다. 또한 Enterprise Services는 분산 트랜잭션과 같이 제공하는 항목이 필요한 애플리케이션에 적합할 수 있지만 MSMQ는 큐에 대기 중인 애플리케이션에 적합한 선택입니다. 그러나 .NET 원격은 주로 동일한 프로세스에서 두 애플리케이션 도메인 간의 통신에 사용해야 합니다. ASMX는 대부분의 다른 경우에 직접 애플리케이션 간 통신에 더 적합합니다.

새 소프트웨어를 도입하면 항상 이미 존재하는 소프트웨어에 영향을 줍니다. Indigo는 서비스 지향 애플리케이션을 빌드하기 위한 공통 기반을 제공하여 개발자에게 보다 간단하고 일관된 플랫폼을 제공합니다. 이 변화는 약간의 고통을 초래하지만, 인디고의 제작자의 목표는 가능한 한 원활하고 간단한 전환을 만드는 것입니다.

결론

Indigo는 개발자가 소프트웨어를 만드는 방법에서 중요한 발전을 나타냅니다. 서비스 지향 애플리케이션이 표준이 됨에 따라 Indigo는 Windows 소프트웨어 개발자를 위한 주류 기술이 될 것입니다. 다른 Microsoft 제품도 Indigo에서 제공하는 제품을 활용하도록 변경됩니다. 예를 들어 BizTalk Server BizTalk Server 2006 릴리스 이후 언젠가 Indigo에 대한 지원을 통신 옵션으로 추가합니다. Indigo는 서비스 지향 소프트웨어에 대한 표준 기반을 제공하기 때문에 Windows 통신의 상당 부분을 위한 기초가 될 것입니다.

이 기술의 영향은 작지 않을 것입니다. Windows에서 분산 애플리케이션을 빌드하는 사람, 특히 다른 플랫폼의 애플리케이션과 상호 운용해야 하는 애플리케이션은 주의해야 합니다. 인디고는 그들의 세계를 크게 바꿀 것입니다.

 

작성자 정보

데이비드 샤펠은 캘리포니아 주 샌프란시스코의 샤펠 & 어소시에이츠(www.davidchappell.com)의 교장입니다. 이 문서는 인디고에 그의 곧 책에서 그려집니다., 애디슨-웨슬리에 의해 출판 될.