Web-Services-munotes

Page 79

Developing Service -
Oriented Applications
with WCF
79

="runSrvice_Click" runat ="server" Text="Execute" >

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 suppli ed 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:libraryFirstService.c s
 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).
4.12 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 applicatio n. 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. munotes.in

Page 80

Web Services
80 WinApp .cs

using System ;
using System .IO;

namespace SvcConsumer {
class SvcEater {
publicstaticvoid Main (String []args){
FirstService mySvc =newFirstService ();
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:Fir stService.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 t hat 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.
4.13 SUMMARY
Web services are open standard (XML, SOAP, HTTP, etc.) based web
applications that int eract with other web applications for the purpose of
exchanging data. Web services can convert your existing applications into
web application s.
4.14 QUESTIONS
1. Explain WCF.
2. List out Features of WCF.
3. Explain Web services Architecture
4. Explain web service Rol es. munotes.in

Page 81

Developing Service -
Oriented Applications
with WCF
81 5. Give short notes on:
a) SOAP
b) WSDL
c) UDDI
4.15 REFERENCE
 https://learn.microsoft.com/en -us/dotnet/framework/wcf/whats -wcf
 https://www.tutorialspoint.com/mfc/mfc_windows_fundamentals.htm
 https://www.tutorialspoint.com/wcf/wcf_architecture.htm


munotes.in

Page 82

82 5
BASIC WCF PROGRAMMING
Unit Structure :
5.0 Introduction
5.1 WCF features supported by th e .NET Framework Client Profile
5.2 Basic WCF programming
5.3 Designing and Implementing Services
5.4 Service Contracts
5.5 Messages Up Front and Center
5.6 Designing Service Contracts
5.7 Classes or Interfaces
5.8 Parameters and Return Values
5.9 Specify Message Protection Level on the Contract
5.10 Configuring WCF services
5.11 Summary
5.12 Questions
5.13 Reference
5.0 INTRODUCTION
NET Framework Client P rofile is a lightweight version of the full .NET
Framework designed for clients that don’t need the entire framework. Not
all of Windows Communication Foundation is supported by the client
framework.
5.1 WCF FEATURES SUPPORTED BY THE .NET
FRAMEWORK CLIEN T PROFILE
The following Windows Communication Foundation features are
supported by .NET Framework Client Profile:
 All of WCF is supported except for Cardspace and web hosting.
 Remoting TCP/IP channels are supported.
 Asmx (Web Services) are not supported. munotes.in

Page 83

Basic WCF
Programming
83 5.2 BASIC WCF PROGRAMMING
Windows Communication Foundation (WCF) enables applications to
communicate whether they are on the same computer, across the Internet,
or on different application platforms.
The Basic Tasks
The basic tasks to perform are, in orde r:
1. Define the service contract. A service contract specifies the signature
of a service, the data it exchanges, and other contractually required
data. For more information..
2. Implement the contract. To implement a service contract, create a class
that imple ments the contract and specify custom behaviors that the
runtime should have. For more information.
3. Configure the service by specifying endpoints and other behavior
information. For more information.
4. Host the service.
5. Build a client application. For more information.
5.3 DESIGNING AND IMPLEMENTING SERVICES
This section shows you how to define and implement WCF contracts. A
service contract specifies what an endpoint communicates to the outside
world. At a more concrete level, it is a statement about a set of specific
messages organized into basic message exchange patterns (MEPs), such as
request/reply, one -way, and duplex. If a service contract is a logically
related set of message exchanges, a service operation is a single message
exchange. For example, a Hello operation must obviously accept one
message (so the caller can announce the greeting) and may or may not
return a message (depending upon the courtesy of the operation).
Overview
This topic provides a high level conceptual orientation to designing a nd
implementing WCF services. Subtopics provide more detailed information
about the specifics of design and implementation. Before designing and
implementing your WCF application, it is recommended that you:
 Understand what a service contract is, how it wo rks, and how to create
one.
 Understand that contracts state minimum requirements that runtime
configuration or the hosting environment may not support.
munotes.in

Page 84

Web Services
84 5.4 SERVICE CONTRACTS
A service contract specifies the following:
 The operations a contract exposes.
 The signature of the operations in terms of messages exchanged.
 The data types of these messages.
 The location of the operations.
 The specific protocols and serialization formats that are used to
