Roger Wolter
Microsoft Corporation

요약: 이 기사는 SOAP, WSDL, UDDI 소개 및 개발자용 XML Web services 값의 개요를 설명합니다(6페이지/인쇄 페이지 기준).

목차

XML Web Service
SOAP
WSDL
UDDI
기타

XML Web Service

XML Web services는 인터넷상에서 분산된 컴퓨팅으로 이동하는 데 기본이 되는 빌딩 블록입니다. 열린 표준과 통신 중심, 작업자 및 응용 프로그램간의 공동 작업으로 응용 프로그램을 통합하는 데 XML Web services가 플랫폼이 되는 환경을 만들었습니다. 응용 프로그램은 위치나 구현 방법과 상관없이 함께 작동하는 다양한 소스의 여러 XML Web services를 사용하여 구성됩니다.

XML Web Service를 만드는 회사가 많은 만큼 XML Web Service의 정의도 다양하겠지만 모든 정의에는 다음과 같은 공통점이 있습니다.

• XML Web Services는 표준 웹 프로토콜을 통해 웹 사용자들에게 유용한 기능을 표시합니다. 대부분의 경우 SOAP 프로토콜이 사용됩니다.
• XML Web services는 사용자와 대화할 수 있는 클라이언트 응용 프로그램을 만들 수 있는 인터페이스를 세부적으로 설명하는 방법을 제공합니다. 일반적으로 이 설명은 Web Services 설명 언어(WSDL) 문서라고 하는 XML 문서에 제공됩니다.
• XML Web services는 잠재적인 사용자가 XML Web services를 쉽게 찾을 수 있도록 등록됩니다. XML Web services는 UDDI(Universal Discovery Description and Integration)에 등록됩니다.

본 기사에서 위의 세가지 기술을 모두 설명하겠지만 XML Web services에 주의를 기울여야 하는 이유를 먼저 설명하겠습니다.

XML Web services 아키텍처의 주요 장점 중 하나는 별도의 플랫폼에 별도의 언어로 작성된 프로그램들이 표준 기반으로 서로 통신할 수 있다는 점입니다. 이 점에 대해 산업 분야에 종사했던 사람들은 DEC 이전과 CORBA에서도 같은 내용이 있었기 때문에 차이점이 없을 것 같다는 의문이 생길 수 있습니다. 첫 번째 차이점은 SOAP가 이전의 접근 방법보다 훨씬 간단하여 표준 규격의 SOAP 구현을 입력하는 작업이 더욱 용이하다는 것입니다. Paul Kulchenko는 79항목이 포함된 마지막 카운트인 http://www.soapware.org/directory/4/implementations 에서 SOAP 구현 목록을 유지 관리합니다. SOAP 구현은 규모가 큰 소프트웨어 회사에서 찾을 수 있지만 개인 개발자가 작성하고 유지 관리하는 구현도 많이 찾을 수 있습니다. 이전에 비해 XML Web services가 갖는 또 다른 큰 장점은 표준 웹 프로토콜인 XML, HTTP 및 TCP/IP와 작동한다는 것입니다. 수 많은 회사들이 웹 인프라와 이를 유지 관리하는 지식과 경험이 있는 직원들을 갖추었기 때문에 XML Web services에 대한 항목에 소모되는 비용이 이전 기술에 비해 현저히 감소됩니다.

지금까지 WSDL 파일에 설명되고 UDDI에 등록된 XML Web service를 SOAP를 통해 웹에 나타나는 소프트웨어 서비스로 정의했습니다. 그 다음 논리적인 질문은 XML Web services로 무엇을 할 수 있는가 하는 것입니다. 처음에 XML Web services는 주식 시세, 일기 예보, 스포츠 등 응용 프로그램에 쉽게 통합될 수 있는 정보원이었습니다. 원하는 정보를 분석하고 집계하여 다양한 방법으로 표시하도록 작성할 수 있는 응용 프로그램이 있습니다. 예를 들어, Microsoft® Excel 스프레드시트를 사용하여 주식, 401K, 은행 계좌, 대출 등의 전체 금융 상태를 요약할 수 있습니다. 이 정보를 XML Web services에서 사용할 수 있는 경우 Excel은 이 Web services를 계속 업데이트합니다. 이 정보 중 일부는 무료이며 어떤 정보는 서비스 구독이 필요할 수도 있습니다. 대부분의 정보는 웹에서 현재 사용할 수 있지만 XML Web services는 더욱 쉽고 안정적인 프로그래밍 방식으로 액세스됩니다.

기존 응용 프로그램을 XML Web services로 나타내면 XML Web services를 빌딩 블록으로 사용하는 더욱 강력한 새 응용 프로그램을 작성할 수 있습니다. 예를 들어, 여러 공급업체의 가격 정보를 자동으로 얻을 수 있고 공급업체를 선택할 수 있으며 주문한 다음 제품이 도착할 때까지 배달 과정을 확인할 수 있습니다. 공급업체 응용 프로그램은 웹상에 서비스를 표시한 다음 XML Web services를 사용하여 고객의 신용 확인, 요금 부과 및 배달 회사에 배달을 의뢰할 수도 있습니다.

앞으로 몇몇 중요한 XML 웹 서비스를 사용하면 웹을 사용하는 응용 프로그램을 지원하여 오늘날에는 실행하지 못하는 사항들을 실행할 수 있게 될 것입니다. 예를 들어, 일정 관리 서비스는 Microsoft .NET My Services 프로젝트가 지원하는 서비스 중 하나입니다. 치과 의사나 정비사가 XML Web service를 사용하여 일정을 관리하는 경우 고객이 온라인으로 시간 약속을 예약하거나, 고객이 원할 경우 치과 의사나 정비사가 직접 고객과 청소 및 정기 점검 약속을 할 수 있습니다.조금만 생각해 보면, 웹을 프로그램할 수 있는 능력이 있기만 하면 작성할 수 있는 응용 프로그램이 많이 있습니다.

XML Web services 및 응용 프로그램 작성에 대한 더 자세한 내용은 MSDN Web services 홈 페이지를 참조하십시오.

SOAP

