Web Hizmetleri - Hızlı Kılavuz

Farklı kitaplar ve farklı kuruluşlar, Web Hizmetlerine farklı tanımlar sağlar. Bazıları burada listelenmiştir.

• Web hizmeti, kendisini internet üzerinden erişilebilir kılan ve standartlaştırılmış bir XML mesajlaşma sistemi kullanan herhangi bir yazılım parçasıdır. XML, bir web hizmetiyle tüm iletişimleri kodlamak için kullanılır. Örneğin, bir istemci bir XML mesajı göndererek bir web hizmetini çağırır, ardından karşılık gelen bir XML yanıtını bekler. Tüm iletişim XML biçiminde olduğundan, web hizmetleri herhangi bir işletim sistemine veya programlama diline bağlı değildir — Java Perl ile konuşabilir; Windows uygulamaları Unix uygulamalarıyla konuşabilir.

• Web hizmetleri, ürünler, süreçler ve tedarik zincirleri oluşturmak için ağ üzerinden tanımlanabilen, yayınlanabilen, konumlandırılabilen veya başlatılabilen bağımsız, modüler, dağıtılmış, dinamik uygulamalardır. Bu uygulamalar yerel, dağıtılmış veya web tabanlı olabilir. Web hizmetleri, TCP / IP, HTTP, Java, HTML ve XML gibi açık standartların üzerine inşa edilmiştir.

• Web hizmetleri, İnternet'i doğrudan uygulamadan uygulamaya etkileşim için kullanan XML tabanlı bilgi değişim sistemleridir. Bu sistemler programları, nesneleri, mesajları veya belgeleri içerebilir.

• Web hizmeti, uygulamalar veya sistemler arasında veri alışverişi için kullanılan açık protokoller ve standartların bir koleksiyonudur. Çeşitli programlama dillerinde yazılan ve çeşitli platformlarda çalışan yazılım uygulamaları, tek bir bilgisayarda süreçler arası iletişime benzer bir şekilde İnternet gibi bilgisayar ağları üzerinden veri alışverişi yapmak için web hizmetlerini kullanabilir. Bu birlikte çalışabilirlik (örneğin, Java ve Python veya Windows ve Linux uygulamaları arasında) açık standartların kullanımından kaynaklanmaktadır.

Özetlemek gerekirse, eksiksiz bir web hizmeti bu nedenle -

• İnternet veya özel (intranet) ağlar üzerinden kullanılabilir

• Standartlaştırılmış bir XML mesajlaşma sistemi kullanır

• Herhangi bir işletim sistemine veya programlama diline bağlı değildir

• Genel bir XML dilbilgisi aracılığıyla kendi kendini tanımlıyor

• Basit bir bulma mekanizmasıyla keşfedilebilir

Web Hizmetlerinin Bileşenleri

Temel web hizmetleri platformu XML + HTTP'dir. Tüm standart web hizmetleri aşağıdaki bileşenleri kullanarak çalışır -

• SOAP (Basit Nesne Erişim Protokolü)

• UDDI (Evrensel Açıklama, Keşif ve Entegrasyon)

• WSDL (Web Hizmetleri Açıklama Dili)

Tüm bu bileşenler Web Hizmetleri Mimarisi bölümünde tartışılmıştır .

Bir Web Hizmeti Nasıl Çalışır?

Bir web hizmeti, HTML, XML, WSDL ve SOAP gibi açık standartları kullanarak çeşitli uygulamalar arasında iletişimi sağlar. Bir web hizmeti şunlardan yardım alır -

• Verileri etiketlemek için XML

• SABUN mesaj aktarmak için

• WSDL, hizmetin kullanılabilirliğini açıklar.

Solaris üzerinde, Windows üzerinde çalışan Visual Basic programınızdan erişilebilen Java tabanlı bir web hizmeti oluşturabilirsiniz.

