Pengertian

Pengertian

Web Service Sepenuhnya berdasarkan standard web dan xml. Web Service dapat membantu:

• Perantara pada integrasi platform sepanjang eksekusi mesin virtual.
• Integrasi antara Web dan OO middleware.
• Integrasi dari aliran kerja terisolasi dan sevice-service (Web Services Flow Language - WSFL).
• Pertukaran data pada aplikasi yang berbeda-beda (X-Schema, XSLT ++)

• (Masa depan: standarisasi dari info konteks antara web servis dan klien – integrasi servis horizontal).

---

• Pemain utama dan standard-standard

Microsoft: .NET SUN: Open Net Environment (ONE) IBM: Web Service Conceptual Architecture (WSCA) W3C: Web Service Workshop Oracle: Web Service Broker Hewlett-Packard: Web Service Platform

• Kemampuan aplikasi, fungsi atau operasi yang di ekspos untuk program lain melalui standard yang terbuka, dan interoperable.

• “payloads” didefinisikan sebagai XML.

• “transports” melalui http atau Internet protocol terbuka lainnya.

• Data diakses dari berbagai bahasa pemrograman , platform hardware atau system operasi.

• Middleware dari Internet.

[sunting] Keuntungan penggunaan Web Service

• Format penggunaan terbuka untuk semua platform.
• Mudah di mengerti dan mudah men-debug.
• Dukungan interface yang stabil.
• Menggunakan standard-standard “membuka service sekali” dan mempunyai pemakai banyak.
• Mudah untuk menengahi pesan-pesan proses dan menambahkan nilai.
• Routing and pengiriman.
• Security.
• management and monitoring.
• schema and service design.
• Akselerasi.
• mudah untuk mengembangkan dengan semantic transport tambahan.
• Terbuka, standard-standard berbasis teks.
• Pencapaian modular.
• Tidak mahal untuk diimplementasikan (relatif).
• Mengurangi biaya integrasi aplikasi enterprise.
• Implementasi yang incremental.

---

[sunting] 1.4 Overview

• XML memungkinkan pengembang software untuk meng-expose sumber daya berharga pada bentuk yang memilki interoperabilitas tinggi, dimana sumber daya ini adalah semua tipe aplikasi atau pnyimpanan data yang digunakan oleh antar organisasi. Arsitektur XML Web services mendefinisikan mekanisme standard untuk menyediakan sumber daya melalui pengiriman pesan XML. Untuk mengakses sumber daya hanya dengan mentransmisikan pesan-pesan XML melalui protokol standard seperti TCP, HTTP, atau SMTP. Kata “Web Service” (singkatnya “service”) mengacu pada bagian kode yang mengimplementasikan interface XML menjadi sumber daya, dimana bias jadi sulit diakses (lihat gambar 1).

Gambar 1: Resources(Sumber daya) and services(Web Service)

• Arsitektur ini memungkinkan untuk konsumen dengan dukungan XML terintegrasi dengan aplikasi Web Service. Bagaimanapun, untuk memenuhi ini, konsumen harus menentukan antarmuka XML yang tepat sepanjang dengan pesan pesan yang beraneka ragam dan mempunyai detail-detail yang tepat. Skema XML dapat memnuhi kebutuhan ini karena mengizinkan pengembang untuk menjabarkan struktur dari pesan-pesan XML. Skema XML sendiri, bagaimanapun, tidak dapat menjabarkan detail-detail tambahan menyangkut komunikasi dengan Web Service.
• Definisi skema memberitahu pesan-pesan XML apa yang dapat digunakan tapi tidak bagaimana pesan-pesan tersebut berhubungan satu sama lain. Sebagai contoh, jika ada elemen XML dinamai Add dan nama lain AddResponse, ini sepertinya kedua nama tersebut berhubungan tapi tidak dapat mengindikasikan skemanya. Oleh sebab itu, sebagai tambahan untuk mengetahui pesan-pesan, konsumen harus juga mengetahui kemungkinan pertukaran pesan yang didukung oleh Web Service (contoh:., jika anda mengirim pesan Add, anda mendapatkan pesan kembali berupa AddResponse).

