2010-06-04 2 views
0

나는 여러 가지 방법을 제공하는 WCF 서비스를 가지고 있습니다.Upcasting ServiceContract

내 응용 프로그램은이 서비스를 사용하며 ServiceContract에는 일부 메서드에만 OperationContract 정의가 포함되어 있습니다.

코드 예제에 따라 질문에 잘라 고려 :

[ServiceContract] 
public interface IServer 
{ 
    [OperationContract] 
    void BasicOperation(); 
} 

[ServiceContract] 
public interface IExtendedServer : IServer 
{ 
    [OperationContract] 
    void ExtendedOperation(); 
} 

내가 해당 응용 프로그램이 확장 기능이 있으므로 계약을하고 싶습니다. 즉, 나는 어디서나 IServer 계약을 사용할 수 있기를 원하지만, 플러그인과 같은 아키텍처가 기본 계약 인터페이스를 확장 할 수 있도록 플러그인 자체가 ExtendedOperation() 운영 계약을 호출 할 수 있도록합니다.

그렇다면 코드를 구조화하거나 다음과 같은 작업을 수행하려면 어떻게 변경해야합니까? 'Contract.IExtendedServer'을 입력 할 투명 프록시를 캐스팅 할 수 없습니다 : 나는이 작업을 수행 할 때 나는 오류를

System.InvalidCastException를 얻을

((IExtendedServer)channel).ExtendedOperation() 

(채널 유형 IServer이다). 내가 혼동되지 않았습니다 희망

...

답변

4

SOA 세계의 서비스에는 잘 정의되고 예쁜 정적 인터페이스가 있어야합니다. SOAP 서비스는 WSDL에서 표현을 필요로합니다 (관련 데이터에 대해 XSD = XML 스키마를 포함 시키거나 별도로 포함).

서비스 세계에서 플러그인 시스템과 같은 것을 어떻게 만들 수 있는지 알지 못합니다. 플러그인은 로컬 응용 프로그램에서 훌륭하게 작동합니다. 리소스, 언어 확장, 그래픽 필터 등을로드 할 수 있습니다. 그러나 SOA 세계에서이 "민첩성"은 사용자가하려는 것과 정확히 반대되는 것입니다. 잘 정의 된 완전 지정 서비스를 작성하여 제공해야합니다.

내가 볼 수있는 유일한 옵션은 REST 기반 접근법을 사용하는 것입니다. 거기에는 그와 같은 제한 사항이 많지 않기 때문입니다. 일반적으로 공식 서비스 설명의 부족은 REST의 주요 단점과 단점 중 하나이지만 REST를 사용하면 작업이 URL의 사용에 의해 정의되는 것만으로도 귀하의 경우에 더할 수 있습니다.

나는 이렇게 말하고 싶다. 서비스에 유연성을 실제로 원한다면, REST 기반 서비스를 체크 아웃해야한다. SOAP은 그 법안에 맞지 않습니다. MSDN의 WCF REST Developer Center으로 이동하여 WCF에서 REST를 사용하는 방법에 대한 다양한 정보와 리소스를 확인하십시오.

+0

+1 사려 깊은 추론을 통해 구체적인 대안을 제공합니다. – David

+0

감사합니다. 나는 내 자신의 추론에서 다소 모호했지만, 약간의 아이디어가 있었지만, 특히 좋은 설명을 한 후에 붙이지 않는 것 같았다. –

0

나는 당신이 여기 달성하려는 모르겠어요. 특정 계약 (즉, 인터페이스)이 드러나는 엔드 포인트가있는 서비스를 다루고 있습니다. 당신은 사물과 주조 등을 다루지 않습니다. 그것은 작동하지 않을 것이고 어쨌든 올바른 접근 방식이 아닙니다.

일반적인 방법으로 한 끝점을 표시하고 확장 작업이있는 다른 계약의 X 끝점을 잠재적으로 나타내는 X 끝점을 제공하는 서비스입니다. 서비스 측면에서는 하나의 서비스 클래스를 가질 수 있지만, 클라이언트가가는 한 그들은 단순히 다른 엔드 포인트/서비스입니다.

관련 문제