JavaServer Pages (JSP) tabanlı ve Linux üzerinde çalışan web uygulamanızdan başlatılabilen Windows üzerinde yeni web hizmetleri oluşturmak için C # da kullanabilirsiniz.

Misal

Basit bir hesap yönetimi ve sipariş işleme sistemini düşünün. Muhasebe personeli, yeni hesaplar oluşturmak ve yeni müşteri siparişleri girmek için Visual Basic veya JSP ile oluşturulmuş bir istemci uygulamasını kullanır.

Bu sistem için işlem mantığı Java'da yazılmıştır ve aynı zamanda bilgileri depolamak için bir veritabanı ile etkileşime giren bir Solaris makinesinde bulunur.

Bu işlemi gerçekleştirme adımları aşağıdaki gibidir -

• İstemci programı, hesap kayıt bilgilerini bir SOAP mesajı halinde paketler.

• Bu SOAP mesajı, HTTP POST isteğinin gövdesi olarak web hizmetine gönderilir.

• Web hizmeti, SOAP isteğini paketinden çıkarır ve bunu uygulamanın anlayabileceği bir komuta dönüştürür.

• Uygulama, bilgileri gerektiği gibi işler ve bu müşteri için yeni bir benzersiz hesap numarasıyla yanıt verir.

• Daha sonra, web hizmeti yanıtı, HTTP isteğine yanıt olarak istemci programına geri gönderdiği başka bir SOAP mesajına paketler.

• İstemci programı, hesap kayıt işleminin sonuçlarını elde etmek için SOAP mesajını açar.

Web Hizmetlerini kullanmanın avantajları şunlardır -

Ağda Mevcut İşlevi açığa çıkarma

Web hizmeti, HTTP kullanılarak uzaktan çağrılabilen bir yönetilen kod birimidir. Yani, HTTP istekleri kullanılarak etkinleştirilebilir. Web hizmetleri, mevcut kodunuzun işlevselliğini ağ üzerinden göstermenize olanak sağlar. Ağda gösterildiğinde, diğer uygulamalar programınızın işlevselliğini kullanabilir.

Birlikte çalışabilirlik

Web servisleri, çeşitli uygulamaların birbiriyle konuşmasına ve kendi aralarında veri ve hizmetleri paylaşmasına izin verir. Diğer uygulamalar da web hizmetlerini kullanabilir. Örneğin, bir VB veya .NET uygulaması Java web hizmetleriyle veya tam tersi şekilde konuşabilir. Web hizmetleri, uygulama platformunu ve teknolojiyi bağımsız kılmak için kullanılır.

Standartlaştırılmış Protokol

Web hizmetleri, iletişim için standartlaştırılmış endüstri standardı protokolü kullanır. Dört katmanın tümü (Hizmet Aktarımı, XML Mesajlaşma, Hizmet Açıklaması ve Hizmet Keşfi katmanları) web hizmetleri protokol yığınında iyi tanımlanmış protokolleri kullanır. Protokol yığınının bu standardizasyonu, işletmeye çok çeşitli seçenekler, rekabet nedeniyle maliyette azalma ve kalitenin artması gibi birçok avantaj sağlar.

Düşük Maliyetli İletişim

Web hizmetleri, HTTP protokolü üzerinden SOAP kullanır, böylece web hizmetlerini uygulamak için mevcut düşük maliyetli internetinizi kullanabilirsiniz. Bu çözüm, EDI / B2B gibi tescilli çözümlere kıyasla çok daha az maliyetlidir. HTTP üzerinden SOAP'ın yanı sıra, web hizmetleri, FTP gibi diğer güvenilir taşıma mekanizmalarında da uygulanabilir.

Web hizmetleri aşağıdaki özel davranış özelliklerine sahiptir -

XML Tabanlı

Web hizmetleri, veri sunumunda ve veri taşıma katmanlarında XML kullanır. XML kullanmak, herhangi bir ağ, işletim sistemi veya platform bağlamayı ortadan kaldırır. Web hizmetleri tabanlı uygulamalar, çekirdek düzeylerinde büyük ölçüde birlikte çalışabilir.

