클레임, Azure 및 SharePoint 통합 도구 키트 3부

클레임, Azure 및 SharePoint 통합 도구 키트 3부

이 게시물은 CASI(클레임, Azure 및 SharePoint 통합) 키트에 대한 내용을 다루는 총 5부의 시리즈 중 3부입니다. 1부에서는 전체 프레임워크와 솔루션에 대해 간략히 살펴보고 시리즈에서 다룰 내용에 대해 설명했습니다. 2부에서는 WCF 응용 프로그램을 만들고 이러한 응용 프로그램에서 클레임을 인식하도록 설정한 다음 이를 Windows Azure로 옮기기 위한 지침을 다뤘습니다. 이 게시물에서는 이 프레임워크의 주요 결과물 중 하나인 사용자 지정 컨트롤 기반 클래스에 대해 설명하겠습니다. 이 클래스는 SharePoint에서 Windows Azure에서 호스팅되는 WCF 응용 프로그램에 연결하는 데 사용할 수 있습니다. 이 게시물에서 다룰 항목은 다음과 같습니다.

· 기본 클래스 – 기본 클래스가 무엇이며 프로젝트에서 어떻게 사용하는지에 대해 설명합니다.

· 레이아웃 페이지 – _layouts 디렉터리의 페이지에 새 컨트롤을 추가하는 방법에 대해 다룹니다.

· 중요한 속성 – 기본 클래스에서 알아야 할 몇 가지 중요한 속성을 살펴봅니다.

CASI 키트 기본 클래스

CASI 키트의 주요 결과물 중 하나는 WCF 응용 프로그램에 연결하고 현재 사용자의 로그온 토큰을 사용하여 요청을 전송하는 사용자 지정 컨트롤에 대한 기본 클래스입니다. 기본 클래스 자체는 표준 ASP.NET 서버 컨트롤이며 이러한 개발 패턴을 구현하려면 이 기본 클래스에서 상속되는 새 ASP.NET 서버 컨트롤을 만들어야 합니다. 이 게시물의 범위를 벗어나지 않도록 하기 위해 여러분의 컨트롤에서는 꼭 필요한 다음과 같은 두 가지를 수행하게 됩니다.

1. Windows Azure에서 호스팅되는 WCF 응용 프로그램에 대한 서비스 참조를 만듭니다.

2. 기본 클래스의 ExecuteRequest 메서드를 재정의합니다. 실제로는 다섯 줄 정도의 코드만 작성하면 되기 때문에 이 작업은 매우 간단합니다. 코드의 이 부분에서는 WCF 응용 프로그램에 연결할 프록시를 만들고 구성한 다음 기본 클래스의 ExecuteRequest 메서드를 호출합니다.

이를 시작하려면 Visual Studio에서 새 프로젝트를 만들고 Windows 클래스 라이브러리 유형 프로젝트를 선택하면 됩니다. 네임스페이스와 클래스 이름을 원하는 대로 변경한 후 AzureConnect.dll 어셈블리라는 CASI 키트의 기본 클래스에 대한 참조를 추가합니다. 또한 Microsoft.SharePoint, System.ServiceModel, System.Runtime.Serialization 및 System.Web 어셈블리에 대한 참조도 추가해야 합니다.

기본 클래스에서 Microsoft.SharePoint에 대한 Using 문을 추가한 다음 AzureConnect.WcfConfig에서 상속하도록 클래스를 변경합니다. WcfConfig 기본 클래스에 포함된 모든 코드 및 논리를 사용하면 WCF 응용 프로그램에 연결하고 구현의 유연성을 높이는 모든 속성을 통합할 수 있는 것은 물론 WCF 서비스 끝점에 연결하는 데 필요한 일반적인 모든 web.config 변경 사항에 대한 필요성이 사라집니다. 일반적인 상황에서는 연결할 WCF 응용 프로그램마다 거의 100줄에 달하는 web.config 변경 사항을 web.config 파일을 사용하는 모든 웹 응용 프로그램의 모든 서버에 있는 모든 web.config 파일에 일일이 추가해야 하므로 이는 반드시 이해해야 하는 부분입니다. WcfConfig 기본 클래스는 이를 컨트롤 내에 모두 요약하므로 여러분은 이러한 컨트롤에서 상속하기만 하면 되며 나머지는 자동으로 처리됩니다. 하지만 web.config에서 변경하는 이러한 모든 속성은 WcfConfig 컨트롤에서도 표시하므로 여기서도 변경이 가능합니다. 이에 대해서는 중요한 속성에 대해 다루는 섹션에서 좀 더 자세히 설명하겠습니다.

