SHBLITZ.NET

ASP.NET에서 파라미터 값을 암호화해서 실버라이트로 넘길려고 했습니다.
그리서 C#에서 많이 사용하는 RijndaelManaged 클래스를 사용할려고 하니 이런.. 헉!!~~
아니 실버라이트에서 지원을 안하네요.. ㅋㅋㅋ
그래서 실버라이트에서도 지원하는 AesManaged 클래스를 사용하여 암복호화를 하였습니다.

그럼 암복호화하는 클래스를 생성하고 사용방법을 알아보도록 하겠습니다.


1. 암복호화 클래스 작성

암복호화 클래스는 실버라이트와 ASP.NET에서 별도로 하나씩 만들어 줘야 합니다.
물론 같은 소스로 그대로.. ^^ 이유는 아실거라 생각합니다..

클래스를 하나 생성합니다. 저는 MyAesManaged 라는 이름으로 클래스를 생성했습니다.
일단 상단에 필요한 네임스페이지를 추가합니다.


클래스 내용을 아래와 같이 작성해줍니다.
저는 static 클래스에 static 함수로 작성을 했습니다. 일반 함수로 작성 후 생성하여 사용하셔도 상관없습니다.

아래 파란색으로 된 PasswordKey, PasswordSalt 값은 원하는 값으로 설정을 하면됩니다.



2. ASP.NET 페이지에서 실버라이트로 넘길 데이터 암호화

저는 파라미터를 암호화해서 넘길려고 해당 클래스를 작성했습니다. 파라미터가 아닌 데이터 연동시 사용해도 좋을거 같습니다. 웹서비스를 이용해서 데이터를 가져올때 암호화해서 실버라이트로 넘기면 좋겠죠^^

아래 코드는 실버라이트로 넘기는 파라미터를 암호화해서 설정하는 코드입니다.
실버라이트의 컨트롤 이름이 slPlayer 입니다^^



3. 실버라이트에서 ASP.NET에서 넘긴 데이터를 받아 복호화

ASP.NET에서 넘긴 파라미터를 받아 복호화한 후 일반 파라미터처럼 사용하도록 설정을 하도록 하겠습니다.
파라미터는 App.xaml.cs 파일에서 받아서 초기화를 하는 방법을 선택했습니다.



이상으로 실버라이트와 ASP.NET에서 공통으로 사용할 수 있는 암복호화 클래스를 작성해보고 사용하는 방법까지 알아보았습니다. 프로젝트 하시는데 도움이 되었으면 좋겠네요^^

비주얼 스튜디오 2008이 나오면서 닷넷프레임워크 3.5 관련 자격인증도 발표되었습니다.
각 자격인증에 대한 내용은 아래 링크에서 확인하세요!!

MCTS : Microsoft Visual Studio 2008 자격별 응시 Exam

Microsoft® Expression® Web 추가 정보
이 문서에서는 Expression Web 설명서를 보완하는 정보를 제공합니다.

목차
   1. 설치 문제
      1.1 Expression Web의 시험판 버전
      1.2 2007 Microsoft Office System에서 단계별 설치
      1.3 Microsoft .NET Framework 설치 및 Microsoft ASP.NET 개발 서버 설치
   2. 알려진 문제
      2.1 FTP 지원 및 Microsoft Internet Explorer® 6
      2.2 WebDAV 지원
      2.3 Windows® Vista™에서 Expression Web 파일 확장명
      2.4 Windows Vista에서 FTP 및 WebDAV 지원
      2.5 Windows Vista에서 기본 인증 지원
      2.6 사용 가능한 도움말 항목 없음


1. 설치 문제

1.1 Expression Web의 시험판 버전
Expression Web을 설치하기 전에 먼저 Expression Web의 시험판 버전(예: Beta 또는 CTP 버전)을 제거해야 합니다.

1.2 2007 Microsoft Office System에서 단계별 설치
Expression Web을 설치하기 전에 먼저 2007 Microsoft Office System의 시험판 버전(예: Beta)을 제거해야 합니다.

1.3 Microsoft .NET Framework 설치 및 Microsoft ASP.NET 개발 서버 설치
Microsoft ASP.NET 개발 서버를 제대로 설치하려면 Expression Web을 설치하기 전에 먼저 Microsoft .NET Framework 2.0을 설치해야 합니다. Expression Web을 설치한 후 .NET Framework를 설치하면 ASP.NET 개발 서버가 설치되지 않습니다. 이 문제를 해결하려면 ASP.NET 개발 서버를 설치하십시오. 이 작업을 진행하는 동안, 실행 중인 프로그램을 닫거나 Expression Web을 설치할 때 사용한 CD 또는 네트워크 위치를 제공하라는 메시지가 표시될 수 있습니다.

2. 알려진 문제

2.1 FTP 지원 및 Microsoft Internet Explorer 6
Microsoft Internet Explorer 6이 설치된 경우 FTP를 사용하여 웹 사이트를 편집하거나 게시하면 서버 연결 오류가 발생할 수 있습니다. FTP를 사용하여 웹 사이트를 편집하려면 Internet Explorer 6 연결 모드를 수동에서 활성으로 변경하거나 Internet Explorer 7을 설치하십시오. Internet Explorer 6 연결 모드를 변경하려면 Internet Explorer의 도구 메뉴에서 인터넷 옵션을 클릭하십시오. 인터넷 옵션 대화 상자의 고급 탭에서 설정 아래의 탐색 목록에 있는 수동 FTP 사용 확인란 선택을 취소하십시오.

2.2 WebDAV 지원
WebDAV 서버에도 FrontPage Server Extensions가 설치된 경우 WebDAV 사이트에 웹 페이지를 저장하지 못할 수도 있습니다. 현재 이에 대한 해결 방법은 없습니다.

2.3 Windows Vista에서 Expression Web 파일 확장명
Windows Vista에서 파일 확장명이 보이지 않는 경우 Expression Web에서 파일을 저장하면 항상 HTM 확장명으로 저장됩니다. 이 문제를 해결하려면 Windows 탐색기에서 구성 단추를 클릭하십시오. 폴더 및 검색 옵션에서 보기를 클릭한 후 알려진 파일 형식의 파일 확장명 숨기기 확인란 선택을 취소하십시오.

2.4 Windows Vista에서 FTP 및 WebDAV 지원
Windows Vista에서 Expression Web을 사용하여 FTP 또는 WebDAV 사이트를 편집하기 어려울 수 있습니다. 현재 이에 대한 해결 방법은 없습니다.

2.5 Windows Vista에서 기본 인증 지원
Windows Vista에서 기본 인증을 사용하여 사이트를 열 때 Expression Web에서 오류가 발생할 수 있습니다. 이 문제를 해결하려면 새 레지스트리 키 및 값을 추가해야 합니다. 레지스트리의 HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters에서 이름은 BasicAuthLevel, 데이터 형식은 REG_DWORD, 값은 2인 새 키를 추가하십시오. 새 키를 추가한 후 컴퓨터를 다시 시작하십시오.

2.6 사용 가능한 도움말 항목 없음
2007 Microsoft Office System과 Expression Web의 언어 설정이 일치하지 않으면 Expression Web에서 도움말을 열 때 오류가 발생할 수 있습니다. 이 문제를 해결하려면 Expression Web 설치와 일치하도록 2007 Microsoft Office System의 언어 설정을 변경하십시오. 언어 설정에 액세스하려면 시작, 모든 프로그램, Microsoft Office, Microsoft Office 도구, Microsoft Office 2007 언어 설정을 차례로 클릭하십시오. Microsoft Office 2007 언어 설정 대화 상자의 표시 언어 탭 아래 도움말 표시 언어에서 설치된 Expression Web의 언어 버전과 일치하는 언어를 클릭하십시오.

출처 : 한국 마이크로소프트

요약:이 기사에서는 ASP.NET 웹 서비스와 Windows Communication Foundation을 비교하며, Windows Communication Foundation의 발표를 앞둔 시점에서 이미 사용 중이거나 계획 단계에 있는 ASP.NET 웹 서비스를 어떻게 처리해야 하는지에 대해 설명합니다.

ASP.NET은 웹 서비스를 빌드하기 위한 .NET Framework 클래스 라이브러리와 도구뿐만 아니라 인터넷 정보 서비스(IIS) 내에서 이러한 웹 서비스를 호스트하기 위한 기능도 제공합니다. Indigo라는 코드명의 Windows Communication Foundation은 소프트웨어 엔터티가 웹 서비스에서 사용되는 프로토콜을 포함한 모든 프로토콜을 사용하여 통신할 수 있도록 하는 .NET 클래스 라이브러리, 도구 및 호스팅 기능을 제공합니다. 이처럼 웹 서비스 빌드를 위한 더욱 새롭고 포괄적인 기술이 등장하고 있는 시점에서 ASP.NET 웹 서비스에 대한 전망을 알아보도록 하겠습니다.

이 문서에서는 두 가지 기술을 비교하고, ASP.NET 웹 서비스 응용 프로그램을 Windows Communication Foundation 응용 프로그램과 함께 사용할 수 있는 방법에 대해 설명합니다. 또한 ASP.NET 웹 서비스를 Windows Communication Foundation으로 마이그레이션하기 위한 준비 방법과 실제로 마이그레이션을 수행하는 방법을 설명합니다.

이 문서에서는 ASP.NET에서 웹 서비스를 빌드하기 위해 제공하는 기능과 Microsoft .NET용 Web Services Enhancements(WSE)를 별개로 취급합니다. WSE를 사용하여 개발된 응용 프로그램에 대한 전망은 다른 곳에서 살펴볼 것입니다.

의사 결정권자를 위한 조언

Windows Communication Foundation은 2006년 하반기에 발표될 예정입니다. Windows Communication Foundation에는 이전 기술인 ASP.NET 웹 서비스와 비교하여 중요한 몇 가지 이점이 있습니다. ASP .NET 웹 서비스를 사용하는 조직에서는 이러한 이점을 고려해야 합니다.

ASP.NET 웹 서비스 도구는 단지 웹 서비스를 빌드하기 위한 것이지만, Windows Communication Foundation은 소프트웨어 엔터티들이 서로 통신하도록 설정되어야 하는 모든 환경에서 사용할 수 있는 도구를 제공합니다. 이는 개발자가 다양한 소프트웨어 통신 시나리오를 적용하기 위해 알아야 하는 기술의 가짓수를 줄여 주며, 따라서 소프트웨어 개발 리소스 비용과 소프트웨어 개발 프로젝트를 완성하는 데 소요되는 시간도 줄여 줍니다.

웹 서비스 개발 프로젝트의 경우에도 Windows Communication Foundation은 ASP.NET 웹 서비스에서 지원하는 것보다 훨씬 많은 웹 서비스 프로토콜을 지원합니다. 이러한 프로토콜은 신뢰할 수 있는 세션과 트랜잭션을 비롯한 여러 가지 장점을 수반하는, 더욱 정교한 솔루션을 제공합니다.

Windows Communication Foundation은 ASP.NET 웹 서비스에서 지원하는 것보다 훨씬 많은 메시지 전송 프로토콜을 지원합니다. ASP.NET 웹 서비스는 HTTP(Hypertext Transfer Protocol)를 통한 메시지 전송만 지원합니다. 그러나 Windows Communication Foundation은 HTTP뿐만 아니라 TCP(Transmission Control Protocol), 명명된 파이프 및 MSMQ(Microsoft Message Queuing)를 통한 메시지 전송도 지원합니다. 더욱 중요한 사실은 Windows Communication Foundation은 추가되는 전송 프로토콜을 지원하도록 즉시 확장 가능하다는 점입니다. 따라서 Windows Communication Foundation을 사용하여 개발된 소프트웨어는 다양한 다른 소프트웨어와 함께 작동하도록 손쉽게 확장할 수 있어 잠재적 투자 수익을 높여 줍니다.

Windows Communication Foundation은 ASP.NET 웹 서비스에서 제공하는 것보다 훨씬 더 풍부한 응용 프로그램 배포 및 관리 기능을 제공합니다. ASP.NET에도 있는 구성 시스템 외에도 Windows Communication Foundation은 구성 편집기, 원하는 수의 중간 단계를 통한 송수신자 간 활동 추적, 추적 뷰어, 메시지 로깅, 많은 수의 성능 카운터 및 WMI(Windows Management Instrumentation) 지원을 제공합니다. 이처럼 풍부한 관리 도구를 사용하면 운영 비용, 실패 위험 및 실제 가동 중단 시간을 줄일 수 있습니다.

ASP.NET 웹 서비스에 대한 Windows Communication Foundation의 이러한 잠재적 이점을 고려할 때, ASP.NET 웹 서비스를 사용하고 있거나 사용할 예정인 조직에서는 다음과 같은 선택을 할 수 있습니다.

• ASP.NET 웹 서비스를 계속 사용하고 Windows Communication Foundation에서 제공하는 이점은 무시합니다. Microsoft의 현재 지원 주기 정책 하에서 ASP.NET 웹 서비스에 대한 기본 지원은 2011년까지, 확장 지원은 2016년까지 제공됩니다. 따라서 ASP.NET 웹 서비스를 계속 사용하더라도 큰 위험은 없습니다.
• 미래의 어느 시점에 Windows Communication Foundation을 채택할 의향을 갖고 ASP.NET 웹 서비스를 계속 사용합니다. 이 문서에서는 새로운 ASP.NET 웹 서비스 응용 프로그램을 미래의 Windows Communication Foundation 응용 프로그램과 함께 사용할 수 있는 가능성을 최대화하는 방법에 대해 설명합니다. 또한 Windows Communication Foundation으로 더 쉽게 마이그레이션할 수 있도록 새 ASP.NET 웹 서비스를 빌드하는 방법도 설명합니다. 그러나 서비스 보안이 중요하거나 신뢰성 또는 트랜잭션 보증이 필요하거나 사용자 지정 관리 기능을 구성해야 한다면 Windows Communication Foundation 채택을 연기하는 것은 잘못된 결정입니다. Windows Communication Foundation은 정확히 이러한 시나리오를 위해 설계되었으며, 기술에 대한 생산 라이선스는 이미 제공되고 있습니다.
• 기존 ASP.NET 웹 서비스 응용 프로그램을 계속 유지하면서 새로운 개발에는 Windows Communication Foundation을 채택합니다. 대부분의 경우 이것이 최적의 선택입니다. Windows Communication Foundation의 이점을 누리면서 이를 사용하기 위해 기존 응용 프로그램을 수정해야 하는 비용은 절약할 수 있기 때문입니다. 이 시나리오에서는 새 Windows Communication Foundation 응용 프로그램과 기존 ASP.NET 응용 프로그램이 공존할 수 있습니다. 또한 새 Windows Communication Foundation 응용 프로그램에서 기존 ASP.NET 웹 서비스를 사용할 수 있으며, Windows Communication Foundation의 ASP.NET 호환 모드를 통해 Windows Communication Foundation을 사용하여 기존 ASP.NET 응용 프로그램에 새 작업 기능을 프로그래밍할 수도 있습니다.
• Windows Communication Foundation을 채택하고 기존 ASP.NET 웹 서비스 응용 프로그램을 Windows Communication Foundation으로 마이그레이션합니다. 조직에서는 개발자들이 ASP.NET 웹 서비스에 대해 알아야 할 필요가 없도록 하기 위해 이 옵션을 선택할 수 있습니다. 그러나 최신 기술 외의 다른 기술에 대한 지원을 배제한다는 것은 비현실적이며, 따라서 이 옵션을 선택하는 이유로는 적절하지 않습니다. Windows Communication Foundation에서 제공되는 기능으로 기존 응용 프로그램이 향상되거나, 기존 ASP.NET 웹 서비스의 기능을 더욱 강력한 새 Windows Communication Foundation 응용 프로그램으로 다시 만드는 경우에만 마이그레이션을 하는 것이 좋습니다. 이 문서에서는 마이그레이션 방법에 대해 설명합니다.

기술 비교: 목적

ASP.NET 웹 서비스 기술은 SOAP(Simple Object Access Protocol) over HTTP를 통해 메시지를 송수신하는 응용 프로그램을 빌드하기 위해 개발되었습니다. 메시지의 구조는 XML 스키마를 사용하여 정의할 수 있으며 .NET 개체와 주고 받는 메시지를 용이하게 serialize할 수 있는 도구가 제공됩니다. 이 기술을 사용하면 웹 서비스를 WSDL(Web Services Description Language)로 설명하는 메타데이터를 자동으로 생성할 수 있으며, WSDL에서 웹 서비스용 클라이언트를 생성하는 보조 도구가 제공됩니다.

Windows Communication Foundation은 .NET 응용 프로그램에서 다른 소프트웨어 엔터티와 메시지를 교환할 수 있도록 하기 위한 것입니다. 기본적으로 SOAP가 사용되지만 메시지는 모든 형식을 가질 수 있으며 모든 전송 프로토콜을 통해 전달될 수 있습니다. 메시지의 구조는 XML 스키마를 사용하여 정의할 수 있으며 .NET 개체와 주고 받는 메시지를 serialize할 수 있는 다양한 옵션이 제공됩니다. Windows Communication Foundation은 이 기술을 사용하여 빌드되는 웹 서비스를 WSDL로 설명하는 메타데이터를 자동으로 생성할 수 있으며, WSDL에서 그러한 응용 프로그램을 위한 클라이언트를 생성하는 도구도 제공합니다.

기술 비교: 표준

ASP.NET 웹 서비스에서 지원되는 표준 목록은 XML Web Services Created Using ASP.NET (영문)을 참조하십시오.

Windows Communication Foundation에서 지원되는 표준에 대한 자세한 목록은 Web Services Protocols Supported in WCF (영문)를 참조하십시오.

기술 비교: 개발

ASP.NET 호환 모드

Windows Communication Foundation에는 특정 Windows Communication Foundation 응용 프로그램을 ASP.NET 웹 서비스처럼 프로그래밍하고 구성하며 동작을 모방할 수 있는 ASP.NET 호환 모드 옵션이 있습니다. 아래에서는 ASP.NET 호환 모드를 채택하는 방법에 대해 설명하며, 이러한 옵션이 정확히 어떤 효과를 내는지에 대한 자세한 정보를 제공합니다.

데이터 표현

ASP.NET으로 웹 서비스를 개발하는 경우 일반적으로 서비스에서 사용할 복합 데이터 형식을 정의하는 것부터 시작합니다. ASP.NET에서는 System.Xml.Serialization.XmlSerializer를 사용하여 .NET 개체로 표현된 데이터를 서비스와 주고 받을 XML로 변환하고 XML로 수신된 데이터를 .NET 개체로 변환합니다. 따라서 ASP.NET 서비스에서 사용할 복합 데이터 형식을 정의할 경우 System.Xml.Serialization.XmlSerializer를 통해 XML로 또는 XML에서 serialize할 수 있는 .NET 클래스에 대한 정의가 필요합니다. 물론 이러한 클래스를 수동으로 작성하거나 명령줄 XML 스키마/데이터 형식 지원 유틸리티인 xsd.exe를 사용하여 XML 스키마의 형식 정의에서 생성할 수 있습니다.

System.Xml.Serialization.XmlSerializer를 통해 XML로, 또는 XML에서 serialize할 수 있는 .NET 클래스의 정의에 대해 알아야 하는 주요 사항은 다음과 같습니다.

• .NET 개체의 공용 필드와 속성만 XML로 변환됩니다.
• 클래스에서 IEnumerable 또는 ICollection 인터페이스를 구현하는 경우에만 컬렉션 클래스의 인스턴스를 serialize할 수 있습니다.
• 그 결과 System.Collections.Hashtable과 같은 System.Collections.IDictionary 인터페이스를 구현하는 클래스는 XML로 serialize할 수 없습니다.
• 클래스의 인스턴스가 XML로 표현되는 방식을 정확히 제어하기 위해 System.Xml.Serialization 네임스페이스의 많은 특성 형식을 .NET 클래스 및 그 구성원에 추가할 수 있습니다.

Windows Communication Foundation 응용 프로그램 개발 역시 대개 복합 형식을 정의하는 것부터 시작합니다. Windows Communication Foundation은 ASP.NET 웹 서비스와 같은 .NET 형식을 사용하도록 만들 수 있지만 더 나은 다른 방법이 제공됩니다.

Windows Communication Foundation System.Runtime.Serialization 어셈블리의 System.Runtime.Serialization.DataContract 및 System.Runtime.Serialization.DataMember 특성을 .NET 형식에 추가하여 해당 형식의 인스턴스가 XML로 serialize된다는 점을 표시하고 이 형식에서 serialize되는 특정 필드 또는 속성을 표시할 수 있습니다. 다음의 세 가지 예제는 모두 유효합니다.

System.Runtime.Serialization.DataContract 특성은 형식의 필드 또는 속성을 0개 이상 serialize한다고 표시하지만 System.Runtime.Serialization.DataMember 특성은 특정 필드 또는 속성을 serialize한다고 표시합니다. System.Runtime.Serialization.DataContract 특성은 클래스 또는 구조체에 적용될 수 있습니다. System.Runtime.Serialization.DataMember 특성은 필드 또는 속성에 적용될 수 있으며, 이 특성이 적용되는 필드 및 속성은 공개 필드 및 속성이거나 개인 필드 및 속성일 수 있습니다. System.Runtime.Serialization.DataContract 특성을 가진 형식의 인스턴스는 Windows Communication Foundation 용어로 데이터 계약이라고 합니다. 이러한 인스턴스는 Windows Communication Foundation의 System.Runtime.Serialization.DataContractFormatter를 사용하여 XML로 serialize됩니다.

System.Runtime.Serialization.DataContractFormatter, System.Runtime.Serialization.DataContract, System.Runtime.Serialization.DataMember 특성은 System.Xml.Serialization.XmlSerializer와, 그리고 System.Xml.Serialization 네임스페이스의 다양한 특성과 어떻게 다를까요? 중요한 차이점이 많이 있습니다.

1. System.Xml.Serialization.XmlSerializer와 System.Xml.Serialization 네임스페이스의 특성은 XML 스키마에 정의된 유효 형식에 .NET 형식을 매핑할 수 있도록 디자인되었으므로 .NET 형식의 XML 표현 방식을 매우 정확하게 제어할 수 있습니다. System.Runtime.Serialization.DataContractFormatter, System.Runtime.Serialization.DataContract, System.Runtime.Serialization.DataMember 특성은 .NET 형식의 XML 표현 방식에 대한 제어를 극히 제한적으로 제공합니다. 형식 및 해당 필드 또는 속성을 XML로 표현하는 데 사용되는 네임스페이스와 이름, 그리고 필드와 속성이 XML로 나타나는 순서만 지정할 수 있습니다.
   
   
   [DataContract(
   Namespace="urn:Woodgrove:2006:January:29",
   Name="LineItem")]
   public class LineItem
   {
       [DataMember(Name="ItemNumber",IsRequired=true,Order=0)]
       public string itemNumber;
       [DataMember(Name="Quantity",IsRequired=false,Order = 1)]
       public decimal quantity;
       [DataMember(Name="Price",IsRequired=false,Order = 2)]
       public decimal unitPrice;
   }

   .NET 형식을 표현하는 데 사용되는 XML 구조에 관한 다른 모든 요소는 System.Runtime.Serialization.DataContractFormatter로 결정됩니다.