Gevşek bağlanmış

Bir web hizmetinin tüketicisi, o web hizmetine doğrudan bağlı değildir. Web hizmeti arayüzü, müşterinin hizmetle etkileşime girme yeteneğinden ödün vermeden zaman içinde değişebilir. Sıkı bir şekilde bağlanmış bir sistem, istemci ve sunucu mantığının birbirine sıkı sıkıya bağlı olduğunu ima eder, bu da bir arayüz değişirse diğerinin güncellenmesi gerektiğini ima eder. Gevşek bağlı bir mimarinin benimsenmesi, yazılım sistemlerini daha yönetilebilir hale getirme eğilimindedir ve farklı sistemler arasında daha basit entegrasyona izin verir.

İri Taneli

Java gibi nesneye yönelik teknolojiler, hizmetlerini ayrı yöntemlerle ortaya çıkarır. Bireysel bir yöntem, kurumsal düzeyde herhangi bir yararlı yetenek sağlamak için çok ince bir işlemdir. Bir Java programını sıfırdan oluşturmak, daha sonra bir istemci veya başka bir hizmet tarafından tüketilen kaba bir hizmete dönüştürülen birkaç ince taneli yöntemin oluşturulmasını gerektirir.

İşletmeler ve ortaya çıkardıkları arayüzler kaba taneli olmalıdır. Web hizmetleri teknolojisi, doğru miktarda iş mantığına erişen kaba taneli hizmetleri tanımlamanın doğal bir yolunu sağlar.

Eşzamanlı veya Eşzamansız Olma Yeteneği

Eşzamanlılık, müşterinin hizmetin yürütülmesine bağlanması anlamına gelir. Eşzamanlı çağrılarda, istemci, devam etmeden önce hizmetin işlemini tamamlamasını bloke eder ve bekler. Zaman uyumsuz işlemler, bir istemcinin bir hizmeti çağırmasına ve ardından diğer işlevleri yürütmesine izin verir.

Zaman uyumsuz istemciler, sonuçlarını daha sonraki bir zamanda alırken, zaman uyumlu istemciler de hizmet tamamlandığında sonuçlarını alır. Eşzamansız yetenek, gevşek bağlı sistemlerin etkinleştirilmesinde önemli bir faktördür.

Uzaktan Prosedür Çağrılarını (RPC'ler) destekler

Web hizmetleri, istemcilerin XML tabanlı bir protokol kullanarak uzak nesneler üzerindeki prosedürleri, işlevleri ve yöntemleri çağırmasına olanak tanır. Uzaktan prosedürler, bir web hizmetinin desteklemesi gereken girdi ve çıktı parametrelerini ortaya çıkarır.

Component development through Enterprise JavaBeans (EJBs) and .NET Components has increasingly become a part of architectures and enterprise deployments over the past couple of years. Both technologies are distributed and accessible through a variety of RPC mechanisms.

A web service supports RPC by providing services of its own, equivalent to those of a traditional component, or by translating incoming invocations into an invocation of an EJB or a .NET component.

Supports Document Exchange

One of the key advantages of XML is its generic way of representing not only data, but also complex documents. These documents can be as simple as representing a current address, or they can be as complex as representing an entire book or Request for Quotation (RFQ). Web services support the transparent exchange of documents to facilitate business integration.

There are two ways to view the web service architecture −

• The first is to examine the individual roles of each web service actor.
• The second is to examine the emerging web service protocol stack.

Web Service Roles

There are three major roles within the web service architecture −

Service Provider

This is the provider of the web service. The service provider implements the service and makes it available on the Internet.

Service Requestor

This is any consumer of the web service. The requestor utilizes an existing web service by opening a network connection and sending an XML request.

Service Registry

This is a logically centralized directory of services. The registry provides a central place where developers can publish new services or find existing ones. It therefore serves as a centralized clearing house for companies and their services.

Web Service Protocol Stack

A second option for viewing the web service architecture is to examine the emerging web service protocol stack. The stack is still evolving, but currently has four main layers.

Service Transport

This layer is responsible for transporting messages between applications. Currently, this layer includes Hyper Text Transport Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP), and newer protocols such as Blocks Extensible Exchange Protocol (BEEP).