support successful communication with the service.
For example , a purchase order contract might have a Create
Order operation that accepts an input of order information types and
returns success or failure information, including an order identifier. It
might also have a GetOrderStatus operation that accepts an order identifier
and returns order status information. A service contract of this sort would
specify:
1. That the purchase order contract consisted of Create Order and Get
Order Status operations.
2. That the operations have specified input messages and output
message s.
3. The data that these messages can carry.
4. Categorical statements about the communication infrastructure
necessary to successfully process the messages. For example, these
details include whether and what forms of security are required to
establish success ful communication.
To convey this kind of information to other applications on many
platforms (including non -Microsoft platforms), XML service contracts are
publicly expressed in standard XML formats, such as Web Services
Description Language (WSDL) and XML Schema (XSD), among others.
Developers for many platforms can use this public contract information to
create applications that can communicate with the service, both because
they understand the language of the specification and because those
languages ar e designed to enable interoperation by describing the public
forms, formats, and protocols that the service supports.
Contracts can be expressed many ways, and while WSDL and XSD are
excellent languages to describe services in an accessible way, they are
difficult languages to use directly and are merely descriptions of a service,
not service contract implementations. Therefore, WCF applications use
managed attributes, interfaces, and classes both to define the structure of a
service and to implement it. munotes.in

Page 85

Basic WCF
Programming
85 The resulting contract defined in managed types can be exported as
metadata —WSDL and XSD —when needed by clients or other service
implementers. The result is a straightforward programming model that can
be described (using public metadata) to any client appl ication. The details
of the underlying SOAP messages, the transportation and security -related
information, and so on, can be left to WCF, which performs the necessary
conversions to and from the service contract type system to the XML type
system automatic ally.
5.5 MESSAGES UP FRONT AND CENTER
Using managed interfaces, classes, and methods to model service
operations is straightforward when you are used to remote procedure call
(RPC) -style method signatures, in which passing parameters into a method
and rec eiving return values is the normal form of requesting functionality
from an object or other type of code. For example, programmers using
managed languages such as Visual Basic and C++ COM can apply their
knowledge of the RPC -style approach (whether using o bjects or
interfaces) to the creation of WCF service contracts without experiencing
the problems inherent in RPC -style distributed object systems. Service
orientation provides the benefits of loosely coupled, message -oriented
programming while retaining th e ease and familiarity of the RPC
programming experience.
Many programmers are more comfortable with message -oriented
application programming interfaces, such as message queues like
Microsoft MSMQ, the System.Messaging namespaces in the .NET
Framework, or sending unstructured XML in HTTP requests, to name a
few.
Understanding the Hierarchy of Requirements
A service contract groups the operations; specifies the message exchange
pattern, message types, and data types those messages carry; and indicates
categ ories of run -time behavior an implementation must have to support
the contract (for example, it may require that messages be encrypted and
signed). The service contract itself does not specify precisely how these
requirements are met, only that they must b e. The type of encryption or
the manner in which a message is signed is up to the implementation and
configuration of a compliant service.
Notice the way that the contract requires certain things of the service
contract implementation and the run -time conf iguration to add behavior.
The set of requirements that must be met to expose a service for use builds
on the preceding set of requirements. If a contract makes requirements of
the implementation, an implementation can require yet more of the
configuration and bindings that enable the service to run. Finally, the host
application must also support any requirements that the service
configuration and bindings add. munotes.in

Page 86

Web Services
86 This additive requirement process is important to keep in mind while
designing, implementing, co nfiguring, and hosting a Windows
Communication Foundation (WCF) service application. For example, the
contract can specify that it needs to support a session. If so, then you must
configure the binding to support that contractual requirement, or the
servic e implementation will not work. Or if your service requires
Windows Integrated Authentication and is hosted in Internet Information
Services (IIS), the Web application in which the service resides must have
Windows Integrated Authentication turned on and a nonymous support
turned off.
5.6 DESIGNING SERVICE CONTRACTS
This topic describes what service contracts are, how they are defined, what
operations are available (and the implications for the underlying message
exchanges), what data types are used, and ot her issues that help you design
operations that satisfy the requirements of your scenario.
Creating a Service Contract
Services expose a number of operations. In Windows Communication
Foundation (WCF) applications, define the operations by creating a
metho d and marking it with the OperationContractAttribute attribute.
Then, to create a service contract, group together your operations, either
by declaring them within an interface marked with the Service Contract
Attribute attribute, or by defining them in a class marked with the same
attribute.
Any methods that do not have a OperationContractAttribute attribute are
not service operations and are not exposed by WCF services.
5.7 CLASSES OR INTERFACES
Both classes and interfaces represent a grouping of function ality and,
therefore, both can be used to define a WCF service contract. However, it
is recommended that you use interfaces because they directly model
service contracts. Without an implementation, interfaces do no more than
define a grouping of methods wi th certain signatures. Implement a service
contract interface and you have implemented a WCF service.
All the benefits of managed interfaces apply to service contract interfaces:
 Service contract interfaces can extend any number of other service
contract i nterfaces.
 A single class can implement any number of service contracts by
implementing those service contract interfaces.
 You can modify the implementation of a service contract by changing
the interface implementation, while the service contract remains the
same. munotes.in

Page 87

