Web Service (Important)

A Web Service is a software program that uses XML to exchange

information with other software via common internet protocols. In a simple
sense, Web Services are a way of interacting with objects over the Internet.

A web service is
● Language Independent.
● Protocol Independent.
● Platform Independent.
● It assumes a stateless service architecture.
● Scalable (e.g. multiplying two numbers together to an entire
customer-relationship management system).
● Programmable (encapsulates a task).
● Based on XML (open, text-based standard).
● Self-describing (metadata for access and use).
● Discoverable (search and locate in registries)- ability of applications
and developers to search for and locate desired Web services
through registries. This is based on UDDI.

What is a Web service?

I hope you know the meaning of web service before you execute the demo.
A web service is nothing but a software application which runs on the web
having some exposed web methods which other applications can use over
HTTP/ HTTPS protocols using technologies such as XML, SOAP, WSDL,
and UDDI. Here in this demo, we will create one such web service and we
will try to use its web methods. We will do all of this in a single web project
but you can try it in different projects on the same machines as well as
different projects on different machines. It should work.

What are web services and why should we use them?

Web services are a standardized way for developing interoperable
applications i.e enabling an application to invoke a method of another
application. These applications can be on the same computer or different
computers. Web services use open standards and protocols like HTTP,
XML and SOAP. Since these are open and well known protocols,
applications built on any platform can interoperate with web services. For
example, a JAVA application can interoperate with a web service built using
.NET. Similarly a web service built using JAVA can be consumed by a .NET
application.

Hyper Text Transfer Protocol (HTTP) is the protocl widely used by web
services to send and receive messages.
The messaging protocol is SOAP. SOAP stands for Simple Object Access
Protocol. SOAP messages are in XML format.

WebService
Implementation-------------------------------------------------------------------------------

https://www.c-sharpcorner.com/article/how-to-create-a-web-service-project-
in-net-using-visual-studio/

Building ASP.NET web services

Building ASP.NET web services is easy. Here are the steps.
Step 1: Create a an ASP.NET Empty Web Application and name it
WebServicesDemo.

Step 2: Right click on WebServicesDemo project in solution explorer and

add - New Item. From the Add New Item dialog box select Web Service.
Change the name of the WebService1.asmx to
CalculatorWebServices.asmx.

Web Services have .asmx extension. For this reason web services are
also often called as ASMX web services.

Notice that a webservice is a class that is decorated with [WebService]

attribute and inherits from System.Web.Services.WebService base class.
The [WebService] attribute tells that the this class contains the code for a
web service. WebService Namespace is used to uniquely identify your
web service on the internet from other services that are already there on
the Web. WebService Namespace can be any string, but it is common to
give it a company's internet domain name as they are usually unique.
Something like
[WebService(Namespace = "http://pragimtech.com/webservices")]

It is not mandatory for a web service to inherit from

System.Web.Services.WebService base class. However, if the web
service has to use ASP.NET session or application state objects, then
inheriting from System.Web.Services.WebService base class will provide
direct access to these asp.net objects.

To allow a web service to be called from Javascript, using ASP.NET AJAX,

then decorate the web service class with
[System.Web.Script.Services.ScriptService] attribute.

Notice that, the CalculatorWebServices class contains a single method

called Add(). This method adds 2 numbers and return the sum. This
method is decorated with [WebMethod] attribute. If you want the method
exposed as part of the Web service, then the method must be public and
should be decorated with [WebMethod] attribute. This attribute has got
several properties which can be used to configure the behavior of the XML
Web service method.

Notice that the Add() method that we created in the web service is
displayed on the page. Clicking on the method name will take you to page
where you can test the method. This page also shows the format of the
SOAP request and response messages.
Web services: SOAP, WSDL, UDDI : (Important)
A Web service is a software system that supports interoperable
machine-to-machine interaction.

● Interaction means that more than one application is involved.

● Interoperable means that applications can operate with one
another without sharing the same platform, operating system,
programming language, etc