이제 Windows Azure에서 호스팅되는 WCF 응용 프로그램에 새 서비스 참조를 추가해야 합니다. 여기서는 CASI 키트와 관련하여 특별히 수행할 작업이 없습니다. 프로젝트에서 참조를 마우스 오른쪽 단추로 클릭하고 서비스 참조 추가를 선택하기만 하면 됩니다. “?WSDL”을 사용하여 여러분의 Azure WCF 응용 프로그램에 대한 URL을 플러그 인하여 응용 프로그램에서 서비스 구현의 WSDL을 가져오도록 합니다. 그런 다음 이름을 원하는 대로 변경하고 참조를 추가하면 이 부분이 완성됩니다.

이 시점에서 빈 클래스와 WCF 응용 프로그램에 대한 서비스 참조가 마련됩니다. 이제 코드 작성 부분으로 넘어가겠습니다. 다행히도 분량이 매우 적습니다. 여기서는 ExecuteRequest 메서드를 재정의하고, 서비스 클래스 프록시를 만들고 구성한 다음 기본 클래스의 ExecuteRequest 메서드를 호출해야 합니다. 설명을 간단히 하기 위해 예제 코드에 대한 전체 코드를 아래에 공개합니다. 이 코드는 게시물에도 첨부했으며 여러분의 서비스 참조와 일치시키기 위해 변경해야 할 부분은 노란색으로 강조 표시해 두었습니다.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Diagnostics;

using Microsoft.SharePoint;

//requires References to:

//1. AzureConnect

//2. Microsoft.SharePoint

//3. System.ServiceModel

//4. System.Runtime.Serialization

//5. System.Web

namespace AzureWcfPage

{

    public class WcfDataControl : AzureConnect.WcfConfig

    {

        //this method must be overridden so the proxy can be

 //configured and created correctly

        public override bool ExecuteRequest()

        {

            try

            {

                //create the proxy instance with bindings and endpoint the base class

                //configuration control has created for this

                CustomersWCF.CustomersClient cust =

                    new CustomersWCF.CustomersClient(this.FedBinding,

                     this.WcfEndpointAddress);

                //configure the channel so we can call it with

              //FederatedClientCredentials.

                SPChannelFactoryOperations.ConfigureCredentials<CustomersWCF.ICustomers>

                     (cust.ChannelFactory,

                     Microsoft.SharePoint.SPServiceAuthenticationMode.Claims);

                //create a channel to the WCF endpoint using the

  //token and claims of the current user

                CustomersWCF.ICustomers claimsWCF =

                    SPChannelFactoryOperations.CreateChannelActingAsLoggedOnUser

                    <CustomersWCF.ICustomers>(cust.ChannelFactory,

                     this.WcfEndpointAddress,

                    new Uri(this.WcfEndpointAddress.Uri.AbsoluteUri));

          //set the client property for the base class

                this.WcfClientProxy = claimsWCF;

            }

            catch (Exception ex)

            {

                Debug.WriteLine(ex.Message);

            }

               

            //now that the configuration is complete, call the method

            return base.ExecuteRequest();

        }

    }

}

이제 기본적으로 다섯 줄의 코드가 추가되었으며 여기에 나와 있는 ExcecuteRequest에 대한 재정의 부분에서 코드를 바로 복사하여 이를 자신의 재정의 부분에 붙여 넣을 수 있습니다. 이렇게 한 다음에는 노란색으로 강조 표시된 부분을 여러분의 WCF에서 표시하는 해당 클래스와 인터페이스로 바꾸기만 하면 됩니다. 위의 강조 표시된 코드에서 살펴볼 내용은 다음과 같습니다.

· CustomersWCF.CustomersClient: “CustomersWCF”는 제 서비스 참조를 만들 때 사용한 이름이며 CustomersClient는 제 WCF 응용 프로그램을 통해 표시한 클래스의 이름입니다. 제 WCF의 클래스 이름은 실제로는 “Customers”이며 VS.NET 서비스 참조 추가 도구에서 끝에 “Client” 부분을 추가한 것입니다.

· CustomersWCF.ICustomers: “CustomersWCF”는 위에 설명한 내용과 같습니다. “ICustomers”는 제 WCF 응용 프로그램에 만들었으며 제 WCF “Customers” 클래스에서 실제로 구현하는 인터페이스입니다.