XML Messaging

This layer is responsible for encoding messages in a common XML format so that messages can be understood at either end. Currently, this layer includes XML-RPC and SOAP.

Service Description

This layer is responsible for describing the public interface to a specific web service. Currently, service description is handled via the Web Service Description Language (WSDL).

Service Discovery

This layer is responsible for centralizing services into a common registry and providing easy publish/find functionality. Currently, service discovery is handled via Universal Description, Discovery, and Integration (UDDI).

As web services evolve, additional layers may be added and additional technologies may be added to each layer.

The next chapter explains the components of web services.

Few Words about Service Transport

The bottom of the web service protocol stack is service transport. This layer is responsible for actually transporting XML messages between two computers.

Hyper Text Transfer Protocol (HTTP)

Currently, HTTP is the most popular option for service transport. HTTP is simple, stable, and widely deployed. Furthermore, most firewalls allow HTTP traffic. This allows XMLRPC or SOAP messages to masquerade as HTTP messages. This is good if you want to integrate remote applications, but it does raise a number of security concerns.ise a number of security concerns.

Blocks Extensible Exchange Protocol (BEEP)

This is a promising alternative to HTTP. BEEP is a new Internet Engineering Task Force (IETF) framework for building new protocols. BEEP is layered directly on TCP and includes a number of built-in features, including an initial handshake protocol, authentication, security, and error handling. Using BEEP, one can create new protocols for a variety of applications, including instant messaging, file transfer, content syndication, and network management.

SOAP is not tied to any specific transport protocol. In fact, you can use SOAP via HTTP, SMTP, or FTP. One promising idea is therefore to use SOAP over BEEP.

Over the past few years, three primary technologies have emerged as worldwide standards that make up the core of today's web services technology. These technologies are discussed below.

XML-RPC

This is the simplest XML-based protocol for exchanging information between computers.

• XML-RPC is a simple protocol that uses XML messages to perform RPCs.

• Requests are encoded in XML and sent via HTTP POST.

• XML responses are embedded in the body of the HTTP response.

• XML-RPC is platform-independent.

• XML-RPC allows diverse applications to communicate.

• A Java client can speak XML-RPC to a Perl server.

• XML-RPC is the easiest way to get started with web services.

To learn more about XML-RPC, visit our XML-RPC Tutorial.

SOAP

SOAP is an XML-based protocol for exchanging information between computers.

• SOAP is a communication protocol.

• SOAP is for communication between applications.

• SOAP is a format for sending messages.

• SOAP is designed to communicate via Internet.

• SOAP is platform independent.

• SOAP is language independent.

• SOAP is simple and extensible.

• SOAP allows you to get around firewalls.

• SOAP will be developed as a W3C standard.

To learn more about SOAP, visit our SOAP Tutorial.

WSDL

WSDL is an XML-based language for describing web services and how to access them.

• WSDL stands for Web Services Description Language.

• WSDL was developed jointly by Microsoft and IBM.

• WSDL is an XML based protocol for information exchange in decentralized and distributed environments.

• WSDL is the standard format for describing a web service.

• WSDL definition describes how to access a web service and what operations it will perform.

• WSDL is a language for describing how to interface with XML-based services.

• WSDL is an integral part of UDDI, an XML-based worldwide business registry.

• WSDL is the language that UDDI uses.

• WSDL is pronounced as 'wiz-dull' and spelled out as 'W-S-D-L'.

To learn more about WSDL, visit our WSDL Tutorial.

UDDI

UDDI is an XML-based standard for describing, publishing, and finding web services.

