The next picture summarizes the web service life cycle. You can find more detail about different kind of specifications used by technology:
1. Design-time tasks:
– The web service consumer finds the web service, either by going directly to the web service URL or by using UDDI server or DISCO file.
– The client retrieves the web service WSDL document, which describes how to interact with the web service.
2. Run time tasks:
– When you run the application and actually interact with the web service, the client sends a SOAP message to trigger to the appropriate web method.
The web service life cycle
How to find web services
There are two specifications you can use:
– DISCO (an abbreviation of discovery) – This standard creates a single file that groups a list of related web services. A company can publish a DISCO file on its server that contains links to all the web services it provides. Then clients simply need to request this file to find all the available web services. This is useful when the client already knows a company that it’s offering services and wants to see what web services they expose and find links to the details of its services. This approach is applicable for local networks where a client connects to the server and can see what and where services are available.
– UDDI (Universal Description,Discovery, and Integration) – UDDI is a centralized directory where web services are published by a group of companies. It’s also the place where potential clients can go to search for their specific needs. Different organizations and groups of companies may use different UDDI registries. To retrieve information from a UDDI directory or register your components, you use a web service interface.
Important notes:
1. DISCO is supported only by Microsoft and is slated to be replaced by a similar more general standard named WS-Inspection in future .NET releases.
2. UDDI is designed for web services that are intended to be shared publicly or among a consortium of companies or organizations.
3. UDDI is not incorporated into the .NET Framework, but you can download a separate .NET component to search UDDI directories and register your components.
How to describe a web service
The WSDL (Web Service Description Language) is an XML-based language that describes details such as what methods are available, what parameters each method uses, and what the data type of each parameter is. The language describes the request message a client needs to submit to the web service and response message the web service returns. It also specifies the transport protocol you need to use (usually HTTP) and the location of the web service.
How to communicate with a web service
You need a well-established approach to create request and response messages that can be parsed and understood on any platform, to communicate with a web service. You can use the XML-based language SOAP (formerly Simple Object Access Protocol but no longer considered an acronym) to create these messages. Note: SOAP defines the messages you use to exchange data (the message format), but it doesn’t describe how you send the message (the transport protocol). With ASP.NET web services, the transport protocol is HTTP i.e. to communicate with a web service, a client opens an HTTP connection and sends a SOAP message.
.NET also supports HTTP GET and HTTP POST, two simpler approaches for interacting with web services that aren’t as standardized and don’t offer the same rich set of features. In both these cases, an HTTP channel is used for communication, and data is sent as a simple collection of name/value pairs, not as a full-blown SOAP message.