- Web Services
- Web Services Components
- Benefits of Web Service
- Why/Where do We need Web Services?
- How to create an ASP.NET Web Service using Visual Studio?
- How to implement the Layers in ASP.NET Web Service?
- How to use ASP.NET Web Service in ASP.NET Web Applications and .NET Windows Applications?
- How to implement the Logging in ASP.NET Web Service using Log4Net?
- How to improve the performance of ASP.NET Web Service?
- How to test the ASP.NET Web Service using SoapUI?
- How to migrate ASP.NET Web Service in to WCF?
ASP.NET Web Services Life Cycle
ASP.NET Web Service Life Cycle
Web services are software components that communicate using pervasive,standards-based Web technologies including HTTP and XML-based messaging.Web services are designed to be accessed by other applications and vary in complexity from simple operations.
such as checking a banking account balance online, to complex processes running CRM (customer relationship
management) or enterprise resource planning (ERP) systems. Since they are based on open standards such as HTTP and XML-based protocols including SOAP and WSDL, Web services are hardware, programming language, and
operating system independent.
This means that applications written in different programming languages and running on different platforms can seamlessly exchange data over intranets or the Internet using Web services.
Sample Web Service : CustomerService
Web Services Components
Web services are powered by XML and three other core technologies: WSDL,SOAP, and UDDI. Before building a Web service, its developers create its definition in the form of a WSDL document that describes the service’s location on the Web and the functionality the service provides. Information about the service may then be entered in a UDDI registry, which allows Web service
consumers to search for and locate the services they need. This step is optional but is beneficial when a company wants its Web services to be discovered by internal and/or external service consumers. Based on information in the UDDI registry, the Web services client developer uses instructions in the WSDL to construct SOAP messages for exchanging data with the service over HTTP. More about these core technologies is detailed below.
Web Services Layer Architecture
XML (eXtensible Markup Language)
XML is a W3C (World Wide Web Consortium) specification that defines a meta-language for describing data. In XML applications, data is described by surrounding it with customizable, text-based tags that give information about the data itself as well as its hierarchical structure. Because XML syntax consists of text-based mark-up that describes the data being tagged, it is both application-independent and human readable. This simplicity and interoperability have helped XML achieve widespread acceptance
and adoption as the standard for exchanging information between heterogeneous systems in a wide variety of applications, including Web services.
XML forms the basis for all modern Web services, which use XML-based technologies to describe their interfaces and to encode their messages. WSDL, SOAP, and UDDI all use XML-based messaging that any machine can interpret.
WSDL (Web Services Description Language)
Also maintained by the W3C, ‘WSDL is an XML-based format for describing Web services’. Clients wishing to access a Web service can read and interpret its WSDL file to learn about the location of the service and its available operations. In this way, the WSDL definition acts as the initial Web service interface, providing clients with all the information they need to interact with
the service in a standards-based way. Through the WSDL, a Web services client learns where a service can be accessed, what operations the service performs, the communication protocols the service supports, and the correct format for sending messages to the service.
A WSDL file is an XML document that describes a Web service using six main elements:
- Port type – groups and describes the operations performed by the service through the defined interface.
- Port – specifies an address for a binding, i.e., defines a communication port.
- Message – describes the names and format of the messages supported bythe service.
- Types – defines the data types (as defined in an XML Schema) used by the service for sending messages between the client and server.
- Binding – defines the communication protocols supported by the operations provided by the service.
- Service – specifies the address (URL) for accessing the service.
Sample Web Service : WSDL
The WSDL document that describes a Web service acts as a contract between Web service client and server. By adhering to this contact the service provider and consumer are able to exchange data in a standard way, regardless of the underlying platforms and applications on which they are operating.
SOAP (Simple Object Access Protocol)
SOAP is an XML-based protocol from the W3C for exchanging data over HTTP. It provides a simple, standards-based method for sending XML messages between applications.Web services use SOAP to send messages between a service and its client(s). Because HTTP is supported by all Web servers and browsers, SOAP messages can be sent between applications regardless of
their platform or programming language. This quality gives Web services their characteristic interoperability.
SOAP messages are XML documents that contain some or all of the following elements:
- Envelope – specifies that the XML document is a SOAP message; encloses the message itself
- Header (optional) – contains information relevant to the message, e.g., the date the message was sent, authentication data, etc.
- Body – includes the message payload.
- Fault (optional) – carries information about a client or server error within a SOAP message
Sample Web Service : SOAP Response
Data is sent between the client(s) and the Web service using request and response SOAP messages, the format for which is specified in the WSDLdefinition. Because the client and server adhere to the WSDL contract when creating SOAP messages, the messages are guaranteed to be compatible.
UDDI (Universal Description Discovery and Integration)
UDDI is a standard sponsored by OASIS (Organization for the Advancement of Structured Information Standards). Often described as the yellow pages of Web services, UDDI is a specification for creating an XML-based registry that lists information about businesses and the Web services they offer.
UDDI provides businesses a uniform way of listing their services and discovering services offered by other organizations. Though implementations vary, UDDI often describes services using WSDL and communicates via SOAP messaging. Registering a Web service in a UDDI registry is an optional step, and UDDI registries can be public or private (i.e. isolated behind a corporate firewall).
To search for a Web service, a developer can query a UDDI registry to obtain the WSDL for the service he/she wishes to utilize. Developers can also design their Web services clients to receive automatic updates about any changes to a service from the UDDI registry
Fig: Web Services Request and Response
Web Services : Requests and Responses
Benefits of ASP.NET Web Services
- Interoperability – This is the most important benefit of Web Services. Web Services typically work outside of private networks, offering developers a non-proprietary route to their solutions. Services developed are likely, therefore, to have a longer life-span, offering better return on investment of the developed service. Web Services also let developers use their preferred programming languages. In addition, thanks to the use of standards-based communications methods, Web Services are virtually platform-independent.
- Usability – Web Services allow the business logic of many different systems to be exposed over the Web. This gives your applications the freedom to chose the Web Services that they need. Instead of re-inventing the wheel for each client, you need only include additional application-specific business logic on the client-side. This allows you to develop services and/or client-side code using the languages and tools that you want.
- Reusability – Web Services provide not a component-based model of application development, but the closest thing possible to zero-coding deployment of such services. This makes it easy to reuse Web Service components as appropriate in other services. It also makes it easy to deploy legacy code as a Web Service.
- Deployability – Web Services are deployed over standard Internet technologies. This makes it possible to deploy Web Services even over the fire wall to servers running on the Internet on the other side of the globe. Also thanks to the use of proven community standards, underlying security (such as SSL) is already built-in.
Why/Where do We need Web Services?
You can use the Web Services for the following requirements.
- Web API : Where you need to expose your service to others such as Payment Gateway, Travel and Cinema Bookings.. etc.,
- Mobile Development: Web Service consume by Android and iOS Devices (Mobile, Tablet)
- Cross Platform Applications: ASP.NET Web Services can consume by Java, PHP appications
- Same Platform but diffrent applications: Windows Applications, Web Applications and Windows Serivces
Image Courtesy: http://www.howtoasp.net