2. .NET 형식을 XML로 표현하는 방식에 대해 많은 제어를 허용하지 않기 때문에 System.Runtime.Serialization.DataContractFormatter에 대해 serialize 프로세스의 예측이 매우 쉽고, 따라서 최적화가 더 용이합니다. 결과적으로 System.Runtime.Serialization.DataContractFormatter 디자인의 실질적 이점은 약 10% 정도의 성능 향상에 있습니다.
3. 다음의 두 형식을 비교해 보십시오. 아래의 첫 번째 형식에는 System.Xml.Serialization.XmlSerializer에 의한 serialize 특성이 있습니다.
   
   
   [Serializable]
   [XmlRoot(Namespace="urn:Woodgrove:2006:January:29")]
   public class LineItem
   {
       public string ItemNumber;
       public decimal Quantity;
       public decimal UnitPrice;
   }

   아래의 두 번째 형식에는 System.Runtime.Serialization.DataContractFormatter에서 사용하는 특성이 있습니다.

   [DataContract(Namespace="urn:Woodgrove:2006:January:29")]
   public class LineItem
   {
       [DataMember]
       public string ItemNumber;
       [DataMember]
       public decimal Quantity;
       [DataMember]
       public decimal UnitPrice;
   }
   
   System.Xml.Serialization.XmlSerializer에서 사용하는 특성은 XML로 serialize될 형식의 필드 또는 속성을 표시하지 않지만, System.Runtime.Serialization.DataContractFormatter에서 사용하는 System.Runtime.Serialization.DataMember 특성은 serialize될 필드 또는 속성을 명시적으로 보여 줍니다. 따라서 데이터 계약은 응용 프로그램에서 송수신할 데이터의 구조에 관한 명시적 계약이라고도 할 수 있습니다.
4. System.Xml.Serialization.XmlSerializer는 .NET 개체의 공개 구성원만 XML로 변환할 수 있지만 System.Runtime.Serialization.DataContractFormatter는 .NET 개체의 구성원에 대한 액세스 한정자와 관계없이 이러한 구성원을 XML로 변환할 수 있습니다.
5. 형식의 비공개 구성원을 XML로 serialize할 수 있기 때문에 System.Runtime.Serialization.DataContractFormatter에는 XML로 serialize할 수 있는 .NET 형식의 다양성에 대한 제한이 더 적습니다. 특히 Systems.Collections.IDictionary 인터페이스를 구현하는 System.Collections.Hashtable과 같은 XML 형식으로 변환할 수 있습니다. 일반적으로 System.Runtime.Serialization.DataContractFormatter는 형식의 정의를 수정하거나 형식을 위한 래퍼를 개발하지 않고도 기존 .NET 형식의 인스턴스를 serialize할 수 있는 가능성이 훨씬 더 높습니다.
6. 그러나 System.Runtime.Serialization.DataContractFormatter가 형식의 비공개 구성원에 액세스할 수 있다는 점에 기인한 또 다른 결과는 System.Xml.Serialization.XmlSerializer와 달리 완전 신뢰가 필요하다는 점입니다.
7. System.Runtime.Serialization.DataContractFormatter는 버전 관리를 위한 일부 지원을 통합하고 있습니다.
   • System.Runtime.Serialization.DataMember 특성에는 IsRequired 속성이 있습니다. 이 속성에는 새 버전의 데이터 계약에 추가된, 이전 버전에는 없었던 구성원에 대해 false 값을 지정할 수 있기 때문에 새 버전의 데이터 계약이 있는 응용 프로그램에서 이전 버전을 처리할 수 있습니다.
   • 데이터 계약에서 간단한 System.Runtime.Serialization.IExtensibleDataObject 인터페이스를 구현하도록 함으로써 System.Runtime.Serialization.DataContractFormatter가 새 버전의 데이터 계약에 정의된 구성원을 이전 버전의 데이터 계약을 사용하는 응용 프로그램을 통해 전달하도록 허용할 수 있습니다.

이러한 모든 차이점에도 불구하고 System.Xml.Serialization.XmlSerializer에서 기본적으로 형식을 serialize하는 XML은 해당 XML에 대한 네임스페이스가 명시적으로 정의되어 있는 경우 System.RuntimeSerialization.DataContractFormatter에서 형식을 serialize하는 XML과 의미상 동일합니다. 따라서 다음과 같이 두 serializer에서 사용하는 특성을 가지고 있는 클래스는 System.Xml.Serialization.XmlSerializer와 System.RuntimeSerialization.DataContractFormatter에서 의미상 동일한 XML로 변환됩니다.

Windows Communication Foundation을 포함하고 있는 소프트웨어 개발 키트에는 서비스 모델 메타데이터 도구라고 하는 svcutil.exe 명령줄 도구가 있습니다. svcutil.exe는 ASP.NET 웹 서비스에서 사용되는 xsd.exe 도구와 마찬가지로 XML 스키마에서 .NET 데이터 형식의 정의를 생성할 수 있습니다. System.Runtime.Serialization.DataContractFormatter에서 XML 스키마에 의해 정의된 형식의 XML을 내보낼 수 있으면 이러한 .NET 데이터 형식은 데이터 계약이 됩니다. 그렇지 않으면 이러한 형식은 System.Xml.Serialization.XmlSerializer를 통해 seriallize됩니다. 또한 svcutil.exe 도구와 /dataContractOnly 스위치를 사용하여 데이터 계약에서 XML 스키마를 생성할 수도 있습니다.

ASP.NET 웹 서비스에서 System.Xml.Serialization.XmlSerializer를 사용하고, Windows Communication Foundation의 ASP.NET 호환 모드를 통해 Windows Communication Foundation 서비스에서 ASP.NET 웹 서비스의 동작을 모방하는 경우에도 ASP.NET 호환 옵션에서 System.Xml.Serialization.XmlSerializer를 사용하도록 제한되지는 않습니다. ASP.NET 호환 모드에서 실행하는 서비스에서 System.Runtime.Serialization.DataContractFormatter도 계속 사용할 수 있습니다.

서비스 개발

다음 예에서 볼 수 있는 것처럼, ASP.NET을 사용하여 서비스를 개발하는 통상적인 방법은 단순히 클래스에 System.Web.Services.WebService 특성을, 서비스의 작업이 되는 해당 클래스의 메서드에 System.Web.Services.WebMethod 특성을 추가하는 것입니다.

ASP.NET 2.0에서는 다음과 같이 클래스가 아니라 인터페이스에 System.Web.Services.WebService 및 System.Web.Services.WebMethod 특성을 추가하고 해당 인터페이스를 구현하는 클래스를 작성하는 옵션이 새로 제공됩니다.

System.Web.Services.WebService 특성을 가진 인터페이스는 서비스에 의해 수행되는 작업에 대한 계약을 설정하며, 같은 계약을 다른 방식으로 구현하는 다양한 클래스에서 동일한 서비스를 다시 사용할 수 있으므로 이 옵션을 사용하는 것이 좋습니다.

Windows Communication Foundation 서비스는 Windows Communication Foundation 끝점을 하나 이상 정의함으로써 제공됩니다. 끝점은 주소, 바인딩 및 서비스 계약으로 정의됩니다. 주소는 서비스가 있는 위치를 정의합니다. 바인딩은 서비스와 통신하는 방법을 지정합니다. 서비스 계약은 서비스에서 수행할 수 있는 작업을 정의합니다.

일반적으로 서비스 계약은 다음과 같이 .NET 인터페이스에 System.ServiceModel.ServiceContract와 System.ServiceModel.OperationContract 특성을 추가함으로써 처음으로 정의됩니다.

System.ServiceModel.ServiceContract 특성은 인터페이스에서 Windows Communication Foundation 서비스 계약을 정의하도록 지정하고, System.ServiceModel.OperationContract 특성은 서비스 계약의 작업을 정의하는 인터페이스의 메서드가 있는 경우 해당 메서드를 나타냅니다.

서비스 계약은 일단 정의되면 다음과 같이 클래스가 서비스 계약을 정의하는 인터페이스를 구현하도록 함으로써 클래스에서 구현됩니다.

서비스 계약을 구현하는 클래스는 Windows Communication Foundation 용어로 서비스 형식이라고 합니다.

다음 단계는 주소와 바인딩을 서비스 형식과 연결하는 것입니다. 이 작업은 일반적으로 파일을 직접 편집하거나 Windows Communication Foundation에서 제공되는 구성 편집기를 사용하여 구성 파일에서 수행됩니다. 다음은 구성 파일 예제입니다.

바인딩은 응용 프로그램과 통신하기 위한 프로토콜 집합을 지정합니다. 다음과 같이 일반 옵션을 나타내는 미리 정의된 여러 가지 바인딩이 있습니다.

이름	목적
BasicHttpBinding	WS-Basic Profile 1.1과 Basic Security Profile 1.0을 지원하는 웹 서비스 및 클라이언트와의 상호 운용성
WSHttpBinding	HTTP를 통한 WS-* 프로토콜을 지원하는 웹 서비스 및 클라이언트와의 상호 운용성
WSDualHttpBinding	이중 HTTP 통신(초기 메시지의 수신자가 초기 송신자에게 직접 응답하지 않고, 일정 기간에 걸쳐 WS-* 프로토콜을 따르는 HTTP를 통해 원하는 수의 응답을 전송할 수 있음)
WSFederationBinding	HTTP 통신(명시적으로 식별된 자격 증명 제공자가 발행한 자격 증명에 따라 서비스의 리소스에 대한 액세스를 제어할 수 있음)
NetTcpBinding	Windows Communication Foundation 소프트웨어 엔터티 간의 네트워크를 통한 안전하고 신뢰성 있는 고성능 통신
NetNamedPipeBinding	같은 컴퓨터에 있는 Windows Communication Foundation 소프트웨어 엔터티 간의 안전하고 신뢰할 수 있는 고성능 통신
NetMsmqBinding	Windows Communication Foundation 소프트웨어 엔터티 간의 MSMQ를 통한 통신
MsmqIntegrationBinding	Windows Communication Foundation 소프트웨어 엔터티와 다른 소프트웨어 엔터티 간의 MSMQ를 통한 통신
NetPeerTcpBinding	Windows Communication Foundation 소프트웨어 엔터티 간의 피어-투-피어 네트워킹을 통한 통신

미리 정의된 바인딩인 System.ServiceModel.BasicHttpBinding은 ASP.NET 웹 서비스에서 지원되는 프로토콜 집합을 통합하고 있습니다.

Windows Communication Foundation 응용 프로그램용 사용자 지정 바인딩은 Windows Communication Foundation에서 개별 프로토콜을 구현하는 데 사용하는 바인딩 요소 클래스들의 컬렉션으로 간단히 정의할 수 있습니다. 새 바인딩 요소를 작성하여 추가 프로토콜을 나타낼 수 있습니다.

서비스 형식의 내부 동작은 behaviors라는 클래스 모음의 속성을 사용하여 조정할 수 있습니다. 다음 예제에서는 System.ServiceModel.ServiceBehavior 클래스를 사용하여 서비스 형식이 멀티스레드 형식이 되도록 지정합니다.

System.ServiceModel.ServiceBehavior와 같이 프로그래머가 설정할 수 있는 속성이 있는 일부 동작은 특성입니다. 관리자가 설정할 수 있는 속성이 있는 다른 동작은 응용 프로그램의 구성에서 수정할 수 있습니다.

서비스 형식 프로그래밍에서는 System.ServiceModel.OperationContext 클래스가 자주 사용됩니다. 이 클래스의 정적 Current 속성은 작업이 실행되고 있는 컨텍스트에 대한 정보로의 액세스를 제공합니다. 따라서 System.ServiceModel.OperationContext는 System.Web.HttpContext 및 System.EnterpriseServices.ContextUtil 클래스 모두와 비슷합니다.

호스팅

ASP.NET 웹 서비스는 클래스 라이브러리 어셈블리로 컴파일됩니다. 확장명이 .asmx인 서비스 파일이라는 파일이 제공됩니다. 이 파일에는 서비스에 대한 코드를 포함하고 있는 클래스 및 이 클래스가 있는 어셈블리를 식별하는 @ WebService 지시문이 있습니다.

서비스 파일은 IIS의 ASP.NET 응용 프로그램 루트에 복사되며, 어셈블리는 이 응용 프로그램 루트의 \bin 하위 디렉터리에 복사됩니다. 그런 다음 응용 프로그램 루트에 있는 서비스 파일의 URL(Uniform Resource Locator)을 통해 이 응용 프로그램에 액세스할 수 있습니다.

Aaron Skonnard는 자신의 칼럼 (영문)에서 .NET Framework 2.0에서 제공되는 HttpListener 클래스를 사용하여 어떤 .NET 응용 프로그램에서든 IIS 외부에서 ASP.NET 웹 서비스를 호스트하는 방법에 대해 설명했습니다. 그러나 Skonnard는 이를 위한 작업은 '간단하지 않다'고 설명하고 있습니다. (영문)

Windows Communication Foundation 서비스는 IIS 5.1이나 6.0, IIS 7의 일부로 제공될 WAS(Windows Activation Service), 그리고 모든 .NET 응용 프로그램 내에서 즉시 호스트가 가능합니다. IIS 5.1 또는 6.0에서 서비스를 호스트하려면 이 서비스가 HTTP를 통신 전송 프로토콜로 사용해야 합니다.

IIS 5.1, IIS 6.0 또는 WAS에서 서비스를 호스트하려면 다음 단계를 따릅니다.

1. 서비스 형식을 클래스 라이브러리 어셈블리로 컴파일합니다.
2. 다음과 같은 서비스 형식을 식별하는 @ ServiceHost 지시문을 포함하는 서비스 파일을 확장명 .svc로 만듭니다.
   
   
   <%@ServiceHost language="c#" Service="MyService" %>
   
   
3. 서비스 파일을 가상 디렉터리에 복사하고 어셈블리를 이 가상 디렉터리의 \bin 하위 디렉터리에 복사합니다.
4. 구성 파일을 가상 디렉터리에 복사하고 파일 이름을 Web.config로 지정합니다.

그러면 응용 프로그램 루트에 있는 서비스 파일의 URL을 통해 해당 응용 프로그램에 액세스할 수 있습니다.

.NET 응용 프로그램에서 Windows Communication Foundation 서비스를 호스트하려면 서비스 형식을 이 응용 프로그램에서 참조하는 클래스 라이브러리 어셈블리로 컴파일하고, Windows Communication Foundation의 System.ServiceModel.ServiceHost 클래스를 사용하여 해당 서비스를 호스트하는 응용 프로그램을 프로그래밍합니다. 다음은 필요한 간단한 프로그래밍 예제입니다.

이 예제에서는 Windows Communication Foundation System.ServiceModel.ServiceHost 생성에서 하나 이상의 전송 프로토콜에 대한 주소가 지정되는 방식을 보여 줍니다. 이러한 주소를 기준 주소라고 합니다.

Windows Communication Foundation 서비스의 끝점에 제공되는 주소는 끝점의 호스트에 대한 기준 주소를 기준으로 하는 상대 주소입니다. 호스트에는 통신 전송 프로토콜당 하나의 기준 주소가 있을 수 있습니다. 끝점의 주소는 호스트의 기준 주소 중 끝점의 통신 전송 프로토콜에 대한 기준 주소의 상대 주소입니다. 위에 있는 구성 파일의 예제에서 끝점으로 선택된 System.ServiceModel.BasicHttpBinding은 HTTP를 전송 프로토콜로 사용하므로 EchoService 끝점의 주소는 호스트의 HTTP 기준 주소의 상대 주소입니다. 위 예제에서 호스트의 경우 HTTP 기준 주소는 http://www.woodgrove.com:8000/입니다. IIS 또는 WAS에서 호스트되는 서비스의 기준 주소는 해당 서비스에 대한 서비스 파일의 URL입니다.

IIS 또는 WAS에서 호스트되고 전송 프로토콜로 HTTP만 사용하도록 구성된 서비스만 Windows Communication Foundation의 ASP.NET 호환 모드 옵션을 사용하도록 만들 수 있습니다. 이 옵션을 사용하려면 다음의 두 단계가 필요합니다.

1. 프로그래머는 다음과 같이 System.ServiceModel.AspNetCompatbilityRequirements 특성을 서비스 형식에 추가하여 ASP.NET 호환 모드가 허용되는지 또는 필수인지 지정해야 합니다.
   
   
   [System.ServiceModel.AspNetCompatibilityRequirements(
           RequirementsMode=AspNetCompatbilityRequirementsMode.Require)]
   public class DerivativesCalculatorServiceType: IDerivativesCalculator
   
   
2. 관리자는 다음과 같이 ASP.NET 호환 모드를 사용하도록 응용 프로그램을 구성해야 합니다.
   
   
   <configuration>
      <system.serviceModel>
         <services>
            [...]
         </services>
   <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
      </system.serviceModel>
   </configuration>

또한 Windows Communication Foundation 응용 프로그램은 서비스 파일의 확장명을 .svc가 아닌 .asmx를 사용하도록 구성할 수 있습니다.

이 옵션을 사용하면 Windows Communication Foundation을 사용하도록 서비스를 수정할 때 .asmx 서비스 파일의 URL을 사용하도록 구성된 클라이언트를 수정하지 않아도 됩니다.

클라이언트 개발

ASP.NET 웹 서비스용 클라이언트는 .asmx 파일의 URL을 입력으로 제공하는 wsdl.exe 명령줄 도구를 사용하여 생성됩니다. Windows Communication Foundation에서 제공되는 이와 유사한 도구는 svcutil.exe입니다. 이 도구는 서비스 계약과 프록시 클래스에 대한 정의를 포함한 코드 모듈을 생성합니다. 또한 서비스의 주소와 바인딩을 포함한 구성 파일도 생성합니다.

원격 서비스의 클라이언트를 프로그래밍할 때 일반적으로 비동기 패턴에 따라 프로그래밍하는 것이 좋습니다. wsdl.exe 도구로 생성되는 코드는 기본적으로 항상 동기 패턴과 비동기 패턴을 모두 제공합니다. svcutil.exe 도구로 생성되는 코드는 둘 중 한 패턴을 제공할 수 있습니다. 이 도구는 기본적으로 동기 패턴을 제공합니다. 이 도구를 /async 스위치와 함께 실행하면 생성된 코드에서 비동기 패턴을 제공합니다.

ASP.NET의 wsdl.exe 도구로 생성되는 프록시 클래스의 이름이 기본적으로 Windows Communication Foundation의 svcutil.exe 도구로 생성되는 프록시 클래스의 이름과 일치할 것이라는 보장은 없습니다. 특히 System.Xml.Serialization.XmlSerializer를 사용하여 serialize되어야 하는 클래스의 속성 이름에는 기본적으로 svcutil.exe 도구로 생성되는 코드에서 Property 접미사가 제공되지만 wsdl.exe 도구에서는 그렇지 않습니다.

메시지 표현

ASP.NET 웹 서비스에서 송수신되는 SOAP 메시지 헤더는 사용자 지정할 수 있습니다. System.Web.Services.Protocols에서 클래스가 파생되어 헤더의 구조가 정의된 다음 System.Web.Services.SoapHeader 특성이 헤더의 존재를 나타내는 데 사용됩니다.

Windows Communication Foundation에서는 다음과 같이 System.ServiceModel.MessageContract, System.ServiceModel.MessageHeader, System.ServiceModel.MessageBody 특성을 제공하여 서비스에서 송수신되는 SOAP 메시지의 구조를 설명합니다.


이 구문은 메시지 구조의 명시적인 표현을 나타내지만 메시지의 구조는 ASP.NET 웹 서비스 코드로 암시될 뿐입니다. 또한 ASP.NET 구문에서는 메시지 헤더가 위 예제의 ProtocolHeader 속성과 같은 서비스 속성으로 나타나지만 Windows Communication Foundation 구문에서는 메시지 속성으로 더욱 정확하게 나타납니다. Windows Communication Foundation에서는 끝점 구성에 메시지 헤더를 추가할 수도 있습니다.

이 옵션을 사용하면 클라이언트 또는 서비스에 대한 코드에서 기반 프로토콜 헤더를 참조할 필요가 없습니다. 끝점 구성 방식에 의해 헤더가 메시지에 간단히 추가됩니다.

서비스 설명

wsdl 쿼리를 사용하여 ASP.NET 웹 서비스의 .asmx 파일에 대해 HTTP GET 요청을 발행하면 ASP.NET에서 해당 서비스를 설명하는 WSDL을 생성하게 됩니다. 이 WSDL이 요청에 대한 응답으로 반환됩니다.

ASP.NET 2.0을 통해 서비스가 WS-I(Web Services-Interoperability Organization) Basic Profile 1.1과 호환되는지 확인하고 서비스가 WSDL과 호환된다는 문구를 넣을 수 있게 되었습니다. 다음과 같이 System.Web.Services.WebServiceBinding 특성의 ConformsTo와 EmitConformanceClaims 매개 변수를 사용하면 됩니다.

ASP.NET에서 서비스에 대해 생성하는 WSDL은 사용자 지정할 수 있습니다. System.Web.Services.Description.ServiceDescriptionFormatExtension의 하위 클래스를 만들어 WSDL에 항목을 추가함으로써 사용자 지정할 수 있습니다.

IIS 5.1, 6.0 또는 WAS에서 호스트되는 HTTP 끝점이 있는 Windows Communication Foundation 서비스의 .svc 파일에 대해 wsdl 쿼리를 사용하여 HTTP GET 요청을 발행하면 Windows Communication Foundation에서 해당 서비스를 설명하는 WSDL로 응답하게 됩니다. .NET 응용 프로그램에서 호스트되는 서비스의 HTTP 기준 주소에 대해 wsdl 쿼리를 사용하여 HTTP GET 요청을 발행해도 같은 효과가 있습니다.

Windows Communication Foundation은 WS-MetadataExchange 요청에 대해서도 서비스를 설명하기 위해 생성하는 WSDL로 응답합니다. ASP.NET 웹 서비스는 WS-MetadataExchange 요청에 대한 지원을 기본적으로 제공하지 않습니다.

Windows Communication Foundation에서 생성하는 WSDL은 광범위하게 사용자 지정할 수 있습니다. System.ServiceModel.ServiceMetadataBehavior 클래스는 WSDL을 사용자 지정하기 위한 몇 가지 기능을 제공하며 System.ServiceModel.Design.IWsdlExporter 구현을 개발하여 완벽하게 제어할 수 있습니다. 또한 다음과 같이 WSDL을 생성하지 않고 지정된 URL에서 정적 WSDL 파일을 사용하도록 Windows Communication Foundation을 구성할 수도 있습니다.

예외 처리

ASP.NET 웹 서비스에서는 처리되지 않는 예외는 클라이언트에 SOAP 오류로 반환됩니다. 또한 System.Web.Services.Protocols.SoapException 클래스의 인스턴스를 명시적으로 발생시켜 클라이언트에 전송되는 SOAP 오류의 내용에 대한 제어 범위를 넓힐 수 있습니다.