SOAP는 XML Web services용 통신 프로토콜입니다. SOAP를 통신 프로토콜로 설명하면 대부분의 사람들은 DCOM 또는 CORBA를 생각하고 "SOAP가 객체를 활성화하는 방법은 " 또는 "SOAP가 사용하는 이름 서비스는 " 등과 같은 질문을 합니다. SOAP 구현에 이러한 내용이 포함되기는 하지만 SOAP 표준은 이 내용을 지정하지 않습니다. SOAP는 메시지 즉, 요청된 사양의 일부에 대한 XML 형식을 정의하는 사양입니다. 몇몇 SOAP 요소에 포함된 올바른 형식의 XML 조각이 있는 경우 SOAP 메시지가 나타납니다. 간단합니다.

SOAP 사양의 다른 부분은 프로그램 데이터를 XML로 표시하고 SOAP를 사용하여 원격 프로시저 호출을 수행하는 방법을 설명합니다. 이러한 사양의 선택적 부품은 클라이언트에서 전송되는 SOAP 메시지에 호출 가능한 함수와 해당 함수에 전달되는 매개 변수가 포함되어 있는 RPC 스타일 응용 프로그램을 구현하는 데 사용되며 서버는 실행된 함수의 결과와 함께 메시지를 반환합니다. COM 또는 CORBA 응용 프로그램을 실행하는 프로그래머들은 RPC 스타일을 이해하기 때문에 현재 대부분의 SOAP 구현은 RPC 응용 프로그램을 지원합니다. 또한 SOAP는 SOAP 메시지가 XML 문서에서 래퍼 기능만 수행하는 문서 스타일 응용 프로그램도 지원합니다. 문서 스타일 SOAP 응용 프로그램은 매우 융통성이 있으며 여러 새 XML Web services는 이 장점을 활용하여 RPC를 사용하여 구현하기 어려운 서비스를 만듭니다.

SOAP 사양의 마지막 선택 부분은 SOAP 메시지를 포함한 HTTP 메시지의 형식을 정의합니다. HTTP 바인딩은 HTTP가 거의 모든 현재 OS 및 현재가 아닌 여러 OS에 의해 지원되기 때문에 중요합니다. HTTP 바인딩은 선택 사항이지만 SOAP에 대해 유일하게 표준화된 프로토콜이기 때문에 거의 모든 SOAP 구현은 HTTP 바인딩을 지원합니다. 이러한 이유로 인해 SOAP에 HTTP가 필요한 것으로 잘못 생각하는 경우가 있습니다. 몇몇 구현은 MSMQ, MQ 시리즈, SMTP 또는 TCP/IP 전송을 지원하지만 거의 모든 현재 XML Web services는 흔히 사용되는 HTTP를 사용합니다. HTTP는 핵심 웹 프로토콜이므로 대부분의 회사는 HTTP를 지원하는 네트워크 인프라와 이를 관리하는 인력을 갖추고 있습니다. 보안, 모니터링 및 HTTP에 대한 로드 균형 인프라는 오늘날 쉽게 사용할 수 있습니다.

SOAP를 시작할 때 혼동되는 주요 원인은 SOAP 사양과 여러 SOAP 사양 구현간의 차이점입니다. SOAP를 사용하는 대부분의 사람들은 SOAP 메시지를 직접 작성하지는 않지만 SOAP 도구 키트를 사용하여 SOAP 메시지를 만들고 구문 분석합니다. 일반적으로 이러한 도구 키트는 함수 호출을 몇몇 종류의 언어에서 SOAP 메시지로 변환합니다. 예를 들어, Microsoft SOAP Toolkit 2.0은 COM 함수 호출을 SOAP로 전환하고 Apache Toolkit는 JAVA 함수 호출을 SOAP로 변환합니다. 함수 호출의 유형과 지원되는 매개 변수의 데이터 유형은 각 SOAP 구현에 따라 다양하기 때문에 한 개의 도구 키트와 함께 작동하는 함수는 다른 도구 키트와 작동하지 않을 수도 있습니다. 이것은 SOAP의 제한 사항이 아니라 사용자가 사용하는 특정 구현입니다.

훨씬 강제적인 SOAP의 기능은 많은 별도의 하드웨어 및 소프트웨어 플랫폼에 구현되었다는 점입니다. 이것은 사용자의 회사 내부, 외부의 서로 다른 시스템을 연결하는 데 SOAP를 사용할 수 있다는 의미입니다. 과거에 시스템을 통합하는 일반 통신 프로토콜을 개발하려는 노력은 많았지만 아무도 SOAP를 일반적으로 채택하지는 않았습니다. 왜냐하면, SOAP는 이전의 많은 프로토콜에 비해 구현하는 데 훨씬 작고 단순했기 때문입니다. 예를 들어, DCE 및 CORBA는 구현하는 데 수 년이 걸렸기 때문에 소수의 구현만이 출시되었습니다. 그러나 SOAP는 기존의 XML 파서 및 HTTP 라이브러리를 사용하여 대부분의 힘든 작업을 수행하므로 수 개월 내에 SOAP 구현을 완료할 수 있습니다. 따라서 70종류의 SOAP 구현을 사용할 수 있습니다. SOAP는 DCE 또는 CORBA가 수행하는 작업을 모두 수행하지는 않지만 기능 교환이 복잡하지 않기 때문에 SOAP를 쉽게 사용할 수 있습니다.

HTTP의 보편성와 SOAP의 간소성이 동시에 존재하면 거의 모든 환경에서 호출할 수 있는 XML Web services를 구현하는 데 있어 이상적인 기반이 됩니다. SOAP에 대한 더 자세한 내용은 MSDN SOAP 홈 페이지를 참조하십시오.

보안

SOAP를 처음 사용하는 사람들의 첫 번째 질문 중 하나는 SOAP가 보안을 다루는 방법입니다. SOAP 개발 초기에는 SOAP가 HTTP 기반 프로토콜로 표시되어 HTTP 보안이 SOAP에 충분했습니다. 오늘날 수 많은 웹 응용 프로그램이 HTTP 보안을 사용하여 실행되므로 HTTP 보안은 SOAP에 충분합니다. 따라서 현재 SOAP 표준은 보안 문제보다는 전송 문제를 다룹니다.