Basic WCF
Programming
87  You can version your service by implementing the old interface and
the new one. Old clients connect to the original version, while newer
clients can connect to the newer version.
5.8 PARAMETERS AND RETURN VALUES
Each operation has a return value and a parameter, even if these are void.
However, unlike a local method, in which you can pass references to
objects from one object to another, service operations do not pass
references to objects. Instead, they pass copies of the objects.
This is signifi cant because each type used in a parameter or return value
must be serializable; that is, it must be possible to convert an object of that
type into a stream of bytes and from a stream of bytes into an object.
Primitive types are serializable by default, a s are many types in the .NET
Framework.
Data Contracts
Service -oriented applications like Windows Communication Foundation
(WCF) applications are designed to interoperate with the widest possible
number of client applications on both Microsoft and non -Micr osoft
platforms. For the widest possible interoperability, it is recommended that
you mark your types with the Data Contract Attribute and Data Member
Attribute attributes to create a data contract, which is the portion of the
service contract that describ es the data that your service operations
exchange.
Data contracts are opt -in style contracts: No type or data member is
serialized unless you explicitly apply the data contract attribute. Data
contracts are unrelated to the access scope of the managed code : Private
data members can be serialized and sent elsewhere to be accessed
publicly. (For a basic example of a data contract, WCF handles the
definition of the underlying SOAP messages that enable the operation's
functionality as well as the serialization of your data types into and out of
the body of the messages. As long as your data types are serializable, you
do not need to think about the underlying message exchange infrastructure
when designing your operations.
Although the typical WCF application use s the Data Contract
Attribute and Data Member Attribute attributes to create data contracts for
operations, you can use other serialization mechanisms. The standard I
Serializable, Serializable Attribute, and IX ml Serializable mechanisms all
work to handl e the serialization of your data types into the underlying
SOAP messages that carry them from one application to another. You can
employ more serialization strategies if your data types require special
support. munotes.in

Page 88

Web Services
88 Mapping Parameters and Return Values to Mess age Exchanges
Service operations are supported by an underlying exchange of SOAP
messages that transfer application data back and forth, in addition to the
data required by the application to support certain standard security,
transaction, and session -related features. Because this is the case, the
signature of a service operation dictates a certain underlying message
exchange pattern (MEP) that can support the data transfer and the features
an operation requires.
Request/ Reply
A request/reply pattern is one in which a request sender (a client
application) receives a reply with which the request is correlated. This is
the default MEP because it supports an operation in which one or more
parameters are passed to the operation and a return value is passed ba ck to
the caller. For example, the following C# code example shows a basic
service operation that takes one string and returns a string.
C#Copy
[OperationContractAttribute ]
string Hello (string greeting );
The following is the equivalent Visual Basic code .
VBCopy

Function Hello (ByVal greeting AsString ) AsString
This operation signature dictates the form of underlying message
exchange. If no correlation existed, WCF cannot determine for which
operation the return value is int ended.
Note that unless you specify a different underlying message pattern, even
service operations that return void (Nothing in Visual Basic) are
request/reply message exchanges. The result for your operation is that
unless a client invokes the operation asynchronously, the client stops
processing until the return message is received, even though that message
is empty in the normal case. The following C# code example shows an
operation that does not return until the client has received an empty
message in response.
C#Copy
[OperationContractAttribute ]
voidHello (string greeting );
The following is the equivalent Visual Basic code.
VBCopy munotes.in

Page 89

Basic WCF
Programming
89
Sub Hello (ByVal greeting AsString )
The preceding example can slow client performance a nd responsiveness if
the operation takes a long time to perform, but there are advantages to
request/reply operations even when they return void. The most obvious
one is that SOAP faults can be returned in the response message, which
indicates that some se rvice -related error condition has occurred, whether
in communication or processing. SOAP faults that are specified in a
service contract are passed to the client application as a Fault
Exception object, where the type parameter is the type specifi ed
in the service contract. This makes notifying clients about error conditions
in WCF services easy.
One -way
If the client of a WCF service application should not wait for the operation
to complete and does not process SOAP faults, the operation can spec ify a
one-way message pattern. A one -way operation is one in which a client
invokes an operation and continues processing after WCF writes the
message to the network. Typically this means that unless the data being
sent in the outbound message is extremely large the client continues
running almost immediately (unless there is an error sending the data).
This type of message exchange pattern supports event -like behavior from
a client to a service application.
A message exchange in which one message is sent a nd none are received
cannot support a service operation that specifies a return value other
than void; in this case an InvalidOperationException exception is thrown.
No return message also means that there can be no SOAP fault returned to
indicate any erro rs in processing or communication. (Communicating
error information when operations are one -way operations requires a
duplex message exchange pattern.)
To specify a one -way message exchange for an operation that returns void,
set the IsOneWay property to true, as in the following C# code example.
C#Copy
[OperationContractAttribute(IsOneWay=true) ]
voidHello (string greeting );
The following is the equivalent Visual Basic code.
VBCopy

Sub Hello (ByVal greeting AsString ) munotes.in

Page 90

Web Services
90 This method is identical to the preceding request/reply example, but
setting the IsOneWay property to true means that although the method is
identical, the service operation does not send a return message and clients
return immediately once the outbound message has been handed to the
channel layer.
Duplex
A duplex pattern is characterized by the ability of both the service and the
client to send messages to each other independently whether using one -
way or request/reply messaging. This form of two-way communication is
useful for services that must communicate directly to the client or for
providing an asynchronous experience to either side of a message
exchange, including event -like behavior.
The duplex pattern is slightly more complex than the request/reply or one -
way patterns because of the additional mechanism for communicating
with the client.
To design a duplex contract, you must also design a callback contract and
assign the type of that callback contract to the CallbackContract property
of the ServiceContractAttribute attribute that marks your service contract.
To implement a duplex pattern, you must create a second interface that
contains the method declarations that are called on the client.
Caution
When a service receives a duplex messa ge, it looks at
the ReplyTo element in that incoming message to determine where to send
the reply. If the channel that is used to receive the message is not secured,
then an untrusted client could send a malicious message with a target
machine's ReplyTo , leading to a denial of service (DOS) of that target
machine.
Out and Ref Parameters
In most cases, you can use in parameters ( ByVal in Visual Basic)
and out and ref parameters ( ByRef in Visual Basic). Because
both out and ref parameters indicate that data i s returned from an
operation, an operation signature such as the following specifies that a
request/ reply operation is required even though the operation signature
returns void.
C#Copy
[ServiceContractAttribute ]
publicinterface IMyContract
{
[Operati onContractAttribute ] munotes.in

Page 91

Basic WCF
Programming
91 publicvoid PopulateData (refCustomDataType data);
}
The following is the equivalent Visual Basic code.
VBCopy
_
PublicInterface IMyContract
_
PublicSub PopulateData( ByRe f data AsCustomDataType)
EndInterface
The only exceptions are those cases in which your signature has a
particular structure. For example, you can use the Net Msmq
Binding binding to communicate with clients only if the method used to
declare an operatio n returns void; there can be no output value, whether it
is a return value, ref, or out parameter.
In addition, using out or ref parameters requires that the operation have an
underlying response message to carry back the modified object. If your
operation is a one -way operation, an InvalidOperationException exception
is thrown at run time.
5.9 SPECIFY MESSAGE PROTECTION LEVEL ON
THE CONTRACT
When designing your contract, you must also decide the message
protection level of services that implement your co ntract. This is necessary
only if message security is applied to the binding in the contract's
endpoint. If the binding has security turned off (that is, if the system -
provided binding sets the System.ServiceModel.SecurityMode to the
value SecurityMode.Non e) then you do not have to decide on the message
protection level for the contract. In most cases, system -provided bindings
with message -level security applied provide a sufficient protection level
and you do not have to consider the protection level for e ach operation or
for each message.
The protection level is a value that specifies whether the messages (or
message parts) that support a service are signed, signed and encrypted, or
sent without signatures or encryption. The protection level can be set at
various scopes: At the service level, for a particular operation, for a
message within that operation, or a message part. Values set at one scope
become the default value for smaller scopes unless explicitly overridden.
If a binding configuration cannot pr ovide the required minimum
protection level for the contract, an exception is thrown. And when no
protection level values are explicitly set on the contract, the binding munotes.in

Page 92

Web Services
92 configuration controls the protection level for all messages if the binding
has messag e security. This is the default behavior.
Important
Deciding whether to explicitly set various scopes of a contract to less than
the full protection level of ProtectionLevel.EncryptAndSign is generally
a decision that trades some degree of security for inc reased performance.
In these cases, your decisions must revolve around your operations and the
value of the data they exchange.
C#Copy
[ServiceContract ]
publicinterface ISampleService
{
[OperationContractAttribute ]
public string GetString ();

[OperationContractAttribute ]
public intGetInt ();
}
The following is the equivalent Visual Basic code.
VBCopy
_
PublicInterface ISampleService
_
PublicFunction GetString() AsString

_
PublicFunction GetData() AsInteger
EndInterface
When interacting with an ISampleService implementation in an endpoint
with a default WSHttp Binding (the default System. Service Model.
Security Mode, which is Message), all messages are en crypted and signed
because this is the default protection level. However, when an I Sample
Service service is used with a default Basic Http Binding (the munotes.in

Page 93

Basic WCF
Programming
93 default Security Mode, which is None), all messages are sent as text
because there is no security for this binding and so the protection level is
ignored (that is, the messages are neither encrypted nor signed). If
the SecurityMode was changed to Message, then these messages would be
encrypted and signed (because that would now be the binding's default
protection level).
If you want to explicitly specify or adjust the protection requirements for
your contract, set the Protection Level property (or any of
the ProtectionLevel properties at a smaller scope) to the level your service
contract requires. In this case, using an explicit setting requires the binding
to support that setting at a minimum for the scope used. For example, the
following code example specifies one Protection Level value explicitly,
for the Get Guid operation.
C#Copy
[ServiceContract ]
publicinterface IExplicitProtectionLevelSampleService
{
[OperationContractAttribute ]
public string GetString ();

[OperationContractAttribute(ProtectionLevel=ProtectionLevel.None) ]
public intGetInt ();

[OperationContractAttribute(ProtectionLevel=Prot ectionLevel.EncryptAn
dSign) ]
public intGetGuid ();
}
The following is the equivalent Visual Basic code.
VBCopy
_
PublicInterface IExplicitProtectionLevelSampleService
_
PublicFunction GetString() AsString
EndFuncti on
munotes.in

Page 94

Web Services
94 _
PublicFunction GetInt() AsInteger
EndFunction
ProtectionLevel.EncryptAndSign)> _
PublicFunction GetGuid() AsInteger
EndFunction
EndInterface
A service that implements this I Explicit Protection Level Sample
Service contract and has an endpoint that uses the default WS Http
Binding (the default System. Service Model. Security Mode, which
is Message) has the following behavior:
 The GetString operation messages are encrypted and signed.
 The GetInt operation messages are sent as unencrypted and unsigned