Pertukaran pesan dapat dimaksudkan sebagai pertukaran operasi. Operasi-operasi yang dilakukan konsumen kebanyakan pada point penting menginteraksikan service (Lihat gambar 2). Setiap kali menggunakan Web Service, akan dilakukan inspeksi daftar operasi yang didukung untuk mendapatkan semua proses yang tersedia.

Gambar 2: Pesan-pesan dan operasi-operasi

• Ini biasa untuk developer untuk mengelompokkan operasi-operasi terhubung menjadi antarmuka-antarmuka. Konsumen harus mengetahui pengelompokkan ini mempengaruhi cara mereka membuat kode. Ini sungguh penting untuk developer-developer yang bekerja dengan Web Service pada lingkup berorientasi objek karena antarmuka XML dapat memetakan menjadi antarmuka programmatis (atau kelas-kelas abstract) pada pilihan bahasa yang dipilih.
• Konsumen juga harus mengetahui protocol komunikasi apa yang digunakan untuk pengiriman pesan menuju service, sepanjang mekanisme spesifik yang terlibat saat menggunakan protokol yang ditentukan seperti pada penggunaan perintah, header-header, kode error. Pembungkusan (binding) menspesifikasikan detail-detail konkrit atas apa yang terjadi pada kabel (wire) dengan mensketsakan cara penggunaan antarmuka dengan protokol komunikasi khusus. Binding juga mempengaruhi cara peasn-pesan abstract di enkodisasi pada wire dengan menspesifikasikan style dari service (document vs. RPC) dan mekanisme enkodisasi (literal vs. terenkodisasi).
• Service dapat mendukung binding-binding ganda pada antarmuka yang ditentukan, tapi setiap binding harus dapta diakses pada alamat unik yang diidentifikasikan oleh URI, juga ditujukan sebagai titik akhir dari Web Service (lihat gambar 3).

Gambar 3: Antarmuka dan binding-binding

• Konsumen harus mencari tahu semua detail-detail yang dijabarkan sebelum mereka dapat berinteraksi menggunakan Web Service.

[sunting] Sejarah

• Sebelum kita memasukki sejarah tentang Web Service, adabaiknya kita terlebih dahulu mebahas masalah paradigma pekembangan bahasa pemrograman terlebih dahulu.

---

[sunting] 1.2 Sejarah bahasa pemrograman adalah:

• Pemrograman terstruktur.
• Pemrograman berorientasi- objek.
• Komputasi terdistribusi.
• Pertukaran data elektronik.
• World Wide Web.
• Web services.

---

[sunting] 1.3 Ada pun perusahaan yang mengusulkan konsep web service adalah:

• Hewlett-Packard's e-Speak pada 1999 adalah penyedia e-service.
• Microsoft memperkenalkan nama "web services" pada Juni 2000.
• Microsoft “mempertaruhkan nama perusahaan" pada strategi web service ini.
• sekarang setiap vendor mulai menjadi “pemain”.

• Untuk lebih lanjut mengenai perkembangan sejarah Web service yang mana cikal bakal terbentuknya dari arsitektur DCE, dapat dilihat pada gambar 4: Sejarah terbentuknya Web Service.
• Dari gambar tersebut dapat dilihat bahwa XML Web Service mempunyai interoperabilitas yang sangat tinggi karena pengembang Web service terdiri dari banyak vendor.

[sunting] Mekanisme Kerja

Sebelum memasuki mekanisme kerja yang terjadi pada Web Service, akan dibahas terlebih dahulu komponen-kompenen yang mempunyai peranan penting pada Web Service, komponen-komponen tersebut dapat dilihat pada standard-standard web service itu sendiri, dimana standard-standard web service adalah sebagai berikut: WSDL Web Services Description Language http://www.w3.org/TR/wsdl Deskripsi-deskripsi dari web service UDDI Universal Discovery, Description & Integration http://www.uddi.org/specification.html Registry mengenai deskripsi servis SOAP Simple Object Access Protocol http://www.w3.org/TR/SOAP/ Protokol transport untuk berkomunikasi antar web service Standard-standard lain: WSRP, WSIA, WSXL…….

Selain standard-standard Web Service, juga ada Bagian-bagian Web Service (Web Service Dumpstack) yang mendeskripsikan task-task yang akan terjadi pada proses berjalannya web service, dimana task-task tersebut antara lain: Wire Protocols, Description, Discovery. Untuk lebih lanjut mengenai bagian-bagian Web Service maka dapat dilihat ilustrasinya pada gambar 5: Bagian-bagian Web Service .