Web services are largely delivered by :

● SOAP (Simple Object Access Protocol), WSDL (Web Services

Description Language), and UDDI (Universal Description,
Discovery, and Interoperability).
● These three build on XML (the metalanguage for the
representation) and HTTP, the transport protocol

In overview

♦ SOAP defines a uniform way of passing XML-encoded data.

In SOAP messages, the name of the service request and the input
parameters take the form of XML elements.

♦ WSDL allows service providers to specify what a web service can

do, where it resides, and how to invoke it.

WSDL describes the data types and structures for Web services, and
tells how to map them into the messages that are exchanged.

♦ UDDI provides a mechanism for clients to dynamically find other

Web services.

UDDI provides a repository for Web-services descriptions. An UDDI

registry can be searched on various criteria to find all kinds of
services offered by businesses.
UDDI, SOAP and its Format (Important)

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 a platform-independent, open framework.
● It uses SOAP for queries and modifications.
● UDDI can communicate via SOAP, CORBA, 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.
● There are global UDDI repositories.
● The largest is at www.uddi.org. UDDI is the Yahoo/Google of Web
services.
● An enterprise can also have local repositories (just like you can have
local Yahoos/Googles).

How UDDI works.

1. The world creates different classifications of services.
2. Businesses submit their Web services to the registry.
3. A Web service is catalogued.
4. Potential web services customers query UDDI for what they
need.
5. A new business relationship is born.
UDDI FORMAT :

Core UDDI Data Types

● businessEntity: A business providing a service
● businessService: A service bindingTemplate: Invocation
details
● tModel: used to specify that a service complies with the
constraints of a particular, pre-defined model. The UDDI
tModel is crucial for interoperability in services, because
without standard, pre-defined models every interface
must be separately defined and software independently
implemented.
● publisherAssertion: relationships between
businessEntities.

UDDI & WSDL

● businessService: created for each Web service
● tModel: Points to the WSDL
● bindingTemplate: the unique URL access points
You’ll probably use an API (e.g., JAXR, the Java API for XML Registries) to
access UDDI.
UDDI Business Entity :

SOAP : (Important)

SOAP is an acronym for Simple Object Access Protocol. It is an XML-based

messaging protocol for exchanging information among computers. SOAP is an
application of the XML specification.

● SOAP is a communication protocol that allows applications to exchange

information. The SOAP is not a language or a platform specific protocol;
instead it allows communication between applications running on different
platforms.
● SOAP is a light-weight, text-based protocol and uses XML based rule to
allow applications and softwares interchange information over HTTP or
RPC.
● SOAP is based on vendor agnostic technology, namely XML and HTTP
and is shared by all the platforms. It uses the internet application layer
protocol as transport protocol and is used to access WS.
● SOAP is nothing but XML message based document with pre-defined
format i.e. HTTP+XML=SOAP.
Although SOAP can be used in a variety of messaging systems and can be
delivered via a variety of transport protocols, the initial focus of SOAP is remote
procedure calls transported via HTTP.
Other frameworks including CORBA, DCOM, and Java RMI provide similar
functionality to SOAP, but SOAP messages are written entirely in XML and are
therefore uniquely platform- and language-independent.

● SOAP - Message Structure (Important)

A SOAP message is an ordinary XML document containing the following elements −
● Envelope − Defines the start and the end of the message. It is a mandatory
element.
● Header − Contains any optional attributes of the message used in processing the
message, either at an intermediary point or at the ultimate end-point. It is an
optional element.
● Body − Contains the XML data comprising the message being sent. It is a
mandatory element.
● Fault − An optional Fault element that provides information about errors that
occur while processing the message.
All these elements are declared in the default namespace for the SOAP envelope −
http://www.w3.org/2001/12/soap-envelope and the default namespace for SOAP
encoding and data types is − http://www.w3.org/2001/12/soap-encoding
NOTE − All these specifications are subject to change. So keep updating yourself with
the latest specifications available on the W3 website.