여기까지가 Windows Azure에서 호스팅되는 WCF 응용 프로그램에 다시 연결하도록 하기 위해 작성해야 하는 코드의 전부입니다. 정말 쉽다는 생각이 드실 겁니다. 배경 설명을 약간 하자면 여러분이 작성한 코드는 WCF 응용 프로그램에 대한 호출을 SharePoint 사용자의 토큰에 따라 전달할 수 있도록 하는 부분입니다. 이에 대한 내용은 제가 작성한 다른 게시물인 https://blogs.technet.com/b/speschka/archive/2010/09/08/calling-a-claims-aware-wcf-service-from-a-sharepoint-2010-claims-site.aspx(영문일 수 있음)에 자세히 설명되어 있습니다.

이제 코드가 완성되었으므로 기본 클래스와 새로운 사용자 지정 컨트롤을 이러한 요소가 사용될 각 서버의 GAC(전역 어셈블리 캐시)에 등록해야 합니다. 이 작업은 SharePoint 솔루션으로 매우 쉽게 수행할 수 있습니다. 컨트롤을 완성하여 등록했으므로 이제 이를 사용하여 데이터를 가져오고 렌더링하는 방법에 대해 살펴보겠습니다. 저는 CASI 키트에서 Azure 데이터를 사용하는 다음과 같은 세 가지 주요 시나리오를 해결하고자 했습니다.

1. 웹 파트를 사용하여 SharePoint 페이지의 콘텐츠 렌더링

2. 일대다 컨트롤을 통해 사용할 구성 데이터를 가져오고 이러한 데이터를 ASP.NET 캐시에 저장

3. 데이터를 가져오고 실행 가능한 작업 유형(예: SharePoint 타이머 작업)에 사용

첫 번째 시나리오가 가장 보편적으로 발생할 가능성이 높으므로 먼저 다뤄보겠습니다. 이 방법론이 개발된 이후 가장 쉬운 작업은 Load 등의 이벤트 도중 이러한 모든 호출을 수행하는 사용자 지정 웹 파트를 만들고 데이터를 가져오고 이를 페이지에서 렌더링하는 일이었을 것입니다. 하지만 제 생각에 이는 큰 실수입니다. 이러한 코드를 웹 파트 자체에 요약하면 페이지 요청이 처리되는 동안 서버측에서 실행되므로 팜의 전체 처리량에 심각한 영향을 줄 수 있습니다. 저는 데이터를 가져오기 위해 응용 프로그램과 데이터 센터 간에서 잠재적인 일대다 호출을 수행하는 일대다 웹 파트를 페이지에 두는 것에 대해 매우 우려했으며, 이를 광범위하게 사용할 경우 전체 팜이 말 그대로 무력해질 수 있는 시나리오가 바로 떠올랐습니다. 하지만 여기서는 사용자 토큰과 요청을 함께 전송하도록 WCF 응용 프로그램에 대한 채널을 구성해야 하기 때문에 일부 코드를 서버에서 실행해야 하는 요구 사항을 해결해야 합니다. 제가 생각해 낸 솔루션은 다음과 같은 두 부분으로 이루어져 있습니다.

1. _layouts 폴더에서 호스팅되는 사용자 지정 페이지. 이 페이지는 위에서 작성한 사용자 지정 컨트롤을 포함하며 실제로 WCF 호출을 통해 반환되는 데이터를 렌더링합니다.

2. 코드 없이 서버측에서 실행되며 JavaScript 및 jQuery를 사용하여 _layouts 폴더의 페이지를 호출하는 사용자 지정 웹 파트. 이 웹 파트는 페이지에서 반환한 데이터를 읽은 다음 기본적으로 콘텐츠를 이 웹 파트에서 렌더링하는 JavaScript 함수로 전달합니다. 물론 이 웹 파트에는 훨씬 많은 사항을 추가할 수 있지만 이에 대해서는 다음 게시물에서 자세히 다루겠습니다. 하지만 이를 통해 사용자가 페이지를 요청하면 WCF 응용 프로그램에 대한 잠재적인 추가 호출 없이 처리됩니다. 대신 페이지는 처리 파이프라인을 거쳐 사용자의 브라우저로 내려오게 됩니다. 그런 다음 페이지가 완전히 로드되면 WCF 콘텐츠만 가져오도록 호출이 발생합니다.

레이아웃 페이지