SOAP가 여러 전송 작업에서 제대로 실행되는 보다 일반적인 용도의 프로토콜로 확장되면 보안은 더욱 큰 문제가 됩니다. 예를 들어, HTTP는 SOAP를 호출하는 사용자를 인증하는 몇 가지 방법을 제공하지만 메시지가 HTTP에서 SMTP로 전송될 때 해당 ID의 전파 방법에 대한 문제가 발생합니다. 다행히 SOAP는 빌딩 블록 프로토콜로 디자인되었기 때문에 SOAP를 작성하는 작업에 이미 사양이 포함되어 Web services에 대한 추가 보안 기능을 제공합니다. WS-Security specification 은 전체 암호화 시스템을 정의하고 WS-License specification 은 호출자의 ID와 권한이 부여된 사용자만 Web service를 사용할 수 있도록 하는 기술을 정의합니다.

WSDL

whiz-dull이라고도 하는 WSDL는 Web Services Description Language의 약어입니다. 편의상, WSDL 파일을 SOAP 메시지 집합 및 해당 메시지가 교환되는 방법을 설명하는 XML 문서라고 할 수 있습니다. 다시 말해서 WSDL은 IDL이 CORBA 또는 COM인 SOAP입니다. WSDL은 XML이기 때문에 읽을 수 있고 편집할 수 있지만 대부분의 경우에는 소프트웨어에 의해 작성되고 사용됩니다.

WSDL의 값을 보려면 비즈니스 파트너가 제공하는 SOAP 메서드를 호출해야 합니다. 비즈니스 파트너에게 몇몇 예제 SOAP 메시지를 요청하고 해당 예제와 같은 메시지를 작성하고 사용하는 응용 프로그램을 작성할 수 있으나, 오류가 발생하기 쉽습니다. 예를 들어, 고객 ID가 2387인 경우 메시지가 문자열이면 ID는 정수입니다. WSDL은 요청 메시지에 포함되는 사항과 응답 메시지의 형식을 명백한 노테이션으로 지정합니다.

WSDL 파일이 메시지 형식을 설명하기 위해 사용하는 노테이션은 XML 스키마 표준을 기반으로 하며, 이것은 프로그래밍 언어 중립적이며 또한 표준 기반이어서 다양한 플랫폼과 프로그래밍 언어에서 액세스할 수 있는 XML Web services 인터페이스를 설명하기에 적합하다는 것을 의미합니다. WSDL은 메시지 컨텐트를 설명할 뿐만 아니라 서비스를 사용할 수 있는 위치 및 서비스와 대화하는 데 사용되는 통신 프로토콜을 정의합니다. 즉, WSDL 파일은 XML Web service와 함께 작동하는 프로그램을 쓰는 데 필요한 모든 사항을 정의합니다. WSDL 파일을 읽고 XML Web service와 통신하는 데 필요한 코드를 생성할 수 있는 몇 가지 도구가 있습니다. 그 중에서 성능이 뛰어난 몇몇 도구들이 Microsoft Visual Studio® .NET에 있습니다.

많은 현재 SOAP 도구 키트에는 기존 프로그램 인터페이스에서 WSDL 파일을 생성하는 도구가 포함되지만 WSDL을 직접 작성하는 도구는 거의 없으며 WSDL에 대해 필요한 만큼 도구가 지원되지 않습니다. WSDL 파일 작성자에게 도구가 지원되어 COM IDL과 같은 프록시 및 스텁을 작성하는 것은 대부분의 SOAP 구현의 일부분이 됩니다. 이런 점에서 WSDL은 XML Web services에 대한 SOAP 인터페이스를 만드는 데 좋은 방법입니다.

http://www.w3.org/TR/wsdl 에서 WSDL 사양을 볼 수 있으며 우수한 description of WSDL을 사용할 수 있습니다.

UDDI

UDDI(Universal Discovery Description 및 Integration)는 Web services의 옐로 페이지입니다. 전통적인 옐로 페이지에서는 필요한 서비스를 제공하는 회사를 찾아 제공된 서비스를 검토한 후에 담당자와 연락하여 자세한 정보를 구할 수 있습니다. 지하실에서 비즈니스를 시작하고 말로 광고를 할 수 있는 것처럼 UDDI에 등록하지 않고도 Web service를 제공할 수는 있습니다. 그러나 시장을 넓히기 위해서는 고객이 Web services를 찾을 수 있도록 UDDI에 등록해야 합니다.

UDDI 디렉터리 항목은 비즈니스 및 제공되는 서비스를 설명하는 XML 파일입니다. UDDI 디렉터리의 항목은 세 부분으로 되어 있습니다. "화이트 페이지"는 서비스를 제공하는 회사의 이름, 주소, 연락처 등을 설명합니다. "옐로 페이지"에는 북미 산업 분류 시스템 및 표준 산업 분류 등과 같은 표준 분류법을 기반으로 하는 산업 범주가 나와 있습니다. "그린 페이지"는 Web service를 사용하는 응용 프로그램을 작성할 수 있도록 서비스에 인터페이스를 세부적으로 설명합니다. 서비스 방법은 유형 모델 또는 tModel이라고도 하는 UDDI 문서를 통해 정의됩니다. 많은 경우에, tModel에는 XML Web service에 SOAP 인터페이스를 설명하는 WSDL 파일이 포함되어 있지만 tModel은 융통성이 있어 거의 모든 종류의 서비스를 설명할 수 있습니다.

또한 UDDI 디렉터리에는 사용자의 응용 프로그램을 작성하는 데 필요한 서비스를 검색하는 몇 가지 방법이 있습니다. 예를 들어, 지정된 지역 및 지정된 유형의 비즈니스로 서비스 공급자를 검색할 수 있습니다. 그런 다음 UDDI 디렉터리는 정보, 연락처, 링크 및 기술적인 데이터를 공급하여 사용자의 요구 사항에 맞는 서비스를 평가할 수 있도록 합니다.