• UDDI stands for Universal Description, Discovery, and Integration.

• UDDI is a specification for a distributed registry of web services.

• UDDI is platform independent, open framework.

• UDDI can communicate via SOAP, CORBA, and Java RMI Protocol.

• UDDI uses WSDL to describe interfaces to web services.

• UDDI is seen with SOAP and WSDL as one of the three foundation standards of web services.

• UDDI is an open industry initiative enabling businesses to discover each other and define how they interact over the Internet.

To learn more about UDDI, visit our UDDI Tutorial.

Based on the web service architecture, we create the following two components as a part of web services implementation −

Service Provider or Publisher

This is the provider of the web service. The service provider implements the service and makes it available on the Internet or intranet.

We will write and publish a simple web service using .NET SDK.

Service Requestor or Consumer

This is any consumer of the web service. The requestor utilizes an existing web service by opening a network connection and sending an XML request.

We will also write two web service requestors: one web-based consumer (ASP.NET application) and another Windows application-based consumer.

Given below is our first web service example which works as a service provider and exposes two methods (add and SayHello) as the web services to be used by applications. This is a standard template for a web service. .NET web services use the .asmx extension. Note that a method exposed as a web service has the WebMethod attribute. Save this file as FirstService.asmx in the IIS virtual directory (as explained in configuring IIS; for example, c:\MyWebSerces).

FirstService.asmx
<%@ WebService language = "C#" class = "FirstService" %>

using System;
using System.Web.Services;
using System.Xml.Serialization;

[WebService(Namespace = "http://localhost/MyWebServices/")]
public class FirstService : WebService{
   [WebMethod]
   public int Add(int a, int b) {
      return a + b;
   }

   [WebMethod]
   public String SayHello() {
      return "Hello World";
   }
}

To test a web service, it must be published. A web service can be published either on an intranet or the Internet. We will publish this web service on IIS running on a local machine. Let us start with configuring the IIS.

• Open Start → Settings → Control Panel → Administrative tools → Internet Services Manager.

• Expand and right-click on the default web site; select New &#rarr; Virtual Directory. The Virtual Directory Creation Wizard opens. Click Next.

• The "Virtual Directory Alias" screen opens. Type the virtual directory name. For example, MyWebServices. Click Next.

• The "Web Site Content Directory" screen opens.

• Enter the directory path name for the virtual directory. For example, c:\MyWebServices. Click Next.

• The "Access Permission" screen opens. Change the settings as per your requirements. Let us keep the default settings for this exercise.

• Click the Next button. It completes the IIS configuration.

• Click Finish to complete the configuration.

To test whether the IIS has been configured properly, copy an HTML file (For example, x.html) in the virtual directory (C:\MyWebServices) created above. Now, open Internet Explorer and type http://localhost/MyWebServices/x.html. It should open the x.html file.

Note − If it does not work, try replacing the localhost with the IP address of your machine. If it still does not work, check whether IIS is running; you may need to reconfigure the IIS and the Virtual Directory.