Windows Communication Foundation 서비스에서는 중요한 정보가 예외를 통해 우발적으로 노출되지 않도록, 처리되지 않은 예외가 클라이언트에 SOAP 오류로 반환되지 않습니다. 디버깅을 위해 처리되지 않은 예외가 클라이언트에 반환되도록 하는 구성 설정이 제공됩니다.

Windows Communication Foundation 프로그래머는 의도적으로 클라이언트에 SOAP 오류를 반환하기 위해 generic 형식의 System.ServiceModel.FaultException<T> 인스턴스를 발생시킬 수 있습니다. 여기서 T는 데이터 계약이어야 합니다. 또한 프로그래머는 다음과 같이 System.ServiceModel.FaultContract 특성을 작업에 추가하여 작업에서 발생할 수도 있는 오류를 지정할 수 있습니다.

이렇게 하면 가능한 오류가 서비스에 대한 WSDL에 알려지기 때문에 클라이언트 프로그래머가 작업에서 발생할 수 있는 오류를 정확히 예상하고 다음과 같이 적절한 catch 문을 작성할 수 있습니다.

상태 관리

ASP.NET 웹 서비스를 구현하는 데 사용되는 클래스는 다음과 같이 System.Web.Services.WebService에서 파생될 수 있습니다.

이러한 경우 System.Web.Services.WebService 기본 클래스의 Context 속성을 사용하여 System.Web.HttpContext 개체에 액세스하도록 클래스를 프로그래밍할 수 있습니다. System.Web.HttpContext 개체를 사용하여 Application 속성을 통해 응용 프로그램 상태 정보를, Session 속성을 통해 세션 상태 정보를 업데이트하고 검색할 수 있습니다.

ASP.NET에서는 System.Web.HttpContext의 Session 속성을 통해 액세스되는 세션 상태 정보가 실제로 저장되는 위치를 세부적으로 제어할 수 있습니다. 세션 상태 정보는 쿠키, 데이터베이스, 현재 서버의 메모리 또는 지정된 서버의 메모리에 저장될 수 있습니다. 저장 위치는 서비스의 구성 파일에서 선택됩니다.

Windows Communication Foundation은 상태 관리를 위한 확장 가능한 개체를 제공합니다. 확장 가능한 개체는 System.ServiceModel.IExtensibleObject<T>를 구현하는 개체입니다. 가장 중요한 확장 가능한 개체는 System.ServiceModel.ServiceHostBase 및 System.ServiceModel.InstanceContext입니다. 전자를 사용하면 같은 호스트에 있는 모든 서비스 형식의 모든 인스턴스에서 액세스 가능한 상태를 유지할 수 있으며, 후자를 사용하면 서비스 형식의 같은 인스턴스 내에서 실행되는 코드로 액세스 가능한 상태를 유지할 수 있습니다.

여기서 TradingSystem 서비스 형식에는 같은 프록시 인스턴스의 모든 호출이 서비스 형식의 같은 인스턴스로 라우팅되도록 지정하는 System.ServiceModel.ServiceBehavior 특성이 있습니다.

DealData 클래스는 다음과 같이 서비스 형식의 같은 인스턴스 내에서 실행되는 코드로 액세스할 수 있는 상태를 정의합니다.


서비스 계약의 작업 중 하나를 구현하는 서비스 형식의 코드에서 DealData 상태 개체는 다음과 같이 서비스 형식의 현재 인스턴스에 대한 상태에 추가됩니다.


그런 다음 이 상태 개체는 다음과 같이 서비스 계약의 작업 중 다른 하나를 구현하는 코드로 검색 및 수정이 가능하게 됩니다.


ASP.NET에서 System.Web.HttpContext 클래스의 상태 정보가 실제로 저장되는 위치를 세부적으로 제어할 수 있지만, 적어도 초기 버전의 Windows Communication Foundation에서는 확장 가능한 개체가 저장되는 위치를 제어할 수 없습니다. 이러한 점이 Windows Communication Foundation 서비스를 위해 ASP.NET 호환 모드를 선택하는 가장 정당한 이유가 됩니다. 구성 가능한 상태 관리가 필수적인 경우 ASP.NET 호환 모드를 채택함으로써 System.Web.HttpContext 클래스의 기능을 ASP.NET에서와 똑같은 방식으로 사용할 수 있으며 System.Web.HttpContext 클래스를 통해 관리되는 상태 정보가 저장되는 위치를 구성할 수도 있습니다.

보안

ASP.NET 웹 서비스의 보안을 유지하기 위한 옵션은 대개 IIS 응용 프로그램의 보안을 유지하는 옵션과 같습니다. Windows Communication Foundation 응용 프로그램은 IIS뿐만 아니라 .NET 실행 파일 내에서도 호스트될 수 있기 때문에 Windows Communication Foundation 응용 프로그램의 보안을 유지하기 위한 옵션은 IIS의 기능에 독립적으로 만들어야 했습니다. 그러나 ASP.NET 웹 서비스에 제공되는 기능은 ASP.NET 호환 모드에서 실행되는 Windows Communication Foundation 서비스에서도 사용할 수 있습니다.

보안: 인증

IIS는 응용 프로그램에 대한 액세스를 제어하는 기능을 제공하므로 이 기능을 통해 익명 액세스 또는 Windows 인증, 다이제스트 인증, 기본 인증, .NET Passport 인증 등 다양한 모드의 인증을 선택할 수 있습니다. Windows 인증 옵션을 사용하면 ASP.NET 웹 서비스에 대한 액세스를 제어할 수 있습니다. Windows Communication Foundation 응용 프로그램이 IIS 내에서 호스트되는 경우에는 이 응용 프로그램에 대한 익명 액세스를 허용하도록 IIS를 구성하여 다양한 다른 옵션과 함께 Windows 인증을 지원하는 Windows Communication Foundation 자체에서 인증을 관리할 수 있도록 해야 합니다. 기본 제공되는 다른 옵션에는 사용자 이름 토큰, X.509 인증서, SAML 토큰 및 InfoCard가 있으며 사용자 지정 인증 메커니즘도 정의할 수 있습니다.

ASP.NET 2.0의 System.Web.HttpContext 클래스에는 특정 종류의 저장소에서 인증된 사용자에 대한 정보를 읽는 방법을 아는 System.Web.Profile.Provider 클래스를 통해 이러한 정보를 저장소에서 자동으로 검색할 수 있는 Profile 속성이 있습니다. 사용자 지정 동작에서 System.Web.Profile.Provider 클래스를 사용하여 프로필 정보를 검색할 수 있지만 이러한 ASP.NET 2.0 메커니즘은 Windows Communication Foundation에서 ASP.NET 호환 모드인 경우를 제외하면 지원되지 않습니다.

보안: 가장

ASP.NET에서는 ASP.NET 웹 서비스가 특정 사용자로, 또는 현재 요청에서 제공된 사용자의 자격 증명으로 가장할 수 있도록 하는 ID 요소를 제공합니다. 이 요소를 사용하면 ASP.NET 호환 모드에서 실행되고 있는 Windows Communication Foundation 응용 프로그램에서 가장을 구성할 수 있습니다.

Windows Communication Foundation의 구성 시스템은 가장할 특정 사용자를 지정하기 위한 자체 ID 요소를 제공합니다. 또한 Windows Communication Foundation 클라이언트 및 서비스는 가장을 위해 별도로 구성할 수 있습니다. 클라이언트는 요청을 전송할 때 현재 사용자로 가장하도록 다음과 같이 구성할 수 있습니다.

서비스 작업은 현재 요청에서 제공된 사용자의 자격 증명으로 가장하도록 다음과 같이 구성할 수 있습니다.

보안: ACL을 사용한 인증

ACL(액세스 제어 목록)을 사용하면 .asmx 파일에 대한 액세스를 제한할 수 있습니다. 그러나 Windows Communication Foundation .svc 파일에 대한 ACL은 ASP.NET 호환 모드인 경우를 제외하고는 무시됩니다.

보안: 역할 기반 인증

IIS Windows 인증 옵션을 ASP.NET 구성 언어로 제공되는 인증 요소와 함께 사용하면 사용자에게 지정된 Windows 그룹 기반의 ASP.NET 웹 서비스에 대한 역할 기반 인증을 쉽게 수행할 수 있습니다. ASP.NET 2.0에는 더 포괄적인 역할 기반 인증 메커니즘인 역할 공급자가 도입되었습니다.

모든 역할 공급자는 사용자에게 지정된 역할을 쿼리하기 위한 간단한 인터페이스를 구현하는 클래스이지만, 각 역할 공급자는 서로 다른 출처에서 해당 정보를 검색하는 방법을 인식하고 있습니다. ASP.NET 2.0은 Microsoft SQL Server 데이터베이스에서 역할 지정을 검색할 수 있는 역할 공급자와 Windows Server 2003 권한 부여 관리자에서 역할 지정을 검색할 수 있는 역할 공급자를 제공합니다.

실제로 역할 공급자 메커니즘은 Windows Communication Foundation 응용 프로그램을 포함한 모든 .NET 응용 프로그램에서 ASP.NET과 별개로 사용할 수 있습니다. 다음은 System.ServiceModel.ServiceAuthorization 동작을 통해 ASP.NET 역할 공급자를 사용하는 옵션이 선택되는 방식을 보여 주는 Windows Communication Foundation 응용 프로그램의 샘플 구성입니다.

보안: 클래임 기반 인증

Windows Communication Foundation의 가장 중요한 기술 혁신 중 하나는 클래임에 기반하여 보호되는 리소스에 대한 액세스 인증을 완벽하게 지원한다는 것입니다. 클래임은 형식, 권한 및 값으로 구성됩니다. 예를 들어 운전 면허증을 생각해 보십시오. 운전 면허증은 소지인에 대한 클래임 집합으로 구성되는데, 그 중 하나는 소지인의 생년월일입니다. 이 클래임의 형식은 생년월일이며, 값은 운전자의 생년월일입니다. 클래임이 소지인에게 부여하는 권한은 소지인이 클래임 값으로 수행할 수 있는 작업을 지정합니다. 운전자의 생년월일에 대한 클래임의 경우 권한은 단순한 소유입니다. 운전자는 해당 생년월일을 소유하고 있지만 변경하는 등의 작업은 할 수 없습니다. 역할은 단순히 클래임의 한 형식이기 때문에 클래임 기반 인증은 역할 기반 인증을 포함합니다.

클래임 기반 인증은 클래임 집합을 작업의 액세스 요구 사항과 비교하여 그 결과에 따라 작업에 대한 액세스 권한을 부여하거나 거부함으로써 수행됩니다. Windows Communication Foundation에서는 다음과 같이 System.ServiceModel.Description.ServiceAuthorizationBehavior의 ServiceAuthorizationManager 속성에 값을 다시 한 번 지정함으로써 클래임 기반 인증을 실행하는 데 사용할 클래스를 지정할 수 있습니다.

클래임 기반 인증을 실행하는 데 사용되는 클래스는 System.ServiceModel.ServiceAuthorizationManager에서 파생되어야 하며, 여기에서 다시 정의할 유일한 메서드는 AccessCheck() 메서드입니다. Windows Communication Foundation에서는 서비스의 작업이 호출될 때마다 이 메서드를 호출하여 System.ServiceModel.OperationContext 개체를 제공하며, 이 개체의 ServiceSecurityContext.AuthorizationContext 속성에는 사용자에 대한 클래임이 있습니다. 따라서 Windows Communication Foundation에서는 사용자가 인증을 위해 제공한 보안 토큰이 어떤 것이든 이 토큰으로부터 사용자에 대한 클래임을 조합하는 작업을 이미 완료한 상태이며, 이러한 클래임이 요청한 작업에 충분한지 여부를 평가하는 간단한 작업만 남게 됩니다.

Windows Communication Foundation이 어떤 종류의 보안 토큰으로든 자동으로 클래임을 조합한다는 점은 매우 중요한 혁신입니다. 클래임 기반 인증을 위한 코드를 인증 메커니즘과는 완전히 별개로 만들어 주기 때문입니다. 반면 ASP.NET에서 ACL 또는 역할을 사용하는 인증은 Windows 인증과 밀접하게 연결됩니다.

보안: 기밀성

ASP.NET 웹 서비스와 교환되는 메시지의 기밀성은 IIS의 응용 프로그램에서 HTTPS(Secure Hypertext Transfer Protocol)를 사용하도록 구성함으로써 전송 수준에서 보장할 수 있습니다. IIS에서 호스트되는 Windows Communication Foundation 응용 프로그램에 대해서도 마찬가지입니다. 한편 IIS의 외부에서 호스트되는 Windows Communication Foundation 응용 프로그램도 보안 전송 프로토콜을 사용하도록 구성할 수 있습니다. 더 중요한 것은 메시지가 WS-Security 프로토콜을 사용하여 전송되기 전에 메시지의 보안을 유지하도록 Windows Communication Foundation 응용 프로그램을 구성할 수 있다는 점입니다. WS-Security를 사용하여 메시지 본문의 보안만 유지하면 메시지가 기밀을 유지한 상태로 중간 단계를 거쳐 최종 목적지에 도달하도록 할 수 있습니다.

세계화

ASP.NET 구성 언어를 사용하면 개별 서비스의 culture를 지정할 수 있습니다. Windows Communication Foundation에서는 ASP.NET 호환 모드인 경우를 제외하고 이러한 구성 설정을 지원하지 않습니다. ASP.NET 호환 모드를 사용하지 않는 Windows Communication Foundation 서비스를 지역화하려면 서비스 형식을 culture별 어셈블리로 컴파일하고 각 culture별 어셈블리가 별도의 culture별 끝점을 갖도록 합니다.

내부 아키텍처

ASP.NET 웹 서비스

최신 ASP.NET 구현에서 HTTP 요청은 http.sys라는 Windows 커널의 HTTP 구현에서 System.Web.HttpWorkerRequest 개체 형식으로 수신됩니다. System.Web.HttpWorkerRequest 개체는 System.Web.HttpRuntime 개체에 수신되며, 이 개체는 System.Web.HttpWorkerRequest의 데이터로 System.Web.HttpContext 개체를 채웁니다. 요청은 System.Web.HttpRequest 개체인 Request 속성으로 System.Web.HttpContext 개체에 통합됩니다.

.asmx 파일로 배달된 HTTP POST 요청을 나타내는 System.Web.HttpRequest 개체는 기본적으로 System.Web.IHttpHandler 인터페이스를 구현하는 개체에 전달됩니다(Skonnard 2003, 2004). 이 개체는 System.Web.Services.Protocols.WebServiceHandlerFactory 클래스를 사용하여 만들어지며, ASP.NET 웹 서비스 요청 처리기라고도 합니다. Windows Communication Foundation은 ASP.NET 호환 모드로 구성되면 ASP.NET 웹 서비스 요청 처리기의 동작을 모방하는 System.Web.IHttpHandler의 구현을 제공합니다.

ASP.NET 웹 서비스 요청 처리기는 적어도 4가지 작업을 수행해야 합니다. 첫째, HTTP 요청에 통합된 SOAP 메시지를 개발자가 제공하는 SOAP E\extensions의 인스턴스에 전달해야 합니다(Meier, Vasireddy, Babbar 및 Mackman 2004). 둘째, 요청을 처리하기 위해 .asmx 파일에 참조된 클래스의 메서드 중 호출할 메서드를 결정해야 합니다. 셋째, 메서드에서 매개 변수로 예상하는 형식의 인스턴스로 요청이 deserialize되도록 해야 합니다. 넷째, 실제로 메서드를 호출하여 요청으로부터 deserialize한 매개 변수를 이 메서드에 전달해야 합니다.

SOAP 확장은 System.Web.Services.Protocols.SoapExtension에서 파생된 형식입니다. 이 확장은 SOAP 메시지가 처리를 위해 .asmx 파일에서 참조되는 클래스의 메서드로 전달되기 전에 요청에 있는 SOAP 메시지를 액세스하거나 수정하는 데 사용됩니다. 또한 이 확장은 응답 메시지를 액세스 및 수정할 수 있으며 서버뿐만 아니라 클라이언트에도 배포될 수 있습니다. SOAP 확장의 일반적 용도는 메시지 로깅 및 암호화입니다. SOAP 확장은 컴퓨터에 배포된 모든 서비스 또는 개별 서비스에 적용되거나, 사용자 지정 System.Web.Services.SoapExtension 특성을 사용하여 서비스의 특정 작업에 적용될 수 있습니다.

ASP.NET 웹 서비스 요청 처리기는 기본적으로 SOAPAction 헤더를 사용하여 요청을 처리하기 위해 호출할 클래스의 메서드를 결정합니다. 기본적으로 요청 처리기는 서비스의 네임스페이스와 작업의 이름 순서로 구성된 SOAPAction HTTP 헤더를 예상합니다. 서비스의 기본 네임스페이스는 http://tempuri.org/이며, 작업의 기본 이름은 해당 작업을 정의하는 메서드의 이름입니다. 다음은 HTTP 요청을 처리하는 예제입니다.

예제에서 HTTP 요청을 처리할 때 요청 처리기는 http://localhost/asmxservice/service.asmx에 있는 파일의 @_WebService 지시문에서 참조되는 클래스가 작업 이름이 Echo인 기본 네임스페이스를 가진 서비스를 정의한다고 예상합니다. 또한 이 요청 처리기는 기본적으로 해당 작업이 Echo라는 클래스의 메서드로 구현된다고 예상하며, 해당 메서드를 호출하여 요청을 처리하려고 합니다. 이러한 모든 동작은 다음과 같이 사용자 지정할 수 있습니다.

요청 처리기에서 SOAPAction HTTP 헤더를 사용하지 않고 SOAP 메시지 본문 요소의 정규화된 요소 이름을 사용하여 호출할 메서드를 식별하도록 할 수 있습니다. 앞의 HTTP 요청 예제에서 본문 요소는 다음과 같습니다.

정규화된 요소 이름은 http://tempuri.org/Echo입니다. 이 요소 이름은 SOAPAction HTTP 헤더와 같기 때문에 ASP.NET 웹 서비스 요청 처리기에서 메시지를 라우팅하는 방법을 결정하기 위해 이 이름을 어떻게 사용할 것인지는 명백합니다. 요청 처리기에서 SOAPAction HTTP 헤더가 아닌 SOAP 메시지 본문 요소의 정규화된 이름을 사용하도록 하려면 서비스를 구현하는 클래스에 System.Web.Services.Protocols.SoapDocumentService 특성을 적용하고 RequestElement를 라우팅 스타일로 지정합니다. 즉 다음과 같습니다.


또한 다음과 같이 System.Web.Services.Protocols.SoapDocumentMethod 특성의 RequestElementName 매개 변수를 사용하여 메서드 이름과는 다른 SOAP 메시지 본문 요소의 로컬 이름을 만들 수도 있습니다.

그러면 ASP.NET 웹 서비스 요청 처리기에서 SOAP 메시지 본문 요소의 로컬 이름을 메서드 이름에 직접 일치시키지 않고 해당 메서드에 적용된 System.Web.Services.Protocols.SoapDocumentMethod 특성의 RequestElementName 매개 변수 값에 일치시킵니다.

다음과 같이 System.Web.Services.WebService 특성의 Namespace 매개 변수를 사용하여 ASP.NET 웹 서비스의 네임스페이스에 대한 기본값을 수정할 수 있습니다.

여기서는 이 매개 변수의 값이 인터페이스에 적용된 System.Web.Services.WebService 특성에 대해 수정된 것으로 보이지만, 유감스럽게도 버그로 인해 실제로 매개 변수의 값을 변경해도 클래스가 아닌 인터페이스에 이 특성이 적용될 때는 아무런 효과가 없습니다.

작업 이름은 해당 작업을 구현하는 메서드의 이름과 다르게 만들 수 있습니다. 다음과 같이 System.Web.Services.WebMethod 특성의 MessageName 매개 변수 값을 지정하면 됩니다.

이 기능은 다음과 같이 ASP.NET 웹 서비스 요청 처리기의 다형적 메서드를 구별하는 데 사용할 수 있습니다.


다음과 같이 System.Web.Services.Protocols.SoapDocumentMethod 특성을 메서드에 추가하여 이 특성의 Action 매개 변수에 대한 값을 제공할 수 있습니다.

이러한 모든 메서드에 대해 ASP.NET 웹 서비스 요청 처리기는 SOAPAction HTTP 헤더를 서비스의 네임스페이스와 작업 이름으로 분해하여 대상 메서드를 식별하려고 시도하지 않고, 단지 SoapDocumentMethod 특성의 Action 매개 변수에 대해 지정된 값과 일치시킵니다.

일단 ASP.NET 웹 서비스 요청 처리기에서 요청을 처리하기 위해 .asmx 파일에서 참조된 클래스의 메서드 중 호출할 메서드를 식별하면 해당 요청은 이 메서드에서 매개 변수로 예상하는 형식의 인스턴스로 deserialize되어야 합니다. 이를 위해 System.Xml.Serialization.XmlSerializer가 사용됩니다.

기본적으로 요청 처리기는 요청에 통합된 SOAP 메시지가 WSDL 1.1 사양의 문서 스타일과 일치한다고 가정합니다. 이러한 스타일의 메시지에는 임의의 스키마에 따라 구조화된 본문 요소가 있으며, 요청 처리기는 System.Xml.Serialization.XmlSerializer를 사용하여 해당 본문 요소를 .NET 형식으로 deserialize합니다. 다음은 작업 예제입니다.

위 작업에서 ASP.NET 웹 서비스 요청 처리기는 다음과 같은 문서 스타일의 SOAP 메시지를 예상합니다.

여기서 요소 이름은 deserialize될 형식의 이름을 식별합니다. 이 메커니즘도 다음과 같이 사용자 지정할 수 있습니다.

1. 형식의 이름이 SOAP 메시지의 구성 요소에 매핑되는 방식은 System.Xml.XmlElement 및 System.Xml.XmlAttribute 특성을 메서드의 매개 변수에 적용함으로써 사용자 지정할 수 있습니다. System.Xml.XmlElement 특성은 다음과 같이 ASP.NET 웹 서비스 요청 처리기에서 형식을 deserialize할 것이라고 예상하는 XML 요소의 이름을 제어합니다.
   
   
   [WebMethod]
   PurchaseOrderType PlaceOrders
   (
       [XmlElement("OrderParameter")]
       PurchaseOrderType order
   );

   System.Xml.XmlAttribute 특성이 매개 변수에 추가된 경우 요청 처리기는 해당 매개 변수를 XML 요소가 아닌 XML 특성에서 deserialize할 것이라고 예상합니다.

2. 요청에 통합된 SOAP 메시지가 문서 스타일과 일치할 것이라는 ASP.NET 웹 서비스 요청 처리기의 기본 예상을 변경하여 해당 SOAP 메시지가 WSDL 1.1 사양의 RPC 스타일과 일치할 것이라고 예상하도록 만들 수 있습니다. 전체 서비스에 대해 SoapRpcService 특성을 사용하거나, 개별 메서드에 대해 SoapRpcMethod 특성을 사용하여 이를 수행할 수 있습니다. 그러나 RPC 스타일 사용은 WS-I Basic Profile 1.1에 포함되지 않고, 따라서 상호 운용성을 낮추기 때문에 이 옵션은 사용하지 않는 것이 좋습니다.

Windows Communication Foundation