gambar 5: Bagian-bagian Web Service 

keterangan :

Wire Protocols Aturan utama: menyediakan standard, channel komunikasi flexible Aturan tambahan: menyediakan standard, representasi wire-level data yang flexible Keuntungan: interoperabilitas pada level terendah

Deskripsi Aturan utama: menyediakan standard, jalan untuk menjabarkan apa dan bagaimana web service melakukan yang harus dilakukan dengan fleksibel. Keuntungan: interoperabilitas.

Discovery Aturan utama: menyediakan standard, jalur untuk menemukan dimana web service di tempatkan dan bagaimana mencari informasi tambahan tentang apa yang dilakukan web service dengan fleksibel Keuntungan: interoperabilitas, integrasi yang dinamis

[sunting] 2.3 UDDI (skema xml)

Kemampuan atribut metadata untuk service-service didaftarkan pada UDDI, dan lalu menjalankan quei-queri berdasarkan pada metadata tersebut yang menengahi secara mutlak menuju tujuan dari UDDI pada kedua waktu desain dan waktu pengekskusian.

UDDI (Universal Description, Discovery, and Integration) mempunyai tugas sebagai berikut: Deskripsi yang Programmatic dari bisnis dan sevice yang didukung Deskripsi yang Programmatic dari spesifikasi web service Model pemrograman dan schema.

[sunting] Tahap Pengembangan dan Implikasi Bisnis

[sunting] 1.TahapPengembangan.

• Sebelum melakukan pengembangan, harus diketahui dulu ruang lingkup pengembangan aplikasi berbasiskan Web Service menurut media protokolnya, adapun ruang lingkup aplikasi Web Service tersebut adalah”

Dalam korporasi firewall Untuk aplikasi enterprise terintegrasi ringan

• Antar korporasi firewall

Untuk digunakan pada layanan eksternal (contoh: passport) Untuuk menyediakan data untuk partner-partner

• Melalui Web

Aplikasi komposit Komponen-komponen AliranKerja

---

Sedangkan tahap-tahap pengembangan Web Service itu sendiri adalah:

• Discover – browse registry UDDI untuk mencari Web Service yang sudah ada untuk integrasi.
• Create or Transform –buat Web Service dari project-project yang ada.
• Build – satukan artifak yang ada sebagai SOAP dan service HTTP dan jabarkan pada WSDL.
• Deploy – Aplikasikan menjadi server aplikasi Websphere atau Tomcat.
• Test – Uji coba web service baik local (stand alone computer) atau secara remote.
• Develop – Bangun contoh aplikasi untuk memberi masukkan dalam membuat aplikasi klien Web service
• Publish – publikasikan / upload Web Service pada bisnis registri UDDI.

[sunting] Implementasi

Umumnya layanan ini digunakan oleh organisasi yang besar dan kompleks untuk metode pertukaran datanya. Atau bisa juga oleh programmer yang "malas" dalam artian lebih senang menulis sedikit code daripada banyak baris untuk hasil yang sama, lebih senang bekerjasama dari pada membangun aplikasi sendirian^[rujukan?].

Layanan Web paling sesuai untuk

• Government to Government (G2G)
• Business to Business B2B (B2B)

---

[sunting] Kesimpulan

Dari Makalah ini dapat diambil kesimpulan sebagai berikut:

• Web service adalah teknologi dengan resiko rendah (relatif) yang dapat digunakan untuk mengimplementasikan strategi bisnis beresiko tinggi.
• Web service berdasarkan middleware OO, XML dan konsep Internet Protokol, dan membantu pergerakkan dari sistem-sistem heterogen menuju sistem yang lebih homogen
• Banyak-vendor turut membuat standard
• Membuka semua jenis kesempatan untuk semua orang
• Incremental, non-intimidating, minimal technology play
• Kostumer memulai tanpa menunggu vendor-vendor
• Web service mentransformasikan web browser centris menjadi servis centris
• Tool-tool yang lebih baik bersifat open source

Overview