(that is, plain) text.
 The GetGuid operation System.Guid is returned in a message that is
encrypted and signed.
Other Operation Signature Requirements
Some application features require a particular kind of operation signature.
For example, the NetMsmqBinding binding supports durable services and
clients, in which an application can restart in the middle of communication
and pick up where it left off without missing any messages.
Another example is the use of Stream types in operations. Because
the Stream parameter includes the entire message body, if an input or an
output (that is, ref parameter, out parameter, or return value) is of
type Stream, then it must be the only input or output specified in your
operation. In addition, the parameter or return type must be
either Stream, System.ServiceModel.Channels.Messag e,
or System.Xml.Serialization.IXmlSerializable.
Names, Namespaces, and Obfuscation
The names and namespaces of the .NET types in the definition of
contracts and operations are significant when contracts are converted into
WSDL and when contract messages are created and sent. Therefore, it is
strongly recommended that service contract names and namespaces are
explicitly set using the Name and Namespace properties of all supporting
contract attributes such as the Service Contract Attribute, Operation
Contra ct Attribute, Data Contract Attribute, Data Member Attribute, and
other contract attributes. munotes.in

Page 95

Basic WCF
Programming
95 One result of this is that if the names and namespaces are not explicitly
set, the use of IL obfuscation on the assembly alters the contract type
names and namespa ces and results in modified WSDL and wire exchanges
that typically fail. If you do not set the contract names and namespaces
explicitly but do intend to use obfuscation, use the Obfuscation
Attribute and Obfuscate Assembly Attribute attributes to prevent t he
modification of the contract type names and name spaces.
5.10 CONFIGURING WCF SERVICES
Once you have designed and implemented your service contract, you are
ready to configure your service. This is where you define and customize
how your service is expo sed to clients, including specifying the address
where it can be found, the transport and message encoding it uses to send
and receive messages, and the type of security it requires.
Configuration as used here includes all the ways, imperatively in code or
by using a configuration file, in which you can define and customize the
various aspects of a service, such as specifying its endpoint addresses, the
transports used, and its security schemes. In practice, writing configuration
is a major part of programm ing WCF applications.
Simplified Configuration Starting with . NET Framework 4, WCF comes
with a new default configuration model that simplifies WCF configuration
requirements. If you do not provide any WCF configuration for a
particular service, the runtim e automatically configures your service with
default endpoints, bindings, and behaviors.
Configuring Services Using Configuration Files A Windows
Communication Foundation (WCF) service is configurable using the .NET
Framework configuration technology. Most commonly, XML elements
are added to the Web.config file for an Internet Information Services (IIS)
site that hosts a WCF service. The elements allow you to change details,
such as the endpoint addresses (the actual addresses used to communicate
with the s ervice) on a machine -by-machine basis.
Bindings In addition, WCF includes several system -provided common
configurations in the form of bindings that allow you to quickly select the
most basic features for how a client and service communicate, such as the
transports, security, and message encodings used.
Endpoints All communication with a WCF service occurs through
the endpoints of the service. Endpoints contain the contract, the
configuration information that is specified in the bindings, and the
addresses that indicate where to find the service or where to obtain
information about the service.
Securing Services Using WCF and existing security mechanisms, you can
implement confidentiality, integrity, authentication, and authorization into
any service. You ca n also audit for security successes and failures.
munotes.in