SOAP Message Structure

The following block depicts the general structure of a SOAP message −
<?xml version = "1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV =
"http://www.w3.org/2001/12/soap-envelope"
SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">

<SOAP-ENV:Header>
...
...
</SOAP-ENV:Header>
 <SOAP-ENV:Body>
...
...
<SOAP-ENV:Fault>
...
...
</SOAP-ENV:Fault>
...
</SOAP-ENV:Body>

</SOAP_ENV:Envelope>

Let’s first take a look at SOAP. Take a very simple search request:
http://www.google.com/search?q=laptop+trackball
This invokes Google with the search terms “laptop” and “trackball”. Google returns lists
of pages that entirely depend on matching the given text strings.

XML provides a lot of advantages over simple text-based search. It allows the preceding
request to be refined and contained in an XML document:
 1. SOAP Envelope
2. SOAP Header
3. SOAP Body
4. SOAP Fault

SOAP Envelope
The SOAP envelope indicates the start and the end of the message so that the
receiver knows when an entire message has been received. The SOAP envelope
solves the problem of knowing when you are done receiving a message and are
ready to process it.

Points to Note
● Every SOAP message has a root Envelope element.
● Envelope is a mandatory part of SOAP message.
● Every Envelope element must contain exactly one Body element.
● If an Envelope contains a Header element, it must contain no more than
one, and it must appear as the first child of the Envelope, before the Body.
● The envelope changes when SOAP versions change.
● The SOAP envelope is specified using the ENV namespace prefix and the
Envelope element.
● The optional SOAP encoding is also specified using a namespace name
and the optional encodingStyle element, which could also point to an
encoding style other than the SOAP one.
● A v1.1-compliant SOAP processor generates a fault upon receiving a
message containing the v1.2 envelope namespace.
● A v1.2-compliant SOAP processor generates a VersionMismatch fault if it
receives a message that does not include the v1.2 envelope namespace.
v1.2-Compliant SOAP Message
Given below is an example of v1.2-compliant SOAP message.
<?xml version = "1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope"
SOAP-ENV:encodingStyle = " http://www.w3.org/2001/12/soap-encoding">
...
Message information goes here
...
</SOAP-ENV:Envelope>

SOAP Header:
The optional Header element offers a flexible framework for specifying
additional application-level requirements. For example, the Header element
can be used to specify a digital signature for password-protected services.
Likewise, it can be used to specify an account number for pay-per-use
SOAP services.

Points to Note
● It is an optional part of a SOAP message.
● Header elements can occur multiple times.
● Headers are intended to add new features and functionality.
● The SOAP header contains header entries defined in a namespace.
● The header is encoded as the first immediate child element of the
SOAP envelope.
● When multiple headers are defined, all immediate child elements of
the SOAP header are interpreted as SOAP header blocks.
SOAP Header Attributes
A SOAP Header can have the following two attributes −

Actor attribute
The SOAP protocol defines a message path as a list of SOAP service nodes. Each of
these intermediate nodes can perform some processing and then forward the message
to the next node in the chain. By setting the Actor attribute, the client can specify the
recipient of the SOAP header.

MustUnderstand attribute
It indicates whether a Header element is optional or mandatory. If set to true, the
recipient must understand and process the Header attribute according to its defined
semantics, or return a fault.
The following example shows how to use a Header in a SOAP message.
<?xml version = "1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV = " http://www.w3.org/2001/12/soap-envelope"
SOAP-ENV:encodingStyle = "
http://www.w3.org/2001/12/soap-encoding">