Membuat web service sekarang sudah menjadi kebutuhan yang harus dilakukan oleh seorang developer untuk bisa menghubungkan sistemnya agar bisa terkoneksi dari jarak jauh dengan menggunakan jaringan internet. Mungkin beberapa programmer masih memiliki konsep berpikir bahwasanya program aplikasi desktop yang kita buat dari bahasa pemrograman delphi tidak bisa berkomunikasi dengan server melalui internet. Sekarang pandangan tersebut harus dirubah karena program desktop pun bisa berkomunikasi dengan server melalui internet. Untuk bisa berkomunikasi ini perlu digunakan web service. Dan dalam tutorial ini akan diajarkan kepada anda tentang pembuatan web service sederhana pada sisi server dengan menggunakan Turbo Delphi .NET

Apa yang diperlukan ?

Pada tutorial ini digunakan sistem operasi Microsoft Windows XP Profesional dan menggunakan Turbo Dephi .NET. Tentu saja komponen lain yang diperlukan adalah IIS harus sudah terinstall dalam sistem operasi.

Info Tambahan

Kali ini saya tidak bisa berbicara panjang lebar mengenai pengertian dari Web Service itu sendiri, namun akan saya ulas secara lengkap nanti dibagian khusus teori dan istilah. Dengan demikian, tutorial kali ini difokuskan pada bagian pembuatan secara Web Service secara teknis menggunakan Turbo Delphi .NET.

Pesan

Selamat mencoba artikel ini dan semoga berhasil. Amin…

Overview

In the wake of increasing terrorism and organized crime, investigators focus on how such groups finance their activities and are aiming to cut off access to these funds. Banks and financial institutions are now being asked or forced to significantly increase their efforts to combat Money Laundering, which requires increased training of their staff to better understand, identify, and alert authorities when they see evidence of Money Laundering. Moreover, regulations are slowly coming into effect in most countries, sometimes with extra territorial jurisdictions which increases the risks of liabilities on organizations both from a financial and a reputation stand point. With the typically large number of staff working for banks. E-Learning provides the banking industry with a tool to help them not only train their large numbers of employees better, quicker, and more efficiently, but also allows them to do this more cost effectively. Knowledge Platform offers a suite of online courses that enable institutions to impart a consistent and effective level of AML training. The courses are highly interactive and appealing and have been validated through adoption by a substantial number of leading multinational banks and financial institutions as well as by AUSTRAC, the Australian AML Financial Intelligence Unit. In addition to offering generic courses, Knowledge Platform works with institutions in creating and managing customized AML awareness and training programs.

Web service with ASP.Net

Web Services are the underpinning of Microsoft's .NET strategy. The concepts and the innovations behind this initiative have struck a chord with developer's building the next generation of Internet applications.

In this month's column, we're going to take a look at the features within ASP.NET to enable Web Services. Before we dig into the technical details let's start with an overview of Web Services.

Web Services Overview

A Web Service is programmable application logic accessible via standard Web protocols. One of these Web protocols is the Simple Object Access Protocol (SOAP). SOAP is a W3C submitted note (as of May 2000) that uses standards based technologies (XML for data description and HTTP for transport) to encode and transmit application data.

Consumers of a Web Service do not need to know anything about the platform, object model, or programming language used to implement the service; they only need to understand how to send and receive SOAP messages (HTTP and XML).

Soap Message

A SOAP message consists of several elements, most notably an envelope. The envelope encapsulates the data transmitted within the SOAP message. Below is a simple SOAP message complete with HTTP headers:

POST /demo/MSDN/PerfCounter.asmx HTTP/1.1
Connection: Keep-Alive
Content-Length: 150
Content-Type: text/xml
Host: localhost
User-Agent: MS Web Services Client Protocol 1.0.2204.19
SOAPAction: "http://tempuri.org/PerfCounters"




 

In the example above, we see the HTTP headers for the request, including the HTTP SOAPAction header, which is optionally used by the server for routing the SOAP message. Following the HTTP headers we find the body of the HTTP message. The body of the HTTP message is the SOAP request for a PerfCounters Web Service, which we are going to build.

Unfortunately we don't have nearly enough room in this column to discuss SOAP in depth. To learn more about SOAP, please see the SOAP Developer Resources page. Here you can find the public specification for SOAP 1.1 as well as articles and other relevant resources.

ASP.NET Web Services