Page 96

Web Services
96 5.11 SUMMARY
To understand the concept of WAS hosting, we need to comprehend how
a system is configured and how a service contract is created, enabling
different binding to the hosted service.
A WCF servic e boasts of a robust security system with two security modes
or levels so that only an intended client can access the services. The
security threats that are common in a distributed transaction are moderated
to a large extent by WCF.
WCF has a layered arch itecture that offers ample support for developing
various distributed applications.
5.12 QUESTIONS
1. Explain WCF features supported by the .NET Framework Client
Profile
2. Explain basics of WCF programming
3. Explain service contracts
4. Explain Parameters and return values
5. How to configure WCF services.
5.13 REFERENCE
 https://learn.microsoft.com/en -us/dotnet/framework/wcf/wcf -and-net-
framework -client -profile

 https://www.tutorialspoint.com/wcf/wcf_creating_service.htm

 https://www.tutorialspoint.com/wcf/wcf_versus_web _service.htm









munotes.in

Page 97

97 6
WEB SERVICE QOS
Unit Structure :
6.0 Introduction
6.1 Web Services Performance
6.2 Proactive Web Service QoS
6.3 Caching Web Services
6.4 Service Quality Requirements
6.5 Why Is QoS Important for Web Services?
6.6 Web Services Performance -Demystifying
6.7 Web Services Performance -Limitations
6.8 Web Services Performance -Best Practices and Solutions
6.9 Performance Monitoring
6.10 Summary
6.11 Questions
6.12 Reference
6.0 INTRODUCTION
With the proliferation of Web services as a business solution to enterpr ise
application integration, the quality of service (QoS) offered by Web
services is becoming the utmost priority for service provider and their
partners. Due to the dynamic and unpredictable nature of the Web,
providing the acceptable QoS is really a chal lenging task. In addition to
this, the different applications that are collaborating for Web service
interaction with different requirements will compete for network
resources. The preceding factors will force service providers to understand
and achieve We b services QoS. Also, a better QoS for a Web service will
bring a competitive advantage over others by being a unique selling point
for a service provider.
The Web services QoS requirement mainly refers to the quality, both
functional as well as non -functi onal, aspect of a Web service. This
includes performance, reliability, integrity, accessibility, availability,
interoperability, and security . In the first part of this article, we covered
each of the above QoS aspects from a broad perspective. Now, in eac h
coming article we will look into each of the QoS in detail and will try to
come up with solutions and explore best practices to be followed. In this munotes.in