UDDI를 사용하여 Web services를 얻을 수 있는 비즈니스를 찾을 수 있습니다. 비즈니스 파트너는 알고 있지만 제공되는 서비스가 무엇인지 모를 경우에는 WS-Inspection specification 을 사용하여 특정 서버에 제공된 XML Web services의 컬렉션을 검색하여 필요한 서비스를 찾을 수 있습니다.

UDDI에 대한 더 자세한 내용은 http://www.uddi.org/about.html 를 참조하십시오.

기타

지금까지 XML Web services와의 대화 방법(SOAP), XML Web services 설명 방법(WSDL) 및 XML Web services 찾는 방법(UDDI)에 대해 설명했습니다. 이러한 사항들은 응용 프로그램 통계 및 집계에 대한 기초를 제공하는 기준 사양 집합을 구성합니다. 회사는 기준 사양을 이용하여 실제 솔루션을 구축하고 실제 값을 얻습니다.

실제 XML Web services를 만드는 데 많은 노력을 해왔지만 앞으로 더욱 많은 노력이 필요합니다. 오늘날 XML Web services를 성공적으로 작성하고는 있지만 보안, 운영 관리, 트랜잭션, 안정된 메시징과 같이 개발자가 개발해야 할 사항들이 여전히 남아 있습니다. 전역 XML Web Services 아키텍처는 모듈화 및 확장 가능한 XML Web services에 새 고급 기능을 추가하는 데 정확한 다용도 모델을 제공하여 XML Web services를 다음 단계로 이동할 수 있도록 도와줍니다.

위에서 언급한 보안 모듈(WS-Security 및 WS-License) 은 전역 Web Services 아키텍처의 사양 중 일부입니다. 운영 관리를 프로세싱하려면 여러 서버 간에 메시지를 라우팅하고 해당 서버를 동적으로 구성해야 하는데 이러한 작업도 전역 Web Services 아키텍처의 일부이며 WS-Routing specification 및 WS-Referral specification 과 일치합니다. 전역 Web Services 아키텍처가 발전함에 따라 해당 사양 및 기타 필요 사항이 소개됩니다.

더 자세한 내용은 Global XML Web Services Architecture 를 참조하십시오.

invalid-file

Building a customizable Web site complete with a collection of pluggable Web Parts is fairly easy with the portal infrastructure of ASP.NET 2.0. This model is very flexible, allowing users to easily place your Web Parts anywhere on the Web page so they are free to customize your site. However, these advantages can also lead to inefficiencies that may degrade the user experience, since you may not know beforehand which components will be used together, and therefore can’t make specific data retrieval optimizations for each individual component.

The most common inefficiency in a typical portal site occurs when multiple Web Parts simultaneously make network requests for data. Each request, whether to a Web service or a remote database, ends up adding to the overall time it takes to process the page even though the requests are typically independent of each other and could conceivably be issued in parallel.

Fortunately, ASP.NET 2.0 also introduces an easy-to-use asynchronous page model that, when used in combination with asynchronous Web service calls and asynchronous database access, can significantly improve the response time for a portal page as several independent Web Parts collect data in parallel. Here I’ll look at techniques for building Web Parts that perform their data retrieval asynchronously to make the portal pages that contain them more responsive and scalable.

Let’s begin by considering the portal page shown in Figure 1. In this sample there are four Web Parts on a portal page, each retrieving data from a different source. The full source for this sample application is available for download on the MSDN^®Magazine Web site and I encourage you to review the application as you read this column. In the sample, three of the Web Parts retrieve their data from a Web service, which intentionally waits for three seconds before returning. The fourth Web Part issues an ADO.NET query to a SQL Server database, which also waits three seconds before returning. This is an exaggerated example of the problem, but it’s not all that improbable.

Figure 1 Sample Portal Page

Each of the Web Parts in the sample application is built with a user control and binds the results of the data retrieval to the controls that display it. The code and markup for each control is kept to a minimum so that the example is simple and lets you focus on making the Web Parts asynchronous.

Here’s the NewsWebPart.ascx user control file:

   <%@ Control Language="C#" 
           AutoEventWireup="true" 
           CodeFile="NewsWebPart.ascx.cs"  
           Inherits="webparts_
           NewsWebPart" %>

   <asp:BulletedList ID="_newsHeadlines" 
           runat="server">
   </asp:BulletedList>

public partial class webparts_NewsWebPart : UserControl
{
    protected void Page_Load(object sender, EventArgs e)
    {
        PortalServices ps = new PortalServices();
        _newsHeadlines.DataSource = ps.GetNewsHeadlines();
        _newsHeadlines.DataBind();
    }
}

Note how it interacts with a Web service to retrieve the sample news headlines. The stock quotes Web Part and the weather forecaster Web Part are implemented in much the same way and use different methods of the same Web service to retrieve their data. Similarly, Figure 2 shows the SalesReportWebPart.ascx user control file and the corresponding codebehind file for the sales report sample Web Part. Note how the control uses ADO.NET to retrieve the sales data from a database and then populates a GridView control with that data.

Figure 3 Sequential Web Part Processing

As soon as the sample portal page is run, a problem becomes apparent. It takes more than 12 seconds for the request to process—a delay that will make most users avoid using the application. The reason for this lengthy delay is shown in Figure 3, which traces the path of execution a request takes when this page is executed. Like any other control in a page’s control hierarchy, each Web Part is loaded in turn, in the order defined by the control hierarchy of the page. Because this process is sequential, each Web Part must wait for the part preceding it in the hierarchy to complete before it can begin requesting its data and preparing its response. Because of the artificial 3-second delay introduced in each data retrieval, it is easy to see why it takes 12 seconds for the response to complete. Each Web Part is performing a completely independent data retrieval, one after the other. The important thing to realize is that all of these retrievals could be performed in parallel, cutting the response time by 75 percent. That is my goal here.

In the example, three Web Parts use Web services to retrieve their data, and one uses ADO.NET to access a database. Let’s start by making the Web service invocations asynchronous, since there is some nice support in the Web service proxy classes generated by the Web Services Description Language tool WSDL.exe (or the Visual Studio 2005 Add Web Service Reference tool) for performing Web method invocation asynchronously.

