인터페이스를 사용하여 서비스 계약을 정의하는 경우와 클래스를 사용하여 서비스 계약을 정의하는 경우의 차이점
인터페이스를 사용하여 서비스 계약을 정의하는 경우
장점
1. 인터페이스는 서비스 계약을 직접 모델링함.
2. 서비스 계약 인터페이스는 다른 여러 서비스 계약 인터페이스를 확장할 수 있습니다.
3. 단일 클래스는 그러한 서비스 계약 인터페이스를 구현하여 원하는 만큼 서비스 계약을 구현할 수 있습니다.
4. 인터페이스 구현을 변경하여 서비스 계약의 구현을 수정할 수 있지만 서비스 계약은 그대로 유지됩니다.
5. 기존 인터페이스와 새 인터페이스를 구현하여 서비스에 버전을 지정할 수 있습니다. 기존 클라이언트는 원래 버전에 연결하며, 새 클라이언트는 새 버전에 연결합니다.
클래스를 사용하여 서비스 계약을 정의하는 경우
장점
1. 클래스와 클래스의 메서드에 각각 직접 적용하여 서비스를 만들면 빠르고 간편함.
단점
1. 관리되는 클래스가 여러 상속을 지원하지 않으므로 따라서 한 번에 하나의 서비스 계약만 구현할 수 있다는 것.
2. 클래스 또는 메서드 서명을 수정하면 해당 서비스에 대한 공용 계약이 수정되므로 수정되지 않은 클라이언트는 서비스를 사용할 수 없습니다. (치명적)
매개 변수 및 반환값
: 각 작업마다 반환 값과 매개 변수가 있으며, 값이 void인 경우에도 값은 존재합니다.
그러나 개체 간에 개체에 대한 참조를 전달할 수 있는 로컬 메서드와 달리 서비스 작업은 개체에 대한 참조를 전달하지 않습니다.
대신 개체 복사본을 전달합니다.
매개 변수 또는 반환 값에 사용되는 각 형식이 serialize될 수 있어야 하므로 이것은 중요한 사항입니다.
즉, 해당 형식의 개체를 바이트 스트림으로 변환하고 바이트 스트림에서 개체로 변환할 수 있어야 합니다.
데이터 계약
광범위한 상호 운용을 위해 DataContractAttribute 및 DataMemberAttribute 특성으로 형식을 표시하여 서비스 작업이 교환하는 데이터를 설명하는 서비스 계약의 부분인 데이터 계약을 만드는 것이 좋습니다.
데이터 계약 특성을 명시적으로 적용하지 않으면 형식이나 데이터 멤버가 serialize되지 않습니다.
메시지 교환에 매개 변수 및 반환 값 매핑
: 서비스 작업은 응용 프로그램 데이터뿐만 아니라 응용 프로그램이 특정 표준 보안, 트랜잭션 및 세션 관련 기능을 지원하는 데 필요한 데이터를 주고받는 SOAP 메시지의 기본 교환에 의해 지원됩니다.
서비스 작업에 대한 서명은 작업에 필요한 데이터 전송 및 기능을 지원할 수 있는 특정 기본 MEP(메시지 교환 패턴)를 지정.
1. 요청/회신
2. 단방향
: WCF 서비스 응용 프로그램의 클라이언트가 작업이 완료될 때까지 기다리지 않아도 되고 SOAP 오류가 처리되지 않을 경우 작업에 단방향 메시지 패턴을 지정.
3. 이중
: 이중 패턴의 특징은 단방향 메시징을 사용하든 요청/회신 메시징을 사용하든 관계없이 서비스와 클라이언트 모두 서로 독립적으로 메시지를 보낼 수 있는 기능.
3.1 이중 계약을 디자인하기
.- 콜백 계약 디자인 (클라이언트에서 호출되는 메서드 선언을 포함하는 다른 인터페이스를 만들어야 합니다.)
.- 콜백 계약의 형식을 서비스 계약을 표시하는 ServiceContractAttribute 특성의 CallbackContract 속성에 지정.
.- 콜백 계약 디자인 구현
주의 :
서비스가 이중 메시지를 받으면 들어오는 해당 메시지에서 ReplyTo 요소를 확인하여 회신을 보낼 위치를 결정합니다.
메시지를 받는 데 사용되는 채널이 보안되지 않으면 신뢰할 수 없는 클라이언트가 대상 컴퓨터의 ReplyTo를 사용하여 악의적인 메시지를 보낼 수 있으므로 해당 대상 컴퓨터의 서비스 거부(DOS)가 발생할 수 있습니다.
Out 및 Ref 매개 변수
: 작업을 선언하는 데 사용된 메서드가 void를 반환하는 경우에만 NetMsmqBinding 바인딩을 사용하여 클라이언트와 통신할 수 있습니다
참고 :
단방향 작업인 경우 InvalidOperationException 예외는 런타임에 throw됩니다.
계약에 메시지 보호 수준 지정
: 계약을 디자인할 때 계약을 구현하는 서비스의 메시지 보호 수준도 결정해야 합니다.
기본 WSHttpBinding(Message인 기본 System.ServiceModel.SecurityMode)을 사용하여 끝점의 ISampleService 구현과 상호 작용할 때 이것이 기본 보호 수준이므로 모든 메시지가 암호화되고 서명됩니다.
기본 BasicHttpBinding(None인 기본 SecurityMode)과 함께 사용되면 이 바인딩에 대한 보안이 없으므로 보호 수준이 무시되기 때문에(메시지가 암호화되거나 서명되지 않으므로) 모든 메시지가 텍스트로 전송됩니다.
계약에 대한 보호 요구 사항을 명시적으로 지정하거나 조정하려면 ProtectionLevel 속성(또는 더 작은 범위의 ProtectionLevel 속성 중 하나)을 서비스 계약에서 필요로 하는 수준으로 설정합니다.