Page 98

Web Services
98 article, we are trying to demystify the “performance” aspect of Web
Services.
6.1 WEB SERVICES PERFORMANC E
The Web services -QoS stack we proposed is shown in the following fig

6.2 PROACTIVE WEB SERVICE QOS
Service providers can proactively provide high QoS to the service
requestors by using  Caching  Load balancing  both approaches can be
done in web ser ver level and web application level
6.3 CACHING WEB SERVICES
munotes.in

Page 99

Web Service QoS
99 Caching refers to storing the server response in the client itself  A client
not make a server request for the same resource again and again. 
Because a server response should have informatio n about how caching is
to be done  So that a client caches the response for a time -period or never
caches the server response  If the data of web services does not change
frequently, properly caching could boost the performance
Load Balancing
Prioritize various types of traffic and ensure that each request is treated
appropriately to the business value  A Web service provider can perform
capacity modeling to create a top -down model of requesttraffic, current
capacity utilization, and the resulting QoS  Also categorize Web service
traffic by the volume of traffic, traffic for different application service
categories, and traffic from different sources.
Load Balancing  Help in understanding the capacity that will be required
to provide good QoS  for a vo lume of service demand and for future
planning E.g. capacity type of load balancing web application servers/Web
servers the number of servers required for setting up a clustered server
farm
Service providers can provide differentiated servicing by using th e
capacity model to…..  determine the capacity needed for different
customers and service types  ensure appropriate QoS levels for different
applications and customers  For example; A multimedia Web Service
might require good throughput, BUT a banking W eb Service might
require security and transactional QoS.
6.4 SERVICE QUALITY REQUIREMENTS
The major requirements for supporting QoS in Web services are as
follows:  Performance  Availability  Accessibility  Integrity 
Reliability  Interoperability  Security 20  The other web service QoS
characteristics  Execution Time  Cost/Price  Transaction (ACID) 
Reputation  Etc
QoS: Performance
Demystifying
Performance is measured by throughput and latency. Performance can also
be determined by response t ime to guarantee maximum time required to
complete a service request
Limitations
The overall performance of WS depends on application logic, network,
and underlying messaging and transport protocols, such as SOAP and
HTTP. The SOAP protocol uses a multi -step process to complete a
communication cycle. This whole process is a timeconsuming one, which munotes.in

Page 100

Web Services
100 requires various levels of XML parsing and XML validation and hence
hits the performance of the Web Service. B
Best Practices
optimize the XML processing s
steps 1. use of efficient and lightweight parsers.
2. Efficient use of XML validation in production mode.
3. Use of compressed XML for sending the messages over network.
4. Web Service Caching 5. Use of simple data types in SOAP messages as
far as possibl e.
QoS: Availability
Demystifying
Availability defines whether the Web Service is ready for immediate
consumption. Associated with availability is Time -toRepair (TTR). TTR
represents the time it takes to repair the Web Service.
Limitations
Building fault -tolerant systems for highly available Web Services is
expensive. As companies roll out Web Services, the ability to manage this
diverse, dynamic, distributed environment will become critical. Questions
such as the following arise: Has one of my key server s become
unavailable? Is a system being overly burdened? Why are requests taking
so long?
Best Practices
Web Service Management Web Service Clustering
QoS: Accessiblity
Demystifying
Accessibility defines whether the Web Service is capable of serving the
client's request. High accessibility of Web Services can be achieved by
building highly scalable systems
Limitations
Building scalable systems are expensive, and this may cause smaller
companies to defer this requirement. Also, this becomes an infrastruct ure
issue for companies that deploy Web Services within their enterprise.
Best Practices S
service pooling
Load balancing (Scalability) munotes.in