Windows Communication Foundation 클라이언트에 사용되는 서비스의 프록시 클래스는 이 클래스의 메서드로 전달되는 매개 변수를 System.ServiceModel.Channels.Message 개체로 serialize합니다. 그러면 해당 개체는 선택한 바인딩으로 수 및 성격이 결정되는 일련의 채널을 통해 전달됩니다. 이 채널은 일반적으로 해당 채널에서 구현하는 프로토콜에 따라 System.ServiceModel.Channels.Message 개체의 Headers 컬렉션에 System.ServiceModel.Channels.MessageHeader 개체를 추가합니다. 일련의 채널에서 마지막 채널은 항상 전송 채널입니다. 전송 채널은 바인딩으로도 성격이 결정되는 인코더를 사용하여 System.ServiceModel.Channels.Message 개체를 전송 채널에서 서버로 전송하는 바이트 스트림으로 serialize합니다. 서버의 수신기는 바이트 스트림을 받은 다음 인코더를 사용하여 바이트 스트림을 System.ServiceModel.Channels.Message 개체로 deserialize합니다. 그 다음 일반적으로 클라이언트의 채널과 일치하는 일련의 채널을 통해 해당 개체가 전달됩니다. 그런 다음 System.ServiceModel.Channels.Message 개체가 System.ServiceModel.Dispatcher.DispatchRuntime 개체로 전달됩니다. System.ServiceModel.Dispatcher.DispatchRuntime 개체는 호출될 서비스 형식의 메서드를 결정하고 System.ServiceModel.Channels.Message 개체의 데이터를 해당 메서드에서 매개 변수로 예상하는 형식의 인스턴스로 deserialize하고 해당 메서드를 호출합니다.

Windows Communication Foundation에서 데이터 전송을 전달하게 되는 채널의 선택과 작업을 서비스 바인딩을 통해 사용자 지정할 수 있을 뿐만 아니라 사용자 지정 채널도 손쉽게 추가할 수 있습니다. 또한 프록시 및 System.ServiceModel.Dispatcher.DispatchRuntime 작업도 이러한 동작을 통해 조정하거나 전체적으로 사용자 지정할 수 있습니다. 즉, ASP.NET에서는 웹 서비스 요청 처리기를 제어하기 위해 많은 특성을 제공하는 반면, Windows Communication Foundation에서는 이와 비슷한 특성 집합뿐만 아니라 프록시 및 System.ServiceModel.Dispatcher.DispatchRuntime을 제어하기 위한 사용자 지정 코드 형식의 스와핑 옵션도 제공합니다.

System.ServiceModel.Dispatcher.DispatchRuntime은 요청을 처리하기 위해 호출되는 서비스 형식의 메서드를 결정할 때 SOAPAction 헤더를 사용합니다. 기본적으로 Windows Communication Foundation 작업에 대한 SOAPAction 헤더는 서비스의 네임스페이스, 서비스 계약 이름, 작업 이름 순서로 구성됩니다. 서비스 계약의 기본 네임스페이스는 http://tempuri.org/입니다. 서비스 계약의 기본 이름은 해당 서비스 계약을 정의하는 데 사용되는 인터페이스 또는 클래스의 이름이며, 작업의 기본 이름은 해당 작업을 구현하는 메서드의 이름입니다. 다음은 작업 예제입니다.

위 작업의 경우 SOAPAction 헤더는 http://tempuri.org/IDerivativesCalculator/CalculateDerivative가 됩니다. 다음과 같이 네임스페이스와 서비스 계약의 이름은 System.ServiceModel.ServiceContract 특성의 Namespace 및 Name 매개 변수를 사용하여 기본 이름을 변경할 수 있으며, 작업 이름은 System.ServiceModel.OperationContract 특성의 Name 매개 변수를 사용하여 기본 이름을 변경할 수 있습니다.

System.ServiceModel.Message 개체의 데이터를 deserialize할 때 System.ServiceModel.Dispatcher.DispatchRuntime은 기본적으로 System.Runtime.Serialization.DataContractFormatter를 사용합니다. XML 요소의 이름을 deserialize되는 클래스와 일치시키기 위한 System.ServiceModel.DataContract와 System.ServiceModel.DataMember 특성의 Namespace 및 Name 매개 변수의 메커니즘에 관해서는 이미 설명했습니다.

다음과 같이 System.ServiceModel.XmlSerializerFormat 특성을 적용함으로써 System.ServiceModel.Dispatcher.DispatchRuntime에서 System.Xml.Serialization.XmlSerializer를 사용하도록 만들 수 있습니다.

이 특성은 서비스의 개별 작업에도 적용할 수 있습니다.

deserialization에 System.Runtime.Serialization.DataContractFormatter가 사용되고 있는 경우 System.ServiceModel.DataContractFormat 특성을 사용하여 데이터가 문서 스타일 과 RPC 스타일 중 어느 것으로 예상되는지 제어할 수 있습니다. 이 특성은 다음과 같이 서비스 계약 전체 또는 서비스 계약의 개별 작업에 적용할 수 있습니다.

Windows Communication Foundation 채택을 위한 사전 준비: 향후 통합 간소화

현재 ASP.NET을 사용 중이고 앞으로 Windows Communication Foundation을 사용할 예정이라면 새 ASP.NET 웹 서비스가 Windows Communication Foundation 응용 프로그램과 올바르게 작동하도록 하기 위해 다음과 같은 지침을 따릅니다.

일반 권장 사항

새로운 모든 서비스에 대해 ASP.NET 2.0을 채택합니다. ASP.NET 2.0을 채택하면 물론 새 버전의 개선된 기능과 향상된 기능을 사용할 수 있으며 같은 응용 프로그램에서 ASP.NET 2.0 구성 요소를 Windows Communication Foundation 구성 요소와 함께 사용할 수 있게 됩니다.

프로토콜

WS-I Basic Profile 1.1에 대한 부합 여부를 검증하기 위한 ASP.NET 2.0의 새로운 기능을 사용합니다.

이 프로필을 따르는 ASP.NET 웹 서비스는 일반적으로 상호 운용성이 더 높고, 미리 정의된 Windows Communication Foundation 바인딩인 System.ServiceModel.BasicHttpBinding을 통해 Windows Communication Foundation 클라이언트와 상호 운용이 가능합니다.

서비스 개발

메시지를 SOAPAction HTTP 헤더가 아닌 SOAP 메시지 본문 요소의 정규화된 이름을 기반으로 발송하려면 System.Web.Services.Protocols.SoapDocumentService 특성을 사용하지 마십시오. Windows Communication Foundation은 SOAPAction HTTP 헤더를 사용하여 메시지를 메서드로 발송합니다.

데이터 표현

System.Xml.Serialization.XmlSerializer에서 기본적으로 형식을 serialize하는 XML은 해당 XML의 네임스페이스가 명시적으로 정의되어 있는 경우 System.RuntimeSerialization.DataContractFormatter에서 형식을 serialize하는 XML과 의미상 동일하다는 점을 상기하십시오. 따라서 앞으로 Windows Communication Foundation을 채택할 예정이면서 현재 ASP.NET 웹 서비스에 사용할 데이터 형식을 정의하는 경우에는 다음을 수행하십시오.

1. XML 스키마가 아닌 .NET 클래스를 사용하여 데이터 형식을 정의합니다.
2. System.Serializable 특성 및 System.Xml.Serialization.XmlRoot 특성만 클래스에 추가하고, 후자를 사용하여 형식에 대한 네임스페이스를 명시적으로 정의합니다. .NET 클래스가 XML로 변환되는 방식을 제어하기 위해 System.Xml.Serialization 네임스페이스의 다른 특성을 추가하지 않습니다.

이러한 접근 방식을 채택하면 .NET 클래스가 전송을 위해 serialize되는 XML을 많은 부분 변경하지 않고도 System.Runtime.Serialization.DataContract 및 System.Runtime.Serialization.DataMember 특성을 추가하여 나중에 .NET 클래스를 데이터 계약으로 만들 수 있습니다. 그러면 ASP.NET 웹 서비스에서 메시지에 사용되는 동일한 형식이 Windows Communication Foundation 응용 프로그램에서 데이터 계약으로 처리될 수 있으며, 이는 다른 이점과 함께 Windows Communication Foundation 응용 프로그램의 성능 향상이라는 이점을 제공합니다.

보안

IIS의 인증 옵션을 사용하지 마십시오. Windows Communication Foundation 클라이언트에서 지원하지 않습니다. Windows Communication Foundation은 표준 프로토콜에 기반한 더욱 풍부한 옵션을 제공하므로 서비스를 보안해야 하는 경우 즉시 Windows Communication Foundation을 채택해야 합니다.

Windows Communication Foundation 채택을 위한 사전 준비: 향후 마이그레이션 간소화

앞으로 새로운 ASP.NET 응용 프로그램을 Windows Communication Foundation으로 더 쉽게 마이그레이션하려면 앞서 설명한 권장 사항과 다음 권장 사항을 모두 따르십시오.

프로토콜

SOAP 1.2에 대한 ASP.NET 2.0 지원을 사용하지 않습니다.

Windows Communication Foundation에서는 SOAP 1.1, SOAP 1.2와 같은 별개의 프로토콜을 따르는 메시지가 각각 별개의 끝점을 거치도록 요구하기 때문에 SOAP 1.2에 대한 ASP.NET 2.0 지원은 사용하지 않는 것이 좋습니다. ASP.NET 2.0 웹 서비스가 기본 구성대로 SOAP 1.1과 SOAP 1.2를 모두 지원하도록 구성되면 ASP.NET 웹 서비스의 기존 클라이언트 모두와 호환되는 원래 주소의 단일 Windows Communication Foundation 끝점으로 마이그레이션할 수 없습니다.

서비스 개발