사용자 지정 컨트롤을 호스팅하는 레이아웃 페이지는 실제로 작성하기가 매우 쉽습니다. 메모장에서 전체 페이지를 작성하는 데 5분 정도밖에 걸리지 않았습니다. 다행히도 여기에 제 레이아웃 페이지를 복사하고 붙여 넣은 다음 여러분의 페이지에서 바꿔야 할 부분을 알려 드릴 예정이므로 여러분의 경우에는 이보다 훨씬 빨라질 것입니다.

<%@ Page Language="C#" AutoEventWireup="true" Inherits="Microsoft.SharePoint.WebControls.LayoutsPageBase,Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" MasterPageFile="~/_layouts/simple.master" %>

 

<%@ Assembly Name="Microsoft.SharePoint.ApplicationPages, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"%>

<%@ Import Namespace="Microsoft.SharePoint.ApplicationPages" %>

<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

<%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

<%@ Import Namespace="Microsoft.SharePoint" %>

<%@ Assembly Name="Microsoft.Web.CommandUI, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>

 

<%@ Assembly Name="AzureConnect, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c0b51bd3d3b33212"%>

<%@ Register Tagprefix="AzWcf" Namespace="AzureWcfPage" Assembly="AzureWcfPage, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f0ed63b2f4046026" %>

 

 

<asp:Content ID="Content1" ContentPlaceHolderId="PlaceHolderPageTitle" runat="server">

    <SharePoint:EncodedLiteral ID="wcfConnectPageTitle" runat="server" text="Azure Wcf Connect Page" EncodeMethod='HtmlEncode'/>

</asp:Content>

<asp:Content ID="Content2" ContentPlaceHolderId="PlaceHolderPageTitleInTitleArea" runat="server">

    <SharePoint:EncodedLiteral ID="wcfConnectPage" runat="server" text="Azure Wcf Connect Page" EncodeMethod='HtmlEncode'/>

</asp:Content>

<asp:Content ID="Content3" ContentPlaceHolderId="PlaceHolderSiteName" runat="server"/>

<asp:Content ID="Content4" ContentPlaceHolderId="PlaceHolderMain" runat="server">

    <AzWcf:WcfDataControl runat="server" id="wcf" WcfUrl="https://azurewcf.vbtoys.com/Customers.svc" OutputType="Page" MethodName="GetAllCustomersHtml" />

</asp:Content>

 

다시 한 번 말하지만 페이지 구현 자체는 정말 쉽습니다. 변경해야 할 부분은 여러분의 사용자 지정 컨트롤에 대한 어셈블리의 강력한 이름뿐입니다. 이해를 돕기 위해 위에서처럼 컨트롤 태그에서 몇 가지 속성을 강조 표시해 두었습니다. 이러한 속성은 제 WCF 서비스와 관련된 것으로, 여러분의 구현에서는 변경할 수 있으며 경우에 따라서는 완전히 제거해도 됩니다. 이들 속성에 대해서는 아래에서 자세히 설명하겠습니다. 만들어진 레이아웃 페이지는 SharePoint 팜에 있는 모든 웹 프런트 엔드 서버의 _layouts 디렉터리에 배포해야 합니다. 이렇게 하면 SharePoint 팜에 있는 모든 클레임 인식 웹 응용 프로그램의 모든 사이트에서 이 페이지를 호출할 수 있게 됩니다. 하지만 이 페이지가 중앙 관리 같은 클래식 인증 사이트에서 작동할 것으로 기대해서는 안 됩니다. 페이지가 배포되면 CASI 키트 웹 파트에서 사용할 수 있게 되며 이에 대해서는 이 시리즈 게시물의 4부에서 설명하겠습니다.

중요한 속성

WcfConfig에는 크게 두 가지 범주의 속성, 즉 WCF 응용 프로그램에 대한 채널 및 연결을 구성하기 위한 속성과 컨트롤의 사용을 구성하는 속성이 포함되어 있습니다.

WCF 속성

앞에서 설명했듯이 web.config 파일에 일반적으로 포함되는 WCF 응용 프로그램에 대한 모든 구성 정보는 WcfConfig 컨트롤로 캡슐화되어 있습니다. 하지만 구현 요구 사항에 따라 수정할 수 있도록 거의 모든 속성이 표시됩니다. 여기서 두 가지 중요한 예외가 있는데 하나는 항상 MessageSecurityVersion.WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12BasicSecurityProfile10인 메시지 보안 버전이고 다른 하나는 항상 HTTP가 아닌 HTTPS인 전송입니다. 그렇지 않은 경우 컨트롤에는 구현을 좀 더 자세히 파악하는 데 유용할 수 있는 다양한 속성이 있지만 일반적인 경우에는 이러한 속성을 변경할 필요가 없습니다.