Page 101

Web Service QoS
101 QoS: Integrity
Demystifying
Integrity is the degree to which a system or component prevents
unauthorized access to, or modification of, computer programs or data.
Limitations
Data Integrity is important for any object's proper functioning and must be
assured or it could corrupt a larger program and generate a very difficult to
trace error. Web Services transactions tend to be asynchronous and long
running in nature. Transaction integrity is just one of several QoS
elements, including security and process orchestration, which are missing
from the first incarnations of Web Services standards of SOAP, UDDI,
and WSDL.
Best Practices
1. Emerging standards in the business process management and
transactions will help to achieve the desired QoS.
2. Adopting standards such as BPEL4WS, WS -Coordination,
WSTransaction, and BTP would benefit service providers.
QoS: Reliability
Demystify ing
Reliability is the overall measure of a Web Service to maintain its service
quality. The number of failures per day, week, month, or year represents
an overall measure of reliability for a Web Service. Reliability also refers
to the assured and ordere d delivery for messages being sent and received
by service requestors and service providers.
Limitations
The Web Services currently rely on transport protocols such as HTTP,
which are inherently stateless and follow a best -effort delivery
mechanism. It do es not guarantee whether the message will be delivered to
the destination.
Best Practices
The above problem rising due to the use of unreliable protocols can be
solved using the following techniques:
1. Use of asynchronous message queues.
2. Adoption of new reliable transport protocols (such as HTTPR, REST,
and BEEP).

munotes.in

Page 102

Web Services
102 QoS: Interoperability
Demystifying
The fundamental goal of interoperability in Web Services is to cross the
lines between the development environments used to implement services
so that developers using those services don't have to think about which
programming language or operating system the services are hosted on.
Limitations
Most of the Web Services specifications are defined under standards
bodies. As these activities are under way, there seems to be a delay in the
implementations. Vendors partly implement the specification in their
products due to the competitive nature of this market. This results in poor
interoperability.
Best Practices
1. Key to enabling seamless Web Services inter operability is the ability
of one Web Services framework to consume the WSDL documents
generated by other frameworks.
2. Web Services -Interoperability (WS -I) Profiles. The Basic Profile
defines how a selected set of specified Web Services technologies,
such a s messaging and discovery, should be used together in an
interoperable manner
QoS: Security
Demystifying
Security for Web Services refers to authentication mechanisms, messages
encryption and access control, confidentiality, nonrepudiation and
resilience to denial -of-service attacks.
Limitations
SOAP is a de -facto messaging standard for Web Services; inherently, it
does not support many security features. Some of the Web Services -
enabled applications also require role -based security features, which
expos e different functionalities, depending on user credentials.
Best Practices .
The following measures can be used while architecting the secure Web
Services:
1. Use of XML Encryption.
2. Use of XML Key Management Specification. 3. Use of Private
WANs, Web Serv ice Network, and VPNs.
3. Use of Private WANs, Web Service Network, and VPNs. munotes.in

Page 103

Web Service QoS
103 4. P3P (Platform for Privacy Preferences) is an emerging standard for
specifying privacy preferences for a user while using Web Services.
5. Use of security assertions.
6.5 WHY IS QOS IM PORTANT FOR WEB SERVICES ?
Web services allow individual components of business logic to be
published as building blocks to larger applications and services. Since
each Web service is only a small segment of a larger application and not
an entire large, mon olithic application, there will be a significant number
of competitive implementations for each Web service. Quality of service
will be one of the most important differentiators between all of these
competitive solutions.
Quality of quality of serviceservi ce encapsulates not only implementation
details that affect metrics such as performance, but also deployment
issues. For example, an application that is deployed on an application
server can automatically scale and create additional ...
As you can see, the performance block (highlighted in purple) in the figure
spans across almost all of the Web service layers on the left. It requires
tuning at all layers to get a desired level of performance from Web service.
Let us first briefly analyze this quality aspec t, for demystifying and to see
its limitations, and then work in depth on some of the optimal solutions.
6.6 WEB SERVICES PERFORMANCE -DEMYSTIFYING
The performance of a Web Service is measured in terms of throughput,
latency, execution time, and transaction time. Throughput represents the
number of Web service requests served at a given time period. Latency is
the round -trip time between sending a request and receiving the
response. Execution time is the time taken by a Web Service to process its
sequence of activities. Transaction time represents the period of time that
passes while the Web Service is completing one complete transaction.
Higher throughput, lower latency, lower execution and transaction times
represent good performing Web Services.
6.7 WEB SE RVICES PERFORMANCE -LIMITATIONS
The overall performance of a Web service depends on application logic,
network, and most importantly on underlying messaging and transport
protocols such as the SOAP and HTTP it uses. The SOAP protocol is still
maturing and h arbors a lot of performance and scalability problems. The
SOAP protocol uses a multi -step process to complete a communication
cycle.
The SOAP request begins with the business logic of your application
learning the method and parameter to call from a Web Se rvices
Description Language (WSDL) document. This whole process is time munotes.in