• Windows Communication Foundation을 사용하면 인터페이스 또는 클래스에 System.ServiceModel.ServiceContract 특성을 적용하여 서비스 계약을 정의할 수 있습니다. 이 특성을 인터페이스에 적용하면 원하는 수의 클래스에서 다양하게 구현할 수 있는 데이터 계약 정의가 생성되므로 클래스보다는 인터페이스에 적용하는 것이 좋습니다. ASP.NET 2.0은 클래스뿐만 아니라 인터페이스에도 System.Web.Services.WebService 특성을 적용하는 옵션을 지원합니다. 그러나 앞서 설명했듯이 ASP.NET 2.0에는 System.Web.Services.WebService 특성이 클래스가 아닌 인터페이스에 적용될 때는 이 특성의 Namespace 매개 변수가 아무런 효과도 없다는 결점이 있습니다. 일반적으로 System.Web.Services.WebService 특성의 Namespace 매개 변수를 사용하여 서비스의 네임스페이스에 대한 기본값(http://tempuri.org)을 수정하는 것이 좋기 때문에 인터페이스 또는 클래스에 System.ServiceModel.ServiceContract 특성을 적용하여 ASP.NET 웹 서비스를 계속 정의해야 합니다.
• 인터페이스를 정의하는 메서드에 최소한의 코드만 사용합니다. 메서드의 작업을 다른 클래스에 위임하도록 합니다. 그러면 새로운 Windows Communication Foundation 서비스 형식에서도 상당한 작업을 해당 클래스로 간단하게 위임할 수 있습니다.
• System.Web.Services.WebMethod 특성의 MessageName 매개 변수를 사용하여 서비스 작업에 명시적 이름을 제공합니다.
  
  
  [WebMethod(MessageName="ExplicitName")]
  string Echo(string input);

  ASP.NET에서 작업의 기본 이름은 Windows Communication Foundation에서 제공하는 기본 이름과 다르기 때문에 이렇게 하는 것이 중요합니다. 명시적 이름을 제공함으로써 기본 이름을 사용하지 않아도 됩니다.

• 다형적 메서드로 ASP.NET 웹 서비스 작업을 구현하지 마십시오. Windows Communication Foundation에서는 다형적 메서드로 작업을 구현하는 것을 지원하지 않습니다.
• System.Web.Services.Protocols.SoapDocumentMethod 특성을 사용하여 HTTP 요청을 메서드로 라우팅할 SOAPAction HTTP 헤더에 명시적 값을 제공합니다.
  
  
  [WebMethod]
  [SoapDocumentMethod(RequestElementName="ExplicitAction")]
  string Echo(string input);
  
  
• 이 접근 방식을 취할 경우 ASP.NET에서 사용되는 기본 SOAPAction 값을 사용하지 않아도 되며 Windows Communication Foundation에서도 마찬가지입니다.
• SOAP 확장을 사용하지 마십시오. SOAP 확장이 필요한 경우에는 고려하고 있는 SOAP 확장의 목적이 이미 Windows Communication Foundation에서 제공되는 기능인지 확인하십시오. 이 경우 당장은 Windows Communication Foundation을 채택하지 않는다는 방침을 재고하십시오.

상태 관리

서비스의 상태를 유지하지 마십시오. 상태를 유지하는 것은 응용 프로그램의 확장성을 떨어뜨리는 경향이 있을 뿐만 아니라, Windows Communication Foundation에서 ASP.NET 호환 모드를 통해 ASP.NET 메커니즘을 지원하지만 ASP.NET과 Windows Communication Foundation의 상태 관리 메커니즘은 매우 다릅니다.

예외 처리

서비스에서 송수신할 데이터 형식의 구조를 디자인할 때 클라이언트로 전달하려는 서비스에서 발생할 수 있는 다양한 종류의 예외를 표시하기 위한 구조도 디자인합니다.

다음과 같이 해당 클래스에 자신을 XML로 serialize할 수 있는 기능을 부여합니다.


그러면 해당 클래스를 사용하여 명시적으로 발생된 System.Web.Services.Protocols.SoapException 인스턴스에 자세한 내용을 제공할 수 있습니다.


이러한 예외 클래스는 다음과 같이 Windows Communication Foundation의 System.ServiceModel.FaultContract<T>에서 즉시 다시 사용할 수 있습니다.

보안

• ASP.NET 2.0 프로필을 사용하지 마십시오.
• 서비스에 대한 액세스를 제어하기 위해 ACL을 사용하지 마십시오.
• ASP.NET 2.0 역할 공급자를 사용하여 서비스의 리소스에 대한 액세스를 인증하는 방법을 고려합니다.

Windows Communication Foundation 채택

ASP.NET 웹 서비스와의 공존

ASP.NET으로 개발된 기존 응용 프로그램을 계속 유지하면서 새로운 개발에는 Windows Communication Foundation을 사용하는 방법을 선택할 수 있습니다. Windows Communication Foundation은 모든 시나리오에서 .NET 응용 프로그램과의 원활한 통신을 위한 최적의 선택이 되도록 고안되었기 때문에 ASP.NET으로는 수행할 수 없었던 방식으로 다양한 소프트웨어 통신 문제를 해결하는 표준 도구로 사용할 수 있습니다.

새로운 Windows Communication Foundation 응용 프로그램은 기존 ASP.NET 웹 서비스와 동일한 컴퓨터에 배포될 수 있습니다. 이러한 ASP.NET 웹 서비스에서 버전 2.0 이전의 .NET 버전을 사용하는 경우 ASP.NET IIS 등록 도구를 사용하여 새 Windows Communication Foundation 응용 프로그램을 호스트할 IIS 응용 프로그램에 .NET Framework 2.0을 선택적으로 배포할 수 있습니다. ASP.NET IIS Registration Tool (Aspnet_regiis.exe) (영문) 문서를 참조하십시오. 이 도구에는 IIS 6 관리 콘솔에 기본적으로 제공되는 직관적인 사용자 인터페이스가 있습니다.

Windows Communication Foundation은 사용하여 ASP.NET 호환 모드에서 실행되도록 구성된 Windows Communication Foundation 서비스를 IIS의 기존 ASP.NET 웹 서비스 응용 프로그램에 추가함으로써 기존 ASP.NET 웹 서비스에 새 기능을 추가할 수 있습니다. ASP.NET 호환 모드 덕분에 새로운 Windows Communication Foundation 서비스의 코드는 System.Web.HttpContext 클래스를 통해 기존 ASP.NET 코드와 동일한 응용 프로그램 상태 정보를 액세스 및 업데이트할 수 있으며 동일한 클래스 라이브러리를 공유할 수 있습니다.

ASP.NET 웹 서비스와 클라이언트를 Windows Communication Foundation으로 마이그레이션

Windows Communication Foundation 클라이언트는 ASP.NET 웹 서비스를 사용할 수 있습니다. System.ServiceModel.BasicHttpBinding으로 구성되는 Windows Communication Foundation 서비스는 ASP.NET 웹 서비스 클라이언트에서 사용할 수 있습니다. ASP.NET 웹 서비스는 Windows Communication Foundation 응용 프로그램과 공존할 수 있으며, Windows Communication Foundation을 사용하여 기존 ASP.NET 웹 서비스에 기능을 추가할 수도 있습니다. Windows Communication Foundation과 ASP.NET 웹 서비스를 함께 사용할 수 있는 이러한 모든 방식을 고려해 보면 ASP.NET 웹 서비스를 Windows Communication Foundation으로 마이그레이션해야 하는 필연적인 이유는 거의 없습니다.

마이그레이션이 필요한 것으로 보이는 일부 경우에서도, 단순히 한 기술에서 다른 기술로 코드를 마이그레이션하는 것은 대부분 올바른 접근 방식이 아니라는 점을 신중하게 고려하십시오. 새로운 기술을 채택하는 이유는 이전 기술로는 따라갈 수 없는 새로운 요구 사항을 충족하기 위한 것이며, 이러한 경우 새로 확장된 요구 사항을 충족하는 새로운 솔루션을 디자인하는 것이 올바른 방법입니다. 새 디자인은 기존 시스템에서의 경험과 해당 시스템이 디자인된 이후 축적된 지식을 활용할 수 있습니다. 또한 새 디자인은 단순히 새 플랫폼에서 이전 디자인을 재생산하는 것이 아니라 새 기술의 완전한 기능을 충분히 고려할 것입니다. 새 디자인의 주요 요소를 프로토타이핑하면 대개 새 시스템에서 기존 시스템의 코드를 다시 사용하는 방법을 명확하게 알 수 있습니다.

단순히 ASP.NET 웹 서비스에서 Windows Communication Foundation으로 이식하는 것이 올바른 솔루션으로 생각되는 일부 경우에 대한 몇 가지 진행 방법 지침이 있습니다. 서비스를 마이그레이션하는 방법과 클라이언트를 마이그레이션하는 방법에 대한 권장 사항이 있습니다.

ASP.NET 웹 서비스를 Windows Communication Foundation으로 마이그레이션

1. 서비스에 대한 포괄적인 테스트 집합이 있는지 확인합니다.
2. 서비스에 대한 WSDL을 생성하고 해당 서비스의 .asmx 파일과 같은 폴더에 복사본을 저장합니다.
3. .NET 2.0을 사용하도록 ASP.NET 웹 서비스를 업그레이드합니다. 먼저 .NET Framework 2.0을 IIS의 응용 프로그램에 배포한 다음 Visual Studio 2005를 사용하여 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/webprojectsVS05.asp?frame=true(영문) 문서의 설명에 따라 코드 변환 프로세스를 자동화함으로써 업그레이드를 수행합니다. 테스트 집합을 실행합니다.
4. System.Web.Services.WebService 특성의 Namespace 및 Name 매개 변수의 값이 아직 제공되지 않았으면 이 매개 변수들에 명시적 값을 제공합니다. System.Web.Services.WebMethod 특성의 MessageName 매개 변수에도 같은 작업을 수행합니다. 또한 요청을 메서드로 라우팅하는 SOAPAction HTTP 헤더에 명시적 값이 아직 제공되지 않았으면 다음과 같이 System.Web.Services.Protocols.SoapDocumentMethod 특성으로 Action 매개 변수의 기본값을 명시적으로 지정합니다.
   
   
   [WebService(Namespace = "http://tempuri.org/", Name = "Adder")]
   public class Adder
   {
       [WebMethod(MessageName = "Add")]
       [SoapDocumentMethod(Action = "http://tempuri.org/Add")]
       public double Add(SumInput input)
       {
           double sum = 0.00;
           foreach (double inputValue in input.Input)
           {
               sum += inputValue;
           }
           return sum;
       }
   }
   
   
5. 테스트 집합을 실행합니다.
6. 클래스의 메서드 본문에 있는 코드를 원래 클래스에서 사용하도록 만들어진 별개의 클래스로 옮깁니다.
   
   
   [WebService(Namespace = "http://tempuri.org/", Name = "Adder")]
   public class Adder
   {
       [WebMethod(MessageName = "Add")]
       [SoapDocumentMethod(Action = "http://tempuri.org/Add")]
       public double Add(SumInput input)
       {
           return new ActualAdder().Add(input);
       }
   }
   
   internal class ActualAdder
   {
       internal double Add(SumInput input)
       {
           double sum = 0.00;
           foreach (double inputValue in input.Input)
           {
               sum += inputValue;
           }
           return sum;
       }
   }
   
   
7. 테스트 집합을 실행합니다.
8. Windows Communication Foundation 어셈블리인 System.ServiceModel 및 System.Runtime.Serialization에 대한 참조를 ASP.NET 웹 서비스 프로젝트에 추가합니다.
9. Windows Communication Foundation의 svcutil.exe 도구를 실행하여 WSDL에서 Windows Communication Foundation 프록시 클래스를 생성합니다. 생성된 클래스 모듈을 솔루션에 추가합니다.
10. 앞 단계에서 생성된 클래스 모듈에는 인터페이스 정의가 포함됩니다.
    
    
    [System.ServiceModel.ServiceContractAttribute()]
    public interface AdderSoap
    {
        [System.ServiceModel.OperationContractAttribute(
          Action="http://tempuri.org/Add",
          ReplyAction="http://tempuri.org/Add")]
        AddResponse Add(AddRequest request);
    }
    Modify the definition of the ASP.NET Web service class so that the class is defined as implementing that interface:
    [WebService(Namespace = "http://tempuri.org/", Name = "Adder")]
    public class Adder: AdderSoap
    {
        [WebMethod(MessageName = "Add")]
        [SoapDocumentMethod(Action = "http://tempuri.org/Add")]
        public double Add(SumInput input)
        {
            return new ActualAdder().Add(input);
        }
    
       
        public AddResponse Add(AddRequest request)
        {
            return new AddResponse(new AddResponseBody(this.Add(request.Body.input)));
        }
    }
    
    
11. 프로젝트를 컴파일합니다. 9단계에서 생성된 코드 때문에 일부 형식 정의가 중복되는 오류가 있을 수 있습니다. 일반적으로 형식에 대한 기존 정의를 삭제하여 이러한 오류를 수정합니다. 테스트 집합을 실행합니다.
12. System.Web.Services.WebService, System.Web.Services.WebMethod, System.Web.Services.Protocols.SoapDocumentMethod 특성 등 ASP.NET 고유의 특성을 제거합니다.
    
    
    public class Adder: AdderSoap
    {
        public double Add(SumInput input)
        {
            return new ActualAdder().Add(input);
        }
    
       
        public AddResponse Add(AddRequest request)
        {
            return new AddResponse(new AddResponseBody(this.Add(request.Body.input)));
        }
    }
    
    
13. Windows Communication Foundation 서비스 형식이 될 클래스를 구성하여 ASP.NET 웹 서비스가 다음 항목을 사용하는 경우 Windows Communication Foundation의 ASP.NET 호환 모드를 요구하도록 합니다.
    • System.Web.Services.HttpContext 클래스
    • ASP.NET 프로필
    • .asmx 파일의 ACL
    • IIS 인증 옵션
    • ASP.NET 가장 옵션
    • ASP.NET 전역화
    [System.ServiceModel.AspNetCompatibilityRequirements(
           RequirementsMode=AspNetCompatbilityRequirementsMode.Require)]
    public class Adder: AdderSoap
    
    
14. 원래의 .asmx 파일 이름을 .asmx.old로 바꿉니다.
15. 서비스에 대한 Windows Communication Foundation 서비스 파일을 만들고, 이 파일의 확장명을 .asmx로 지정한 다음 IIS의 응용 프로그램 루트에 저장합니다.
    
    
    <%@Service Class="MyOrganization.Adder" %>
    <%@Assembly Name="MyServiceAssembly" %>
    
    
    
16. 서비스에 대한 Windows Communication Foundation 구성을 Web.config 파일에 추가합니다. BasicHttpBinding을 사용하고, 앞 단계에서 만든 .asmx 확장명의 서비스 파일을 사용하고, 자체적으로 WSDL을 생성하지 않고 2단계에서 생성된 WSDL을 사용하도록 서비스를 구성합니다. 또한 위 10단계에서 필요하다고 판단된 경우 ASP.NET 호환 모드를 사용하도록 서비스를 구성합니다.
    
    
    <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
       <system.web>
          <compilation>
             <buildProviders>
    <remove extension=".asmx" />
                <add extension=".asmx"
                   type=
    "System.ServiceModel.ServiceBuildProvider, System.ServiceModel, Version=2.0.0.0,
                Culture=neutral,
                PublicKeyToken=b77a5c561934e089" />
             </buildProviders>
          </compilation>
       </system.web>
       <system.serviceModel>
          <services>
             <service name="MyOrganization.Adder "
                      behaviorConfiguration="AdderBehavior">
    <endpoint
    address=""
    binding="basicHttpBinding"
    contract="AdderSoap "/>
             </service>
          </services>
          <behaviors>
               <serviceBehaviors>
             <behavior name="AdderBehavior">
                <metadataPublishing
                   enableMetadataExchange="true"
                   enableGetWsdl="true"
                   enableHelpPage="true"
    metadataLocation=
    "http://MyHost.com/AdderService/Service.wsdl"/>
             </behavior>
            </serviceBehaviors>
          </behaviors>
          <serviceHostingEnvironment
    aspNetCompatibilityEnabled ="true"/>
       </system.serviceModel>
    </configuration>
    
    
17. 구성을 저장합니다.
18. 프로젝트를 컴파일합니다.
19. 테스트 집합을 실행합니다.

ASP.NET 웹 서비스 클라이언트를 Windows Communication Foundation으로 마이그레이션

1. 클라이언트에 대한 포괄적인 테스트 집합이 있는지 확인합니다.
2. Visual Studio 2005를 사용하여 클라이언트 응용 프로그램을 .NET 2.0으로 업그레이드합니다. 테스트 집합을 실행합니다.
3. 클라이언트 프로젝트에서 ASP.NET 프록시 코드를 제거합니다. 이 코드는 대개 wsdl.exe 도구를 사용하여 생성된 모듈에 있습니다.
4. svcutil.exe 도구를 사용하여 Windows Communication Foundation 프록시 코드를 생성합니다. 이 코드를 클라이언트 프로젝트에 추가하고 구성 출력을 클라이언트의 기존 구성 파일에 병합합니다.
5. 응용 프로그램을 컴파일합니다. 기존 ASP.NET 프록시 형식에 대한 참조를 새 Windows Communication Foundation 프록시 형식에 대한 참조로 바꾸어 컴파일 오류를 수정합니다.
6. 테스트 집합을 실행합니다.

요약

ASP.NET 웹 서비스 도구는 단지 웹 서비스를 빌드하기 위한 것이지만, Windows Communication Foundation은 소프트웨어 엔터티들이 서로 통신하도록 설정되어야 하는 모든 환경에서 사용할 수 있는 도구를 제공합니다. 웹 서비스 개발 프로젝트에서도 Windows Communication Foundation은 ASP.NET 웹 서비스에서 지원하는 것보다 더 많은 웹 서비스 프로토콜을 지원합니다. 이러한 프로토콜은 신뢰할 수 있는 세션과 트랜잭션을 비롯한 여러 가지 장점을 수반하는, 더욱 정교한 솔루션을 제공합니다. 대부분의 경우 권장되는 작업 과정은 기존 ASP.NET 웹 서비스 응용 프로그램을 계속 유지하면서 새로운 개발에는 Windows Communication Foundation을 채택하는 것입니다. 이러한 작업 과정은 Windows Communication Foundation의 이점을 누리면서 기존 응용 프로그램을 마이그레이션해야 하는 비용을 절약해 줍니다. 새 Windows Communication Foundation 응용 프로그램은 기존 ASP.NET 웹 서비스를 사용할 수 있으며 기존 ASP.NET 응용 프로그램과 공존할 수 있습니다. Windows Communication Foundation의 ASP.NET 호환 모드 덕분에 Windows Communication Foundation을 사용하여 기존 ASP.NET 응용 프로그램에 새로운 작업 기능을 프로그래밍할 수도 있습니다.

출처 : 한국 마이크로소프트 MSDN (2006년 7월)

호환성

가장 주목할 만한 부분은, 통합된 아키텍처가 기존의 ASP.NET 런타임 아키텍처와 APIs 를 여전히 지원하므로, 기존의 ASP.NET 응용 프로그램과 서비스 대부분이 수정을 거치지 않고서도 정상적으로 동작한다는 점입니다. 게다가 단지 약간의 수정만으로도 새로운 ASP.NET 기능들의 이점을 누리도록 변경할 수 있습니다.

ASP.NET 응용 프로그램을 통합 모드에서 실행할 수 있도록 설정하는 방법에 대한 보다 자세한 정보는 IIS7 통합 모드를 위한 ASP.NET 응용 프로그램의 마이그레이션을 참고하시기 바랍니다.

게다가, 개발자들은 런타임 통합으로 인한 이득을 누리면서도, 계속해서 친숙한 기존의 ASP.NET APIs 를 사용하여 새로운 응용 프로그램을 작성할 수 있습니다.

IIS7 은 통합 모드에서 지원되지 않는 특정한 호환성이 요구되는 ASP.NET 응용 프로그램을 위한 "클래식" ASP.NET 모드를 지원합니다. 관리자는 응용 프로그램 풀 단위로 필요한 통합 모드를 선택할 수 있으며, 결과적으로는 새로운 통합 모드를 사용하는 응용 프로그램과 클래식 ASP.NET 모드를 사용하는 응용 프로그램을 동일한 서버에서 함께 운영할 수 있습니다.

두 가지 ASP.NET 통합 모드간의 전환에 대한 보다 많은 내용을 보시려면 응용 프로그램을 위한 ASP.NET 모드 변경을 참고하시기 바랍니다.


IIS7 통합 모드를 위한 ASP.NET 응용 프로그램의 마이그레이션

기본적으로 IIS7 은 ASP.NET 이 새로운 통합 모드에서 동작하도록 구성되어 있습니다. 따라서, 여러분들의 응용 프로그램은 최소한의 변경만으로도 향상된 통합 모드의 이점을 얻을 수 있습니다.

구성설정이 통합되었기 때문에 일부 응용 프로그램들은 통합 모드에서 운영되기 위해서는 마이그레이션이 필요할 수도 있습니다. 기본적으로 서버는 마이그레이션을 지원하기 위해 응용 프로그램이 마이그레이션을 필요로 하는지를 감지하고, 응용 프로그램을 마이그레이션하기 위해 요구되는 내용들을 오류 메시지로 리턴합니다.

다음과 같은 구성설정은 마이그레이션 오류를 발생시킵니다.

1. 응용 프로그램의 web.config 파일이 <httpModules> 구성설정 섹션을 정의합니다.
   응용 프로그램이 새로운 ASP.NET 모듈을 로드하거나, 기존 모듈 중 하나를 제거합니다. 통합 모드상에서 ASP.NET 모듈은 네이티브 모듈과 함께 통합된 <system.webServer>/<modules> 구성설정 섹션에 지정됩니다. <system.web>/<httpModules> 구성설정 섹션에 지정된 ASP.NET 모듈이 정상적으로 동작하기 위해서는 새로운 구성설정 섹션으로 이동되어야만 합니다. 새로운 ASP.NET 모듈은 통합된 섹션에 직접 추가되어야만 합니다.
   
2. 응용 프로그램의 web.config 파일이 <httpHandlers> 구성설정 섹션을 정의합니다.
   응용 프로그램이 일부 콘텐츠 유형을 대상으로 사용자 정의 핸들러 맵핑을 사용합니다. 통합 모드에서 ASP.NET 핸들러 맵핑이 정상적으로 동작하기 위해서는 통합된 <system.webServer>/<handlers> 구성설정 섹션을 통해 지정되어야만 합니다. 새로운 ASP.NET 핸들러 맵핑은 통합된 <handlers> 섹션에 직접 추가되어야만 합니다. <handlers> 섹션은 이전 버전에서 ASP.NET 핸들러 맵핑을 설정하기 위해 사용되던 ASP.NET <httpHandlers> 구성설정과 IIS 스크립트맵 구성설정을 모두 대체합니다.
   
3. 응용 프로그램의 web.config 파일이 <identity impersonate=”true” /> 구성설정 섹션을 정의합니다.
   응용 프로그램이 클라이언트의 신원을 가장합니다. (대부분 인트라넷 응용 프로그램의 경우) 통합 모드에서 클라이언트 신원 가장 기능은 일부 초기 요청 처리 단계에서 사용이 불가능합니다. 이런 경우, 대부분 오류 발생을 무시하도록 설정해도 크게 문제가 되지 않으며, 또는 응용 프로그램이 클래식 ASP.NET 모드에서 실행되도록 구성할 수도 있습니다.

이와 같은 오류가 발생하는 경우, 일반적으로 응용 프로그램의 구성설정을 마이그레이션하거나 (첫 번째나 두 번째 경우 추천), 응용 프로그램이 클래식 ASP.NET 모드를 사용하도록 전환할 수 (세 번째 경우 추천) 있습니다.


응용 프로그램 구성설정 마이그레이션

IIS7 은 마이그레이션 작업을 수행해주는 APPCMD.EXE 명령줄 도구를 통해서 여러분들의 응용 프로그램 마이그레이션 작업을 여러분 대신 처리해줄 수 있습니다. 대부분의 마이그레이션 오류 메시지에는 여러분들의 응용 프로그램을 통합 모드에 알맞게 즉시 마이그레이션 할 수 있게 해주는, 관리자 권한 명령어 실행창에서 실행 가능한 명령어가 포함되어 있습니다.

마이그레이션 명령어의 기본적인 형식은 다음과 같습니다.

[Application Path] 에는, 예를 들어서 “기본 웹 사이트/app1” 과 같은 사이트 이름을 포함한 가상 경로가 위치합니다.

마이그레이션을 마친 뒤, 여러분들의 응용 프로그램은 통합 모드와 클래식 모드 양쪽에서 모두 정상적으로 동작할 것입니다.

일단 마이그레이션을 마친 뒤에는, 여러분들이 다시 구성설정을 변경한다고 하더라도 서버는 다시 마이그레이션을 하라는 메시지를 지원하지 않는다는 점을 명심하시기 바랍니다. 최초의 마이그레이션 작업이 끝난 다음부터 두 모드 사이의 구성설정 동기화에 대한 모든 책임은 여러분들의 몫입니다. – 여러분들은 다시 한 번 APPCMD.EXE 명령줄 도구를 실행하여 수작업으로 응용 프로그램의 마이그레이션을 수행할 수 있습니다.


클래식 ASP.NET 통합 모드 전환

만약 여러분들이 다시 클래식 ASP.NET 모드를 사용하고 싶다면, 그저 간단히 여러분들의 응용 프로그램을 클래식 모드에서 실행되도록 구성된 응용 프로그램 풀로 이동하기만 하면 됩니다. 해당 응용 프로그램 외의 다른 모든 응용 프로그램들은 클래식 모드 응용 프로그램과 함께 여전히 새로운 통합 모드에서 실행될 것입니다.

응용 프로그램을 클래식 ASP.NET 모드로 이동하는 방법에 대한 보다 많은 내용을 보시려면 응용 프로그램을 위한 ASP.NET 모드 변경을 참고하시기 바랍니다.

마이그레이션 오류 메시지 비활성화

만약 여러분들이 수작업으로 응용 프로그램을 마이그레이션하거나, 통합 모드를 사용함에도 불구하고 구성설정을 마이그레이션하고 싶지 않다면 (추천하지 않음), 응용 프로그램의 web.config 파일에 다음과 같은 구성설정 섹션을 추가하여 마이그레이션 오류 메시지를 비활성화 시킬수 있습니다.

주의 : 앞에서 설명한 APPCMD.EXE 명령줄 도구를 사용하여 구성설정을 마이그레이션하고 나면 서버는 자동적으로 오류 메시지를 비활성화 시킵니다. 만약 수작업으로 마이그레이션 오류 메시지를 비활성화 시킨다면, 여러분들은 앞에서 설명했던 지원되지 않는 구성설정에 대한 어떠한 경고 메시지도 더이상 서버로부터 제공되지 않는 상태에서, 응용 프로그램이 통합 모드상에서 적절히 동작하도록 책임져야만 합니다.


응용 프로그램을 위한 ASP.NET 모드 변경

만약 여러분들의 응용 프로그램이 통합된 ASP.NET 모드에서 올바르게 동작하지 않는다면, 응용 프로그램을 다른 응용 프로그램 풀로 이동하여 간단하게 클래식 ASP.NET 모드로 이동할 수 있습니다. 이는 각각의 응용 프로그램 풀이 개별적으로 필요한 통합 모드를 사용하도록 구성되어질 수 있기 때문에 가능한 일입니다. 게다가 이러한 특징은 서로 다른 ASP.NET 통합 모드를 사용하는 응용 프로그램들의 그룹이 동일 서버상에서 함께 실행될 수 있게 해줍니다.

응용 프로그램의 ASP.NET 통합 모드를 변경하려면 다음과 같이 하십시오.

1. 원하는 모드로 구성된 응용 프로그램 풀을 찾거나 생성하십시오.
   기본적으로 시스템상의 모든 새로운 응용 프로그램 풀은 통합 모드에서 실행됩니다. ASP.NET 은 "Classic .NET AppPool" 라는 이름의 클래식 ASP.NET 통합 모드로 실행되는 응용 프로그램 풀을 제공합니다. 여러분들은 새로운 통합 모드에서 실행되면 안되는 응용 프로그램들을 위해서 이 응용 프로그램 풀을 사용할 수 있습니다. 그리고 여러분들은 IIS7 관리 도구 또는 APPCMD.EXE 명령줄 도구를 사용하거나, 수작업으로 응용 프로그램 풀 구성설정을 변경하여 기존 응용 프로그램 풀의 ASP.NET 모드를 변경할 수도 있습니다.
   
2. 해당 응용 프로그램 풀을 사용하도록 응용 프로그램을 설정하십시오.
   각각의 응용 프로그램들은 개별적으로 응용 프로그램 풀을 사용하도록 구성됩니다. 기본적으로 모든 응용 프로그램은 통합 모드에서 동작하는 "DefaultAppPool" 이라는 이름의 기본 응용 프로그램 풀을 사용합니다. 여러분들은 IIS7 관리 도구 또는 APPCMD.EXE 명령줄 도구를 사용하거나, 수작업으로 응용 프로그램의 응용 프로그램 풀 설정을 변경할 수 있습니다.

응용 프로그램을 위한 ASP.NET 버전 선택

역사적으로 IIS 는 여러 버전의 ASP.NET / CLR 을 동시에 지원해 왔으며, 예를 들어 동일한 서버에서 .NET 프레임워크 v1.1 을 사용하는 ASP.NET 응용 프로그램과 .NET 프레임워크 v2.0 을 사용하는 ASP.NET 응용 프로그램이 동시에 실행될 수 있습니다. 이와 같은 지원은 IIS 스크립트맵 구성설정을 기반으로, ASP.NET 콘텐츠 요청을 처리하기 위한 적절한 버전의 ASPNET_isapi.dll 파일이 맵핑됨으로서 제공됩니다.

예를 들어서, 동일한 서버에서 여러 버전의 ASP.NET / CLR 을 동시에 지원하기 위해 다음과 같은 스크립트맵을 구성할 수 있습니다.

1. ASP.NET v1.1 응용 프로그램인 /app1
   *.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll
   
2. ASP.NET v2.0 응용 프로그램인 /app2:
   *.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll

응용 프로그램에 *.aspx 파일에 대한 요청이 도착하면, IIS 는 지정된 aspnet_isapi.dll 파일을 로드하고, 이 로딩된 aspnet_isapi.dll 파일이 올바른 버전의 CLR 을 작업자 프로세스에 로딩함으로서 해당 요청을 처리합니다.

그리고 ASP.NET 은 동일한 서버에서 여러 버전의 ASP.NET / CLR 을 동시에 지원하기 위한 다음과 같은 구성 방법을 제공합니다.

1. ASP.NET MMC 익스텐션. 사용자가 사용하고자 하는 ASP.NET 의 버전을 지정할 수 있으며, 익스텐션은 자동적으로 응용 프로그램을 위한 올바른 버전의 aspnet_isapi.dll 파일을 지정하여 스크립트맵을 구성하게 됩니다.
   
2. ASP.NET aspnet_regiis.exe. ASP.NET aspnet_regiis.exe. 사용자는 적절한 ASP.NET 버전을 지정하는 스크립트맵을 설치하기 위해 -i 와 -r 옵션을 사용할 수 있습니다.

공교롭게도, 단일 작업자 프로세스에는 하나의 CLR 버전만 로드될 수 있다는 제약 때문에, 서로 다른 버전을 사용하는 두 응용 프로그램이 같은 응용 프로그램 풀을 사용하게 구성되지 않도록 주의를 기울여야만 합니다. 그렇지 않으면, 최초의 요청으로 인해서 그에 대응하는 aspnet_isapi.dll 파일의 CLR 이 로드되고, 직후에 뒤따라 발생한 같은 응용 프로그램 풀의 다른 버전에 대한 요청은 실패하게 됩니다.

IIS7 은 응용 프로그램 풀을 ASP.NET 버전관리의 최소 단위로 간주합니다. 따라서 응용 프로그램 풀에 로드되는 CLR / ASP.NET 의 버전은 응용 프로그램 풀 구성설정에 명확하게 설정됩니다. IIS 는 작업자 프로세스가 로딩될 때 이 구성설정에 지정된 버전의 CLR 을 기본적으로 미리 로드할 것입니다. (버전정보가 공백으로 설정된 경우는 제외)

응용 프로그램 풀이 .NET 프레임워크 버전관리의 경계선이기 때문에, 다음과 같은 작업은 ASP.NET 응용 프로그램의 버전에 변화를 주게 됩니다.

1. 응용 프로그램을 원하는 ASP.NET 버전을 사용하는 응용 프로그램 풀로 이동합니다.
   기본적으로 응용 프로그램은 ASP.NET v2.1 통합 모드로 실행되는 “DefaultAppPool” 이라는 이름의 기본 응용 프로그램 풀을 사용합니다. ASP.NET v2.1 클래식 모드를 사용하기 위해 응용 프로그램을 “Classic .NET AppPool” 이라는 응용 프로그램 풀, 또는 여러분들이 선택한 다른 응용 프로그램 풀로 이동할 수 있습니다.
   
2. 응용 프로그램이 실행되는 응용 프로그램 풀을 원하는 ASP.NET 버전을 사용하도록 설정합니다.
   기본적으로 모든 새로운 응용 프로그램 풀은 ASP.NET 2.1 통합 모드에서 실행되도록 구성됩니다.

특정 응용 프로그램을 대상으로나 전반적으로 ASP.NET 의 버전을 구성하기 위해서는 aspnet_regiis /i 또는 /r 옵션을 사용하면 안된다는 점에 주의하시기 바랍니다.

II7 은 설정된 CLR 버전과 응용 프로그램 풀의 관리되는 통합 모드에 따라 자동적으로 핸들러 맵핑의 올바른 집합을 (클래식 모드에서의 ASPNET_isapi.dll 파일 또는 통합 모드에서의 관리되는 핸들러 유형들을 위한) 선택하기 위해 미리 구성된 핸들러 맵핑을 사용합니다. 이러한 핸들러 맵핑은 ASP.NET 2.0 설치시 서버 수준에서 설치됩니다.

출처 : 한국 마이크로소프트 MSDN (2006년 10월)

서론

ASP.NET 은 처음 발표된 이래로 Windows / IIS 플랫폼에서 웹 응용 프로그램 개발을 위해 가장 먼저 선택되어지는 플랫폼이 되었습니다. ASP.NET 2.0 은 웹 응용 프로그램 개발을 완전히 새로운 수준으로 이끌었고 개발자들로 하여금 보다 강력한 응용 프로그램을 과거의 그 어느때 보다도 신속하게 작성할 수 있도록 해주었습니다.

IIS7 은 ASP.NET 런타임 확장성 모듈과 핵심 서버를 통합함으로서 ASP.NET 을 또 한 단계 끌어올렸습니다. 이는 개발자들이 저수준의 IIS C++ APIs 를 사용하지 않고서도, ASP.NET 2.0 과 .NET 프레임워크가 제공하는 풍부한 기능들만을 사용하여 IIS 서버 전체를 확장할 수 있게 해줍니다. 게다가 기존의 ASP.NET 응용 프로그램도 폼 인증, 역할, 그리고 출력 캐시 등과 같은 ASP.NET 으로부터 제공되는 기존의 기능들을 모든 유형의 콘텐츠를 대상으로 확장할 수 있게 됨으로서, 견고한 통합으로부터 얻어지는 직접적인 이점을 즉시 누릴수 있게 됩니다.

물론 IIS7 이 진보된 ASP.NET 통합을 기본으로 제공하기는 하지만, 그 선택은 여전히 여러분들의 몫으로 남겨져 있습니다. IIS7 은 하나의 서버상에서 동시에 운영될 수 있는 새로운 통합 모드와 기존 통합 모드를 모두 지원합니다.

본문에서는 새로운 ASP.NET 통합 모드에 의해 소개된 개선점들과, 두 가지 모드의 아키텍처, 그리고 ASP.NET 응용 프로그램을 위해 통합 모드를 선택하거나 구성하는 방법에 대해서 설명합니다.

IIS7 에서의 ASP.NET 의 향상

보다 개선된 IIS7 과 ASP.NET 의 통합은 기존의 응용 프로그램들을 향상시키며, 새롭게 작성되는 응용 프로그램들이 ASP.NET 기능들의 이점을 새로운 방법으로 누릴 수 있도록 해줍니다.

1. ASP.NET 의 서비스들이 모든 유형의 콘텐츠들을 대상으로 사용될 수 있습니다.
   지금까지는 폼 인증, 역할, URL 권한 부여 그리고 출력 캐시 등과 같은 ASP.NET 의 기능들은 오직 ASP.NET 콘텐츠 유형 (예를 들어, ASPX 페이지) 들을 대상으로만 사용할 수 있었습니다. 정적 파일들과 ASP 페이지들, 그리고 다른 유형의 파일들은 이러한 서비스들의 이점을 누릴 수가 없었습니다. IIS7 에서 모든 ASP.NET 서비스들은 모든 콘텐츠들을 대상으로 일관되게 제공될 수 있습니다. 이를테면, ASP.NET 인증, 멤버자격 그리고 로그인 컨트롤들로 작성된 여러분들이 이미 보유하고 있는 ASP.NET 2.0 접근 제어 솔루션을 사용하여, 이미지 파일들과 ASP 페이지들을 포함한 여러분들의 모든 콘텐츠들을 보호하는 것이 가능합니다.
2. ASP.NET 을 사용하여 완벽한 IIS 의 확장이 가능합니다.
   IIS 의 과거 버전에서는 ASP.NET 의 런타임 제약으로 인해서 네이티브 ISAPI 필터나 익스텐션 확장성 모드를 통해 작성되는 서버 확장성이 빈번하게 요구되곤 했었습니다. IIS7 에서는 ASP.NET 모듈을 네이티브 (C++) 서버 API 를 사용하여 개발된 모듈과 완벽하게 동일한 방법으로 직접 서버의 파이프 라인에 끼워 넣을수 있습니다. ASP.NET 모듈은 요청 처리 파이프 라인의 모든 런타임 단계에서 실행될 수 있으며, 네이티브 모듈에 대해서 어떠한 순서로도 실행되어질 수 있습니다. ASP.NET API 또한 이전에 가능했던 것보다 더 많은 요청 처리 제어를 위해 확장되어질 수 있습니다.
3. 통합된 서버 런타임.
   견고한 ASP.NET 통합은 IIS 와 ASP.NET 간의 많은 기능들까지도 통합되어질 수 있게 해줍니다. IIS7 의 기능들은 IIS 와 ASP.NET 모듈 그리고 핸들러에 대한 구성설정을 통합합니다. 사용자 정의 오류, 그리고 추적을 포함한 다른 많은 기능들도 보다 나은 관리와 집중된 응용 프로그램 디자인을 위해 통합되었습니다.

IIS7 의 새로운 ASP.NET 모드가 제공하는 이점을 활용하는 방법에 대해 보다 많은 내용을 보시려면 Taking Advantage of the Integrated ASP.NET mode 를 참고하시기 바랍니다.

ASP.NET 통합 아키텍처

IIS6 와 그 이전의 릴리스들에서, ASP.NET 은 IIS ISAPI 익스텐션으로 구현되었습니다.

ASP.NET 콘텐츠 유형에 대한 요청은 먼저 IIS 에 의해서 처리되어지고, 그 뒤에 ASP.NET 요청 파이프 라인과 페이지 프레임워크를 호스팅하는 ASP.NET ISAPI DLL 로 전달됩니다. 반면 ASP 페이지나 정적 파일과 같은 비 ASP.NET 콘텐츠들에 대한 요청은 IIS 나 다른 ISAPI 익스텐션들에 의해 처리되며, ASP.NET 쪽으로는 전혀 전달되지 않습니다.

이 모델의 가장 명확한 한계는 ASP.NET 모듈들이나 사용자 정의 ASP.NET 응용 프로그램 코드가 비 ASP.NET 요청에 대해 그 어떠한 서비스도 제공할 수 없다는 점입니다. 더군다나 ASP.NET 실행 경로의 전과 후에 발생하는 IIS 요청 처리의 각각의 부분들에 대해서 ASP.NET 모듈은 일말의 영향도 미칠수 없습니다.

그림1: IIS 6.0 ASP.NET 통합. ASP.NET 요청은 우선 IIS 에 의해 처리되고, 그 다음에 ASP.NET 처리를 위해 ASP.NET ISAPI 익스텐션으로 전달됩니다.

IIS7 에서는 ASP.NET 요청 처리 파이프 라인이 IIS 의 파이프 라인에 직접적으로 중첩되며, 이는 단순하게 끼워 넣어지는 것이 아니라 본질적인 레퍼로서 제공되는 것입니다.

콘텐츠 유형과는 무관하게, 도착한 모든 요청은 IIS 에 의해 전체 과정의 모든 단계에서 요청 처리 제공이 가능한 네이티브 IIS 모듈과 ASP.NET 모듈 양쪽 모두를 통해서 처리됩니다. 바로 이 점으로 인해서 폼 인증 또는 출력 캐시 등과 같은 ASP.NET 모듈이 제공하는 서비스들을 ASP 페이지, PHP 페이지, 정적 파일 등에도 제공할 수 있게 되는 것입니다.

이처럼 서버 파이프 라인에 ASP.NET 모듈을 직접 끼워 넣을 수 있기 때문에, ASP.NET 모듈로 IIS 의 기능을 대체하거나, 특정한 IIS 기능이 실행되기 직전이나 직후에 ASP.NET 모듈을 실행하는 것이 가능합니다. 예를 들어서, 멤버자격 서비스와 SQL 서버 사용자 데이터베이스를 사용하도록 작성된 사용자 정의 ASP.NET 기본 인증 모듈을 사용하여, 오직 Windows 계정에 대해서만 동작하는 내장 IIS 기본 인증 기능을 대체할 수도 있습니다.

게다가, 확장된 ASP.NET APIs 는 요청 처리 작업에 대한 더 많은 직접 통합의 이점을 누립니다. 예를 들어서, ASP.NET 모듈은 ASP 응용 프로그램이 사용자 선호도에 따라 지역화된 콘텐츠를 클라이언트로 강제 전송하는 작업을 실행하기 전에 Accept-Language 헤더를 추가하는 등, 다른 구성 요소들이 특정 요청을 처리하기 이전에 미리 해당 요청의 헤더 정보를 변경할 수도 있습니다.

그림2: IIS 7.0 통합 모드. ASP.NET 구성요소는 IIS 요청 처리 파이프 라인에 직접적으로 끼워 넣어지며, 콘텐츠 유형을 구분하지 않고 모든 요청을 대상으로 실행됩니다.

런타임 통합으로 인해서, IIS 와 ASP.NET 은 서버 모듈들의 활성화와 정렬, 그리고 핸들러 맵핑 구성을 위해 동일한 구성설정을 사용할 수 있게 되었습니다. 추적, 사용자 정의 오류, 그리고 출력 캐시 등을 포함한 다른 통합된 기능들도 마찮가지 입니다.

출처 : 한국 마이크로소프트 MSDN (2006년 10월)

웹사이트를 만들다보면 입력박스에서 데이터의 유효성 검사를 필히 하게된다.
특히 회원가입을 할 경우 필수적이라고 할수 있다.
ASP.NET에는 이런 유효성 검사를 할수 있는 유효성 검사 컨트롤을 지원하고 있다.


1. ASP.NET에서 지원하는 유효성 검사 컨트롤

RequiredFieldValidator	사용자가 데이터를 입력 하였는지 또는 어떤 선택을 하였는지 확인한다. 만일 아무런 입력이 되지 않았으면 에러를 발생한다.
RegularExpressionValidator	사용자 입력에 대한 정규식을 확인한다. 정규식을 활용하면 우편번호나 전화번호 또는 자기가 직접 만든 정규 데이터 형식의 다양한 입력 값의 유효성을 확인을 할 수 있다.
CompareValidator	고정된 값과 입력 컨트롤 또는 다른 입력 컨트롤과의 값을 비교한다. 예를 들어 비밀번호의 경우 비밀번호 확인 텍스트 박스에 사용할 수 있다. 또한 형식화된 데이터나 숫자의 비교에 사용할 수 있다.
RangeValidator	CompareValidator와 비슷하지만 입력한 값을 고정된 두 값을 비교할 수 있다.
CustomValidator	개발자가 직접 유효성 검사 프레임워크의 특정 코드를 입력하도록 허용하는 컨트롤이다.

2. 필수입력 유효성 검사 구현
　- 유효성 검사 서버 컨트롤을 사용하여 모든 필드에 값을 채워놓도록 강제하는 것을 구현하여 보자.

3. 정규식 사용하기
　- 사용자 아이디나 비밀번호 필드에 들어갈 수 있는 문자에 대한 강제하는 작업이 필요로 하다. 우리는 이 작업을 위해 "RegularExpressionValidator" 컨트롤을 사용할 것이다. 정규식은 우편번호, 전화번호, 전자우편 주소처럼 간결한 표현을 확인하고자 하는 경우 매우 유용하게 사용할 수 있다.

4. 컨트롤 입력 값 비교
　- 비밀번호와 비밀번호 확인 필드가 일치하는지 확인해야 한다. 이것을 구현하기 위해 두 개의 입력 컨트롤을 동시에 비교할 수 있는 CompareValidator 컨트롤을 사용할 것이다.

5. 사용자 정의형
　- 우리는 우리들의 가상의 사이트에 아이디가 이미 존재하는지 확인하는 과정이 필요하다. 이것을 위해서는 서버상에 몇 가지 데이터를 찾아보는 작업이 필요하다. 실제는 데이터베이스를 사용하여 구현하는 것이 원칙이나 가상으로 이 상황을 구현하기 위해 아이디가 "aaa"가 아니면 중복이 아니라고 판별하는 가상의 함수를 작성해 보자.

　* 서버 이벤트 스트립트를 이용하여 작성

　* 자바 스트립트를 이용하여 작성

작성자 : 상현넘™ [http://www.shblitz.net]

제가 Atlas에 대해 읽었던 모든 책이나 기사들은 저에겐 단순한 두통거리였습니다. 그것들은 공통적으로 2가지 메시지를 담고 있었습니다. 첫 번째로 제가 제작한 서버 측 ASP.NET 응용프로그램들이 지금은 오래되었다는 것, 두 번째로 그것들을 고치기 위해서는 정말 복잡한 자바스크립트를 추가해야 한다는 것입니다. 이렇게 슬플수가...

이런 책들과 기사들 (이름은 언급하지 않겠습니다. 요즘들어 변호사 비용이 비싸졌기 때문에...) 모두 진짜 Atlas 프로그래머가 되기 위한 것들을 포함했다고 보지만, 저는 블랙박스로 감춰진 것들을 숨기지 말고, Ajax와 JavaScript 그리고 좋은 평가 수단으로서의 XMLHTTPRequest 객채들을 이해해야 한다고 생각합니다. 이것은 1985년의 진짜 C 프로그래머가 되기 위해 겪었던 악몽과도 같은 일의 재현입니다. 여러분은 실제로 무언가 잘못된 경우 때문에 어셈블러를 이해해야 할 필요가 있었으며, 레지스터에 무엇이 있었는지 보기 위해 스냅샷 디버거에 프로그램을 넣기도 했었습니다. (잠시동안 그런 일을 하지 않았지만, 전 더 많은 것들을 잃어버리지 않았습니다.)

아니, 전 그것을 갖지 않길 원했습니다. 추상화의 사다리 위로 올라가 있는 것은 좋은 것입니다. 우리가 더 높은 추상화 단계의 도구를 사용하는 것을 말했을 때가 옳았습니다. 마이크로소프트와 다른 벤더들이 제공하는 잘 테스트된 컨트롤들을 연결하는 것을 떠나서, 우리는 문제에 더 집중할 수 있습니다. 저는 자료형도 불안정하고 객체지향적이지도 않은 자바스크립트를 쓰게끔 된다면 욕을 해댈겁니다. 연기속에서, 하수도 아래에서, 문 밖에서 진행해온 20년. 우웩~

운좋게도, 그것은 얼리어답터의 조각난 현미경 렌즈를 통해 보이는 수평선에 나타난 키메라입니다. 스크립트 지향적 접근은 자바스크립트 기반이 최고라고 알고 있는 사람들이 탐사중인 먼저 배포된 기술의 인공물입니다. Ajax가 큰 관심을 얻으며 시작됐을 때, 그것을 쓰려던 사람들은 실제로 자바스크립트 애호가들이었습니다. 그들은 사용자들이 경험했던 것보다 충분히 다른 차이점을 갖춘 클라이언트 측의 자바스크립트 코드를 만들 수 있었던 사람들이었습니다.

Atlas 전문가는 스크립트 전문가와 같다고 인식됩니다. 하지만, 잘못된 인식은 노출될 필요가 있으며 가능한 빨리 깨져야 합니다. ASP.NET 프로그래밍 4판이 출간되었을 때, 우리는 Atlas를 충분히 다룰 것입니다만, 자바스크립트에 대해서는 거의 다루지 않을 것입니다. 저는 응용프로그램 프로그래머들이 응용프로그램에 초점을 두고, 컨트롤 프로그래머들이 훌륭히 캡슐화된 (사용자들이 제공할 수 없는, 블랙박스를 여는 것이 워런티를 피하는 것이 아닌) 컨트롤들을 완성하는데 초점을 둘 것이라고 생각합니다.

이 기사는 자바스크립트를 보여주지 않습니다.

이 기사를 쓰는 동안, 저는 Atlas 컨트롤들과 Visual Studio 2005에서의 그래그 앤 드랍을 사용하여 하향식으로 프로그래밍을 시작하고 있습니다. 그리고 가능한 모든 곳에서 블랙박스 안을 들여다보지 않을 것입니다. (모든 사람들이 불가능하게 보거나, 적어도 죄받을 만한 일이라고 봅니다만, 아닌가요? 그러나, 제가 어떻게 일반 ASP.NET 컨트롤들을 알려드릴지에 따라 결정될 것입니다.)

모든것을 다룰까요? 아니오. 그러나 우리는 여러분이 작업할 ASP.NET 프로그램을 어떻게 하면 빠르고 쉽게 Atlas 컨트롤들을 사용하여 개선할지에 대해 구성할 것입니다. Atlas 컨트롤들은 마이크로소프트에서 무료로 다운로드 할 수 있으며 잘 작동합니다. 그리고 제 생각엔 여러분들이 이 방법들을 배우자마자 이 방법을 지지할 것이라 생각합니다.

여러분이 Atlas 응용프로그램을 작성하는데 필요한 것

Microsoft Atlas 웹사이트는 여러분이 원하는 것에 대해, 그리고 파일들을 어떻게 설치할지에 대해 (잘 아시다시피, 비주얼 스튜디오에 어떻게 통합하는지) 아주 좋은 설명을 제공합니다. ASP.NET Atlas 홈페이지를 검색하고 JUNE CTP 와 관련된 다운로드 아이콘을 클릭해주십시오. (짐작컨데 지금 최신의 CTP가 있다면 그걸 써보고 싶고, 이 기사의 예제 코드가 잘 작동하길 바라거나 약간만 수정해서 가능하기를 바랄 것입니다.) June CTP는 문서, 예제, 설치 3 부분으로 구성됩니다. 설치부분만 사용해도 됩니다만, 여러분은 3가지 모두를 원할 것입니다. 완료했을 때 홈페이지로 돌아가서 Atlas 컨트롤 툴킷에 클릭하십시오. 이 기사 다음에 클릭 하시는 것이 좋을 것입니다.

다운로드한 것에는 여러분의 도구상자에 Atlas와 Atlas Toolkit, 두 탭을 추가하는 것과 (정확한 DLL을 검색할 수 있는 수단인) 컨트롤들을 탭에 두는 것에 대한 지시사항을 포함합니다. 이 작업은 무척 쉽습니다. 만약 드래그 앤 드랍 접근이 적용되지 않는다면, 여러분은 항상 도구상자 탭에서 오른쪽 클릭을 하고 "Choose Items"를 선택한 후 "Browse"를 클릭하여 Bin 디렉터리에 있는 DLL을 선택할 수 있습니다. 그렇게 하면 그림 1에 보이는 것처럼 모든 Atlas 컨트롤들을 dll로부터 탭에 추가할 것입니다.


그림1. dll로부터 컨토를을 더하기

동작하는 프로그램으로 시작하기

5월에 저는 Building a Web-Based Bug Tracking Application를 출판했습니다. 기사와 완벽한 소스는 제 웹 사이트에서 얻으실 수 있습니다. (책을 클릭하고 기사를 클릭하십시오.) 저희는 존재하는 응용프로그램을 개선하기 위해 Atlas 기능을 추가하는 시작점으로 Tiny Bug Tracker를 구성하는 응용프로그램을 이용할 것입니다. 나아가서 여러분이 이미 작성한 어떤 웹 응용프로그램을 개선하는데 Atlas 컨트롤들을 추가할 수 있을 것입니다.

Tiny Bug Tracker의 목적은 개인 프로그래머(혹은 아주 작은 그룹의 프로그머들)에게 알려진 버그들의 진행, 작업, 수정, 그리고 팀의 여러 구성원들이 버그 항목의 닫은 상태를 추적하기 위한 간단한 웹 기반 응용프로그램을 제공하는 것입니다. 그림 2에서 보이는 것처럼 웹 사이트 관리자 도구를 사용하여 사용자와 역할을 생성하는 것으로 시작합니다.


그림2. WAT로 사용자 추가하기

다음으로 그림 3에서 보이는 것처럼, 응용프로그램을 사용하기 위해 사용자가 인증을 합니다.


그림3. 로그인

그림 4에서 보이는 것처럼 사용자들은 버그를 입력하기 위해 새로운 버그 형식을 제공하는 (또한 버그를 수정하는데 사용되는) 메뉴를 클릭할 수 있습니다.


그림4. 버그 입력하기

이 버그들의 모든것은 그림 5에 나타난 것과 같이, Bugs 테이블에 각 버그에 대한 하나의 항목, BugHistories 테이블에 버그의 각 수정에 대한 하나의 항목으로 이뤄진 TBTData 데이타베이스에 위치합니다.


그림5. 버그 데이터베이스

여러분의 데이타베이스에 버그를 갖게 되면, 여러분은 TBTReview.aspx 에서 버그들을 다시 볼 수 있습니다. Details 를 클릭하는 것은 그 버그에 대한 세부사항 패널을 전달하고, 규격과 다른 영역을 나타냅니다. 그림 6 과 같이 History 를 클릭하는 것은 주어진 버그에 대한 각각의 변경된 점을 갖는 규격을 전달합니다. 그리고 그 변경된 점에 대한 세부사항을 나타나게 할 수 있습니다.


그림6. 미리보기

우리가 이 응용프로그램이 가지고 있는 문제를 해결하는데 Atlas가 도움이 됩니다. 여러분이 한 버그의 세부사항에서 다음 세부사항으로 이동할 때마다, 전체 페이지가 서버에 다시 포스트 됩니다. 거기엔 지연시간이 있으며 그 때문에 화면의 깜빡임이 있습니다. 또한, 미리보기를 스크롤하면서, 새로운 버그에 들어가려 할 때에는, 메뉴가 맨 위에 있어서 다시 스크롤을 위로 올려야 합니다. 이 부분은 사용하기 편한 메뉴가 될 것입니다. 마지막으로, 만약 여러분이 새 버그로 들어갈 때 Cancel 을 클릭하면 이 작업은 취소됩니다. 겉으로 드러내지 않고 바로 작업처리를 버리는 것입니다.

Atlas 버전 생성하기

작업을 편하게 하기 위해, 이미 있는 응용프로그램에 Atlas 컨트롤들을 추가하는 것보다, 새 Atlas 응용프로그램을 만드는 것이 좋습니다. 그 다음에 이전 응용프로그램에 있던 페이지들을 추가할 것입니다. 이 방법은 비주얼 스튜디오가 Atlas 에 필요로 하는 모든 레퍼런스들을 설치할 것이며, 이전 기사의 페이지들을 사용하여 기본 응용프로그램 코드가 작동하는지 알 수 있도록 하고, 기본적인 기능들을 다시 시험해보지 않도록 합니다. 저는 Atlas의 June CTP 버전을 사용하고 있다는 것을 주의하십시오. 만약 여러분이 다른 버전을 사용하고 있다면, 여러분의 재량에 따라 결과가 다를 것입니다.

원본 기사를 잠시 읽어본다면 다음의 내용이 훨씬 쉽게 이해될 것입니다. 전 여기서 기다릴 것입니다. 여러분이 읽어보실 시간을 갖으십시오. 전 다른 프로젝트를 작업할 것입니다. 준비되면 저를 깨워주세요.

첫번째 개선: 깜빡임 감소-각 페이지의 일부분만 갱신하기

Tiny Bug Tracker 응용프로그램의 가장 큰 문제 중 하나는 다른 버그의 세부사항에 대해 요청할 때마다, 전체 페이지가 다시 그려지고 지겨운 깜빡임을 유발한다는 것입니다. (캐쉬로 인해 데이터베이스는 매번 멈추지 않으나, 서버에 대한 라운드 트립이 현저한 정지 상태를 유발합니다.)

우리는 업데이트 되어야 할 페이지의 일부분만을 업데이트 하도록 Atlas를 사용할 수 있습니다. 그렇게 하기 위해, 우리는 TBTReview 페이지에 네가지 업데이트 패널을 추가할 것입니다. 업데이트 패널은 페이지의 다른 것들과 독립적으로 갱신되기 위해 세부적으로 설계된 Atlas 컨트롤입니다. 이것이 어떻게 동작하는지에 대한 세부사항을 아는 것은 매력있는 것이지만, 여러분이 실제로 기억할 내용은 이것이 비동기적으로 동작한다는 것입니다. 즉, 전체 페이지를 모두 다시 포스트 할 필요가 없습니다. 심지어 더 좋은 것은, 여러분이 도구상자로부터 페이지에 드래그 하여 바로 올려놓는 것으로 각 업데이트 패널을 생성할 수 있다는 것입니다. (얼쑤!) 그것 참. 비주얼 스튜디오가 여러분들을 위해 작업을 해줍니다. (또한 여러분은 소스 뷰에 수동으로 업데이트 패널을 추가하는 것으로 업데이트 패널을 생성하거나, 실행시에 C#에서 동적으로 업데이트 패널을 추가할 수 있습니다.)

단계적으로 Atlas 응용프로그램 생성하기

여러분은 여러분이 가지고 있는 응용프로그램에 Atlas 컨트롤들과 라이브러리들, 레퍼런스들을 추가하는 것으로 새 응용프로그램을 생성할 수 있습니다. 정말입니다. 그러나 제가 위에서 말했듯이, 저는 그렇게 하지 않을 것입니다. 왜냐하면 베타 소프트웨어와 함께 비주얼 스튜디오가 한 번에 모든 것을 설치하도록 하는 것을 좋아하기 때문입니다. 그래서, 저는 그림 7에서 나오듯이 새 웹 사이트를 생성하고 템플릿에 "Atlas Web Site"를 선택하는 것으로 Atlas 버그 트랙커라고 불리는 웹 사이트를 생성할 것입니다.


그림7. 새로운 Atlas 웹사이트 생성하기

기본적인 사이트는 기본적으로 포함되어 있는 readme.txt, eula.rtf, default.aspx, web.config, 그리고 bin 안에 있는 Microsoft.Web.Atlas.dll 과 같은 몇몇 파일들로 구성될 것입니다. readme.txt, eula.rtf, Default.aspx 파일을 지우세요. 여러분은 그것들을 필요로 하지 않을 것입니다.

WAT를 열고, security 탭에서 forms-based authentication을 선택한 다음, 이전 응용프로그램에 있었던 사용자 이름과 역할을 생성하십시오. (Alex, Dan, Jesse, Ctacey와 같은 이름, Developer, Manager, QA, 그리고 User 등과 같은 역할)

TBTMaster.master, TBTReview.aspx, TBTBug.aspx, TBTWelcome.aspx 페이지와 그 뒤의 코드 페이지에 복사하십시오. 그리고 그것들을 프로젝트에 추가하십시오. web.config 파일에 복사하지 마십시오.

WAT가 여러분이 Atlas 프로젝트를 선택할 때 여러분들을 위해 생성된 web.config 파일을 수정했습니다. 그래서 여러분들은 폼 기반 보안을 갖는 Atlas 페이지로서 양쪽의 조합된 설정을 동시에 가지고 있습니다.

여러분들은 프로그램을 변경하기 이전에 프로그램을 실행해보길 원할 것이고, 모든 설정이 잘되었는지 확인하길 원할 것입니다.

주의: 완성 소스 코드는 (책을 클릭하고 기사를 클릭하면 나오는) 저의 웹사이트에서 다운로드 받을 수 있습니다. 제 개인적인 지원 포럼에 대한 링크와 흥미로울만한 내용도 같이 있습니다.

스크립트 관리자

Atlas에 대한 핵심 컨트롤은 스크립트 관리자입니다. 가상적으로 모든 Atlas 컨트롤은 컨트롤이 있는 페이지가 스크립트 관리자를 필요로 합니다. 그 페이지에서 모든 Atlas 컨트롤들을 조정하는 것이 스크립트 관리자의 일입니다. 운좋게도, 이 응용프로그램은 주 페이지를 가지고 있으므로 스크립트 관리자를 주 페이지에 하나만 놓는 것으로 응용프로그램의 각 페이지에 대한 스크립트 관리자를 제공할 수 있습니다.

우리가 스크립트 관리자에 추가할 필요가 있는 한가지 속성은 EnablePartialRendering= "True" 입니다. 왜냐하면 이 속성이 페이지 전체를 포스트하지 않고 비동기적으로 페이지의 일부분을 나타나도록 하는 기능을 작동시키기 때문입니다.

여러분은 스크립트 관리자 컨트롤을 주 페이지 어디에든 위치할 수 있습니다. 저는 로그인 상태 컨트롤 아래에 바로 두었습니다.

<atlas:ScriptManager ID="ScriptManager1" runat="server" EnablePartialRendering="True" />

컨트롤을 도구상자로부터 드래그 앤 드랍하는 것은 아마도 페이지에 컨트롤을 추가하는 가장 쉬운 방법일 것이며, 그렇게 하는 것이 페이지에 컨트롤을 적절하게 등록하도록 보장합니다. 하지만 그렇게 할 때 그림 8에서 보이는 것처럼 Destination File Exists 대화상자를 보게 될 것입니다.


그림8. Destination File Exists

컨트롤이 페이지에 추가될 때, 그것은 대화 상자와 함께 Microsoft.Web.Atlas.dll 을 보냅니다. Yes를 클릭하고 파일을 갱신하지 않을 이유가 없습니다.

섹션에 TBTReview를 쪼개넣기

배치해놓은 스크립트 관리자로, 이미 여러분은 다양한 규격들에 대한 비동기 업데이트들과 DetailsView 객체들을 TVTReview 페이지에 추가할 준비가 되었습니다. 그렇게 하기 위해 페이지에 있는 도구상자의 Atlas 탭으로부터 4개의 UpdatePanel 객체들을 드래그하십시오. 각 UpdatePanel은 독립적으로 갱신될 수 있는 UI의 블럭을 나타냅니다. 저는 BugReviewGrid와 그것의 데이터 소스를 처음에 두고, BugDetailsView와 그 데이터를 2번째에, BugHistoryGrid와 그 데이터를 세번째, BugHistoryDetailsView와 그 데이터 소스를 4번째에 두었습니다. 여러분들도 Design 뷰에서 드래그 앤 드랍을 하거나, 소스뷰에서 HTML을 옮기는 것으로 이 작업을 할 수 있습니다.

예를 들어 그림 9에서 UpdatePanel2 를 폼에 드래그 했고 패널에 BugDetailsView를 드래깅하고 있습니다.


그림9. 업데이트 패널에 드래그하기

마우스 버튼을 떼었을 때, 소스뷰 안에서 HTML에 반영되는 것으로 BugDetailsView와 이것의 SqlDataSource가 Update Panel 안에 내장될 것입니다. (간소하게 여기선 생락되었습니다.)

<span class="style1"><atlas:UpdatePanel ID="UpdatePanel2" runat="server">
     <ContentTemplate></span>
         <asp:DetailsView ...  </asp:DetailsView>
          <asp:SqlDataSource ...>   </asp:SqlDataSource>
     <span class="style1"></ContentTemplate>
  </atlas:UpdatePanel></span>
</span>

성능상으로 변경된 것들은 즉각적이고 놀랄만한 것입니다. 갑자기 페이지가 껌뻑임을 멈췄습니다. 여러분이 어떤 버그의 세부사항에서 다른 버그로 이동할 때, 부드럽고 빠르며 껌뻑임도 없습니다. 차이점이 실제 그러한지 확인하기 위해 마스터 페이지에 있는 스크립트 관리자에서 EnablePartialRendering="True" 속성을 제거하고 응용프로그램을 다시 실행해보십시오. 결코 모르지 않을 것입니다. (속성을 되돌려 놓는 것을 잊지 마십시오!)

엄마 봐봐! 자바스크립트가 없어.

잠시 멈추고 자바스크립트를 쓸 시간이 없었다는 것에 주목하십시오. 여러분은 XMLHttpRequest를 건들지 않았으며, 이것이 어떻게 동작을 완료하는지 생각하지도 않았습니다. 이것은 예를 들어 DataGrid 컨트롤이 스스로 작동하는 것처럼 모두 아주 놀라울 만한 것들입니다. 제 말의 요점이 이것입니다. 단순히 괜찮은 것이 아니라 엄청나게 좋습니다. 이러한 무시가 여러분들이 시도하려는 것에 초점을 맞추도록 만들며, Microsoft가 컨트롤들을 제작하는데 힘을 쏟도록 만듭니다. (이봐요! 그만 훌쩍거려요. 만약 당신이 정말로 그게 어떻게 동작하는지 알기 원한다면, 제가 장담하죠. 우리는 모든 잔인할 정도의 세부사항을 지향하는 자바스크립트와 Atlas 프로그램에 대한 책을 엄청나게 많이 가지고 있습니다. 그러나 작업을 완료하기 위한 관점에서는 한순간으로 충분하지 않나요?)

그러나 더 많은게 있습니다...

좋아요, 우리는 비동기식 업데이트를 완성했고, 여기까지는 Atlas 에 관한 아주 좋은 감정을 느낄 수 있습니다만, 잠시만 컨트롤 익스텐더들에 대해 짚고 넘어가자고요. 여러분은 Atlas 도구키트로 아주 일부를 얻었습니다. (그리고 더 많은 것들은 시간이 알려주겠죠.) 제가 정말로 좋아하는 것은 AlwaysVisible 익스텐더 입니다. 이것은 여러분이 어떤 컨트롤을 갖출 수 있도록 하며, "사용자들이 이것으로 스크롤 하도록 내 페이지에 보이게 하길 원해." 라고 말하게 할 것입니다. 그뿐만이 아니라 이것은 이것저것 따져봐도, 아주 인상깊으며, 실제로 아주 유용합니다. 이것은 여러분들에게 어떤 혼란 없이 프레임들의 힘과 (아까 전에 제 디자이너 친구들이 저에게 말하는 프레임들)을 부여할 것입니다.

우리의 주 페이지는 익스텐더에 대한 몇몇 수정될 항목을 가지고 있습니다. 그 중의 하나가 사용자가 버그를 추가하도록 하게 해주는 메뉴입니다. 심지어 그/그녀가 다시보기 페이지에서 스크롤을 했을 때에도 사용자가 그 메뉴를 쓸 수 있다면 좋을 것입니다. 이것은 황당할 정도로 너무 쉽게 고칠 수 있습니다.

TBTMaster.master 를 열고 페이지에 AlwaysvisiblecontrolExtender 의 인스턴스를 드래그 합니다. 소스 뷰에서 이렇게 하세요. 여는 태그와 닫는 태그 사이에 여러분은 AlwaysVisibleControlProperties 형식의 한가지 요소를 추가할 것입니다. (여러분들의 지력으로 여러분들 스스로 알아맞춰 보세요.) 여러분들은 이미 속성에 대해 알고 있겠지만, 저는 그것들을 여러분들에게 보여줄 것입니다.

TargetControlID="mnuTBTNavigation"
VerticalSide ="top"
VerticalOffset = "10"
HorizontalOffset ="10"
HorizontalSide ="right"
ScrollEffectDuration =".1" />

TargetControlID는 여러분이 보이도록 만들 컨트롤입니다. 이 경우는 menu 입니다. 수직, 수평부분은 (그림 10에서처럼) 메뉴를 어디에 나타내게 하는지 지시합니다. 오프셋은 왼쪽 상단으로부터 여러분이 원하는 만큼 얼마나 떨어지게 하는지, 그리고 스크롤 효과 시간을 여러분이 얼마나 유지할 것인지에 대한 값입니다. (이 경우 0.1초 입니다.) 저는 이것을 허용하는 것을 싫어합니다만 이것은 여러분들이 결정하십시오. Atlas는 나머지를 제거합니다. 스크롤을 하면서 메뉴는 애완견처럼 여러분을 따라다닙니다.


그림10. 항상 보이는 메뉴

여러분이 버그의 세부사항을 찾아보기 위해 스크롤하는 만큼 메뉴가 따라다니다니 놀랍군요. 이렇게 간단한 것만으로도 다른 사람들은 엄청 힘들게 만들만한 것을 쉽게 만들다니... 전 이런 모든 것들을 폼에 드래그 하고, 이것이 작동하도록 마이크로소프트사가 하나의 컨트롤에 캡슐화 했다는 사실이 너무나 좋습니다. --풉!-- 네, 시간이 지났어요. 저는 그것들이 어떻게 동작하는지 알았으면 합니다만, 여러분은 어떤가요? 전 마감할 때가 다 되었고, 이 프로그램은 잘 동작합니다.

취소를 위한 트랩 생성하기

우리가 십수번 (혹은 천 번 넘게) 쓰는 코딩 중 하나가 취소 버튼을 위한 "트랩"입니다. 우리는 사용자가 Cancel을 클릭할 때, 사용자에게 그/그녀가 작업한 내용을 모두 취소한다는 내용을 확인하기 위한 팝업창을 원합니다. 이것은 ASP.NET 응용프로그램 안에서 장난처럼 작성될 수 있습니다. 몇몇 자바스크립트에서 필요로 하는 대화상자처럼 말이죠. 다시 한 번 Atlas는 이런 하찮은 것뿐만이 아니라, 나머지 부분도 똑같이 구성하여, 현재 가지고 있는 응용프로그램과 경계없이 통합됩니다.

TBTBug.aspx 파일은 btnSave와 btnCancel, 두 컨트롤들을 가지고 있습니다. btnCancel에 대한 트랩을 추가하기 위해 여러분이 해야 할 모든것은 ConfirmExtender를 두 버튼이 있는 셀에 드래그 하는 것입니다.

<td colspan="2">
  <AtlasToolkit:ConfirmButtonExtender
  ID="ConfirmButtonExtender1" runat="server">
     <AtlasToolkit:ConfirmButtonProperties ConfirmText="Are you sure you want to discard this?"
      TargetControlID="btnCancel" />
  </AtlasToolkit:ConfirmButtonExtender>
   <asp:Button ID="btnSave" runat="server" Text="Save" BackColor="Lime" Font-Bold="True" OnClick="btnSave_Click" />
   <asp:Button ID="btnCancel" runat="server" Text="Cancel" BackColor="Red" Font-Bold="True" ForeColor="Yellow" OnClick="btnCancel_Click" />
</td>

이 효과는 그림 11과 같습니다.


그림11. 취소 확인

ConfirmExtender는 자체적으로 두 가지 속성을 갖는 ConfirmButtonProperties 형식의 내부적인 속성을 가집니다. 한 속성은 메시지 박스 안에 표시될 텍스트에 대한 것이고, 다른 하나는 확인을 알리는 버튼을 확인하기 위한 것입니다.

이 작업을 위해, 컨트롤은 꼭 등록되어 있어야 합니다만, 이것은 여러분이 폼에 컨트롤을 드래그 할 때에 이미 완료되었습니다. 얼씨구나! 제가 사용하는 버전 안에선 태그가 CC1에 설정되어 있지만, 여러분이 원하는 대로 태그를 변경하는 것도 간단합니다. 저는 그것을 AtlasToolkit 으로 변경했습니다.

<%@ Register Assembly="AtlasControlToolkit" Namespace="AtlasControlToolkit" TagPrefix="AtlasToolkit" %>

그래서 제가 컨트롤을 사용 할 때, 저는 이렇게 코드를 쓸 수 있습니다. <AtlasToolkit:ConfirmButtonProperties, 컨트롤의 소스 중 일부입니다. 꼭 필요하진 않지만, 좋습니다.

Toolkit과 함께 유용한 컨트롤들이 많이 있습니다. 그리고 Atlas에서 볼 수 있는 How Do I 시리즈 비디오 튜토리얼을 보기를 권합니다. 그것은 이 부분과 이후의 것도 모두 다룰 것입니다. 여러분은 어떤 Atlas 컨트롤들이 발표되었는지 꾸준히 업데이트 되는 내용을 RSS 피드를 통해 구독하길 원할지도 모르겠습니다.

이 글 전체를 통틀어, 어느 누구도 여러분에게 Atlas가 어렵다고 강요할 수 없습니다. 주안점은 이것이 ASP.NET처럼 쉽고, 여러분의 응용프로그램을 구성하는데 초점을 두도록 하며 밑바닥에서부터 구성하도록 만들지 않는다는 것입니다.

Jesse Liberty 는 Microsoft .NET MVP 이며 베스트셀러인 오라일리 미디어의 ASP.NET 프로그래밍, C# 프로그래밍, VB2005 프로그래밍, 그리고 수십권의 웹과 객체지향 언어에 대한 다른 책들의 저자입니다. 그는 .NET 에서 계약 프로그래밍, 상담, 그리고 온라인 강좌를 제공하는 자유연합의 대표입니다.

출처 : 한빛 네트워크

이 문서 내용:
　- ASP.NET “Atlas” 소개
　- Atlas 아키텍처
　- 클라이언트 및 서버 컨트롤
　- Atlas와 웹 서비스

목차
　- Atlas란?
　- Atlas 아키텍처
　- 클라이언트 스크립트 핵심 라이브러리
　- 클라이언트 스크립트 컨트롤과 구성 요소
　- 서버 컨트롤
　- 웹 서비스
　- 결론

2005년 9월, ASP.NET 팀은 "Atlas"라는 코드명의 ASP.NET에 도입된 새 기능에 대한 첫 CTP(Community Technology Preview) 버전을 발표했습니다.

Microsoft .NET Framework 2.0에 적용되는 이 확장 기능을 사용하여 개발자는 브라우저와 서버의 기능을 모두 활용하여 풍부한 기능의 대화형 웹 사이트를 보다 쉽게 만들 수 있습니다.

Atlas에서 제공하는 풍부한 개발 환경을 흔히 AJAX(Asynchronous JavaScript and XML)라고 하며, 이는 그 동안 사용된 여러 가지 기술의 이름을 결합하여 만든 비교적 새로운 머리글자어입니다. 요즘에 사용되는 브라우저에는 JavaScript에서 서버를 호출하는 데 사용할 수 있는 XMLHttpRequest 개체가 포함되어 있는데, 이 개체를 사용하면 웹 페이지에서 사용자가 입력한 내용에 반응하여 전체 페이지를 새로 고치지 않고도 대역 외 작업을 수행할 수 있습니다. 이 개념 자체는 단순하지만 AJAX 라이브러리는 서버와 통신하고 웹 서비스에서 반환되는 XML을 처리하기 위해 클라이언트 쪽 JavaScript를 작성해야 하는 고된 작업을 크게 줄여줄 수 있습니다.

AJAX를 통해 해결하려는 일반적인 문제들은 대개 HTTP 프로토콜 자체의 특성에서 비롯됩니다. HTTP는 브라우저가 웹 서버와 통신하여 웹 페이지를 가져오고 데이터를 웹 서버에서 받아 다시 게시하기 위해 사용하는 표준 프로토콜로서, 상태를 저장하지 않는 방식의 프로토콜이므로 페이지를 새로 고치기 전에는 사용자의 입력이 서버의 코드에 전달되지 않습니다. 따라서 일반적인 사용자 환경에서는 상태 정보를 서버로 보내기 위해 전체 페이지를 새로 고쳐야 합니다. 사용자가 페이지에 입력한 내용은 서버에서 처리된 후 HTML 형식으로 복원되어 브라우저로 다시 보내집니다.

ASP.NET에서는 이러한 프로세스를 화면에 보이지 않는 폼 필드를 사용하여 관리합니다. 페이지의 일부만 업데이트되더라도 전체 페이지의 HTML이 전송되므로 브라우저 화면은 일시적으로 비어 있게 됩니다. 또한 페이지의 내용을 새로 고치기 위해 브라우저에서 새 내용을 받아 렌더링하는 동안에는 사용자가 웹 페이지와 상호 작용할 수 없습니다. AJAX는 이러한 환경을 개선하기 위해 전체 페이지를 새로 고치지 않고도 서버를 호출하여 웹 서비스를 실행할 수 있는 XMLHttpRequest 개체를 사용합니다. 이 개체를 사용하면 수신한 XML을 기반으로 페이지의 업데이트할 부분을 JavaScript에서 직접 수정할 수 있습니다. 사용자는 페이지가 업데이트되고 있는지 알아챌 수 없으며, 작업은 대역 외 방식으로 백그라운드에서 비동기로 실행되므로 그 동안에도 계속해서 웹 페이지를 읽거나 상호 작용할 수 있습니다.

Atlas란?

ASP.NET의 Atlas 기능을 단지 클라이언트 중심의 웹 응용 프로그램을 만들기 위한 또 하나의 AJAX 스크립트 라이브러리로 생각해서는 안 됩니다. Atlas는 .NET Framework 2.0을 기반으로 만들어졌으며 클라이언트 쪽 JavaScript와 XMLHttpRequest 개체의 기능을 보다 잘 활용할 수 있도록 지원합니다. 또한 기존 ASP.NET 응용 프로그램뿐 아니라 Atlas 컨트롤과 서비스에서 사용하는 클라이언트 스크립트 라이브러리도 손쉽게 향상시킬 수 있는 서버 기반 기능을 갖추고 있습니다. 그림 1의 Atlas 아키텍처 다이어그램은 Atlas가 클라이언트와 서버 모두를 확장하며, 기능이 더욱 다양하고 응답이 보다 빠른 브라우저 간 웹 응용 프로그램을 만들 수 있는 광범위한 개발 기술로 간주되어야 함을 보여 줍니다.


그림 1 ASP.NET Atlas 아키텍처

Atlas를 활용할 수 있는 시나리오는 JavaScript를 비동기식으로 호출하여 웹 페이지의 일부를 업데이트하는 것에 한정되지 않으며 그 동안 구현하기 힘들었던 다양한 클라이언트 환경을 만드는 데 사용할 수 있습니다. 예를 들어 영화 관련 데이터로 구성된 웹 응용 프로그램이 있다고 가정해 보겠습니다. 사용자가 이 응용 프로그램을 사용하여 특정 배우를 검색할 수도 있습니다. 모든 배우 이름을 하나의 드롭다운 목록으로 만들어 제공하는 것은 비현실적이므로 선택의 폭을 좁힐 수 있는 다른 방법을 찾아야 합니다. 예를 들어 배우 이름의 첫 번째 글자를 선택하도록 사용자에게 요청하고 이 글자로 서버에 요청하여 해당 글자가 포함된 목록을 제공하면 처리가 보다 수월해지지만 사용자 입장에서는 귀찮은 일이 됩니다. 또 다른 방법으로, 배우의 이름 중 일부만 입력하여 검색할 수 있는 입력란을 제공할 수도 있습니다. 그러면 서버에서 사용자가 입력한 데이터를 기준으로 검색의 범위를 좁힐 수 있을 것입니다. 첫 번째 방법보다는 낫지만, 이 방법 역시 여전히 개선의 여지가 있습니다. Atlas를 사용하면 사용자의 입력에 따라 동적으로 반응하는 입력란을 제공하여 브라우저에서 전체 페이지를 새로 고칠 때까지 기다리지 않고도 검색 범위를 좁힐 수 있습니다. 그림 2는 Atlas를 사용하여 사용자의 입력에 따라 피드백을 제공하는 자동 완성 동작을 추가한 모습을 보여 줍니다.


그림 2 필터링 콤보 상자

Atlas CTP는 atlas.asp.net (영문)에서 다운로드할 수 있습니다. Atlas CTP를 설치하면 C# .NET 및 Visual Basic .NET용 추가 웹 사이트 템플릿이 Microsoft Visual Web Developer™에 추가되므로 Visual Web Developer에서 파일, 새로 만들기, 웹 사이트를 차례로 클릭하여 웹 사이트 프로젝트를 새로 만들 때 그림 3과 같은 대화 상자가 표시됩니다. Atlas 기반의 ASP.NET 기능을 사용하기 위해, Atlas 웹 사이트에는 웹 응용 프로그램을 구성하는 업데이트된 web.config 파일과 Microsoft.Web.Atlas.dll이 포함됩니다. 현재 릴리스의 경우 Microsoft.Web.Atlas.dll은 응용 프로그램 전체에서 사용할 수 있는 로컬 어셈블리로 응용 프로그램의 bin 디렉터리에 배치됩니다.


그림 3 Atlas 웹 사이트 만들기

Atlas 기반 응용 프로그램은 Atlas를 별도로 설치할 필요 없이 개발 컴퓨터에 있는 파일을 ASP.NET 2.0이 있는 서버로 복사하여 쉽게 배포할 수 있습니다. Atlas는 시스템 수준이 아니라 응용 프로그램 수준에서 설치되므로 다음 버전의 CTP가 제공되면서 기능이 발전하고 변경될 경우 이전 버전의 Atlas가 있는 컴퓨터에서 새 버전을 사용할 수 있습니다. 따라서 시스템 수준으로 설치하는 경우보다 더욱 유연하게 마이그레이션할 수 있습니다.

Atlas 아키텍처

그림 1의 Atlas 아키텍처 다이어그램에서 가장 먼저 주목해야 할 사실은 Atlas가 클라이언트와 서버 양쪽 모두에 적용된다는 점입니다. ASP.NET 2.0에 몇 가지 클라이언트 기능이 추가되었지만 이는 Atlas의 적용 범위에 미치지 못합니다. 아키텍처 다이어그램의 오른쪽을 보면 Atlas의 서버 기능이 ASP.NET 2.0을 기반으로 이를 확장하고 있음을 알 수 있습니다. Atlas는 브라우저에서 서버 기반 데이터와 서비스에 액세스할 수 있는 새로운 기능뿐만 아니라 새로운 서버 컨트롤 집합도 제공합니다.


그림 4 일반적인 클라이언트-서버 상호 작용

다이어그램 왼쪽에는 서버 기능과는 별도로 클라이언트 중심의 JavaScript를 만들 때 사용할 수 있는 포괄적인 클라이언트 스크립트 라이브러리가 나와 있습니다. 이 라이브러리는 향상된 클라이언트-서버 상호 작용이 가능한 풍부한 기능의 응용 프로그램을 개발하기 위해 새 Atlas 기능에서 많이 사용하는 클라이언트의 기반 구조라 할 수 있습니다.

그림 4는 웹 응용 프로그램의 일반적인 클라이언트-서버 상호 작용 방식을 보여 줍니다. 먼저 브라우저에서 웹 페이지를 요청하고 사용자는 이 페이지와 상호 작용합니다. 사용자의 작업을 위해 서버의 데이터가 필요하면 전체 페이지가 새로 고쳐지며


그림 5 Atlas의 클라이언트-서버 상호 작용

사용자 입력에 따라 페이지의 일부를 업데이트합니다. 그러나 이 방식에서는 페이지가 업데이트되는 동안 사용자가 페이지와의 상호 작용을 계속할 수 없습니다. 즉, 사용자는 웹 응용 프로그램에서 작업하는 동안 계속해서 작업을 일시 중단해야 합니다.

그림 5는 전체 페이지를 새로 고칠 필요가 없는 Atlas의 클라이언트-서버 상호 작용 방식을 보여 줍니다. 이 방식에서는 처음 HTML을 가져온 후 서버를 다시 호출할 경우 XML, JSON(JavaScript Object Notation) 또는 HTML 조각으로 업데이트된 데이터를 가져와 페이지를 증분 업데이트합니다. 웹 서비스를 호출하거나 페이지 변경 내용을 가져오기 위한 호출이 비동기식으로 백그라운드에서 수행되므로 사용자는 작업을 일시 중단할 필요가 없습니다. 이러한 비동기식 호출에서는 서버로의 다음 번 다시 게시 작업을 위해 업데이트된 보기 상태 정보를 관리하므로 페이지를 완전히 새로 고쳐야 할 경우 페이지의 정확한 상태를 서버에 전달합니다.

클라이언트 스크립트 핵심 라이브러리

Atlas의 클라이언트 스크립트 라이브러리는 분리된 몇 개의 고유한 조각으로 브라우저에 전달됩니다. 스크립트 핵심은 나머지 라이브러리의 기반이 되는 하위 계층을 구성하며 최하단에는 브라우저 호환성 계층이 자리잡게 됩니다. Atlas의 주요 특징은 AJAX의 주요 요소를 지원하는 최신 브라우저에서만 Atlas가 실행된다는 점입니다. CTP 빌드를 지원하는 브라우저로는 Mozilla Firefox, Apple Safari 및 Microsoft Internet Explorer가 있습니다. 브라우저 호환성 계층은 브라우저의 차이에 신경 쓰지 않고 보다 편리하게 스크립트를 작성할 수 있게 해 주는 추상화 계층입니다. 이 계층을 통해 브라우저의 구현 방식에 의한 차이는 감춰지며 브라우저의 업데이트나 새 버전 발표에 맞춰 Atlas 지원도 쉽게 확장될 수 있습니다. 요청하는 브라우저의 종류에 따라 호환성 계층의 브라우저별 부분 중 어떤 부분이 사용될지 자동으로 결정되며 추상화 계층에 상위 수준의 코드가 미리 작성되어 있으므로 브라우저 구현에 따라 다르게 코딩할 필요가 없습니다.

호환성 계층의 최상단에는 핵심 형식 시스템이 있습니다. 형식 시스템은 JavaScript에서 개체 지향 방식을 사용하기 위한 것으로, JavaScript 개발자는 이 시스템을 사용하여 네임스페이스를 만들고 이 네임스페이스에 클래스를 추가할 수 있으며 개체 상속도 시뮬레이트할 수 있습니다. 또한 인터페이스, 대리자, 열거형을 지원하므로 C# 같은 개체 지향 프로그래밍 언어를 사용하는 서버에서의 코드 개발과 JavaScript를 사용하는 클라이언트 코드 작성 간의 전환이 수월합니다.

그림 6 Using the Atlas Type System

형식 시스템을 기반으로 구축된 기본 클래스 라이브러리 계층은 클라이언트 스크립트 라이브러리의 핵심을 완성합니다. 개념 자체가 .NET Framework를 모방한 것이므로 일부 형식은 이미 사용자에게 친숙할 것입니다. 예를 들어 JavaScript에서 자연스럽게 이벤트를 멀티캐스팅할 수 있도록 지원하는 Event 개체가 있으며 StringBuilder 개체도 있습니다. 또한 JSON과 XML 데이터에 대한 지원뿐 아니라 개체의 직렬화(serialization)도 지원합니다. 기본 클래스 라이브러리에는 브라우저의 XMLHttpRequest 개체에 대한 추상화를 제공하는 WebRequest와 WebResponse 클래스도 있습니다. 이는 .NET Framework의 System.Net 네임스페이스에 있는 개체와 상당히 유사합니다. 그림 6의 코드는 Atlas 스크립트 핵심을 사용하여 JavaScript로 두 개의 간단한 형식을 만드는 방법을 보여 줍니다. 첫 번째 형식인 Movie는 영화의 제목과 장르를 보여주는 두 속성, 그리고 결과를 문자열로 반환하는 toString 메서드를 지원합니다. 두 번째 형식인 Drama는 Movie 형식을 확장하고 toString 메서드를 다시 정의합니다.

그림 7 Inheritance Demonstration

Movie와 Drama 형식을 사용하는 페이지는 그림 7에서 볼 수 있습니다. 이 페이지는 먼저 형식이 정의되어 있는 .js 파일을 참조합니다. 이 파일은 Atlas ScriptManager 컨트롤에 포함되어 있습니다. 그런 다음 Click 처리기에서 Movie와 Drama 형식의 인스턴스를 만들고 이 인스턴스의 toString 메서드를 호출합니다. 사용되는 코드는 동적 JavaScript이지만 상속 동작은 개체 지향 프로그래밍 언어를 사용할 때와 동일합니다. 현재 발표된 Atlas의 또 다른 장점은 클라이언트 스크립트 라이브러리의 디버그 버전이 포함되어 디버깅과 문제 해결이 더 쉽다는 것입니다. JavaScript 디버깅은 항상 번거로운 작업이었으므로 이러한 지원은 많은 수고를 덜어줄 수 있습니다.

클라이언트 스크립트 컨트롤과 구성 요소

AppDomain은 관리 코드의 하위 프로세스를 격리합니다. 이것은 각 AppDomain에 고유의 상태 집합이 있다는 의미입니다. 하나의 AppDomain에 있는 확인할 수 있는 코드는 호스팅 환경에서 작성된 인터페이스가 상호 작용을 허용하지 않는한 다른 AppDomain에 있는 코드나 데이터를 손상시키지 않습니다. 이것이 어떤 방식으로 작동하는지 알아 봅시다. C# 및 Visual Basic .NET 컴파일러에서 기본적으로 작성되는 형식이 안전한 확인할 수 있는 코드는 어떤 방법으로도 메모리에 액세스할 수 없습니다. 각 명령은 형식이 안전한 방식으로 메모리에 액세스하도록 확인 규칙 집합을 사용하여 런타임으로 검사됩니다. 따라서 런타임 검사을 통해 확인할 수 있는 코드를 실행할 때 AppDomain의 격리를 보장하며 확인할 수 없는 코드의 실행을 막을 수 잇습니다.

호스트는 이러한 격리를 통해 코드를 동일한 프로세스에서 다른 신뢰 수준으로 안전하게 실행할 수 있습니다. 낮은 신뢰 코드는 신뢰할 수 있는 호스트 코드 또는 다른 낮은 신뢰 코드와는 별도로 AppDomain에서 실행할 수 있습니다. 낮은 신뢰 코드의 호스트에 필요한 AppDomain 수는 해당 호스트의 격리 의미에 따라 다릅니다. 예를 들어 Internet Explorer는 관리 컨트롤에 대해 사이트당 하나의 AppDomain을 작성합니다. 한 사이트의 컨트롤은 동일한 AppDomain에서 상호 작용할 수 있지만 다른 사이트의 컨트롤을 간섭하거나 악의적으로 이용할 수 없습니다.

Atlas 아키텍처의 클라이언트 스크립트 핵심을 구성하는 계층 위에는 구성 요소 모델과 컨트롤 계층이 있습니다. 스크립트 라이브러리의 이 계층은 하부의 스크립트 핵심을 기반으로 구축되지만 클라이언트에서는 별도로 렌더링됩니다. 스크립트를 작성할 때 구성 요소 계층을 포함하지 않고 JavaScript 형식 시스템과 기본 클래스 라이브러리를 직접 사용할 수도 있지만, 이렇게 하면 Atlas에서 제공되는 클라이언트 구성 요소에 액세스할 수 없으며 브라우저로 보내지는 페이지 마크업에 포함되는 새로운 선언적 요소 집합인 xml-script를 사용할 수 없게 됩니다. xml-script 요소는 다음과 같은 새로운 형식 값을 사용하는 스크립트 태그 안에 포함됩니다.


그림 8 Page Showcasing Pop-Up Behavior

마크업에서 추가적인 요소 집합을 사용하기 위한 가장 기본적인 방법은 스크립트 태그를 사용하는 것입니다. 브라우저는 스크립트 요소를 인식하지만 text/xml-script 형식을 처리할 수는 없습니다. 스크립트 태그 자체에 포함된 요소는 Atlas 스크립트 라이브러리에서 처리될 수 있으며 마크업은 클라이언트 스크립트 라이브러리의 구성 요소 계층에서 처리됩니다. xml-script는 클라이언트에서 구문 분석되어 구성 요소와 컨트롤의 인스턴스를 만듭니다. xml-script에는 정의하는 구성 요소와 컨트롤에 대한 속성 설정이 포함될 수 있으며 페이지의 다른 부분에 있는 HTML 요소와의 바인딩도 선언될 수 있습니다. 또한 xml-script 요소에서 웹 서비스 리소스를 선언한 다음 마크업의 다른 부분에서 이를 데이터 소스로 참조할 수도 있습니다. 그림 8의 예제 페이지는 xml-script를 사용하여 마우스 포인터로 연도를 가리킬 때 해당 연도와 관련된 영화 제목이 팝업 요소로 표시되도록 선언적으로 설정하고 있습니다.

그림 8의 페이지에서는 연도를 표시하기 위해 DIV 요소를, 영화 제목을 표시하기 위해 SPAN 요소를 사용하지만 숨겨지도록 선언했습니다. xml-script의 popupBehavior는 영화 제목과 연결되어 있으며 해당 연도와 연결된 hoverBehavior에 의해 실행됩니다. popupBehavior에 대한 코드는 Atlas 스크립트 라이브러리의 컨트롤과 구성 요소 계층에 있습니다. xml-script는 일반적으로 페이지에 포함되는 JavaScript에 비해 더 쉽게 분석할 수 있으며, 특히 다수의 브라우저 구현을 처리하기 위해 코드에서 팩터링을 시작할 때 이러한 특징이 두드러지게 나타납니다. 그림 8의 xml-script와 같은 선언적 구문은 개발 도구를 사용하여 쉽게 만들고 사용할 수 있으며 풍부한 기능의 사용자 환경을 가능하게 하는 xml-script는 페이지가 실행될 때 Atlas 서버 컨트롤에 의해 만들어집니다. Atlas 응용 프로그램에서 사용되는 대다수의 xml-script는 .aspx 파일에 전혀 존재하지 않으며 개발자가 직접 코딩할 필요도 거의 없습니다.

Atlas CTP에서 제공하는 다양한 동작은 사용자 환경을 개선하는 데 사용됩니다. 진행률 동작은 백그라운드에 보류되어 있는 작업에 대한 정보를 제공할 수 있으며 클릭, 가리키기, 팝업 동작은 다양한 사용자 상호 작용을 가능하게 합니다. 이러한 동작은 xml-script를 사용하여 선언적 방식으로 페이지의 HTML 요소와 쉽게 연결할 수 있습니다. 동작 자체는 JavaScript로 구현되기 때문에 더 복잡한 동작도 가능하지만, 페이지에서 동작을 사용할 때는 xml-script를 사용할 수 있습니다.

서버 컨트롤

Atlas CTP에 포함된 서버 컨트롤을 사용하면 페이지를 다시 게시할 때 일시적으로 상호 작용이 중단되는 것을 방지할 수 있습니다. 즉, 서버 컨트롤이 백그라운드에서 렌더링을 업데이트하는 동안 사용자는 웹 페이지와 계속 상호 작용할 수 있습니다. 이러한 기능의 주역은 함께 작동하는 두 개의 서버 컨트롤입니다. 이러한 두 서버 컨트롤을 기존 페이지에 추가하면 상당한 기능 향상을 얻을 수 있습니다. 첫 번째 컨트롤인 ScriptManager 컨트롤은 클라이언트에서 서버로의 다시 게시 동작을 변경하며 두 번째 컨트롤인 UpdatePanel 컨트롤은 변경 작업을 위해 서버에서 페이지의 수명 주기를 관리합니다.

ScriptManager 컨트롤은 Atlas 기능을 사용할 모든 페이지에 포함되어야 합니다. 이 컨트롤은 클라이언트로 보내는 JavaScript를 제어하는 역할을 하는데, 서버 컨트롤은 클라이언트에 JavaScript를 제공할 수 있으며 이 동작을 제어하기 위해 ScriptManager 컨트롤을 이용합니다. ScriptManager 컨트롤은 구현을 위해 새로운 IScriptComponent 인터페이스를 이용하며 xml-script 요소와 연결되는 구성 요소 스크립트 라이브러리도 지원합니다.

다음과 같이 ScriptManager 컨트롤의 EnablePartialRendering 속성을 true로 설정하면 클라이언트에서 서버로의 다시 게시 동작이 새롭게 변경됩니다.


이 코드를 통해 사용자 환경을 중단하지 않고도 서버로 다시 게시를 요청할 수 있게 됩니다. 요청 간의 제어 정보를 보존하는 데 필요한 보기 상태 정보는 부분적 렌더링 요청을 위해 유지됩니다. 그리고 새로 고쳐지거나 수정되는 부분에 대한 HTML은 브라우저 DOM(Document Object Model)과 상호 작용하는 JavaScript에서 업데이트됩니다. ASP.NET 페이지에서 부분 업데이트를 허용해야 하는 영역은 UpdatePanel 컨트롤을 사용하여 지정됩니다.

UpdatePanel 컨트롤은 페이지의 나머지 부분과는 별개로 업데이트되어야 하는 영역을 ScriptManager 컨트롤에 알리는 역할을 합니다. 사용자가 브라우저에서 수행한 작업으로 인해 페이지의 일부를 다시 게시해야 할 경우, 폼 데이터가 게시되고 페이지 수명 주기가 서버에서 실행되기 시작합니다. 이때 스크립트는 백그라운드에서 비동기식으로 다시 게시 작업을 초기화하므로 페이지가 계속 사용자에게 표시됩니다. 서버에서는 클라이언트에서 게시한 보기 상태 데이터를 바탕으로 컨트롤 상태를 복원합니다. 렌더링 단계에 접어들면 ScriptManager 컨트롤은 UpdatePanel 영역을 새로 고쳐 브라우저로 돌려 보내기 위해 이 영역에 대한 렌더링을 격리시킵니다. 또한 페이지의 보기 상태 데이터가 수집되고 응답의 일부로 HTML이 전송됩니다. 그런 다음 브라우저의 스크립트에서 UpdatePanel의 이전 내용을 해당하는 새 HTML로 바꿉니다.

UpdatePanel 컨트롤에는 다음과 같이 Triggers와 ContentTemplate에 대한 요소가 포함될 수 있습니다.


ContentTemplate 내의 영역은 ScriptManager 컨트롤이 비동기식으로 요청된 다시 게시 작업을 처리할 때 새로 고쳐집니다. Triggers 요소에는 ControlEventTrigger 및 ControlValueTrigger 요소가 포함될 수 있으며, 웹 페이지 개발자는 Triggers 요소를 사용하여 어떤 내용이 변경되었을 때 영역이 업데이트될 것인지 지정할 수 있습니다. 이렇게 하면 UpdatePanel 컨트롤에 직접 포함되지 않은 외부 컨트롤에 의해서도 변경이 이루어지도록 할 수 있습니다. 또한 간단한 선언을 사용하여 페이지의 동작과 UpdatePanel 컨트롤을 제어하고 가져온 새 데이터를 표시할 수 있습니다.

한 페이지에 여러 개의 UpdatePanel 컨트롤을 배치하고, 각 컨트롤을 업데이트하도록 하는 여러 Triggers를 추가할 수 있습니다. UpdatePanel 컨트롤의 내용은 특정 사용자 입력에 응답하는 데 필요한 최소한의 범위로 축소할 수 있습니다. UpdatePanel 컨트롤을 사용하면 기존의 ASP.NET 페이지를 크게 변경하지 않고도 사용자의 입력에 보다 빠르게 응답하도록 만들 수 있습니다.

웹 서비스

웹 응용 프로그램은 서비스 지향 아키텍처를 중심으로 만들어집니다. 대화형 응용 프로그램을 가능하게 하는 핵심은 브라우저에서 서비스에 액세스할 수 있는 기능으로, Atlas에서 제공하는 서비스에는 두 가지 종류가 있습니다. ScriptManager 컨트롤은 다음과 같이 웹 서비스 참조를 위해 자동으로 생성되는 프록시를 사용합니다.


이렇게 하면 클라이언트 쪽 구성 요소가 스크립트에서 웹 서비스를 직접 호출할 수 있습니다. 웹 서비스는 컨트롤에 바인딩되어 더욱 풍부한 동작을 지원합니다. 예를 들어 웹 서비스를 사용하여 관련된 정보를 검색하도록 xml-script에서 AutoCompleteBehavior를 정의할 수 있습니다(그림 9 참조).

그림 9 AutoCompleteBehavior in xml-script

동작은 페이지의 요소에 연결되어 해당 요소의 동작을 확장하며 .aspx 마크업에 설정되면 extender로 참조됩니다. AutoCompleteBehavior는 AutoCompleteExtender 컨트롤을 통해 요소와 연결될 수 있습니다. xml-script를 직접 작성하는 대신 extender가 서버의 컨트롤과 연결됩니다. 그런 다음 적절한 xml-script를 렌더링하여 클라이언트 쪽 동작을 가져옴으로써 컨트롤 동작이 확장됩니다. 웹 서비스를 호출할 때는 호출과 반환에 대한 결과가 대개 XML로 전달됩니다. 그러나 Atlas는 웹 서비스의 데이터를 JSON 형식으로 serialize할 수 있는 기능도 제공하므로 이를 통해 XML 사용으로 인한 일부 오버헤드를 줄일 수 있습니다. JSON 데이터는 브라우저에서 JavaScript 개체로 직접 deserialize될 수 있습니다. 이 밖에도 Atlas는 서버에서 사용되는 보다 복잡한 .NET의 관리되는 형식을 브라우저에서 JavaScript 개체로 serialize할 수 있는 기능을 지원하므로 브라우저에서 웹 서비스에 액세스하는 작업이 간단해집니다.

브라우저에서 사용할 수 있는 웹 서비스는 응용 프로그램의 일부인 사용자 지정 웹 서비스뿐만 아니라 ASP.NET 응용 프로그램 서비스까지 다양합니다. Atlas는 다음과 같이 JavaScript에서 폼 인증 서비스를 직접 사용할 수 있는 기능도 제공합니다.


사용자가 로그인 자격 증명을 제공할 때 HTML이 동적으로 변경될 수 있으므로 사용자는 로그인 페이지로 리디렉션된 후 원래 페이지로 되돌아가지 않아도 됩니다. .aspx 페이지에서 사용되는 프로필 데이터는 웹 서비스 호출을 통해서도 사용할 수 있으며 JavaScript 개체를 통해 서버에 저장된 프로필 데이터를 저장하거나 가져오는 기능도 제공됩니다.

응용 프로그램에서 사용하는 웹 서비스가 언제나 같은 호스트 서버에 있는 것은 아닙니다. 호스트 서버뿐 아니라 실제로 웹 서비스가 같은 도메인에 있어야 한다는 규칙도 없습니다. 그러나 브라우저는 페이지의 원래 출처가 아닌 도메인에 대해서는 XmlHttpRequest를 사용하는 호출을 차단합니다. 자식 요청을 시작하는 숨겨진 IFrame 개체를 사용하여 이 제한을 피하는 몇 가지 교묘한 방법이 있기는 하지만 실행하기가 상당히 번거롭습니다. Atlas에서는 웹 서비스 브리징을 제공하여 이 문제를 해결합니다. 웹 서비스 브리징을 사용하면 클라이언트가 다른 도메인으로 보내는 웹 서비스 호출을 시작할 수 있습니다. 이 호출은 Atlas 응용 프로그램으로 보내지며, 여기서 대상 서버로 요청을 프록시한 후 serialize하여 클라이언트로 결과를 돌려 보냅니다. 물론 Atlas는 IFrame 기술을 사용하여 다른 도메인과 직접 통신하는 기능도 제공합니다.

결론

Atlas는 풍부한 기능을 갖춘 웹 응용 프로그램을 만들기 위한 다양한 기능을 제공합니다. 클라이언트 스크립트 라이브러리는 JavaScript를 작성하는 작업을 간소화하며 JavaScript를 작성할 때 개체 지향적 접근 방식을 사용하기 위한 구문을 제공합니다. 웹 서비스 기능을 사용하면 원격 및 로컬 서비스에 쉽게 액세스할 수 있습니다. 또한 복잡한 형식을 serialize하여 클라이언트와 서버에서 다양한 형식을 쉽게 이용할 수 있습니다. 서버 컨트롤 역시 클라이언트 스크립트 라이브러리를 이용하며 이를 통해 기존 응용 프로그램과 새 응용 프로그램에서 일반적으로 발생하는 '사용 대기를 위한 일시 중지'를 상당히 줄일 수 있습니다.

CTP 빌드는 업데이트, 변경, 새 기능 추가 등이 이루어져 거의 두 달에 한 번씩 새로 발표되고 있습니다. 궁극적으로 Atlas는 Visual Studio의 디자인 환경에서 사용할 수 있는 기능을 포함하여 다음 릴리스의 .NET Framework에 통합될 예정입니다. 근래에 Microsoft는 현재 사용 중인 사이트에 Atlas를 배포하여 웹 응용 프로그램에서 이용할 수 있는, 사용권이 제한된 버전의 Atlas를 발표했습니다. 자세한 내용을 보거나 최신 Atlas CTP를 다운로드하려면 atlas.asp.net (영문)을 참조하십시오.

출처 : MSDN