먼저, 구성에 사용되는 최상위 구성 개체를 표시하기 위한 다섯 개의 읽기 전용 속성이 있습니다. 여기서 읽기 전용이라는 말은 개체 자체가 읽기 전용이라는 의미지만 컨트롤을 프로그래밍 방식으로 작업하는 경우에는 해당 속성을 일일이 설정할 수 있습니다. 이러한 속성은 다음과 같습니다.

SecurityBindingElement SecurityBinding

BinaryMessageEncodingBindingElement BinaryMessage

HttpsTransportBindingElement SecureTransport

WS2007FederationHttpBinding FedBinding

EndpointAddress WcfEndpointAddress

다른 속성은 모두 레이아웃 aspx 페이지에 추가되는 컨트롤 태그에서 구성할 수 있습니다. 이러한 속성에 대해서는 복합 속성 값에 유용할 것으로 기대한 명명 규칙을 사용했습니다. 예를 들어 SecurityBinding 속성에는 CacheCookies라는 부울 속성이 있는 LocalClient라는 속성이 있습니다. 이를 보다 쉽게 이해하여 사용할 수 있도록 하기 위해 저는 SecurityBindingLocalClientCacheCookies라는 속성을 만들었습니다. 앞으로도 이와 같은 여러 속성을 확인하게 되는데, 이는 .NET Framework SDK를 살펴볼 때 기본 클래스 구현에서 이러한 일부 속성 값을 수정하는 방법을 궁금해하는 경우에 올바른 속성을 확인하기 위한 실마리 역할을 하기도 합니다. 다음은 전체 속성의 목록입니다.

SecurityAlgorithmSuite SecurityBindingDefaultAlgorithmSuite

SecurityHeaderLayout SecurityBindingSecurityHeaderLayout

SecurityKeyEntropyMode SecurityBindingKeyEntropyMode

bool SecurityBindingIncludeTimestamp

bool SecurityBindingLocalClientCacheCookies

bool SecurityBindingLocalClientDetectReplays

int SecurityBindingLocalClientReplayCacheSize

int SecurityBindingLocalClientMaxClockSkew

int SecurityBindingLocalClientMaxCookieCachingTime

int SecurityBindingLocalClientReplayWindow

int SecurityBindingLocalClientSessionKeyRenewalInterval

int SecurityBindingLocalClientSessionKeyRolloverInterval

bool SecurityBindingLocalClientReconnectTransportOnFailure

int SecurityBindingLocalClientTimestampValidityDuration

int SecurityBindingLocalClientCookieRenewalThresholdPercentage

bool SecurityBindingLocalServiceDetectReplays

int SecurityBindingLocalServiceIssuedCookieLifetime

int SecurityBindingLocalServiceMaxStatefulNegotiations

int SecurityBindingLocalServiceReplayCacheSize

int SecurityBindingLocalServiceMaxClockSkew

int SecurityBindingLocalServiceNegotiationTimeout

int SecurityBindingLocalServiceReplayWindow

int SecurityBindingLocalServiceInactivityTimeout

int SecurityBindingLocalServiceSessionKeyRenewalInterval

int SecurityBindingLocalServiceSessionKeyRolloverInterval

bool SecurityBindingLocalServiceReconnectTransportOnFailure

int SecurityBindingLocalServiceMaxPendingSessions

int SecurityBindingLocalServiceMaxCachedCookies

int SecurityBindingLocalServiceTimestampValidityDuration

int BinaryMessageMaxReadPoolSize

int BinaryMessageMaxWritePoolSize

int BinaryMessageMaxSessionSize

int BinaryMessageReaderQuotasMaxDepth

int BinaryMessageReaderQuotasMaxStringContentLength

int BinaryMessageReaderQuotasMaxArrayLength

int BinaryMessageReaderQuotasMaxBytesPerRead

int BinaryMessageReaderQuotasMaxNameTableCharCount

System.Net.AuthenticationSchemes SecureTransportAuthenticationScheme

System.ServiceModel.HostNameComparisonMode SecureTransportHostNameComparisonMode

System.Net.AuthenticationSchemes SecureTransportProxyAuthenticationScheme