Web Services are simple and easy to understand. It is possible, in fact, to author a simple application that surfaces data as XML conforming to the SOAP specification. It would also be relatively straightforward to build an application capable of receiving SOAP messages over HTTP and deriving meaningful value out of it. For those of you familiar with PERL, this could simply be a matter of using RegEx to parse the value out of the XML result; it's just another string.

However, just as we use frameworks such as ASP and ASP.NET to build Web applications, we would much rather use a framework for building Web Services. The reasoning is quite logical. We don't need to reinvent the plumbing—that is, at a high level, the capability to serialize our data as XML, transport the data using HTTP, and de-serialize the XML back to meaningful data. Instead, we want a framework that makes building Web Services easy, allowing us to focus on the application logic not the plumbing. ASP.NET provides this framework for us.

From a developer's point of view, if you have ever written application logic, you have the required skills to author ASP.NET Web Services. More importantly, if you're at all familiar with ASP or ASP.NET application services, (application state memory, and so on) you can also leverage these skills when you build ASP.NET Web Services.

Exposing

For the purpose of example, we're going to write a Web Service that exposes Web application performance counters. Performance counters provide us with details about the behavior of our application, such as the number of active sessions or the number of requests served. We don't always have local server access to our Web server, and if we have a farm of servers we might want to expose the performance counters from all these servers and aggregate them in a central location.

Starting with a Simple Example

Rather than jumping straight into the Performance Counters example, let's start with some very simple application logic so we can see what we need to do to expose our logic as a Web Service. We'll use an Add() method that accepts two Integers and returns their sum. Below is this simple Visual Basic logic:

Public Class MyMath
Public Function Add(a As Integer, b As Integer) As Integer
 Return a + b
End Function
End Class

We could use this class and its method as follows:

Dim mymath As new MyMath
Dim result As Integer
result = mymath.Add(10, 20)

To expose the above class, MyMath, as an ASP.NET Web Service we need to move the application logic into a *.asmx file. Just as we use the extension *.aspx for ASP.NET Pages, we use *.asmx to tell ASP.NET that the file is an ASP.NET Web Service.

After we created the *.asmx source file and add our application logic, we need to make a few more small changes:

<%@ WebService Language="VB" Class="MyMath" %>
Public Class MyMath
Public Function Add(a As Integer, b As Integer) As Integer
 Return a + b
End Function
End Class

Changes to our source

The changes we've made to the *.asmx file include adding a WebService directive that names both the Language as well as the Class we're exposing as a Web Service. The WebService directive is required, as we must tell ASP.NET the class that contains the application logic. Next, we've added a attribute to our Add() function declaration. An attribute is a declarative code element that lets us change the behavior of our application logic without necessarily writing more code. In the case of the attribute, this tells ASP.NET that the method with this attribute is to be treated as 'Web callable'. Web callable in the sense that ASP.NET does the necessary work for this method to support SOAP.

Now that we've seen what needs to be done to enable application logic as Web callable, let's look at a more relevant sample.

Performance Counter Web Service

Below is application logic that gives us access to the Windows® performance counters, with the changes for ASP.NET Web Services. The file we've created is PerfCounter.asmx:

<%@ WebService language="VB" class="PerfCounters" %>
Imports System.Xml.Serialization
Imports System.Web.Services
Imports System.Diagnostics

Public Class PerfCounters
Inherits WebService

' Returns a Counter class
Public Function GetCounters() As Counters
  Dim c As new Counters

  ' Application Name
  c.ApplicationName              = IISAppName

  ' System specific
  c.WorkerProcessRestarts = Poll(0, "Worker Process Restarts")
  c.WorkerProcessRunning  = Poll(0, "Worker Process Running")
  c.ApplicationsRunning   = Poll(0, "Applications Running")
  c.RequestsQueued        = Poll(0, "Requests Queued")

  ' Application Specific
  c.RequestsTotal         = Poll(1, "Requests Total")  
  c.RequestsFailed        = Poll(1, "Requests Failed")
  c.RequestsSucceeded     = Poll(1, "Requests Succeeded")
  c.ActiveSessions        = Poll(1, "Sessions Active")

  Return c
End Function