When a Web service proxy class is created in ASP.NET 2.0, it actually generates three different ways of invoking any particular method, one synchronous and two asynchronous. For example, the Web service proxy that the Web Parts are using has the following methods available for invoking the GetNewsHeadlines Web method:

   public string[] GetNewsHeadlines()
   
   public IAsyncResult BeginGetNewsHeadlines(
       AsyncCallback callback, object asyncState) 
   public string[] EndGetNewsHeadlines(       IAsyncResult asyncResult) 

   public void GetNewsHeadlinesAsync() 
   public void GetNewsHeadlinesAsync(       object userState)
   public event
       GetNewsHeadlinesCompletedEventHandler 
       GetNewsHeadlinesCompleted;

The first method, GetNewsHeadlines, is the standard synchronous method. The next two, BeginGetNewsHeadlines and EndGetNewsHeadlines, can be used to invoke the method asynchronously and can be tied into any number of asynchronous mechanisms in .NET through the standard IAsyncResult interface.

But the most interesting method to use in this scenario is the last one: GetNewsHeadlinesAsync. In order to use this particular method, I must register a delegate with the proxy class’s event that was specifically generated to capture the results of async invocations (the GetNewsHeadlinesCompleted event in the example). The delegate signature is strongly typed to contain the return values of the method so that I can easily extract the results in the method implementation.

Using this event-based asynchronous method, rewriting the Web method invocation in the headline news Web Part to be asynchronous is easy, as shown in Figure 4. I first subscribe a delegate to the GetNewsHeadlinesCompleted event of the proxy class, and then call the GetNewsHeadlinesAsync method. In the implementation of the method subscribed to the completed event, I bind the results of the Web method call to the BulletedList to display to the client. One additional consideration is that these asynchronous methods only work if the Web Part is placed on a page with the Async="true" attribute set, which can be checked programmatically by looking at the IsAsync property of the containing page. If the page the Web Part is placed on is not async, then I need to resort to standard synchronous binding, as shown in Figure 4.

Now, for the asynchronous Web Part to perform its data retrieval asynchronously, it must be placed on a page with the Async attribute set to true, so I modify the Page directive of the portal page to look like the following:

<%@ Page Language="C#" AutoEventWireup="true"  Async="true" %>

Once I update the other two Web Parts that use Web services to retrieve their data asynchronously, the portal page is much more responsive. In fact, depending on the order in which the parts are loaded, it may render to the client in just over three seconds (if the sales Web Part is loaded first, it will take just over six seconds)! Even though the sales report Web Part is still sequentially accessing the database, the other three Web Parts are now performing their Web service invocations asynchronously so the primary request thread is no longer waiting for their completion. Of course, I ultimately want to have all of the I/O-bound work be asynchronous so that clients could use both Web service and database-driven Web Parts without unnecessary sequential blocking.

The other reason to push the I/O-bound work onto asynchronous I/O requests is to relinquish the primary thread back to the thread pool to service other requests. Currently I’m relinquishing the thread only after my sales report database query has completed, which means I’m sitting idly for three full seconds occupying a threadpool thread that could be used to service other requests. If I can make this last I/O-bound request for data asynchronous as well, my page will use the request thread only long enough to spool off all the asynchronous I/O requests and then return immediately back to the pool.

If you’ve ever done any asynchronous programming, you probably have the feeling that the minor changes made to the Web service invocation can’t possibly be sufficient. I didn’t even have to touch an IAsyncResult interface, nor did I have to let the containing page know that I was performing asynchronous operations (by registering a task or some other technique), and yet it all seemed to work as I had hoped.

The secret lies in the Web service proxy class’s implementation of the asynchronous method, along with a helper class introduced in the Microsoft^® .NET Framework 2.0 called the AsyncOperationManager. When I called the GetNewsHeadlinesAsync method of the proxy class, it mapped the call onto an internal helper method of the SoapHttpClientProtocol base class, called InvokeAsync, from which the proxy class derives. InvokeAsync does two important things—it registers the asynchronous operation by calling the AsyncOperationManager’s static CreateOperation method, and it then launches the request asynchronously using the WebRequest class’s BeginGetRequestStream method. At this point the call returns and the page goes on processing its lifecycle, but because the page has been marked with the Async="true" attribute, it will only continue processing the request up through the PreRender event and will then return the request thread to the thread pool. Once the asynchronous Web request completes, it will invoke the method I subscribed to the completed event of the proxy on a separate thread drawn from the I/O thread pool. If this is the last of the asynchronous operations to complete (kept track of by the synchronization context of the AsyncOperationManager), the page will be called back and the request will complete its processing from where it left off, starting at the PreRenderComplete event. Figure 5 shows this entire lifecycle when you use asynchronous Web requests in the context of an asynchronous page.

Figure 5 Asynchronous Web Requests in Asynchronous Pages

The AsyncOperationManager is a class that is designed to be used in different environments to help in the management of asynchronous method invocations. For example, if I called a Web service asynchronously from within a Windows^® Forms application, it would also tie into the AsyncOperationManager class. The difference between each environment is the SynchronizationContext associated with the AsyncOperationManager. When running in the context of an ASP.NET-based application, the SynchronizationContext will be set to an instance of the AspNetSynchronizationContext class. The primary purpose here is to keep track of how many outstanding asynchronous requests are pending so that when they are all complete, the page request processing can resume. In contrast, when in a Windows Forms-based application, the SynchronizationContext will be set to an instance of the WindowsFormsSynchronizationContext class. Its primary purpose is to allow for easier marshaling of invocations from a background thread to the UI thread.

Now, back to the problem of making the last Web Part asynchronous and the general issue of performing asynchronous data retrieval with ADO.NET. Unfortunately, there is no equivalent to the simple asynchronous mechanism exposed by Web service proxies for performing asynchronous data retrieval, so I’m going to have to do a little more work to get the final Web Part to participate in the asynchronous shuffle. I can work with the new asynchronous methods on the SqlCommand class and the asynchronous task feature of ASP.NET. Using SqlCommand, I can now invoke commands asynchronously using one of the following methods:

• IAsyncResult BeginExecuteReader(AsyncCallback ac, object state)
• IAsyncResult BeginExecuteNonQuery(AsyncCallback ac, object state)
• IAsyncResult BeginExecuteXmlReader(AsyncCallback ac, object state)

• SqlDataReader EndExecuteReader(IAsyncResult ar)
• int EndExecuteNonQuery(IAsyncResult ar)
• XmlReader EndExecuteXmlReader(IAsyncResult ar)

To use any of these asynchronous retrieval methods, "async=true" must be added to the connection string. For this scenario, I am interested in populating a GridView by binding it to a SqlDataReader, so I will use the BeginExecuteReader method to initiate the asynchronous call.

To tie this into the asynchronous page, ASP.NET 2.0 also allows you to register asynchronous tasks that need to be executed before the page completes rendering. This is a more explicit model than the one I used with the Web service proxies, but it also provides more flexibility. To register an asynchronous task, I create an instance of the PageAsyncTask class and initialize it with three delegates: begin handler, end handler, and timeout handler. The begin handler must return an IAsyncResult interface, so this is where I will launch my asynchronous data request using BeginExecuteReader. The end handler is called once the task is complete (when there is data ready to read in this example), at which point I can use the results. ASP.NET will take care of invoking the begin handler just before it relinquishes the request thread (immediately after the PreRender event completes). Figure 6 shows the updated implementation of the sales report Web Part performing asynchronous data access using the asynchronous tasks and the asynchronous BeginExecuteReader method of the SqlCommand class.

Note that I could use this same technique with my Web service requests by using the alternate asynchronous methods provided on the proxy class (BeginGetNewsHeadlines, for example). One potential advantage to this technique is that I can also specify a timeout handler. If the remote invocations fail to return in time, the associated timeout handler will be invoked. This timeout is specified in the Page directive using the AsyncTimeout attribute and defaults to 20 seconds. Also note that unlike when using the event-based asynchronous pattern, when using Page.RegisterAsyncTask I don’t have to branch to a synchronous invocation based on the result of Page.IsAsync. Asynchronous page tasks in Web Parts work just fine on synchronous pages, and even allow for parallel execution of Web Parts. The core difference is that on synchronous pages (ones without the Async="true" attribute), the main page thread won’t be released back to the thread pool during the execution of the asynchronous operations.

With all of the Web Parts now performing their data retrieval asynchronously, I can now use these parts in any page marked as asynchronous and know that the response time will no longer be the sum of the time it takes for all the Web Parts to retrieve their data, but the maximum amount of time taken by any one Web Part. By marking the page as asynchronous and using Web Parts that perform asynchronous I/O, I also increase the potential scalability of the site since the page will free up the primary request thread to service other clients while waiting for the data. The key takeaway here is that if you’re building portal sites with ASP.NET 2.0, you should keep in mind all of the new asynchronous features introduced in this release, and take advantage of them to improve both the responsiveness and scalability of your applications. For more information on asynchronous support in ASP.NET 2.0, see Jeff Prosise’s Wicked Code column in the October 2005 issue of MSDN Magazine.

Send your questions and comments for Fritz to xtrmasp@microsoft.com.