<SOAP-ENV:Header>
<t:Transaction
xmlns:t = "http://www.tutorialspoint.com/transaction/"
SOAP-ENV:mustUnderstand = "true">5
</t:Transaction>
</SOAP-ENV:Header>
...
...
</SOAP-ENV:Envelope>
SOAP Body
The SOAP body is a mandatory element that contains the application-defined
XML data being exchanged in the SOAP message. The body must be contained
within the envelope and must follow any headers that might be defined for the
message.
The body is defined as a child element of the envelope, and the semantics for
the body are defined in the associated SOAP schema.
The body contains mandatory information intended for the ultimate receiver of
the message. For example −
<?xml version = "1.0"?>
<SOAP-ENV:Envelope>
........
<SOAP-ENV:Body>
<m:GetQuotation xmlns:m =
"http://www.tp.com/Quotation">
<m:Item>Computers</m:Item>
</m:GetQuotation>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

The example above requests a quotation of computer sets. Note that the
m:GetQuotation and the Item elements above are application-specific elements.
They are not a part of the SOAP standard.

Here is the response to the above query −

<?xml version = "1.0"?>
<SOAP-ENV:Envelope>
........
<SOAP-ENV:Body>
<m:GetQuotationResponse xmlns:m =
"http://www.tp.com/Quotation">
<m:Quotation>This is Qutation</m:Quotation>
</m:GetQuotationResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Normally, the application also defines a schema to contain semantics
associated with the request and response elements.

SOAP Fault
If an error occurs during processing, the response to a SOAP message is a
SOAP fault element in the body of the message, and the fault is returned to the
sender of the SOAP message.
The SOAP fault mechanism returns specific information about the error,
including a predefined code, a description, and the address of the SOAP
processor that generated the fault.
● A SOAP message can carry only one fault block.
● Fault is an optional part of a SOAP message.
● For HTTP binding, a successful response is linked to the 200 to 299 range
of status codes.
● SOAP Fault is linked to the 500 to 599 range of status codes

More information : https://www.tutorialspoint.com/soap/soap_fault.htm

SOAP Fault Example

The following code is a sample Fault. The client has requested a method named
ValidateCreditCard, but the service does not support such a method. This represents a
client request error, and the server returns the following SOAP response
<?xml version = '1.0' encoding = 'UTF-8'?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV = "http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi = "http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd = "http://www.w3.org/1999/XMLSchema">

<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode xsi:type =
"xsd:string">SOAP-ENV:Client</faultcode>
<faultstring xsi:type = "xsd:string">
 Failed to locate method (ValidateCreditCard) in class
(examplesCreditCard)at
/usr/local/ActivePerl-5.6/lib/site_perl/5.6.0/SOAP/Lite.pm line
1555.
</faultstring>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
In this example, the meeting reminder message will be broadcast to the
device list by the send service located at the address defined by the URL:
http://www.xmlbus.com/broadcastServices. Separate namespaces
(broadcastService and function) are used to qualify the element and
attributes for each part of the message.

This simple one-way message can be bound to HTTP using POST:

The HTTP header indicates that the document is being sent to the
broadcastService at the indicated URL. When the program implementing
the broadcastService receives the message, it will decode the body block
and execute the send Although SOAP is usually used over HTTP, it can be
used over other protocols as well, e.g., SMTP/POP
WSDL : https://www.tutorialspoint.com/wsdl/wsdl_introduction.htm
WSDL stands for Web Services Description Language. It is the standard
format for describing a web service. WSDL was developed jointly by
Microsoft and IBM.