Private Function Poll(counterType As Integer, counter As String) As Integer
   Dim PerfCounter As PerformanceCounter

   If (counterType = 0)
     PerfCounter = new PerformanceCounter("ASP Plus System", counter, "")
   Else
     PerfCounter = new PerformanceCounter("ASP Plus Applications", counter, IISAppName)
   End If

   Return PerfCounter.NextValue().ToInt32()
End Function

Private Function IISAppName() As String
  Dim AppName As String

  AppName = Context.Request.ServerVariables("APPL_MD_PATH")
  AppName = AppName.Replace("/"C, "_"C)

  Return AppName
End Function
End Class

Public Class Counters
Public ApplicationName As String
Public WorkerProcessRestarts As Integer
Public WorkerProcessRunning As Integer
Public ApplicationsRunning As Integer
Public RequestsQueued As Integer
Public RequestsTotal As Integer
Public RequestsFailed As Integer
Public RequestsSucceeded As Integer
Public ActiveSessions As Integer
End Class

Again we see that we've declared a WebService directive at the top of the file noting both the language and the class. The class that contains the Web callable method is PerfCounters. Within PerfCounters we find a single method, GetCounters(), with the attribute. GetCounters() returns an instance of another class, Counters.

When we call GetCounters(), the method creates a new instance of the Counter class and begins to set its public members; note, these public members should be implemented as properties, but I chose to save the space for the purpose of the article.

When the Counter class' members are set, we're setting them with the returned result of a call to a private method Poll(). Poll() is responsible for doing the actual work of polling the systems performance counters and returning a result.

Finally, the last method, IISAppName(), returns the value of the server variable APPL_MD_PATH and replaces '/' characters with '_' characters; this value is used as the application name within the performance counters.

Now that we've built the service, let's take a look at how we test it.

Testing Web Services

Now that we've authored this ASP.NET Web Service, how do we test it? The consumer of a Web Service is another application, but ASP.NET provides a simple browser interface to our Web Service that we can use for testing or documentation purposes.

Since our service is exposed as a resource available from our Web server, we can simply open a browser and make a request for that resource. Doing so provides us with a nice HTML-based Web Service Help page that lets people learn about what our service provides:

Figure 1. HTML-based Web Service Help page

ASP.NET generates the above page for us, and we can use it to test our service (note the HTML Invoke button within the GetCounters Web Method section) and access the XML contract language used to describe what our service offers; we'll be coming back to the XML contract language momentarily.

If we press the Invoke button, a new browser window is opened, and a request is made to our service using HTTP-Get; one of the three supported protocols used by ASP.NET Web Services:

Figure 2. Example of the new browser window that is created when pressing the Invoke button.

The XML returned is a valid XML document that describes all of the settings we identified in our Counters class. However, it is not SOAP. SOAP is the default protocol that is used when we do application-to-application communication.

Although we didn't discuss it in this article, we can customize our help page quite extensively. This is done by making some changes to the ASP.NET configuration system, or modifying the DefaultSDLHelpGenerator.aspx. I would recommend not modifying the DefaultSDLHelpGenerator.aspx, as this is the template used for all our Web Services. Instead, make a copy of it and reference the copied version in the application's configuration that makes use of it.

Now that we've discussed authoring and testing our Web Service, let's make use of it.

Consuming

We have several options for consuming Web Services. Since this article is about ASP.NET, we'll focus on .NET technologies that can consume Web Services. However, I should point out that any platform or framework that understands SOAP should be able to communicate with our Web Service. Building the Web Service with ASP.NET does not mean that the service is only available to other Microsoft applications.

Consumers of a Web Service need to know what the service offers—for example, what its Web callable method look like. Therefore, all Web Services optionally share another common XML document: a contract (note, Web Services built with ASP.NET always have a contract provided automatically).

Contract

In the examples above when we discussed testing a Web Service, we didn't discuss the link found within Web Service Help Page: SDL Contract. If we were to follow that link, instead of pressing the Invoke button for the GetCounters() Web Method, we would be presented with the following XML document:

Figure 3. XML document presented when following the link found within the Web Service Help Page

This XML document is a contract that describes our Web Service. It details the protocols supported as well as the semantics for calling and returning values. It additionally defines an XML schema for our Counters class.

Tools can use this XML schema to build proxy classes for our Web Service. A proxy class is a class that looks and feels like a local object, but it is in fact doing the work to serialize, send, receive, and de-serialize our method request to a SOAP endpoint.