Page 104

Web Services
104 consuming; it requires various levels of XML parsing and XML validation
and hence hits the performance of the Web service.
Apart from these factors, the performance of a Web service be comes
crucial if it uses the synchronous one where a consuming application is
blocked for the time it gets a response from the Web service.
6.8 WEB SERVICES PERFORMANCE -BEST
PRACTICES AND SOLUTIONS
Analyzing the above situations, following are some of the useful practices
and solutions which we should have in mind while developing and
exposing it to outside world. I am dealing with them layer by layer of the
Web service stack.
a. At the Data Layer: At data layer of a Web service stack, the Web
service is o nly sending/receiving XML messages through the network.
Some of the best practices to be followed to achieve the same are listed
below:
1. Use of compressed XML for sending the messages over network:
SOAP/XML messages are generally bigger in size than normal
GET/POST calls, so we should try to compress the message if the
network latency is bigger than CPU overhead for compression. Lots of
XML compression tools are available from different vendors such as
Oracle XDK and there are many open source tools also the re to fit the
budget.
2. Use of simple data types in SOAP messages as far as possible reduces
complexity to great extent. This reduces the processing time and
increases maintainability; enhancements are easy to do.
b. At the Logical Layer: At the logical laye r, Web service mainly deals
in processing SOAP/XML messages. Being XML intensive at this layer,
we should try to optimize XML processing steps. Some of the best
practices to be followed to achieve the same are listed below:
1. Use of efficient & lightweight p arsers: There are many parsers
available on the market, each vying for its performance. But, to get
performance we should first analyze our application and its
requirement. If the application requires big XML files to be
exchanged, a SAX parser would be th e best over a DOM parser. A
DOM parser actually loads the whole document in memory and thus
utilizes a considerable amount of the memory and processor. Instead, a
SAX parser is event based, is faster, and does not consume much
memory.
Even better, if we k now about XML messages that are coming (which
is generally the case) from a client/application, we should try to use
pull parsers instead of push ones. Using a pull parser will load only
that part of XML, which is required by the application that time. munotes.in

Page 105

Web Service QoS
105 2. Efficient use of XML validation in production mode.
XML validation should be kept to minimum during the production
mode because it generally slows down the parser. XML validation can
be turned OFF for trusted parties after authorization has been done.
And, in stead of performing XML validation at the parser level, some
critical validations, depending on application requirements, can be
done at the application level.
3. Web Service Caching: One must cache request results wherever
possible in their Web service. Even the WSDL can be cached at the
client side to minimize the multiple requests.
b. At the Presentation Layer: At the presentation layer, a Web service
deals mainly with how to present the responses in an effective manner.
Depending on the client, one can apply the following strategies:
1. Repeated SOAP -client calls to access server state can choke a network
and degrade the server performance. Cache data on the client
whenever possible to avoid requests to the server.
2. Ensure the client data remains up to date by usi ng a call to a service,
which blocks until data is changed.
6.9 PERFORMANCE MONITORING
Tracing the performance of a Web service in real time gives lot of hints.
We can actually identify the bottlenecks in the execution of a Web service.
Once we know the pr oblems, we can actually find solutions to it by
applying best practices as mentioned above or by using better hardware.
There are lot of tools and methodologies available for monitoring the
performance.
6.10 SUMMARY
 QoS is an important requirement of busin ess-to-business transactions
necessary element in Web services.

 The various QoS properties need to be addressed in the
implementation of Web service applications.

 The properties become even more complex when you add the need for
transactional features to Web services.

 Some of the limitations of protocols such as HTTP and SOAP may
hinder QoS implementation, but there are a number of ways to provide
proactive QoS in Web services.




munotes.in

Page 106

Web Services
106 6.11 QUESTIONS
1. Explain Qos ?
2. Why is Qos important for web services ?
3. Explain web service performance and best practices ?
4. Explain Caching Web Services ?
6.12 REFERENCE
 https://www.oreilly.com/library/view/de veloping -enterprise -
web/0131401602/0131401602_ch09lev1sec2.html

 https://www.developer.com/web -services /quality -of-service -for-web-
services -demystification -limitations -and-best-practices -for-
performance/

 https://myweb.cmu.ac.th/choosak_s/954376/Chapter%205/Lecture5 -
QoS%20for%20Web%20Service.pdf





munotes.in