출처 : MSDN (http://msdn.microsoft.com/msdnmag/issues/06/07/ExtremeASPNET/default.aspx)

Show Me the Code

I created two .NET projects for this article. One is a basic Web Service; the other is a Windows Forms client that calls the Web Service. The Web Service is a simple service that maintains a list of people and their phone numbers. It reads the information from a file and caches the file contents in the ASP.NET application cache for efficiency. The Web Method I call is named FindPhoneNumberForName.

The client is a Windows Forms application in this demonstration, but this isn't universally the case. Quite often, the client could be another service or perhaps some business logic in a large enterprise application. Any .NET consumer of a Web Service can use the techniques I show here. Figure 2 shows the user interface I created.

Figure 2: Demonstration User Interface

The user provides a name for which he or she desires a phone number, clicks "Get", and then waits for the response.

The interesting code is in the button click handler for the "Get" button:

private void cmdGet_Click(object sender, System.EventArgs e)
{
   // Create the Web Service proxy...
   YPServiceClass ws = new YPServiceClass();

   if ( tbName.Text.Length > 0 )
   {
      this.Cursor = Cursors.AppStarting;
      try
      {
         // Make the asynchronous call
         ws.BeginFindPhoneNumberForName(tbName.Text,
            new AsyncCallback(lookupHandler),ws);
      } // try
      catch (Exception ex)
      {
         string strMsg =
            String.Format("Error initiating asynchronous " +
                          "call: '{0}'",ex.Message);
         MessageBox.Show(strMsg, "Web Error",
                         MessageBoxButtons.OK,
                         MessageBoxIcon.Error);
         this.Cursor = Cursors.Arrow;
      } // catch
       // if
   else
   {
      lblPhone.Text = "";
   } // else
}

I italicized the actual call to the Web Service. Note that unlike a synchronous call, which would look like this:

ws.FindPhoneNumberForName(tbName.Text);

it has a very different invocation that looks like this:

ws.BeginFindPhoneNumberForName(tbName.Text,
     new AsyncCallback(lookupHandler),ws);

You know it's an asynchronous call because I use the "begin" form of the method's signature, but other parameters go into the request also. The first is an instance of an AsyncCallback object, and the second is my instance of the Web Service proxy itself. The AsyncCallback object is actually a .NET delegate defined specifically for asynchronous callbacks. It defines the method signature for a method that you provide to handle the returned information from the Web Service. The delegate defines a method signature like the following:

delegate void AsyncCallback(IASyncResult iar);

If you generate a method with the preceding signature and provide that to the constructor of the AsyncCallback delegate (as I did in the Web Service invocation), when the Web Service response arrives from the remote server, .NET will invoke the method you provided to the delegate's constructor. In this case, .NET will invoke the method I named lookupHandler.

The lookupHandler method is then where I actually strip out the results of the Web Service invocation:

private void lookupHandler(IAsyncResult iar)
{
   try
   {
      // Finalize the asynchronous call
      string number = ((YPServiceClass)iar.AsyncState).
         EndFindPhoneNumberForName(iar);

      // Update the user interface
      object[] args = new object[1];
      args[0] = number;
      this.Invoke(new LookupUIUpdateHandler(lookupUIUpdateHandler),
         args);
   } // try
   catch (Exception ex)
   {
      string strMsg = 
         String.Format("Error terminating asynchronous " + 
         "call: '{0}'",ex.Message);
      MessageBox.Show(strMsg,"Web Error",
                      MessageBoxButtons.OK,
                      MessageBoxIcon.Error);
   } // catch
}

I italicized the magic line of code in lookupHandler for extracting the resulting Web Service return parameter information, but I'll repeat it here because it looks a little strange:

string number =
   ((YPServiceClass)iar.AsyncState).EndFindPhoneNumberForName(iar);

As you may recall, when we invoked the Web Service asynchronously, we passed our parameters, an AsyncCallback object, and a reference to the Web Service proxy itself into the "begin" method. We provided the proxy reference to a call implemented by the proxy itself because an object must be responsible for maintaining the state of the asynchronous call. In other words, some object .NET can control must contain the results of the call so that .NET can forward those results to us. This is the job of the proxy: the proxy implements the "end" (call finalization) method. If you write your own asynchronous calls, you may have to provide your own asynchronous state object. But in the case of .NET Web Services and its proxies, you use the proxy objects themselves.

So, the following piece of code does nothing more than return the original proxy object:

((YPServiceClass)iar.AsyncState

And becaise it's our Web Service's proxy, it implements the "end" method, EndFindPhoneNumberForName. So, all we really did was perform a simple cast to obtain our proxy and then finalize the call. The return value for EndFindPhoneNumberForName is simply the return value of the phone number request method, which is a string representing the phone number of the individual requested.

If I were calling this Web Service code and didn't need to display the string in a window, I'd be done. But in the lookupHandler method, some additional code is necessary because I am sending this string to a window for display. Remember, only the thread that created the window can change its state, and when .NET calls back with the result of an asynchronous Web Service call, the callback is executing on a .NET thread pool thread. So, I must marshal the string from the .NET thread pool thread to my application's user interface thread before I can display it. If I don't, the application might not work. The only correct thing to do is marshal the data, even if it is just a simple string.

As I mentioned previously, .NET accomplishes marshaling by its eventing environment and the Control.Invoke method. The following code sets up the call to Invoke:

object[] args = new object[1];
args[0] = number;
this.Invoke(new LookupUIUpdateHandler(lookupUIUpdateHandler), args);

The LookupUIUpdateHandler follows the .NET guidelines for triggering Invoke events. It defines a method that accepts the type and number of parameters contained within args. For this example, that's merely a single string input:

delegate void LookupUIUpdateHandler(string number);

To the delegate's constructor, I passed a reference to the method that implements the delegate, lookupUIUpdateHandler:

private void lookupUIUpdateHandler(string number)
{
   // Update the window
   lblPhone.Text = number != null ? number : "(no number listed)";

   // Reset the cursor (previously set when async call
   // was made).
   this.Cursor = Cursors.Arrow;
}

And, it is here I finally update the user interface because .NET guarantees me that at this point I'll be on the proper thread for managing windows in my application.

Wrap Up

And there you have it: .NET provides a pool of threads that you can use for asynchronous client-side Web Service processing. The way you get to these threads is to use the special "begin" and "end" methods .NET generates when it reads the service description language. You'll find these methods in the resulting proxy file created when adding a Web reference to your project.

By using one of these internal .NET threads, you can free your primary process thread (the one that most likely created your user interface if you're calling the Web Service from a Windows Forms application). The secondary thread blocks while waiting for the Web Request to return, allowing the primary thread to continue performing its main processing tasks (such things as painting, animation, and button/text inputs). This is the essence of asynchronous processing, and it's quite effective. Give it a try!

About the Author

Kenn Scribner is with Wintellect.

출처 : develoter.com (http://www.developer.com/net/net/article.php/11087_3408531_2)

Working With Asynchronous .NET Web Service Clients
By Kenn Scribner

by Kenn Scribner of Wintellect

While many developers realize that consuming Web Services using the asynchronous call mechanisms built into .NET is useful, they also find it confusing. If you've had trouble trying to use the asynchronous call methods in your generated proxies—or if you're wondering what asynchronous means in the first place—this article helps clarify some things and makes your programming tasks (at least as related to asynchronous processing) a little easier.

The general discussion focuses on consuming .NET Web Services, but because asynchronous processing is built into .NET, the information is applicable to any asynchronous processing you might want to perform. That is, when you create a proxy for your Web Service, the asynchronous methods are baked in. But, you also have similar asynchronous methods built into your .NET delegate classes and therefore also can utilize delegates in an asynchronous fashion (hmm, perhaps fodder for another article: using .NET delegates as the poor man's multithreaded processing platform?).

Web Service Proxies

To be clear about Web Services and their consumption, Figure 1 presents the basic architecture.

Click here for a larger image.

Figure 1: Generalized Web Service Communication Architecture

The ultimate goal of a Web Service is to give the client the illusion that remote resources and processing capabilities are actually present on the client computer. For this to occur, some software on the client must generate and issue the request (as well as interpret the response), and some software on the server must accept requests, translate them into formats the server can work with, and activate the server-side processing itself. The first of these pieces of software is known as the proxy, because it simulates the server on the client. The proxy communicates with some form of stub, whose job is to take the SOAP-based XML and convert it into binary information resident within the server's memory. The stub also initiates the server-side processing.

When you use .NET to consume Web Services, it can create this proxy for you automatically, either with Visual Studio or the tool that ships with .NET itself, Wsdl.exe. Either tool queries the Web Service for its service description, as described by the Web Service Description Language (WSDL), and then generates the proxy source code for you by interpreting the WSDL it finds.

If you open the proxy source code you've been given, you should find all of the Web-based methods exposed by the Web Service. But, you'll also find some curiously named methods beginning with "Begin" and "End" and ending with the Web methods you'd expect. That is, if the Web Service exposed a single method named "CalcPayment," in your proxy you would find executable code for not only CalcPayment itself, but also for BeginCalcPayment and EndCalcPayment. You will use these "begin" and "end" methods for your asynchronous processing.

Asynchronous Processing

What exactly is asynchronous processing and why should you be concerned about using it? To answer that, let me first ask you a question: How do you feel when an application's user interface locks for some extended period of time while it processes your selected action? Most of us tend to dislike that kind of application behavior—and I'm being kind here.

Instead, we prefer our user interfaces responsive, even when working on actions we know to be lengthy. If that action involved a call to a Web Service, especially one over the Internet (versus simply a local one found on our intranet), the request might take quite a bit of time to process. Delays from 200 milliseconds up to full seconds are not uncommon. For example, say a given Web Service takes on average of 600 milliseconds to complete, but the user waits over half a second for each call. That might not seem like much, but to a user it could prove to be a major annoyance. Remember, the user interface locks entirely for this call duration.

The process thread used to make the call to the Web Service causes the locking phenomenon. The user interface usually locks up because the thread servicing the user interface (button clicks, painting behavior, and so forth) is also the very same thread making an extended call somewhere else, waiting for data. It might be a Web Service call, but it also might be some lengthy local financial calculation, database query, or whatever. Anything that takes a significant amount of time to process, if serviced by the same thread that manages the user interface, will cause the user interface to cease taking inputs from the user and appear to be locked. In general, try to avoid this. Such behavior has been known to cause users to throw keyboards, break monitors, and worst of all, no longer purchase your software.

Getting back to asynchronous processing, my dictionary defines asynchronous as "pertaining to a transmission technique that does not require a common clock between the communicating devices." Overlooking the clock reference, you could rewrite this definition in its loosest terms to read something like "asynchronous processing is a form of multithreaded programming where a primary thread activates a lengthy process to be managed by a secondary thread." The primary thread's task is complete when the process is activated, so it can (almost immediately) return to its main function, which in this case might be managing the user interface. The secondary thread then begins the lengthy process and sustains the wait, a procedure known as blocking. It locks and ceases processing, waiting for the lengthy process to terminate. It then (optionally) reports back to the primary thread the results of the process.

A side benefit of this is that you then can easily make multiple such processing calls in parallel. If the primary thread made multiple calls (synchronously, on the same thread), each synchronous call would need to be made sequentially, thus increasing the processing time greatly.

Asynchronous .NET Web Requests

In the case of a Web Service called using the proxy's asynchronous call methods, the secondary thread is actually a thread from the .NET thread pool. What's great about that is you don't need to create and manage your own thread (or pool of threads, which is even more complicated). Instead, when you call the "begin" method found in your proxy, you pass into that a callback function .NET will use to provide the Web Service response to your application. Always remember that when your callback function is executed, the .NET thread executes it, not the primary thread (which is most likely the thread that created your user interface). I'll revisit this a bit later in this discussion.

Although not the only way to process asynchronous Web Service calls, I finalize the call to the Web Service by extracting the resultant parameter values, as well as the method return value, in the callback function. This finalization is the call to the "end" method found in your Web Service proxy. The "end" method retrieves the resulting parameter objects (out and ref parameters), as well as the return value, and provides them to you for further processing. The beauty is that your primary thread doesn't have to block while waiting for the Web Service to complete. Instead, a .NET thread is used, and your user interface is free to continue to accept user inputs and be just as responsive and snappy as it was prior to the Web Service invocation. Later, when the call is complete, you can marshal the data back to your user interface thread and do whatever is necessary at that point.

You could, if you desire, perform some wait processing in your main thread (a technique for this is described in the MSDN article "Communicating with XML Web Services Asynchronously"). Personally, I find this to be of limited value because you're still employing the primary thread to perform the wait processing. But, I would be remiss if I didn't at least mention it.

Asynchronous Behavior Is a Client-Side Phenomenon

No matter how you call your Web Service, synchronously or asynchronously, each call is the same to the Web Service. You're still sending in one SOAP packet, and you'll still (hopefully) receive a single SOAP packet in response.

Marshaling—a Side Note for Windows User Interface Programmers

Marshaling—what an ugly sounding word. It harkens back to the old COM programming days when we had to deal with passing data between threads. Oh, but that's exactly what we're doing here! Uh-oh. Actually, it's not so bad. Marshaling basically is the process of converting information for communication between threads.

Because Windows is a virtual, memory-based operating system, memory addresses are meaningless between processes. If you pass information between processes based upon that information's memory address, it will have no meaning in the other process and this second process likely will crash. Old COM programmers (and I include myself here) know this all too well.

Fortunately, .NET handles marshaling for you without too much effort on your part. The age-old Windows rule that only—and I mean only—the thread that created a window can update that window's state also helps. Therefore, you can't just change window text, color, shape, size, or political affiliation willy-nilly without making sure you're doing so from the thread that created the window. Forget this fact and Windows becomes unpredictable. Sometimes things work, and sometimes they don't. If you follow the basic rule, though, and always let the window's creating thread update the window, your code (and application) won't crash and burn.

Delegates in .NET

If you look into your MSDN documentation under System.Windows.Forms.Control, you'll find a curious method called Invoke(). The first sentence of the associated documentation page reads: "Executes a delegate on the thread that owns the control's underlying window handle." Wow, that sounds a lot like "the thread that created the window." But what's this "executes a delegate" stuff?

We're back into the guts of .NET, but this time we're looking at the delegate and its relationship to events and event handling. If you create a delegate that has as its parameters the very same parameters that the Web Service returned, .NET will marshal those parameters for you and ship them to the particular window's creation thread. There you have it! The parameters are now available to the window's creating thread, so at that point you can update the window to your heart's content. Easy, right?

The truth is it isn't too bad, once you've seen it in action. In .NET terms, a delegate is essentially a type-safe callback function. So, what you need to do utilize it is:

1. Design a method in your application that accepts the same parameters the Web Service returned;
2. Designate it as a delegate data type; and
3. Create one of these delegates for use with Invoke().

I'll show some code for this shortly. But first, back to asynchronous Web Service calls in general.

출처 : developer.com(http://www.developer.com/net/net/article.php/11087_3408531_1)