Note Beta 1 of .NET surfaces an "SDL—Service Description Language" contract, Beta 2 will switch to use the more recent "WSDL—Web Service Description Language" contract. Semantically they are very different. WSDL is the collaborative work of Microsoft, IBM, and several other companies to better standardize the XML contract language.

We have various options for consuming Web Services, however, I'd like to call out three in particular:

• Visual Studio .NET: —Visual Studio .NET does the work of creating the proxy from the SDL or WSDL and adds the appropriate code to our project. This is done by simply selecting Project | Web References, and then pointing at a valid contract. Note that for beta 1 the contract must be SDL.
• Command Line Tools: —The .NET SDK ships with a tool called WebServiceUtil.exe that accepts an SDL contract and can generate the proxy source code for Visual Basic .NET, C#, or JScript.NET.
• IE 5.5. Behavior: —A browser specific behavior that allows for rich client interaction with SOAP end-points. For those of you familiar with Remote Scripting, you're going to love this! To learn more about the IE 5.5 behavior, please see WebService Behavior.

Unfortunately, we don't have the space to discuss these three options in detail. However, I thought it would be worthwhile to briefly cover building a proxy with the command line tool, as this is applicable to those who have installed .NET; not just those that have Visual Studio .NET.

Command line tool

.NET, whether you install it as part of Visual Studio .NET or the .NET SDK, includes a command line proxy generation tool called WebServiceUtil.exe. The path to this command line tool, as well as several other command line tools, is added to our path when we installed .NET.

WebServiceUtil.exe allows us to name a SDL, or contract, as one of the command line arguments and the tool can then generate the source code for a proxy to our Web Service.

If, for example, we were to save the SDL from our PerfCounters.asmx example, we could use WebServiceUtil.exe to generate a Visual Basic .NET proxy to this Web Service:

WebServiceUtil.exe /command:proxy PerfCounter.sdl /language:VB

This generates a source file PerfCounters.vb that we now need to compile.

Using the VB.NET command line compiler, vbc.exe, we can compile our VB source file:

vbc /t:library /r:system.web.dll /r:system.web.services.dll /r:system.xml.serialization.dll perfcounters.vb

What we've done with the command line compiler is specify that we want to create a library (dll) rather than an executable (exe), and in addition to naming the source file to compile, we've specified some .NET assemblies (libraries containing classes our source file requires) as arguments to the compiler.

The result is PerfCounters.dll, a complete proxy to our PerfCounters.asmx ASP.NET Web Service that we can now use in .NET applications to communicate via SOAP to our Web Service.

Let's use this proxy to build a simple ASP.NET page that consumes and uses our Web Service.

Using the Web Service

First we need to deploy the compiled proxy, known as an assembly, to a Web application's \bin directory. Although we haven't discussed deploying compiled code in this column yet (yet another topic for a future column), suffice to say that to 'register' an assembly on the system simply requires copying the *.dll to a Web application's \bin directory. This is a feature of .NET, but the use of the \bin directory is specific for ASP.NET.

To make things simple, we'll create a bin directory off of the server's root directory, c:\inetpub\wwwroot\bin for example. A \bin directory must exist in an application root, either the root of the Web or a folder marked as an application in IIS.

Next, we copy our assembly, PerfCounters.dll, to our \bin directory. We can now author our ASP.NET page, which we'll deploy to c:\inetpub\wwwroot. We'll call it PerfCountersConsume.aspx:

Web Application: 

Process Restarts: 

Processes Running: 

Applications Running: 

Requests Queued: 

Requests Total: 

Requests Failed: 

Requests Succeeded: 

Active Sessions: 

The code above creates an instance of our proxy class PerfCounters (available to us since it's a registered assembly in our \bin directory) calls its GetCounters() method and returns an instance of a Counters class. We then use the instance of the Counters class, counters, to request its member variables and populate ASP.NET server controls. The result is below:

Figure 4. ASP.NET server controls

Summary

This column has taken a very high level overview of ASP.NET Web Services. There's quite a bit of detail that we either glossed over or didn't cover at all, for example security, use of session state, extensions, and so on. In next month's column we're going to look at a more advanced feature of ASP.NET Web Services, extensions, that we can use for building attributes that allow us to trace the request/response of our ASP.NET Web Service.