Features of WSDL
● WSDL is an XML-based protocol for information exchange in
decentralized and distributed environments.
● WSDL definitions describe 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 Universal Description, Discovery, and
Integration (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'.

WSDL - Elements :
WSDL breaks down web services into three specific, identifiable elements that
can be combined or reused once defined.
The three major elements of WSDL that can be defined separately are −
● Types
● Operations
● Binding
A WSDL document has various elements, but they are contained within these
three main elements, which can be developed as separate documents and then
they can be combined or reused to form complete WSDL files.
WSDL Elements
A WSDL document contains the following elements −
● Definition − It is the root element of all WSDL documents. It defines the
name of the web service, declares multiple namespaces used throughout
the remainder of the document, and contains all the service elements
described here.
● Data types − The data types to be used in the messages are in the form of
XML schemas.
● Message − It is an abstract definition of the data, in the form of a message
presented either as an entire document or as arguments to be mapped to
a method invocation.
● Operation − It is the abstract definition of the operation for a message,
such as naming a method, message queue, or business process, that will
accept and process the message.
● Port type − It is an abstract set of operations mapped to one or more
end-points, defining the collection of operations for a binding; the collection
of operations, as it is abstract, can be mapped to multiple transports
through various bindings.
● Binding − It is the concrete protocol and data formats for the operations
and messages defined for a particular port type.
● Port − It is a combination of a binding and a network address, providing
the target address of the service communication.
● Service − It is a collection of related end-points encompassing the service
definitions in the file; the services map the binding to the port and include
any extensibility definitions.
In addition to these major elements, the WSDL specification also defines the
following utility elements −
● Documentation − This element is used to provide human-readable
documentation and can be included inside any other WSDL element.
● Import − This element is used to import other WSDL documents or XML
Schemas.
NOTE − WSDL parts are usually generated automatically using web
services-aware tools.
The WSDL Document Structure
The main structure of a WSDL document looks like this −
<definitions>
<types>
definition of types........
</types>

<message>
definition of a message....
</message>

<portType>
<operation>
definition of a operation.......
</operation>
</portType>

<binding>
definition of a binding....
</binding>

<service>
definition of a service....
</service>
</definitions>

A WSDL document can also contain other elements, like extension elements and a
service element that makes it possible to group together the definitions of several web
services in one single WSDL document.

Given below is a WSDL file that is provided to demonstrate a simple WSDL

program.
Let us assume the service provides a single publicly available function, called sayHello.
This function expects a single string parameter and returns a single string greeting. For
example, if you pass the parameter world then service function sayHello returns the
greeting, "Hello, world!".
Example :
Contents of HelloService.wsdl file −
<definitions name = "HelloService"
targetNamespace =
"http://www.examples.com/wsdl/HelloService.wsdl"
xmlns = "http://schemas.xmlsoap.org/wsdl/"
xmlns:soap = "http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns = "http://www.examples.com/wsdl/HelloService.wsdl"
xmlns:xsd = "http://www.w3.org/2001/XMLSchema">

<message name = "SayHelloRequest">

<part name = "firstName" type = "xsd:string"/>
</message>

<message name = "SayHelloResponse">

<part name = "greeting" type = "xsd:string"/>
</message>

<portType name = "Hello_PortType">

<operation name = "sayHello">
<input message = "tns:SayHelloRequest"/>
<output message = "tns:SayHelloResponse"/>
</operation>
</portType>

<binding name = "Hello_Binding" type = "tns:Hello_PortType">

<soap:binding style = "rpc"
transport = "http://schemas.xmlsoap.org/soap/http"/>
<operation name = "sayHello">
<soap:operation soapAction = "sayHello"/>
<input>
<soap:body
encodingStyle =
"http://schemas.xmlsoap.org/soap/encoding/"
namespace = "urn:examples:helloservice"
use = "encoded"/>
</input>

<output>
<soap:body
 encodingStyle =
"http://schemas.xmlsoap.org/soap/encoding/"
namespace = "urn:examples:helloservice"
use = "encoded"/>
</output>
</operation>
</binding>

<service name = "Hello_Service">

<documentation>WSDL File for HelloService</documentation>
<port binding = "tns:Hello_Binding" name = "Hello_Port">
<soap:address
location = "http://www.examples.com/SayHello/" />
</port>
</service>
</definitions>

Example Analysis
● Definitions − HelloService
● Type − Using built-in data types and they are defined in XMLSchema.
● Message −
○ sayHelloRequest − firstName parameter
○ sayHelloresponse − greeting return value
● Port Type − sayHello operation that consists of a request and a
response service.
● Binding − Direction to use the SOAP HTTP transport protocol.
● Service − Service available at http://www.examples.com/SayHello/
● Port − Associates the binding with the URI
http://www.examples.com/SayHello/ where the running service can
be accessed.
WCF ARCHITECTURE :
WCF has a layered architecture that offers ample support for developing various
distributed applications. The architecture is explained below in detail.
Layer 1: Contracts

WCF contracts are much like a contract that you and I would sign in real life. This
contract or WCF contract contains information such as what a service does and
the type of information it will make available. A WCF Contract is a collection of
Operations that specifies what the Endpoint communicates to the outside world.
There are four types of contracts.

Type Of Contract :
https://www.c-sharpcorner.com/UploadFile/87b416/various-types-of-wcf-contracts
/#:~:text=There%20are%20two%20type%20of,Fault%20Contract%20and%20Me
ssage%20Contract.&text=The%20Service%20Contracts%20describes%20what,
attribute%20is%20in%20the%20System.

OR

https://www.c-sharpcorner.com/UploadFile/0c1bb2/contracts-in-wcf-service/

1. Data contract explicitly stipulates the data that will be exchanged by the
service.
2. Message contract controls the SOAP messages sent and received by the
service.
3. Service contract is what informs the clients and the rest of the outside
world what the endpoint has to offer and communicate.
4. Policy and Binding contracts specify important information such as
security, protocol and other information.
Layer 2: Service Runtime
This layer specifies and manages the behaviors of the service that occur during
service operation.

List of various behaviors managed by Service Runtime layer:

1. Throttling Behavior determines the number of processed messages.

2. Error Behavior specifies what action will be taken if an error occurs during
service runtime.
3. Metadata Behavior controls whether or not metadata is exposed to the
outside world.
4. Instance Behavior drives how many instances of the service will be
available to process messages.
5. Message Inspection gives the service the ability to inspect all or parts of a
message.
6. Transaction Behavior has the ability to rollback the transaction, if a process
fails during the service runtime.
7. Dispatch Behavior service determines how the message is to be handled
and processed.
8. Concurrency Behavior determines how each service, or instance of the
service, handles threading.
9. Parameter Filtering filters the message headers and executes preset
actions based on the filter of the message headers.

Layer 3: Messaging
This layer defines what formats and data exchange patterns can be used during
service communication.

Following lists the channels and components that the Messaging layer is
composed of:

1. WS Security Channel implements the WS-Security specification, which

enables message security.
2. WS Reliable Messaging Channel which provides guaranteed message
delivery.
3. Encoders let you pick from a number of encodings for the message.
4. HTTP Channel tells the service that message delivery will take place via
 the HTTP protocol.
5. TCP Channel tells the service that message delivery will take place via the
TCP protocol.
6. Transaction Flow Channel governs transacted message patterns.
7. NamedPipe Channel enables inter-process communication.
8. MSMQ Channel helps to use MSMQ.

Layer 4: Activation and Hosting

This layer provides various options in which a service can be started as well as
hosted. Services can be hosted within the context of another application, or they
can be self-hosted. The following list details the hosting and activation options
provided by this layer:

1. Windows Activation Service enables WCF applications to be automatically

started when running on a computer that is running the Windows Activation
Service.
2. .EXE, WCF allows services to be run as executables.
3. Windows Services, WCF allows services to be run as Windows service.
4. COM+, WCF allows services to be run as COM+ application.
Note :
An .asmx file extension: An abbreviation for Active Server Method File, a
file with the ASMX file extension is an ASP.NET Web Service Source file.
ASMX (ASP.NET Web Services) is the primary web service technology in .
NET 1.0 and . NET 2.0. ASMX provides the ability to build web services
that send SOAP (Simple Object Access Protocol) messages over HTTP
protocol
ASMX web services are a legacy technology. Most of the companies are
now using WCF (Windows Communication Foundation) to build XML Web
services and XML Web service clients. However, this course will be useful
for those who are searching for a job as a dot net developer as there are
some companies still using ASMX web services today, and could ask
interview questions related to them.