System.ServiceModel.TransferMode SecureTransportTransferMode

bool SecureTransportManualAddressing

long SecureTransportMaxBufferPoolSize

long SecureTransportMaxReceivedMessageSize

bool SecureTransportAllowCookies

bool SecureTransportBypassProxyOnLocal

bool SecureTransportKeepAliveEnabled

int SecureTransportMaxBufferSize

string SecureTransportRealm

bool SecureTransportUnsafeConnectionNtlmAuthentication

bool SecureTransportUseDefaultWebProxy

bool SecureTransportRequireClientCertificate

HostNameComparisonMode FedBindingHostNameComparisonMode

WSMessageEncoding FedBindingMessageEncoding

Encoding FedBindingTextEncoding

SecurityAlgorithmSuite FedBindingSecurityMessageAlgorithmSuite

SecurityKeyType FedBindingSecurityMessageIssuedKeyType

bool FedBindingSecurityMessageNegotiateServiceCredential

int FedBindingCloseTimeout

int FedBindingOpenTimeout

int FedBindingReceiveTimeout

int FedBindingSendTimeout

bool FedBindingBypassProxyOnLocal

bool FedBindingTransactionFlow

long FedBindingMaxBufferPoolSize

long FedBindingMaxReceivedMessageSize

bool FedBindingUseDefaultWebProxy

int FedBindingReaderQuotasMaxDepth

int FedBindingReaderQuotasMaxStringContentLength

int FedBindingReaderQuotasMaxArrayLength

int FedBindingReaderQuotasMaxBytesPerRead

int FedBindingReaderQuotasMaxNameTableCharCount

bool FedBindingReliableSessionOrdered

int FedBindingReliableSessionInactivityTimeout

bool FedBindingReliableSessionEnabled

다시 언급하지만 이러한 속성은 모두 레이아웃 aspx 페이지의 컨트롤 태그에서 바로 수정할 수 있도록 만들어졌습니다. 예를 들어 다음은 FedBindingUseDefaultWebProxy 속성을 설정하는 방법입니다.

<AzWcf:WcfDataControl runat="server" id="wcf" WcfUrl="https://azurewcf.vbtoys.com/Customers.svc" OutputType="Page" MethodName="GetAllCustomersHtml" FedBindingUseDefaultWebProxy="true" />

 

사용 속성

컨트롤의 다른 속성은 컨트롤이 사용되는 방식을 제어하도록 디자인되어 있습니다. 속성 목록이 다소 길지만 이는 주로 사용 과정에 유연성을 높이기 위한 것입니다. 단순한 상황에서는 하나 내지 두 개의 속성만 설정할 수도 있고, 이 시리즈 게시물의 4부에서 설명할 웹 파트에서 설정할 수도 있습니다. 다음은 각 속성의 목록과 속성에 대한 간략한 설명입니다.

