.NET Framework 3.0 소개http://www.microsoft.com/korea/msdn/netframework/using/documentation/aa479861.aspx David Chappell July 2006 적용 대상: 개요:Microsoft .NET Framework 3.0은 현재의 응용 프로그램 개발에 직면한 중요한 과제 해결을 위한 다양한 기술이 구현되었습니다. .NET Framework 3.0 설명 응용 프로그램 개발의 과제는 단기간에 최고의 소프트웨어를 개발하는 것입니다. 그러나 소프트웨어 개발의 기본이 되는 플랫폼이 진화하면서 더욱 어려워지고 있습니다. Window의 경우는 초기Win32 인터페이스에 한층 더 기능적인 .NET Framework 을 통합하게 되었습니다. 2002년에 출시 된 버전 1.0 과 2005 년에 출시 된 버전 2.0을 거쳐 Windows 소프트웨어 설계 및 기술하는 개발자의 환경은 한층 더 효율적이며 생산적인 방향으로 진화하고 있습니다. 새로운 버전인 .NET Framework 3.0 (구 WinFX)으로 구축된 응용 프로그램은 Visual Studio 2005으로 작성할 수 있습니다. 따라서 대부분의 Windows 소프트웨어 개발자들은 .NET Framework 3.0과 친숙합니다. .NET Framework 3.0에는 버전 2 에는 없던 기능들이 추가되었습니다. 2006년 말에 출시 된 .NET Framework 3.0은Windows Vista, Windows Server 2003 및 Windows XP 에서도 이용 가능합니다. 이 문서에서는 새로운 출시에 대한 설명, 기술 사용 방법 및 기술에 대한 간단한 설명과 함께 .NET Framework 3.0 및 구성 요소의 큰 그림을 보여드립니다. 표준적인 응용 프로그램의 개발에는 많은 요건이 관련됩니다. 보존 데이터 조작이나 웹 브라우저 액세스 등을 고려하는 것도 중요하지만, 충분하지는 않습니다. 현대의 응용 프로그램 개발에는 다음과 같은 새로운 과제가 요구됩니다. .NET Framework 3.0은Windows 응용 프로그램으로 이러한 문제를 해결할 수 있습니다. 그림 1 과 같이 .NET Framework 3.0은 .NET Framework 2.0 위에 구축되었으며, 기능적인 변화는 없습니다. 따라서 버전 2 에서 작성된 기존의 응용 프로그램은 버전 3 에서도 문제없이 작동합니다. 가 .NET Framework 3.0에는 Windows Workflow Foundation, Windows Communication Foundation, Windows CardSpace 및 Windows Presentation Foundation 이라는 새로운 4 개의 구성 요소가 추가되었습니다. 여기에서는 .NET Framework 2.0을 살펴보고, 새롭게 추가된 각 구성 요소가 제공하는 기능에 대해 설명합니다. 그림 1 현재도 Win32 인터페이스를 직접 사용하는 소프트웨어를 기술하는 것은 가능하지만, 새로운 Windows 응용 프로그램에서는 .NET Framework이 주요한 환경이 됩니다. .NET Framework의 중요한 구성 요소의 일부는 다음과 같습니다. 버전 2.0에서는 이전 버전의 편리한 기능을 몇 가지 추가했습니다. 예를 들어ASP.NET Web 응용 프로그램의 작성을 크게 개선하는 기술, 64 비트 버전의 Windows에서 실행되는 64 비트 응용 프로그램 지원, 새로운 트랜잭션 처리 방법 등입니다. 따라서 .NET Framework 2.0 기능의 일부가 버전 3.0 에 추가된 새로운 구성 요소로 교체되어도 버전 2.0 기술은 버전 3.0 에서도 계속 기초를 이루게 됩니다. 이 부분은 다음에 자세하게 설명하겠습니다. 워크플로는 단순한 개념으로 정해진 순서로 실행되는 일련의 스텝입니다. 응용 프로그램은 특정 프로세스를 실행하기에, 응용 프로그램에는 워크플로가 구현되어 있다고 생각할 수도 있습니다. 그러나 C#, Visual Basic 및 다른 프로그램 언어로 응용 프로그램을 작성하는 기존의 접근 방법은 프로세스 스텝이 코드 내에 포함되어있습니다. 이 방법에서도 응용 프로그램이 작동하지만, 프로세스의 구현이나 변경이 어렵습니다. 워크플로 기술을 사용하여 프로세스 로직을 구현하면 이 문제를 해결할 수 있습니다. 로직을 통상의 코드로 짜지 않고, 프로세스의 각 스텝을 명시적으로 정의한 후 워크플로 엔진에서 실행합니다. 이렇게 하여 프로세스 자체를 구현할 수 있습니다. 워크플로 엔진 사용은 Windows나 다른 시스템에서도 이미 사용되고 있습니다. 예를 들어, 마이크로소프트는 일부의 제품에 워크플로 엔진을 포함하고 있지만, 워크플로 접근 방법이 응용 프로그램 작성의 주류가 된 지금, Windows 용의 통일된 워크플로 기술을 제공하는 것이 당연하며, Windows Workflow Foundation (WF)에서 실현되었습니다. Windows용의 공통 워크플로 기술로서, WF는 워크플로 기본 응용 프로그램에도 동일한 파운데이션을 제공합니다. Microsoft Office 2007 system 이나 Windows SharePoint Services 등의 마이크로소프트의 소프트웨어도 WF를 사용할 예정입니다. 그러나 공통의 워크플로 기술에도 몇 개의 과제가 있습니다. 예를 들어, 다양한 워크플로 응용 프로그램이 필요로 하는 다양한 요건을 하나의 접근 방법으로 어떻게 채울 수 있는 것인가? 대답은 WF에서 채용하고 있는 워크플로의 일반적인 개념에 있습니다. 그림 2 와 같이, WF 워크플로는 WF 엔진에 의해 실행되는 액티비티 그룹에 지나지 않습니다. 각 액티비티는 실제로는 클래스이며, 워크플로의 작성자가 의도하는 임의의 작업을 포함할 수 있습니다. 액티비티는 다른 워크플로로 재이용할 수 있어 새로운 문제에 대한 자동화 솔루션을 작성하기 쉽습니다. 그림 2 공통 워크플로 기술에서 발생하는 또 다른 문제는 휴먼 지향과 시스템 지향이라는 구분에 의한 워크플로의 차이입니다. 주로 사용자에 의해서 사용되는 워크플로 응용 프로그램에는 곧바로 프로세스를 변경할 수 있는 유연성이 필요합니다. 반대로 주로 시스템(소프트웨어)에 의해서 사용되는 워크플로 응용 프로그램은 정적인 한편, 효율성이 요구됩니다. WF는 양쪽 모두를 고려하여 설계되었습니다. 즉, 실행중의 워크플로를 변경할 수 있는 휴먼 지향적인 특징을 가지면서, 시스템 지향적인 처리도 지원합니다. .NET Framework 3.0 의 WF, Windows 의 공통 워크플로 기술이 제공되면 개발자는 소프트웨어 작성에 편리한 패러다임(paradigm)를 이용할 수 있습니다. 프로세스 지향의 소프트웨어 보급에 따라서 워크플로 사용은 더욱 일반적화 될 것입니다. 응용 프로그램이 워크플로 사용여부와 관계없이, 대부분의 응용 프로그램은 다른 응용 프로그램과 통신할 필요가 있습니다. 이 통신 방법은 과거 몇 년 사이에 큰 진보가 있었습니다. 오랜 혼란 끝에 주요 벤더사들은 응용 프로그램 통신에 동일 프로토콜을 지원하기로 합의하였습니다. SOAP 에 근거한 Web Services의 세계적인 합의에 의해, 다양한 플랫폼 (J2EE 나 .NET Framework 등) 에서 구축된 응용 프로그램간의 상호 운용이, 과거와 비교해서 현격히 용이하게 되었습니다. 또한 대부분의 조직에서는 서비스 지향 아키텍처라는 아이디어가 보다 현실화되었습니다. 통신에는 이미 많은 방법이 존재합니다. 일례로서 .NET Framework 2.0에는 다음의 옵션이 있습니다. 이러한 기술들은 각각 의미와 역할이 있습니다. 그러나, 기본적으로 같은 문제를 해결하기 위해, 왜 다른 솔루션이 필요한지, 상호 운용 가능한 서비스를 사용하는 응용 프로그램 통신으로 단일의 파운데이션을 구축하는 것이 좋은 지 의문이 남습니다. Windows Communication Foundation (WCF)는 이런 문제를 해결할 수 있습니다. 개발자는 통신의 종류마다 다른 응용 프로그램 프로그래밍 인터페이스를 개입시켜 여러 가지 기술을 다루는 반면, WCF (코드 네임 "Indigo")에서 제공하는 공통의 API를 개입시켜, 일관된 방법으로 개발 할 수 있습니다. .NET Framework 3.0 환경에서는 통신에 상기 기술을 사용한 대부분의 응용 프로그램에 WCF 가 사용됩니다. WCF 는 현대의 컴퓨팅에서 빠질 수 없는 SOAP 에 의한 상호 운용 가능한 통신을 강력하게 지원합니다. WS-Security, WS-ReliableMessaging 및 WS-AtomicTransaction 등 일부의 WS-* 사양의 지원도 포함됩니다. 가 SOAP는WCF 의 필요 조건은 아닙니다. 따라서 최적화된 바이너리 프로토콜 MSMQ 를 사용하는 메시지 큐잉, 단순한 REST 기본의 통신 등 다른 방법을 사용할 수도 있습니다. 게다가WCF는 통신에 명시적인 서비스 지향 접근 방법을 채용하고 있습니다. WCF는 오브젝트간에 투과적인 통신을 실시하는 대신에, 조금 다른 추상화 된 서비스를 통신 파티간에 삽입합니다. 이 결과, 분산 오브젝트 시스템에 존재하는 밀접한 결합을 해소할 수 있어 에러의 발생을 막거나 변경을 간단하게 할 수 있습니다. 조직 내외를 불문하고, 응용 프로그램간의 통신은 현대의 소프트웨어로 중요한 부분을 차지하고 있습니다. 인터넷으로 사용자가 인증을 받는 방법을 생각해 봅시다. 대부분의 경우 사용자의 디지털 ID는 단순한 사용자명으로 나타납니다. 이 ID는 패스워드와 결합하여, 전자 메일 계정, 인터넷 쇼핑, 온라인 뱅크, 그 외 상용 사이트로의 액세스에 사용됩니다. 그러나, 사용자명과 패스워드에는 그 단순함에 기인하는 몇 개의 문제가 있습니다. 그 중에 특히 두 가지 중요한 문제가 있습니다. 이러한 중대한 위험을 막기 위해 디지털 ID를 관리하기 위한 새로운 접근 방법이 필요합니다. 이 접근 방법의 중요한 부분이 Windows CardSpace (코드 네임 "InfoCard") 입니다. 사용자가 자신의 디지털 ID 를 관리할 수 있도록 CardSpace에는 각각의 ID가 고유의 인포메이션 카드로 표시됩니다. Web 사이트가 CardSpace 로그인을 받아들이면, 로그인 하려는 사용자에게, 그림 3 과 같은 CardSpace 선택 화면이 표시됩니다. 사용자는 카드를 선택하여 그 사이트에 액세스 할 수 있는 디지털 ID를 선택할 수 있습니다. 이렇게 하여 사용자는 대량의 사용자명으로 패스워드를 기억하는 대신에, 사용하는 카드로 식별할 수 있습니다. 다른 카드에는 또 다른 정보를 포함할 수도 있어 각 사이트에서 필요한 정확한 ID를 관리할 수 있습니다. 그림 3 카드에 의해 나타난 ID는 하나 이상의 ID 공급자 에 의해 작성됩니다. 조직에서도 ID 공급자를 제공할 수 있습니다. 각 ID 공급자가 제공한 ID 에는 단순한 사용자명과 패스워드 대신에, 강력한 암호화 메커니즘을 사용합니다. 사용자는 ID 로 인증을 받을 수 있습니다. CardSpace 자체에도 클라이언트 머신으로 실행하는 자기 발행형 ID 공급자가 포함되어 있습니다. 이 공급자를 사용해 사용자는 패스워드와 관계없이 자신의 인증용 ID 를 작성할 수 있습니다. Web 사이트에서 통상의 패스워드 기본의 인증을 대신하고, 이러한 자기 발행형 CardSpace ID를 사용할 수 있습니다. 이렇게 하여 패스워드 관련 문제를 줄일 수 있습니다. 사이트의 로그인시에 패스워드를 사용하지 않으면 피싱 사기로 패스워드를 도둑맞는 일은 없어집니다. 그렇지만 피싱 사기범이 사용자를 속여 가짜 사이트에 로그인 시킨 후, 의료 정보 등의 다른 개인정보를 훔쳐갈 우려가 있습니다. 이것을 피하려면 사용자가 진짜 사이트와 사기범에 의해서 작성된 가짜 사이트를 분별 할 필요합니다. 이것을 가능하게 하기 위해, Web 사이트를 가지고 있는 조직은 신뢰할 수 있는 증명서를 취득할 수 있습니다. 단순한 SSL 증명서와는 달리, 새로운 증명서를 취득하려면 한층 더 엄격한 인증 프로세스가 요구됩니다. 예를 들어, 증명을 받으려는 조직은 자신을 증명하기 위해 한층 더 어려운 요건을 채워야 합니다. 신뢰할 수 있는 증명서에는 기업의 로고나 그 외 정보가 포함되어 있어 이 증명서를 사용하는 사이트의 신뢰성을 사용자가 확인하는데 도움이 됩니다. 사용자가 새로운 사이트에 액세스 하면, CardSpace는 표준 화면을 사용하고 사이트의 증명서에 포함되는 정보를 표시합니다. 또한 수신한 증명서의 인증 레벨에 따라서 사이트의 신뢰성에 관한 보증 레벨을 나타냅니다. 목적은 사이트의 신뢰성을 사용자가 직접 올바르게 판단하도록 돕기 위해서 입니다. Windows CardSpace 는 실제로 보다 대규모 ID 메타시스템 의 일부를 구성하고 있습니다. 완전히 공개된 프로토콜에 근거한 이 메타시스템은 다양한 플랫폼 (Windows 이외의 오퍼레이팅 시스템도 포함)이나 응용 프로그램 (Internet Explorer 이외의 Web 브라우저도 포함) 사이의 다양한 디지털 ID 기술을 통일해 사용하는 방법을 정의합니다. Windows 전용으로 ID를 선택하기 위한 공통의 방법이나 그 외 기능을 제공하여 CardSpace는 ID 메타시스템의 중심적인 역할을 합니다. 또 ID 에 관한 근본적인 문제에 있어서, .NET Framework 3.0의 중요한 부분을 담당합니다. 대부분의 응용 프로그램에서 사용자 인터페이스는 중요한 부분을 차지하고 있습니다. 그런데 응용 프로그램의 인터페이스에 대한 사용자의 요구는 더욱 더 커지고 있습니다. 응용 프로그램으로, 종래의 메뉴 구동형 GUI도 중요하지만, 비디오, 애니메이션 실행, 2D/3D 그래픽의 사용, 다양한 문서 처리도 필요합니다. 이러한 모든 조작은 응용 프로그램이 독립 실행형 데스크톱 클라이언트 또는 Web 브라우저의 어디에서 실행되고 있어도 실시할 수 있어야 합니다. 기존의 사용자 인터페이스의 이러한 측면은 다양한 방법으로 Windows 에 구현되어 왔습니다. 예를 들어 개발자는 .NET Framework의 일부인 Windows 폼을 사용해 Windows GUI를 구축할 수 있습니다. Web 브라우저 인터페이스의 작성에는 HTML 에 함께 Java 애플릿이나 JavaScript 코드가 필요합니다. 게다가 비디오를 실행하려면 Windows Media Player 또는 Adobe 의 Flash Player 등의 소프트웨어가 필요하고, 문서 형식은 Microsoft Word 또는 Adobe 의 PDF 등에서 정의됩니다. 따라서, 개발자가 직면한 과제는 명백합니다. 즉, 다양한 기술을 사용하는 한편 다양한 클라이언트에 대응할 수 있는 일관된 사용자 인터페이스의 구축은 간단하지 않다는 것입니다. WPF(Windows Presentation Foundation. 코드네임 "Avalon")는 이러한 과제를 해결하기 위해서 준비되었습니다. WPF 는 사용자 인터페이스의 이러한 면에 대응하는 기술적으로 통일된 기반을 제공하는 것으로, 개발자의 작업을 줄여줍니다. 그리고 비디오, 애니메이션, 2D/3D 그래픽, 다양한 문서의 지원 등이 새로운 접근 방법으로 지금까지 없었던 사용자 경험(experience)를 실현합니다. 또한 데스크톱 클라이언트와 브라우저 클라이언트에 공통의 파운데이션을 제공하여 양쪽 모두에서 실행할 수 있는 응용 프로그램을 간단하게 구축하는 것이 가능합니다. 그림 4에는 WPF에서 제공되는 이미지, 라이브 그래픽, 3 차원 뷰 등을 포함한 인터페이스의 예가 있습니다. 다양한 스킬이 없는 개발자도 이러한 인터페이스를 일관된 방법으로 작성할 수 있습니다. 그림 4 사용자 인터페이스 작성자가 오랫동안 직면해 온 과제 중 하나는 효과적인 인터페이스 구축에 필요한 역할이 다른 것에 비롯되고 있습니다. 인터페이스의 배후에 있는 로직을 작성하려면 소프트웨어 개발자가 필요하지만, 개발자가 인터페이스의 외관이나 조작성을 정의하는데 적임인지는 의문이 남습니다. 오히려, 휴먼 머신 interaction의 스페셜리스트인 디자이너가 적임입니다. 그런데Windows 폼 등의 구 기술에서는 철저하게 개발자만을 염두에 두고 설계되었습니다. 따라서 개발자와 디자이너가 효과적으로 공동 작업을 할 수 없습니다. 이 문제를 해결하기 위해, WPF는 XAML (eXtensible Application Markup Language)를 기본으로 합니다. XML 기본 언어 하나에 XAML 사용자 인터페이스를 지정하는 것이 가능합니다. 이렇게 하면 디자이너가 작성한 인터페이스의 외관 디자인에 근거해, 툴로 인터페이스의 사양을 생성 또는 조작하는 것이 용이하게 됩니다. 마이크로소프트는 신제품 Expression Interactive Designer를 제공하여 디자이너는 이 툴 (또는 서드 파티 제공의 다른 툴)을 사용하여, 인터페이스 외관을 작성하고, 그 인터페이스의 XAML 정의를 생성할 수 있게 됩니다. 개발자는 그 정의를 Visual Studio 에 독립 실행시켜 인터페이스에서 필요한 로직을 작성할 수 있습니다. Windows 에서 직접 실행되는 독립 실행형 WPF 응용 프로그램을 작성하는 경우, 개발자는 WPF 의 모든 기능을 사용할 수 있습니다. 한편 Web 브라우저 내에서 실행되는 클라이언트를 작성하는 경우 개발자는 XBAP 으로 불리는 XAML 브라우저 응용 프로그램을 구축할 수 있습니다. XBAP은 독립 실행형 WPF 응용 프로그램과 같은 파운데이션으로 구축되어, 다운로드 되는 브라우저 응용 프로그램 내에서 같은 스타일의 사용자 인터페이스를 표시할 수 있습니다. 또, 양쪽 모두의 응용 프로그램으로 같은 코드를 사용할 수 있으므로, 개발자는 데스크톱 클라이언트와 브라우저 클라이언트로 다른 기술 스킬을 사용할 필요가 없습니다. 인터넷으로부터 다운로드 할 수 있는 XBAP는 이런 종류의 리치 인터넷 응용 프로그램과 같은 시큐어인 샌드 박스 내에서 실행하기 위해, 이 응용 프로그램으로 실시할 수 있는 기능이 한정됩니다. 그렇지만 독립 실행형 WPF 응용 프로그램으로 사용할 수 있는 사용자 인터페이스 기능의 대부분을 XBAP에서 사용할 수 있습니다. WPF 독립 실행형 응용 프로그램과 XBAP 의 양쪽 모두는WPF에서 지원되는 최신 그래픽을 이용할 수 있습니다. 이것은 하드웨어 가속기의 사용이나 벡터 그래픽의 지원 등이 있습니다. 한층 더 WPF는 고성능인 그래픽을 지원하여, Windows 폼이나 다른 구 기술에서는 불가능했던 다채로운 데이터 비주얼화 옵션이 가능하게 되어 있습니다. WPF 는 XPS (XML Paper Specification)의 파운데이션도 제공합니다. XPS에 의해 고정 서식 문서를 표시, 배포, 인쇄하기 위한 표준 형식이 정의됩니다. 사용자 인터페이스는 현대의 응용 프로그램에 대해 중요한 부분이며, 그 기능은 복잡화되고 있습니다. .NET Framework 3.0 의 WPF는 이러한 사용자 인터페이스로 생기는 과제를 해결하기 위한 완성도의 높은 일관한 솔루션을 제공합니다. 목적은 사용자 인터페이스의 작성과 관계된 개발자와 디자이너 모두 한층 더 효율적으로 작업할 수 있도록 하는 것입니다. 소개한 다양한 기술이 어떻게 제휴되는지 알기 위해, 기술 사용 방법의 실례를 생각해봅시다. 예를 들어 고객과 대리점이 보험 가입을 신청하여 사용하는 응용 프로그램에 대해서 생각합니다. .NET Framework 3.0 에서 구현하면, 그림 5 와 같이 됩니다. 그림 5 그림의 왼쪽 상단에 나타내는 응용 프로그램의 비즈니스 로직은 WF 워크플로를 사용해 구현되었습니다. 보험 가입의 신청 처리는 멀티 스텝 프로세스이며, 그 신청을 보험 회사의 가입자 규칙에 비추어 평가하는 것 (신청자의 신용 카드 확인이나 매니저 승인 등) 이 포함됩니다. 워크플로는 이러한 스텝을 액티비티로서 구현하여, 필요에 따라서 다른 소프트웨어를 사용합니다. 일례로서 이 워크플로에서는 보존된 데이터에 액세스 하기 위해서 ADO.NET 에서 사용되고 있습니다. 이 보험 회사에는 콜 센터를 만들고 고객이 전화로 보험 가입 신청을 할 수 있습니다. 이 콜 센터의 스탭이 사용하는 클라이언트 소프트웨어는 그림의 우측 상단에 나타나듯이, 독립 실행형 WPF 응용 프로그램으로서 구현되고 있습니다. 이 클라이언트 소프트웨어는 WCF-WCF 통신에 최적화된 바이너리 프로토콜을 개입시켜, WCF를 사용하는 응용 프로그램 비즈니스 로직과 통신합니다. 그림이 보이듯이 콜 센터 스텝은 이 응용 프로그램에 로그인할 때, Windows CardSpace 를 사용해 ID를 선택합니다. 고객은 Web에서 보험 가입 신청을 할 수도 있습니다. 또, 보험대리점도 이와 같이 신청을 제출할 수 있습니다. 이것을 가능하게 하려면 응용 프로그램이 ASP.NET을 사용해 Web 브라우저와 통신할 필요가 있습니다. 도표의 왼쪽 하단에 있듯이, Internet Explorer에서 통상의 HTML 인터페이스를 개입시켜 이 응용 프로그램에 액세스 하는 고객도, CardSpace를 사용해 목적의 ID 를 선택할 수 있습니다. 서드 파티는 다른 클라이언트 오퍼레이팅 시스템 및 브라우저 전용으로 ID의 선택 메커니즘을 구현할 수도 있습니다. 이렇게 하여 ID 메타시스템을 Windows 이외의 클라이언트나 Web 브라우저에 확장하는 것이 가능하게 됩니다. 인터넷으로 이 응용 프로그램에 액세스하는 보험대리점은 한층 더 기능적인 인터페이스를 필요로 하는 경우가 있습니다. 이 경우 보험대리점에서는 단순한 HTML 인터페이스가 아닌 XBAP를 사용할 수 있습니다. 이것에 의해, 대리점은 콜 센터의 WPF 데스크톱 응용 프로그램이 제공하는 사용자 인터페이스 기능의 대부분을 사용할 수 있게 됩니다. 어느 쪽의 경우도 같은 파운데이션상에 구축되어 있기 때문에, 응용 프로그램 개발자는 양쪽 모두의 클라이언트 타입에 같은 코드를 재이용할 수 있습니다. 또, 다른 클라이언트 머신과 같이 대리점도 CardSpace를 사용하여 원하는 ID 로 응용 프로그램에 로그인할 수 있습니다. 마지막으로 이 응용 프로그램의 다른 응용 프로그램과의 상호 액세스에 대해서 생각해봅니다. 예를 들어, 고객의 승인에 크레디트 카드의 확인이 필요한 경우, 통상 이 처리는 외부 서비스를 호출해 실시하게 됩니다. 또, 다른 소프트웨어로부터의 요구를 직접 받아들이는 경우도 있습니다. 이 경우는 외부 응용 프로그램 서비스를 호출할 수 있도록 그 서비스를 공개해야 합니다. 이러한 경우, 그림의 오른쪽 하단에 보이듯이, 응용 프로그램은 WCF를 기본으로 하여 표준적인 Web 서비스를 사용해 통신할 수 있습니다. 이러한 외부 응용 프로그램이 어떤 기술로 구축되던 WCF 에서SOAP를 지원함으로 그러한 응용 프로그램과 직접 상호 액세스 하는 것이 가능합니다. 이 시나리오는 ET Framework 3.0 에서 가장 중요한 구성 요소의 일부의 사용 예입니다. 옵션의 대부분이 생략 되었기 때문에, 이 간단한 시나리오로 .NET Framework 3.0 기술 패밀리의 모든 것을 다루는 것은 아닙니다. 이 시나리오의 목적은 실제 비즈니스상의 문제를 해결하는데 .NET Framework 3.0 의 다양한 기능을 어떻게 사용할 수 있는지 알기 쉽게 소개하는 것입니다. NET Framework 3.0 에서 무엇이 가능한지를 알기 위해, .NET Framework 3.0 을 구성하는 각 기술을 이해하는 것은 매우 효과적입니다. 여기에서는 .NET Framework 3.0을 구성하는 5 개의 부분에 대해, 간단한 안내서를 소개합니다. 각 부분의 상세한 소개에 대해서는 뒷부분의 「참고 정보」를 참조해 주세요. 그림 6 .NET Framework 2.0 은 Windows 소프트웨어 개발의 기초를 이루며, .NET Framework 3.0 의 기반이 됩니다. 그림 6은 Framework 의 2 개의 구성 요소인 CLR (Common Language Runtime)과 .NET Framework 클래스 라이브러리를 보여줍니다. WF, WCF 및 WPF 등 .NET Framework 3.0 의 일부 구성 요소는 그 대부분이 .NET Framework 클래스 라이브러리 확장으로 구현됩니다. 다만, 앞에서 말한 바와 같이 클래스 라이브러리의 대부분이 계속 개발자 환경에서 중요한 부분을 차지하는 한편, .NET Framework 3.0에서 제공된 새로운 기술로 통일된 기능도 있습니다. 예를 들어, 브라우저에 액세스 가능한 응용 프로그램을 작성하려면, 앞으로도 ASP.NET이 기본이 되어, 보존 데이터 처리에는 ADO.NET가 계속 사용됩니다. 한편 .NET Framework 3.0 개발자는 네이티브의 Windows GUI 의 작성에 Windows 폼이 아닌, WPF를 사용해 ASP.NET Web Services, .NET 리모팅 또는 Enterprise Services 보다 WCF를 사용하고 싶을 것입니다. 이와 같이 기능의 사용 방법으로 변화가 있지만 NET Framework 3.0 환경에서 전 버전의 Framework 는 중심적인 위치를 차지하고 있습니다. 워크플로에 의한 프로세스 지향의 설계는 대부분의 Windows 소프트웨어에 있어서 이상적인 접근 방법이라고 할 수 있습니다. WF 의 목적은 개발자가 이러한 워크플로 기본 응용 프로그램을 작성해, 실행할 수 있도록 하는 것입니다. 그림 7은 이것을 실현하기 위해서 WF에서 제공되는 구성 요소를 나타내고 있습니다. 그림 7 앞에서 말한 것처럼, 각 워크플로는 몇 개의 액티비티로 구축됩니다. 워크플로도 액티비티도 클래스에 지나지 않기 때문에 어느 쪽이나 코드로 직접 작성할 수 있습니다. 또WF 에는 Visual Studio를 호스트로 하는 워크플로 구축용 그래픽 툴 Workflow Designer 도 준비되어 있습니다. 어느 쪽이든 워크플로를 작성하면 WF 제공의 BAL (Base Activity Library) 이나 그 외의 소스에서 액티비티를 가져올 수 있습니다. 워크플로가 정의되면 WF 런타임 엔진에 의해 그 워크플로가 실행됩니다. 이 엔진은 런타임 서비스 그룹에 근거해, 워크플로 상태를 기록해 워크플로의 실행이나 그 외의 정보를 추적합니다. 이것들 모두 (런타임 서비스, 런타임 엔진, 및 워크플로 자체)는 몇 개의 호스트 프로세스에 포함됩니다. 이 프로세스는 데스크톱으로 실행되는 간단한 콘솔이나 WPF 응용 프로그램부터 측정할 수 있는 서버 프로세스까지 어떤 Windows 프로세스에도 사용할 수 있습니다. WF 를 이해하기 위해서는 구성 요소에 대해 최소한 알아 둬야 할 것들이 있습니다. 각각의 구성 요소에 대해 간단하게 설명합니다. 본질적으로 워크플로는 액티비티의 그룹에 지나지 않습니다. WF는 다음 두 가지 스타일의 워크플로를 기본 제공하고 있습니다. 순차적 옵션은 순수하게 소프트웨어 기본 프로세스로 사용되는 워크플로와 같이 충분히 정의된 워크플로에 적절합니다. 이 워크플로 작성과 이해가 비교적 간단하여 대부분의 개발자들이 워크플로와 친숙해질 것입니다. 한편, 상태 시스템 워크플로는 실행 패스를 예측하기 어려운 경우에 적절합니다. 예를 들어 사용자와의 교환과 관련된 워크플로가 좋은 예입니다. 이 경우 어느 사용자도 임의의 시점에서 워크플로를 캔슬할 가능성이 있습니다. 이 상황에 순차적 워크플로로 대응하는 것도 가능하지만, "워크플로가 캔슬되지 않았으면 이 조작을 실행하고 캔슬되면 다른 조작을 실행한다" 와 같이 스텝이 모두 분기되어 버립니다. 이런 종류의 움직임은 상태 시스템을 사용하면 매우 간단하게 모델링 할 수 있습니다. 워크플로 캔슬 요구가 임의의 시점에서 받아 처리할 수 있는 하나의 이벤트에 지나지 않기 때문입니다. 상태 시스템 워크플로 지원은 WF에서 어떻게 휴먼 워크플로와 시스템 워크플로의 양쪽 모두가 지원 되는지를 나타내는 좋은 예입니다. 다른 예는 워크플로의 실행의 변경을 지원하는WF의 기능입니다. 워크플로가 진행되고 있는 동안 사용자가 스텝을 추가/삭제하거나 프로세스를 변경하는 경우가 있습니다. 사용자의 변경 요구를 제어하기 위해 WF 에는 워크플로를 작성하는 개발자가 실행 중에 워크플로의 변경을 허가할지, 또 어떤 변경을 허가할지 지정하는 기능이 있습니다. 개발자는 자유롭게 사용자 지정 활동을 작성할 수 있습니다. 실제로 마이크로소프트의 목표는 재이용 가능한 풍부한 액티비티로 구성된 WF 생태계의 구축을 촉진해 나가는 것입니다. 기본적인 액티비티의 공통 세트가 준비되어 있다면, 개발을 시작하는 것이 용이하게 됩니다. 이 공통 세트의 배포라고 하는 역할을 담당하는 것이 BAL (Base Activity Library) 입니다. 워크플로에 반드시 BAL 액티비티를 사용할 필요는 없습니다. 그러나 많은 개발자들에게, 특히 개발 초기 단계에서는 BAL 이 도움이 될 것입니다. BAL은 다음의 액티비티가 포함됩니다. WF 에서 워크플로의 작성에 특정의 언어를 지정하는 대신에 액티비티 사용에 관한 폭넓은 접근 방법을 취하고 있습니다. 따라서 BAL에서 1 개의 " 언어" 가 제공되지만WF를 사용하는 개발자는 자신이 사용하고 싶은 액티비티를 자유롭게 정의할 수 있습니다. 워크플로를 사용해 응용 프로그램을 작성하는 것에는 워크플로를 시각적으로 정의할 수 있다고 하는 이점이 있습니다. WF 의 Workflow Designer는 그림 8 에서 보듯이 워크플로를 시각화하여 실현합니다. 기본값에서는BAL 의 액티비티가 툴 박스에 표시됩니다. 개발자는 그러한 액티비티를 툴의 디자인 화면에 드러그 앤드 드롭하여 워크플로를 작성할 수 있습니다. 그림 8 개발자에 따라서는 시각적인 설계보다 코드의 기술을 좋아하는 경우가 있습니다. WF에서는 이 방법도 사용할 수 있습니다 (경우에 따라서는 코드기술이 필요합니다. 보통 액티비티는 직접 코드로 구축됩니다). 이 두 가지 방법을 조합해Workflow Designer 와 코드 기술의 양쪽 모두를 사용해 워크플로를 작성할 수도 있습니다. 목적은 개발자가 가장 생산적인 접근 방법을 사용할 수 있도록 하는 것입니다. 또, 다양한 툴을 지원 할 수 있도록 WPF와 사용되는 언어와 같은 XAML로 워크플로를 나타낼 수도 있습니다. 실제Workflow Designer를 사용해서 작성된 워크플로에서는 기본값으로 XAML 정의가 사용됩니다. 앞서 말했듯이 WF 런타임 엔진에는 워크플로로 액티비티를 실행하는 역할이 있습니다. 그 과정에서WF 런타임 엔진은 런타임 서비스의 그룹을 사용합니다. WF는 이러한 런타임 서비스를 표준으로 구현하지만, 의욕적인 개발자는 필요에 따라서 서비스를 옮겨놓을 수 있습니다. 런타임 서비스는 두 세가지 다른 기능을 지원하지만, 특히 주목해야 할 것이 두 가지 있습니다. 새로운 접근 방법의 도입이 기존의 접근 방법에게 주는 영향은 피할 수 없습니다. .NET Framework 3.0 의 새로운 기술도 예외 없이 다른 마이크로소프트 기술에 영향을 줍니다. 특히 WF 의 영향이 최초로 현저하게 나타난 것은 Windows SharePoint Services, Microsoft Office 2007 시스템 및 BizTalk Server 입니다. 개발자가 문서 협업이나 다른 정보 공유 워크플로 응용 프로그램을 한층 더 간단하게 작성할 수 있도록 Windows SharePoint Services 버전 3 은 WF 런타임을 호스트 합니다. Office 2007 시스템을 구성하는 Office SharePoint Server 2007 는 Windows SharePoint Services 의 WF 지원상에 구축되고 있습니다. 그 밖에도 이 서비스를 추가하는 것으로 Office 2007 클라이언트 응용 프로그램으로 InfoPath 폼을 직접 표시하거나 문서의 승인 등 공통 시나리오용의 정의가 끝난 워크플로 세트를 사용하는 것이 가능합니다. BizTalk Server에 익숙한 사용자는 그 오케스트레이션 기능과 WF 제공의 기능이 비슷한 것을 알 수 있을 것입니다. 실제BizTalk Server 2006 의 차기 출시부터 기존의 오케스트레이션 기능이 WF으로 옮겨질 예정입니다. 기존의 오케스트레이션을 WF 워크플로로 이행하기 위한 툴도 제공됩니다. 그렇지만 WF과 BizTalk Server 2006 에서 다루는 과제는 완전히 다르다는 것을 알아두는 것이 중요합니다. WF은 Windows 의 표준 워크플로 기술로써, 향후 다른 마이크로소프트 제품이나 기술에서도 채용될 것입니다. 마이크로소프트의 방침이 무엇이든 WF는 많은 개발자들이 사용하는 응용 프로그램으로 정착될 것입니다. 통신 서비스 지향의 변화는 응용 프로그램의 대화 방법에 영향을 줍니다. 서비스 지향의 응용 프로그램을 지원하도록 명시적으로 설계된 WCF는 이 변화를 반영하고 있습니다. 여기에서는WCF 에서 가장 중요한 부분인 서비스와 클라이언트, 통신 옵션 및 보안, 통신의 신뢰성, 트랜잭션 지원에 대해 설명합니다. 그림 9 그림 9 에 나타나듯이 WCF 의 기본적인 아이디어는 클라이언트에 의해서 액세스 가능한 인터페이스를 서비스가 공개한다는 심플한 것입니다. 이 인터페이스는 Web Services Description Language (WSDL)를 사용해 정의하여, 그 후 코드로 변환할 수 있습니다. 또C#이나 Visual Basic 등의 언어로 직접 정의할 수도 있습니다. 보험 응용 프로그램 서비스를 공개하는 간단한 인터페이스의 경우 언어로 직접 기술하면 다음과 같습니다. C# 인터페이스의 정의는ServiceContract속성으로 표시 되고 있습니다. 이 속성은WCF에서 인터페이스의 메소드를 원격 호출해 가능한 조작으로서 공개할 수 있는 것을 나타냅니다. 인터페이스내의 어느 메소드가 공개될지는OperationContract속성으로 표시 되고 있는지 어떤지에 의합니다. 이 간단한 예에서는 각 메소드가 이 속성으로 표시 되고 있습니다. 따라서, 이것들 모든 메소드가 원격의 호출에 공개됩니다. 다만, 모든 메소드에 표시 할 필요는 없습니다. 인터페이스의 일부의 메소드인 만큼OperationContract를 적용하는 것도 가능합니다. 어느 쪽의 방법을 취하건 응용 프로그램의 몇 개의 클래스에서 이 인터페이스를 구현해, 인터페이스가 정의하는 메소드의 실제의 코드를 제공할 필요가 있습니다. 이것이 완료되면WCF는 자동적으로OperationContract에서 표시 된 메소드를 이 서비스의 클라이언트에 액세스 할 수 있도록 합니다. 그림 10은 서비스가 실제로 그 클라이언트에 공개되는 모습을 한층 더 자세하게 나타내 보입니다. 인터페이스에 직접 액세스 하는 대신에, 클라이언트는 특정의 끝점 에 접속합니다. 서비스에서는 복수의 끝점을 공개할 수 있어 다양한 클라이언트가 다른 방법으로 액세스 하는 것을 가능하게 합니다. 그림 10 그림 10과 같이 각각의 끝점은 3 개의 업무를 지정합니다. WCF의 기본은 심플합니다. 대부분의 통신 기술처럼, 상세한 부분에서는 많은 옵션이 있어 복잡하지만, 일반적인 WCF 응용 프로그램의 작성은 어렵지 않습니다. 다양한 분야의 개발자에 의해서 구축된 다종 다양한 응용 프로그램에서는 다른 통신 방법이 필요합니다. 대부분의 개발자에게 있어서 가장 간단한 접근 방법은 원격 프로시저 콜 (RPC)를 사용하는 방법입니다. 이 방법에서는 거의 로컬의 감각으로, 클라이언트로부터 원격 조작을 호출할 수 있습니다. 전술의 인터페이스를 예로 하면, 클라이언트는 통상의 동기의 방법으로 임의의 조작을 호출해, 응답이 되돌아 올 때까지 대기할 수 있습니다. 이 옵션은 개발자에게 있어서 간단한 접근 방법이고, 상황에 따라 적절합니다. WCF 에는 다음과 같은 옵션들도 같습니다. WCF 로 개발자는 다양한 로컬 설정을 제어할 수도 있습니다. 예를 들어,ServiceBehavior속성을 사용하여, 서비스가 싱글 또는 multi-thread, 각 호출에 새로운 서비스 인스턴스를 작성 등 다양한 옵션을 설정할 수 있습니다. 시스템간에 데이터의 교환을 실시하는 기본적인 통신 기능은 유용하지만, 그것만으로는 불충분합니다. 대부분의 응용 프로그램에서는 한층 더 고도의 기능이 요구됩니다. 예를 들어, 분산 응용 프로그램은 통상 하등의 보안 대책을 필요로 합니다. 그러나 사용되는 접근 방법이나 기술이 다양화된 현재 보안의 구현은 복잡한 작업이 됩니다. 상세한 점을 모두 파악하지 않고 개발자가 안전한 분산 응용 프로그램을 작성할 수 있도록, WCF에서는 보안 구현에 주로 바인딩이 이용됩니다. 예를 들어, 전술의 BasicHttpBinding 은 HTTP 가 아닌, HTTPS)를 사용하도록 설정할 수 있습니다. 보안 옵션을 제공하는 바인딩은 그 밖에도 있습니다. 일례로서 WS-Security를 지원하는 WSHttpBinding를 사용하면, 상호 운용 가능한 SOAP 기본의 인증을 실시해, 데이터 정합성, 데이터 기밀성을 확보할 수 있습니다. 개발자는 응용 프로그램이 필요로 하고 있는 보안 서비스를 제공하도록 바인딩을 커스터마이즈 할 수도 있습니다. 통신의 신뢰성을 확보하는 일도 많은 응용 프로그램에 있어서 매우 중요합니다. HTTP를 개입시켜 SOAP를 송신하는 종래의 Web 서비스 접근 방법으로 충분한 경우는 basicHttpBinding을 사용할 수 있습니다. 그러나 일반적으로 넓게 사용되고 있지만, 많은 경우 BasicHttpBinding 에서 충분히 필요를 채울 수 없습니다. 예를 들어, 한 개 이상의 SOAP 중개자를 경유하는 메시지로 엔드 투 엔드의 신뢰성을 확보하려고 하는 경우, 이 단순한 접근 방법에 의지할 수 없습니다. WC는 이러한 문제에 대처하기 위해서 WS-ReliableMessaging를 구현하고 있습니다. WsHttpBinding 과 같은 옵션을 지원하는 바인딩을 선택하는 것만으로 개발자는 상호 운용 가능한 신뢰성이 높은 메시지 송수신을 실시할 수 있습니다. 일부의 응용 프로그램에서는 분산 트랜잭션도 매우 중요합니다. WCF는 .NET Framework 2.0 의 기능인System.Transaction를 기본으로 구축되어 있기 때문에, WCF를 사용하여, 트랜잭션 소프트웨어를 작성할 수 있습니다. 메소드에서는OperationBehavior속성을 사용하고, 트랜잭션이 필요한 것을 지정해, 트랜잭션 동작을 정의할 수 있습니다. 벤더의 구분 없이 분산 트랜잭션를 가능하도록, WCF 는 WS-AtomicTransaction 사양을 채용하고 있습니다. 복수의 벤더의 합의에 의해 정의된 이 기술로, WCF 응용 프로그램은 J2EE 등, 다양한 기술이 혼재하는 환경에서도 트랜잭션에 참가할 수 있습니다. 먼저 말한 것처럼, WCF 는 마이크로소프트에서 지금까지 사용되어 온 만큼 산 응용 프로그램의 작성에 관련하는 기술에 취해 대신하는 것입니다.지금까지 ASP.NET Web Service,.NET 리모팅, Enterprise Services, System.Messaging, 또는 WSE 를 사용해 구축되고 있던 응용 프로그램의 대부분은 향후 WCF 를 기본으로 구축됩니다.WCF 응용 프로그램은 ASP.NET Web Service 응용 프로그램 (어느쪽이나 표준의 SOAP 를 지원 하고 있다), 및 Enterprise Services, MSMQ, WSE 의 버전 3.0 을 기반으로 하는 응용 프로그램과 상호 운용할 수 있습니다. WCF 는 BizTalk Server 2006 으로 사용할 수도 있습니다.BizTalk Server 의 향후의 버전에서는 WCF 의 제공하는 기능이 보다 직접적으로 활용되게 됩니다. WCF 에 교체되는 종래의 기술이 새로운 .NET Framework 3.0 응용 프로그램으로 적극적으로 사용될 수는 없지만, 여전히 .NET Framework 3.0 의 일부를 구성하고 모두 종래대로 지원됩니다. 이러한 예전 기술을 사용해 구축된 응용 프로그램도 정상적으로 실행됩니다. .NET Framework 3.0의 인스톨이나 사용에 의해, 기존의 코드가 파괴될 것은 없습니다. Web 브라우저를 사용하는지, 그 외의 타입의 클라이언트 사용여부와 관계없이, 사용자는 일상적으로 네트워크를 개입시켜 응용 프로그램에 액세스 하고 있습니다. 이러한 응용 프로그램에서는 사용자의 신원을 확인하는 것이 일반적이 되고 있습니다. 결과적으로 사용자는 빈번히 ID 정보를 취득해, 원격 소프트웨어에 그 정보를 제공하도록 요구됩니다. 일반적인 예는 브라우저를 개입시켜 인터넷 응용 프로그램에 액세스 하는 경우가 있지만, 인트라넷의 사용자도 같은 문제에 직면하고 있습니다. 전술과 같이, 사용자는 통상, 디지털 ID로서 사용자명과 패스워드를 사용하지만, 이 방법에는 많은 문제가 수반합니다. Windows CardSpace 는 이러한 문제에 대처하는 새로운 접근 방법을 제공합니다. Windows CardSpace 는 ID 메타시스템의 구성요소입니다. 따라서CardSpace 에서 어떻게 동작하는지 이해하려면, 우선 ID 메타시스템의 기본적인 개념을 이해할 필요가 있습니다. Web 브라우저, 응용 프로그램 고유의 클라이언트 또는 그 외의 앞으로 사용할 경우에서도, 응용 프로그램에 액세스 하는 사용자는 통상, 하등의 디지털 ID를 제시하게 됩니다. 디지털 ID는 다양한 형태를 취하지만, 네트워크상에서는 대부분의 경우, 보안 토큰 에 의해서 나타내집니다. 단순한 보안 토큰은 사용자명만으로 구성됩니다만, 좀 더 복잡한 것이 되면 X.509 증명서나 XML 문서를 포함하기도 합니다. 이와 같이 다른 종류가 존재하지만, 보안 토큰은 지금 네트워크상에서 디지털 ID 를 나타내는 대표적인 메커니즘이 되고 있습니다. 보안 토큰의 형식이 하나로 통일되는 날이 온다는 것은 매력적인 생각이지만, 현실적이지는 않습니다. 지갑 안에 운전 면허증, 신용 카드, 마일리지 카드 등 몇 개의ID 카드가 있는 것과 같이, 사용자는 계속해 다양한 종류의 보안 토큰에 의한 다양한 디지털 ID 를 가지게 됩니다. 이러한 현실에서 단일의 ID 시스템에 의한 보편적인 해결책은 불가능하고, 복수의 보안 토큰은 향후도 필요하게 된다고 생각할 수 있습니다. 그러나, 다양한 디지털 ID 에 대해서 일관한 관리를 실시할 수 있는 시스템이 필요한 것도 사실입니다. 단일의 ID 시스템에 의해서 그 필요를 채울 수 없습니다만, ID 시스템을 통괄하는 시스템 (ID 메타시스템)을 작성하는 것은 가능합니다. 이 시스템에 의해, 무수한 디지털 ID를 일관한 방법으로 사용 가능합니다. 마이크로소프트는 타사와 공동으로 이 메타시스템을 정의하는 작업을 진행해 왔습니다. WS-Security 나 WS-Trust 등의 오픈 Web 서비스 기술에 근거한 이 메타시스템은 디지털 ID 가 의존하는 보안 토큰의 타입에 관계없이, 디지털 ID 취득 및 사용 방법을 정의합니다. 디지털 ID 의 발행, 취득, 사용이라고 하는 일련의 흐름에는 세 가지의 다른 역할이 관계한다고 생각할 수 있습니다. 세 가지의 역할이란, 다음과 같습니다. ID 메타시스템에서는 이러한 세 가지의 엔티티가 서로 정보를 교환합니다. 그림 11 에서는 이러한 교환과 CardSpace의 역할을 나타냅니다. 그림 11 일련의 프로세스는 우선 CardSpace 를 인식할 수 있는 응용 프로그램을 사용해 사용자가 의거 당사자에게 액세스 하는 것으로써 개시됩니다. 의거 당사자가 요구하는 보안 토큰의 타입을 알기 위해, 응용 프로그램은 의거 당사자의 정책을 취득합니다 (스텝 1). 일반적인 케이스로서Web 사이트에 액세스 하는 브라우저의 경우, 사이트의 정책은 HTML 형식에서 기술되어Web 페이지의 일부로서 주어집니다. 한편Web 서비스를 개입시켜 응용 프로그램에 액세스 하는 경우는WS-MetadataExchange 에 의해서 정의된 업계표준의 프로토콜을 사용해 의거 당사자에게 정책의 송부를 의뢰합니다. 이 경우, 정책이 다른 업계표준의 WS-SecurityPolicy를 사용해 기술됩니다. 어느 방법으로 입수되었을 경우에서도 정책에는 의거 당사자가 받아 들이는 보안 토큰의 종류와 토큰에 포함할 필요가 있는 정보의 지정이 포함되어 있습니다. 필요한 보안 토큰의 타입이 통지되면, 위에 나타나고 있는 ID 화면이 표시됩니다. 이 화면에는 사용자가 사용할 수 있는 모든 디지털 ID 에서 정보 카드로 표시됩니다. 외부의 의거 당사자에 의해서 발행된 카드는 매니지 카드로 불려 CardSpace 의 자기 발행 공급자에 의해서 발행된 카드는 자기 발행 카드로 불립니다. 이러한 카드는 양쪽 모두 화면에 표시되므로, 사용자는 몇 개의 타입의 카드를 선택할 수 있습니다. 결정을 돕기 위해 의거 당사자의 요구를 채우지 않은 카드는 그레이로 표시되어, 사용자는 적절한 카드를 분별할 수 있습니다. 표시된 카드 중에서 사용자는 디지털 ID로써 사용하는 카드를 선택합니다. (스텝 2) 다만 보안 토큰 그 자체가 카드로 보관되고 있는 것은 아닙니다. 카드에는 해당하는 ID 공급자를 특정하여, 사용자의 보안 토큰을 요구하는데 필요한 정보가 보관됩니다. (모든 카드는 원래 몇 개의 ID 공급자가 작성한 것입니다.) CardSpace는 사용자에 의해서 선택된 카드의 내용을 사용해, 카드를 발행했던 ID 공급자에 대해서 보안 토큰을 요구합니다 (스텝 3) .이 요구는 또 다른 업계표준 프로토콜 WS-Trust를 사용해 행해집니다. 사용자는Kerberos, X.509 증명서, 디지털 서명, 또는 다른 메커니즘을 사용해ID 공급자에 대해서 스스로를 인증합니다. 암호화된 토큰이 돌려 보내집니다. 토큰에는 경로를 벗어나 도용되지 않도록 타임 스탬프가 포함되어 있습니다. 요구한 보안 토큰이 주어지면, 그 토큰은 의거 당사자에게 송신됩니다(스텝4). 토큰에 보관되어 있는 정보가 의거 당사자에 의해서 어떻게 사용될지는 경우마다 다릅니다. 예를 들어 토큰에 X.509 증명서가 포함되어 있어 디지털 서명이 첨부된 경우는 의거 당사자가 토큰을 사용해 사용자의 인증을 실시한다고 생각할 수 있습니다. 다만, 토큰은 반드시 인증 혹은 다른 보안 관련의 목적으로 사용해야 하는 것은 아닙니다. ("보안 토큰" 은 정확한 명칭이 아닙니다.) 토큰에는 사용자의 연령을 증명하거나 인터넷의 쇼핑 사이트에서 할인을 받는 자격이 있을지를 나타내는 정보가 포함되는 경우도 있습니다. 보안 토큰이 인증에 사용되는 경우가 많지만, 다른 목적으로 사용하는 것도 가능합니다. 중요한 점은CardSpace에서는 ID 메타시스템 전체적으로도, 개개의 보안 토큰으로 사용되고 있는 형식이나 기술은 인식되지 않습니다. 메타시스템의 목적은 디지털 ID 의 소스를 하나에 통합하거나 보안 토큰의 표준 형식을 작성하지 않고, 모든 종류의 보안 토큰에 근거하는 디지털 ID를 일관한 방법으로 사용할 수 있도록 합니다. 메타시스템의 핵심을 Windows에 구현한 것으로, CardSpace는 디지털 ID를 관리하는 포괄적 접근 방법을 현실화하는 중요한 역할을 이루어 있습니다. 많은 경우 ID 공급자와 사용자와는 명확하게 구별됩니다. 예를 들어, 고용주에 의해서 ID 를 할당할 수 있는 경우 등이 그렇습니다. 그러나, ID 공급자가 사용자 자신이라고 하는 경우도 적지 않습니다. CardSpace를 사용하지 않는 경우, Web 사이트로의 액세스로 요구되는 사용자명이나 패스워드는 어느 쪽이든 사용자에 의해서 정의됩니다. 사용자는 한 번 ID 를 작성하면, 그 다음은 그 사용자명과 패스워드를 입력하고, 잔고 조회나 책의 구입 등 그 사이트에서 가능한 조작을 실시할 수 있습니다. 이러한 패스워드에 의존하는 자기 발행 ID은 전에 말한 것처럼 공격자의 대상이 됩니다. 이러한 공격을 줄이기 위해, CardSpace는 자기 발행 ID를 작성하는 새로운 방법을 제공하고 있습니다. 이 자기 발행 ID 공급자는 사용자의 Windows 시스템으로 로컬에 실행됩니다. 사용자명이나 패스워드에 의지하는 대신에 자기 발행 ID 공급자에 의해서 작성되는 보안 토큰은OASIS 정의의 표준인 Security Assertion Markup Language(SAML)을 사용해 정의됩니다. 이러한 토큰은 패스워드가 아니고, 공개 키 기술을 사용해 사용자의 ID를 증명합니다. 의거 당사자의 옆에서 지원되고, 이러한 토큰은 종래의 사용자명이나 패스워드와 같은 역할을 완수할 수 있습니다. 이 방법은 피싱 사기범이 훔칠 수 있는 패스워드가 이미 존재하지 않는다고 하는 것입니다. 패스워드에 의존을 줄여 전술의 신뢰할 수 있는 증명서에 의한 사이트의 ID 증명을 이용한다면, 피싱은 큰 위협이 아닙니다. CardSpace는 다음과 같은 마이크로소프트 기술이 연관되어있습니다. 마이크로소프트는 그 밖에도 ID 에 관련한 기술을 제공하고 있습니다. 그러한 기술은 각각 CardSpace 와는 다른 과제입니다. 예를 들어 Active Directory federation Services (ADFS)는 조직 전체의 연합 아이덴티티 실현에 초점을 맞추고 있습니다. 이것은 중요한 과제이며, 타사와의 공동 작업을 실시하는 많은 기업이 직면해 온 문제이기도 합니다. 그러나 CardSpace나 ID 메타시스템이 관한 광범위한 문제와는 다른 문제 입니다. 워크플로 기본 로직, 서비스 지향의 통신ID는 모두 현대의 응용 프로그램에 있어서 중요합니다. 그러나 많은 사용자가 주목하는 것은 사용자 인터페이스입니다. WPF 의 목적은 현대의 응용 프로그램의 사용자 인터페이스를 작성해야 하는 과제입니다. WPF는 인터페이스의 작성에 유용한 다양한 기능을 갖추고 있습니다. 개발자는WPF 응용 프로그램의 인터페이스를 모두 C#, Visual Basic, 또는 그 외의 CLR 기본 언어로 작성할 수 있습니다. 그러나, 전술과 같이 WPF 에서 XML 기본의 XAML를 사용해 인터페이스를 지정할 수 있습니다. XAML 의 요소와 속성은 WPF에서 제공하는 클래스나 속성에 직접 대응합니다. 예를 들어, XAML에서 단순한 버튼은 다음과 같이 정의됩니다. 이 예에서는 "No" 라고 하는 텍스트 라벨을 가지는 붉은 버튼이 작성됩니다. 이것과 완전히 같은 버튼을 다음과 같은 코드로 작성할 수도 있습니다. 정의 방법에 관계없이, 사실상 모든 WPF 응용 프로그램은 같은 기본 모델에 따릅니다. 응용 프로그램은 기본적인 메소드, 이벤트, 속성을 제공하는 WPF 의 표준 응용 프로그램 오브젝트를 계승합니다. WPF 응용 프로그램은 종래의 다이얼로그 구동형 인터페이스 또는 브라우저 응용 프로그램과 같이 기능하는 네비게이션 인터페이스의 어느 쪽이든지 구현할 수 있습니다. 후자의 스타일로 구축되는 응용 프로그램은 통상, 페이지의 그룹으로서 구현됩니다. 각 페이지는XAML에서 정의된 사용자 인터페이스와 코드로 정의된 로직으로 구성됩니다. 이러한 페이지들을 링크하려면, HTML 과 같이 Hyperlink 요소가 사용됩니다. 응용 프로그램은 한 번에 하나의 페이지를 표시해, 사용자는 각 페이지를 왕래할 수 있습니다. 응용 프로그램에는 이력 리스트의 유지 등의 기능도 있습니다. 네비게이션 응용 프로그램을 XBAP로서 Web 브라우저 내에서 실행할 수도 있지만, 반드시 이 방법을 사용할 필요는 없습니다. 개발자는 독립 실행형의 WPF 응용 프로그램으로 이 인터페이스 스타일을 사용할 수도 있습니다. WPF에서 목표로 하고 있는 것은 브라우저 인터페이스와 네이티브 Windows 인터페이스 각각의 장점을 조합한 소프트웨어의 작성입니다. 어느 인터페이스 스타일을 선택하는 경우에서도, WPF 응용 프로그램의 기본적인 레이아웃은 패널 에 의존합니다. 각 패널에는 컨트롤 에는 포함됩니다. WPF에서 Button, TextBox, ComboBox, Menu 등의 컨트롤이 제공되고 있습니다. 이러한 컨트롤이 어떻게 배치되는지는 선택되는 패널의 타입에 따라서 다릅니다. 예를 들어 특정 그리드에 컨트롤 배치되지만, Canvas 에서는 개발자가 패널의 경계내의 임의의 장소에 컨트롤을 배치할 수 있습니다. GUI와 같이, 사용자에 의해서 생성되는 이벤트는 응용 프로그램의 다양한 컨트롤이나 클래스에 의해서 포착 및 처리됩니다. 또 컨트롤의 그룹에 대해서 스타일이나 템플릿을 적용할 수도 있습니다. 이것은 응용 프로그램의 인터페이스에 통일감을 줄 수 있는 간단한 방법입니다. WPF는 이러한 기본적인 사용자 인터페이스 기능에 가세하고, 다음과 같은 기능도 갖추고 있습니다. WPF가 제공하는 다양한 사용자 인터페이스 기능에 의해, 개발자나 디자이너는 매력적인 사용자 인터페이스를 작성할 수 있습니다. 그러나, 클라이언트 응용 프로그램의 인터페이스가 아무리 매력적이어도, 배포시 문제가 있어 망설이는 기업이 있습니다. 클라이언트의 업그레이드를 실행하는데, 응용 프로그램이 인스톨 떠날 수 있어 모든 데스크톱 머신을 물리적으로 조작해야 한다고 하면, 그 코스트는 막대한 것이 됩니다. 이 문제를 피하기 위해 네이티브 Windows 클라이언트 대신에 브라우저 기본의 클라이언트를 작성한다고 하는 방법이 취해지고 있습니다. 그러나, 일반적으로 브라우저의 사용자 인터페이스는 성능이나 응답성의 면에서 네이티브 Windows 클라이언트에 뒤떨어집니다. 클라이언트의 배포에 관련하는 이러한 과제를 해결하기 위해, 독립 실행형의 WPF 응용 프로그램은 ClickOnce를 사용해 배포할 수 있습니다. ClickOnce는 .NET Framework 2.0 에서 발표된 기술입니다. ClickOnce 를 사용하면 Internet Explorer 사용자는 Web 을 개입시켜 응용 프로그램을 선택해, 로컬 머신에 자동적으로 인스톨 할 수 있습니다. 또, 인스톨 된 응용 프로그램이 새로운 버전의 출시시에 자동적으로 갱신되도록 설정할 수도 있습니다. 이 기술의 목적은 양쪽 모두의 장점, 즉 Web 클라이언트의 단순함이나 배포비용의 저렴함과 독립 실행형 WPF 응용 프로그램의 퍼포먼스나 기능성을 살리는 것입니다. ClickOnce 를 사용해 배포된 독립 실행형 WPF 응용 프로그램은 많은 경우 클라이언트로서 최적인 선택사항이 됩니다. 다만WPF 의 제공하는 인터페이스를 사용자가 이용할 수 있는 경우에서도, 이러한 응용 프로그램의 사용이 적절하지 않은 케이스도 있습니다. 예를 들어, 전술의 시나리오에 등장한 원격의 보험대리점이나 3D 그래픽스, 비디오, 및 WPF 가 지원하는 다른 최신 기능을 제공하는 인터넷 상점 같은 케이스가 있습니다. 이러한 경우, 사이트에 액세스 하기 위해, 사용자가 네이티브의 WPF 응용 프로그램을 인스톨 하는 것은 기대할 수 없습니다. 보다 좋은 해결책은 Web 브라우저 내에서 WPF 스타일의 인터페이스를 제공하는 것입니다. XAML 브라우저 응용 프로그램 (XBAP) 은 이 목적을 위해서 설계되었습니다. 독립 실행형 WPF 응용 프로그램을 배포하는 것이 아니라, Internet Explorer 사용자가 직접 XBAP)를 브라우저에 다운로드 할 수 있도록 합니다. Internet Explorer 안에서 실행되는 이 응용 프로그램은 사용자에게 WPF 기본의 사용자 인터페이스를 제공할 수 있습니다. 그렇다고는 해도, 인터넷 Web 사이트로부터 코드를 다운로드 해 실행하는 것에는 위험이 수반합니다. 악의가 있는 개발자로부터 사용자를 보호하기 위해 인터넷으로부터 다운로드 되는 모든 XBAP는 부분적으로 신뢰 받은 샌드 박스 내에서 실행됩니다. .NET Framework 가 제공하는 코드 액세스 보안에 근거하는 이 샌드 박스는 XBAP 의 기능을 제한합니다. 예를 들어, 인터넷으로부터 다운로드 된 XBAP에서는 독립 실행형 윈도우를 작성하거나 새로운 윈도우를 열거나 할 수 없습니다. 또 XBAP 자신에 의해서 기동된 보존 다이얼로그를 표시하는 것이나, 분리된 기억역 이외의 장소에 있는 파일 시스템에 액세스 할 수도 있습니다. 샌드 박스에 의해서 제한이 부과된다고는 해도XBAP는 WPF 의 대부분의 기능을 사용할 수 있습니다. 이것에는 2D 및 3D 의 그래픽스, 애니메이션, 화면상의 문서, 이미지, 비디오 등이 포함됩니다. 앞서 말했던 것처럼, WPF 응용 프로그램에서는 XAML의FlowDocument요소를 사용해 환경에 적응하는 문서를 표시할 수 있습니다. 다만, 환경에 의해서 외관이 바뀌는 문서가 항상 적절한 선택사항이라고는 할 수 없습니다. 경우에 따라서는 화면상에서도 프린터상에서도 항상 외관이 변화하지 않는 고정 서식 문서가 적절하다라고 하는 것이 있습니다. WPF 의 XPS 문서는 이 문제를 해결합니다. XAML 의 부분집합에 의해서 정의되었다XPS 문서는 XPS 리더를 갖춘 시스템으로 읽을 수 있습니다. 이 문서에 의해서 Windows 에 추가되는 새로운 인쇄 서식에서는 복잡한 그래픽스도 충실히 재현해 인쇄할 수 있습니다. 다른 타입의 문서를 일관한 방법으로 처리할 수 있듯이 하기 위해, XPS 문서와 Office 2007 문서의 양쪽 모두로 마이크로소프트의 Open Packaging Conventions 에서 사용되고 있습니다. Open Packaging Conventions 는 문서 내용의 보존이나, 문서에의 디지털 서명 등을 실시하는 공통의 방법을 정의합니다. WPF 사용자 인터페이스는 기본적인 기능을 갖춘 텍스트 에디터로 코드 또는 XAML를 사용해 직접 작성할 수 있습니다. 그러나 보다 세련된 툴을 요구하는 사람들을 위해, WPF 응용 프로그램을 작성할 수 있는 확장 기능이 Visual Studio 2005 에 추가되었습니다. Visual Studio 의 다음 출시 (코드네임은 "Orcas")에서는 Visual Designer for Windows Presentation Foundation 에서 한층 더 충실한 기능이 제공됩니다. 이 툴을 사용하는 것으로써, 개발자는 이미지 대로의 사용자 인터페이스를 그래픽으로 작성하여, 인터페이스의 코드를 툴에 생성시킬 수 있습니다. 그러나, 많은 경우 사용자 인터페이스의 정의를 실시하는 적임자는 개발자가 아닙니다. 사람과의 커뮤니케이션을 전문으로 하는 디자이너가 적합합니다. 대부분의 디자이너는 코드를 기술하지 않기 때문에, Visual Studio 에 포함된 Visual Designer for Windows Presentation Foundation은 디자이너에 있어서 효과적인 툴이 아닙니다. 디자이너가 WPF 환경에서 효과적으로 작업할 수 있도록, 마이크로소프트는 Expression Interactive Designer를 작성했습니다. 디자이너는 이 툴을 사용해 인터페이스의 외관이나 조작성 정의, 애니메이션의 지정 등을 실시합니다. 작성한 인터페이스의 XAML 코드는 툴에 생성시킬 수 있습니다. 개발자는 이 XAML를 Visual Studio 에 독립 실행하여, 이벤트의 처리를 실시하는 코드를 추가합니다. Visual Studio과 Expression Interactive Designer는 어느 쪽이나 같은 구축 시스템을 사용하고 있으므로, 개발자와 디자이너는 각각 사용하기 쉬운 툴을 사용하면서, 하나의 프로젝트를 진행시켜 나갈 수 있습니다. 이러한 툴의 목적은 디자인과 소프트웨어 엔지니어링이라고 하는 다른 분야의 전문가가 공동으로 효율적으로 작업할 수 있도록 하는 것입니다. 다른 .NET Framework 3.0 구성 요소와 같이, WPF 도 기존의 마이크로소프트 기술에 영향을 줍니다. 영향을 받는 기술 가운데 중요한 것은 다음과 같습니다. 응용 프로그램으로 .NET Framework 3.0을 사용하려면, 응용 프로그램을 실행하는 머신에 이 버전의 Framework 를 인스톨 할 필요가 있습니다. Windows Vista 의 경우는 디폴트로 .NET Framework 3.0 이 인스톨 되기 때문에, 새롭게 인스톨을 실시할 필요는 없습니다. 즉, Windows Vista에 탑재된 새로운 머신과 Vista 로 업그레이드 된 기존의 머신에서는 .NET Framework 3.0 응용 프로그램을 실행하는 것이 자동적으로 가능합니다. .NET Framework 3.0은Windows XP 나 Windows Server 2003에서 실행할 수도 있습니다. 이러한 시스템의 기존 사용자도 새로운 .NET Framework 3.0 구성 요소를 사용할 수 있도록, 무료 다운로드가 가능합니다. .NET Framework 3.0은Windows 프로그래밍 모델의 진화한 형태입니다. .NET Framework 2.0를 기반으로, 한층 더 그 기능이 확장된 Framework 3.0는 현대의 응용 프로그램의 작성을 지원하는 것을 목적으로 합니다. 따라서 .NET Framework 3.0 에는 오늘의 응용 프로그램 개발로 직면하는 중요한 과제를 해결하기 위한 다양한 기술이 구현되어 있습니다. 다양한 기술을 공통의 파운데이션 위에 구축하는 것으로써 마이크로소프트는 1 + 1 에서 2 이상이 되도록 꾸준히 노력하고 있으며 개발자가 일관한 방법으로 .NET Framework 3.0 의 다양한 기술을 이용해 응용 프로그램을 작성할 수 있도록 지원하고 있습니다. 새로운 출시에 포함된 기술을 도입하는 경우, 기업의 Windows 소프트웨어 환경에 반드시 큰 영향이 있습니다. 개발자, 설계자, 의사결정자 모두 Windows 의 소프트웨어 환경에서 작업하는 사용자 모두 .NET Framework 3.0 의 장점을 지금 검토해 보시기 바랍니다. 「Understanding .NET, Second Edition」David Chappell, Addison-Wesley, 2006 Windows Workflow Foundation 의 소개(영어) Windows Communication Foundation 의 소개(영어) |