To test this web service, copy FirstService.asmx in the IIS virtual directory created above (C:\MyWebServices). Open the web service in Internet Explorer (http://localhost/MyWebServices/FirstService.asmx). It should open your web service page. The page should have links to two methods exposed as web services by our application. Congratulations! You have written your first web service!

Testing the Web Service

As we have just seen, writing web services is easy in the .NET Framework. Writing web service consumers is also easy in the .NET framework; however, it is a bit more involved. As said earlier, we will write two types of service consumers, one web-based and another Windows application-based consumer. Let us write our first web service consumer.

Web-Based Service Consumer

Write a web-based consumer as given below. Call it WebApp.aspx. Note that it is an ASP.NET application. Save this in the virtual directory of the web service (c:\MyWebServices\WebApp.axpx).

This application has two text fields that are used to get numbers from the user to be added. It has one button, Execute, that when clicked gets the Add and SayHello web services.

WebApp.aspx
<%@ Page Language = "C#" %>
<script runat = "server">
   void runSrvice_Click(Object sender, EventArgs e) {
      FirstService mySvc = new FirstService();
      Label1.Text = mySvc.SayHello();
      Label2.Text = mySvc.Add(Int32.Parse(txtNum1.Text),  Int32.Parse(txtNum2.Text)).ToString();
   }
</script>

<html>
   <head> </head>
   
   <body>
      <form runat = "server">
         <p>
            <em>First Number to Add </em>:
            <asp:TextBox id = "txtNum1" runat = "server" Width = "43px">4<  /asp:TextBox>
         </p>
			
         <p>
            <em>Second Number To Add </em>:
            <asp:TextBox id = "txtNum2" runat = "server" Width = "44px">5</asp:TextBox>
         </p>
			
         <p>
            <strong><u>Web Service Result -</u></strong>
         </p>
			
         <p>
            <em>Hello world Service</em> :
            <asp:Label id = "Label1" runat = "server" Font-Underline = "True">Label< /asp:Label>
         </p>

         <p>
            <em>Add Service</em> :
            & <asp:Label id = "Label2" runat = "server" Font-Underline = "True">Label</asp:Label>
         </p>
			
         <p align = "left">
            <asp:Button id = "runSrvice" onclick = "runSrvice_Click" runat = "server" Text = "Execute"></asp:Button>
         </p>
      </form>
   </body>
</html>

After the consumer is created, we need to create a proxy for the web service to be consumed. This work is done automatically by Visual Studio .NET for us when referencing a web service that has been added. Here are the steps to be followed −

• Create a proxy for the Web Service to be consumed. The proxy is created using the WSDL utility supplied with the .NET SDK. This utility extracts information from the Web Service and creates a proxy. The proxy is valid only for a particular Web Service. If you need to consume other Web Services, you need to create a proxy for this service as well. Visual Studio .NET creates a proxy automatically for you when the Web Service reference is added. Create a proxy for the Web Service using the WSDL utility supplied with the .NET SDK. It will create FirstSevice.cs file in the current directory. We need to compile it to create FirstService.dll (proxy) for the Web Service.

c:> WSDL http://localhost/MyWebServices/FirstService.asmx?WSDL
c:> csc /t:library FirstService.cs

• Put the compiled proxy in the bin directory of the virtual directory of the Web Service (c:\MyWebServices\bin). Internet Information Services (IIS) looks for the proxy in this directory.

• Create the service consumer, in the same way we already did. Note that an object of the Web Service proxy is instantiated in the consumer. This proxy takes care of interacting with the service.

• Type the URL of the consumer in IE to test it (for example, http://localhost/MyWebServices/WebApp.aspx).

Windows Application-Based Web Service Consumer

Writing a Windows application-based web service consumer is the same as writing any other Windows application. You only need to create the proxy (which we have already done) and reference this proxy when compiling the application. Following is our Windows application that uses the web service. This application creates a web service object (of course, proxy) and calls the SayHello, and Add methods on it.

WinApp.cs

using System;
using System.IO;

namespace SvcConsumer {
   class SvcEater {
      public static void Main(String[] args) {
         FirstService mySvc = new FirstService();
         Console.WriteLine("Calling Hello World Service: " + mySvc.SayHello());
         Console.WriteLine("Calling Add(2, 3) Service: " + mySvc.Add(2, 3).ToString());
      }
   }
}

Compile it using c:\>csc /r:FirstService.dll WinApp.cs. It will create WinApp.exe. Run it to test the application and the web service.

Now, the question arises: How can you be sure that this application is actually calling the web service?

It is simple to test. Stop your web server so that the web service cannot be contacted. Now, run the WinApp application. It will fire a runtime exception. Now, start the web server again. It should work.

Security is critical to web services. However, neither XML-RPC nor SOAP specifications make any explicit security or authentication requirements.

There are three specific security issues with web services −

• Confidentiality
• Authentication
• Network Security

Confidentiality

If a client sends an XML request to a server, can we ensure that the communication remains confidential?

Answer lies here −

• XML-RPC and SOAP run primarily on top of HTTP.
• HTTP has support for Secure Sockets Layer (SSL).
• Communication can be encrypted via SSL.
• SSL is a proven technology and widely deployed.

A single web service may consist of a chain of applications. For example, one large service might tie together the services of three other applications. In this case, SSL is not adequate; the messages need to be encrypted at each node along the service path, and each node represents a potential weak link in the chain. Currently, there is no agreed-upon solution to this issue, but one promising solution is the W3C XML Encryption Standard. This standard provides a framework for encrypting and decrypting entire XML documents or just portions of an XML document. You can check it at www.w3.org/Encryption

Authentication

If a client connects to a web service, how do we identify the user? Is the user authorized to use the service?

The following options can be considered but there is no clear consensus on a strong authentication scheme.

• HTTP includes built-in support for Basic and Digest authentication, and services can therefore be protected in much the same manner as HTML documents are currently protected.

• SOAP Digital Signature (SOAP-DSIG) leverages public key cryptography to digitally sign SOAP messages. It enables the client or server to validate the identity of the other party. Check it at www.w3.org/TR/SOAP-dsig.

• The Organization for the Advancement of Structured Information Standards (OASIS) is working on the Security Assertion Markup Language (SAML).

Network Security

There is currently no easy answer to this problem, and it has been the subject of much debate. For now, if you are truly intent on filtering out SOAP or XML-RPC messages, one possibility is to filter out all HTTP POST requests that set their content type to text/xml.

Another alternative is to filter the SOAPAction HTTP header attribute. Firewall vendors are also currently developing tools explicitly designed to filter web service traffic.

This chapter gives you an idea of all the latest standards related to web services.

Transports

BEEP, the Blocks Extensible Exchange Protocol (formerly referred to as BXXP), is a framework for building application protocols. It has been standardized by IETF and it does for Internet protocols what XML has done for data.

• Blocks Extensible Exchange Protocol (BEEP)

Messaging

These messaging standards and specifications are intended to give a framework for exchanging information in a decentralized, distributed environment.

• SOAP 1.1 (Note)

• SOAP 1.2 (Specification)

• Web Services Attachments Profile 1.0

• SOAP Message Transmission Optimization Mechanism

Description and Discovery

Web services are meaningful only if potential users may find information sufficient to permit their execution. The focus of these specifications and standards is the definition of a set of services supporting the description and discovery of businesses, organizations, and other web services providers; the web services they make available; and the technical interfaces which may be used to access those services.

• UDDI 3.0

• WSDL 1.1 (Note)

• WSDL 1.2 (Working draft)

• WSDL 2.0 (Working Group)

Security

Using these security specifications, applications can engage in secure communication designed to work with the general web services framework.

• Web Services Security 1.0

• Security Assertion Markup Language (SAML)

Management

Web services manageability is defined as a set of capabilities for discovering the existence, availability, health, performance, usage, as well as the control and configuration of a web service within the web services architecture. As web services become pervasive and critical to business operations, the task of managing and implementing them is imperative to the success of business operations.

• Web Services Distributed Management

In this tutorial, you have learnt how to use web services. However, a web service also include components such as WSDL, UDDI, and SOAP that contribute to make it active. The next step is to learn WSDL, UDDI, and SOAP.

WSDL

WSDL is an XML-based language for describing web services and how to access them.

WSDL describes a web service, along with the message format and protocol details for the web service.

To learn more about WSDL, visit our WSDL Tutorial.

UDDI

UDDI is an XML-based standard for describing, publishing, and finding web services.

To learn more about UDDI, visit our UDDI Tutorial.

SOAP

SOAP is a simple XML-based protocol that allows applications to exchange information over HTTP.

To learn more about SOAP, visit our SOAP Tutorial.