string WcfUrl – WCF 서비스 끝점에 대한 URL(즉, https://azurewcf.vbtoys.com/Customers.svc)입니다.

string MethodName – 페이지가 요청될 때 호출해야 하는 메서드의 이름입니다. 이 속성은 기본적으로 호출되는 메서드로 설정할 수 있습니다. 또한 AllowQueryStringOverride 속성을 false로 설정하면 페이지에서 컨트롤 태그에 정의한 MethodName만 사용하도록 제한할 수 있습니다. 이 속성은 CASI 키트 웹 파트를 사용하여 쿼리 문자열을 통해 설정할 수 있습니다.

string MethodParams – 메서드 호출에 전달해야 하는 세미콜론으로 구분한 매개 변수 값 목록입니다. 이러한 매개 변수는 메서드 시그니처에서 나타나는 것과 동일한 순서를 유지해야 합니다. 이 블로그 시리즈의 2부에서 설명했듯이 매개 변수 값에서는 string, bool, int 및 datetime 같은 단순한 데이터 형식만 지원합니다. 좀 더 복잡한 개체를 매서드 매개 변수로 전달하려면 매개 변수를 문자열로 만들고 메서드를 호출하기 전에 개체의 직렬화를 XML로 해제해야 하며, WCF 응용 프로그램에서 문자열을 다시 개체 인스턴스로 직렬화할 수도 있습니다. 하지만 이를 쿼리 문자열 매개 변수로 전달하는 경우 브라우저 및 IIS에서 지원하는 최대 쿼리 문자열 길이로 인한 제한을 받게 됩니다. 이 속성은 CASI 키트 웹 파트를 사용하여 쿼리 문자열을 통해 설정할 수 있습니다.

object WcfClientProxy – WcfClientProxy는 실제로 WCF 응용 프로그램을 호출하는 데 사용됩니다. 호출과 함께 사용자 토큰을 전달하려면 이 속성을 구성해야 합니다. 바로 이 때문에 ExecuteRequest를 재정의할 때 사용자 지정 컨트롤에 작성하는 구성 코드의 마지막 부분에서 현재 클라이언트 자격 증명을 사용하도록 만들고 구성한 서비스 응용 프로그램 프록시와 이 프록시가 같아지도록 설정하는 것입니다.

string QueryResultsString – 이 속성에는 메서드 호출에서 반환하는 결과의 문자열 표현이 포함되어 있습니다. WCF 메서드에서 bool, int, string, datetime 같은 단순한 데이터 형식을 반환하는 경우 이 속성의 값은 반환 값인 ToString()이 됩니다. WCF 메서드가 기본 클래스에서 반환 값을 가져올 때 사용자 지정 클래스를 반환하는 경우 이를 문자열로 직렬화를 해제하므로 데이터의 XML 표현을 얻게 됩니다.

object QueryResultsObject – 이 속성에는 메서드 호출에서 반환하는 결과의 개체 표현이 포함되어 있습니다. 이는 컨트롤을 프로그래밍 방식으로 사용하는 경우에 유용합니다. 예를 들어 컨트롤을 사용하여 ASP.NET 캐시에 저장하거나 SharePoint 타이머 작업에서 사용할 데이터를 가져오는 경우 QueryResultsObject 속성에는 WCF 메서드 호출을 통해 반환되는 항목이 포함되어 있습니다. 사용자 지정 클래스인 경우 이 속성의 결과를 이를 사용할 적절한 클래스 유형에 캐스팅하면 됩니다.

DataOutputType OutputType – OutputType 속성은 열거형이며 Page, ServerCache, Both 또는 None 같은 네 개의 값 중 하나일 수 있습니다. 컨트롤을 레이아웃 페이지에서 사용하는 상황에서 웹 파트러 결과를 렌더링하려는 경우 OutputType은 Page 또는 Both여야 합니다. 데이터를 가져오고 ASP.NET 캐시에 저장되도록 하려는 경우에는 ServerCache나 Both를 사용해야 합니다. 참고: 결과를 캐시에 저장하는 경우 QueryResultsObject만 저장됩니다. Both는 데이터를 렌더링하고 이를 ASP.NET 캐시에 저장하는 작업을 모두 수행합니다. SharePoint 타이머 작업에서처럼 컨트롤을 프로그래밍 방식으로 사용하는 경우에는 이 속성을 None으로 설정하면 됩니다. 이는 ExecuteRequest 메서드를 호출한 후 QueryResultsString 또는 QueryResultsObject만 읽기 때문입니다. 이 속성은 CASI 키트 웹 파트를 사용하여 쿼리 문자열을 통해 설정할 수 있습니다.

string ServerCacheName – OutputType을 ServerCache 또는 Both로 선택한 경우에는 ServerCacheName 속성을 비어 있지 않은 문자열 값으로 설정해야 하며 그렇지 않으면 예외가 발생합니다. 이는 ASP.NET 캐시에 결과를 저장하는 데 사용되는 키입니다. 예를 들어 ServerCacheName 속성이 “MyFooProperty”가 되도록 설정하는 경우 ExecuteRequest 메서드를 호출한 후 HttpContext.Current.Cache["MyFooProperty"]를 참조하여 WCF 응용 프로그램에서 반환된 개체를 가져올 수 있습니다. 이 속성은 CASI 키트 웹 파트를 사용하여 쿼리 문자열을 통해 설정할 수 있습니다.

int ServerCacheTime – 이 속성은 ASP.NET 캐시에 추가된 항목을 유지해야 하는 시간(분)입니다. OutputType 속성을 ServerCache 또는 Both로 설정하는 경우에는 이 속성도 0이 아닌 값으로 설정해야 하며 그렇지 않으면 예외가 발생합니다. 이 속성은 CASI 키트 웹 파트를 사용하여 쿼리 문자열을 통해 설정할 수 있습니다.

bool DecodeResults – 이 속성은 WCF 응용 프로그램에서 HtmlEncoded 처리된 결과를 반환하는 경우에 대비하여 제공되는 것입니다. 이 속성을 true로 설정하면 결과에 HtmlDecoding이 적용됩니다. 대부분의 경우 이는 필요하지 않습니다. 이 속성은 CASI 키트 웹 파트를 사용하여 쿼리 문자열을 통해 설정할 수 있습니다.

string SharePointClaimsSiteUrl – 이 속성은 주로 SharePoint 타이머 작업 같이 HTTP 요청을 벗어나 컨트롤을 프로그래밍 방식으로 만드는 시나리오를 위해 제공됩니다. 기본적으로 웹 파트를 통해 요청이 발생하면 기본 클래스에서는 WCF 호출에 대한 사용자 토큰을 제공하기 위해 현재 사이트의 URL을 사용하여 SharePoint STS 끝점에 연결하게 됩니다. 하지만 컨트롤을 프로그래밍 방식으로 만든 상황에서 HTTP 컨텍스트가 없는 경우에는 이 속성을 클레임 보안 SharePoint 사이트의 URL로 설정할 수 있으며 그러면 이 사이트는 SharePoint STS에 액세스하는 데 사용됩니다. 따라서 예를 들어 여러분은 레이아웃 페이지를 호출할 때 항상 HTTP 컨텍스트가 있으므로 레이아웃 페이지의 컨트롤 태그에서 이 속성을 설정할 필요가 없어야 합니다.

bool AllowQueryStringOverride – 관리자는 이 속성을 사용하여 레이아웃 페이지에서 컨트롤 태그를 효과적으로 잠글 수 있습니다. AllowQueryStringOverride를 false로 설정하면 CASI 키트 웹 파트에서 전달되는 모든 쿼리 문자열 재정의 값이 무시됩니다.

string AccessDeniedMessage – 이 속성은 특정 메서드에 대해 사용자의 액세스가 거부되는 경우 CASI 키트 웹 파트에 표시되어야 하는 액세스 거부 오류 메시지입니다. 예를 들어 이 시리즈의 2부에서 설명한 것처럼 사용자의 토큰을 WCF 호출에 전달하기 때문에 모든 메서드에 “이 사용자는 Sales Managers 그룹에 속해 있어야 합니다.” 같은 PrincipalPermission 요구를 추가할 수 있습니다. 사용자가 PrincipalPermission 요구를 충족하지 못하면 WCF 호출이 실패하고 액세스 거부 오류가 발생합니다. 이 경우 웹 파트는 내용에 관계없이 액세스 거부 메시지를 표시합니다. HTML 태그를 사용하여 글꼴을 굵게 또는 빨간색으로 설정하는 등의 작업을 수행하기 위해 이 메시지에 다양한 서식을 사용할 수 있습니다(즉, <font color='red'>액세스 권한이 없습니다. 관리자에게 문의하십시오.</font>). 이 속성은 CASI 키트 웹 파트를 사용하여 쿼리 문자열을 통해 설정할 수 있습니다.

string TimeoutMessage – 이 속성은 WCF 메서드 호출을 실행하려고 할 때 시간 제한 오류가 발생하는 경우 CASI 키트 웹 파트에 표시되는 메시지입니다. 이 속성에서도 글꼴을 굵게 또는 빨간색으로 설정하는 등의 다양한 서식을 지원합니다. 이 속성은 CASI 키트 웹 파트를 사용하여 쿼리 문자열을 통해 설정할 수 있습니다.

단일 게시물로는 좀 길다는 점은 인정하지만 이 부분에 CASI 키트의 가장 중요한 글루 코드가 있기 때문에 아마 시리즈에서 가장 긴 부분이 될 것입니다. 다음 게시물에서는 이 단계에서 개발한 사용자 지정 컨트롤과 레이아웃 페이지를 사용하여 WCF 응용 프로그램의 데이터를 렌더링하도록 CASI 키트에 포함된 웹 파트에 대해 설명하겠습니다.

아울러 이 게시물에는 제가 만든 Visual Studio 2010 프로젝트 예제가 들어 있는 zip 파일을 첨부했습니다. 이 프로젝트 예제에는 CASI 키트의 기본 클래스 어셈블리, CASI 키트 기본 클래스에서 상속되는 제 사용자 지정 컨트롤 그리고 제 사용자 지정 레이아웃 페이지가 포함되어 있습니다.

이 문서는 번역된 블로그 게시물입니다. 원본 문서는 The Claims, Azure and SharePoint Integration Toolkit Part 3를 참조하십시오.