WCF (Windows Communication Foundation) Interview Questions And Answers

Suppose the service we consumed is not working in the client
application. we want to know the real cause of the problem.
How we can know the error? For this we are having Fault
Contract. Fault Contract provides documented view for error
occurred in the service to client. This helps us to easy
identity, what error has occurred.

Windows Process Activation Server (WAS) supports the
communication protocols such as HTTP, TCP, Named Pipes and
MSMQ while IIS supports only HTTP. WAS is available with
Windows Server 2008 only. If the server is Server 2008 then
the better option to deploy WCF service is through WAS. If
the deployment server is Server 2003, the only possible way
to deploy the application with protocols other than HTTP is
using self hosting (using a Windows Application or a Windows
Service and if for a demo purpose can use Console
application also). So WAS is a gift with Vista and Server
2008.

Windows Process Activation Server (WAS) is a new server
available with Vista and Windows Server 2008. The new server
is capable of deploying WCF applications which is driven
through different communication protocols such as TCP, Named
Pipes, MSMQ etc together with HTTP. IIS can host WCF
services that communicates only using HTTP while WAS
supports all of the above given protocols. So for an
application that communicates internally using TCP can be
deployed in HTTP by adding a few changes in the
configuration. So the same applicaiton communicates with TCP
and HTTP under a host.

Using the "Name" we can achieve operational overloading
interface IInterfaceName
{
[OperationContract (Name = "aliasName1")]
int MethodName (int param1, int param2);

[OperationContract (Name = "aliasName2")]
double MethodName (double param1, double param1);
}

For authentication:-
Say windows,

set the authentication mode as follows
<authentication mode="Windows" />

then in the end point set bind the configuration as below.

<endpoint address="basic" binding="basicHttpBinding"
contract="WcfServiceLibrary1.IService1"
bindingConfiguration="BND" />

<bindings>
<basicHttpBinding>
<binding name="BND">
<security mode ="Transport">
<transport clientCredentialType ="Windows"/>
</security>
</binding>
</basicHttpBinding>
</bindings>

For to USE IIS,make sure that IIS Annonymous authentication
is DISABLED.

there are 3 ways host wcf service
1) Self Hosting in managed applications
2) Windows Service
3) IIS
4) WIndows Process Actiation Service (WAS)

Service Contract:
Service contracts describe the operation that service can
provide. For Eg, a Service provide to know the temperature
of the city based on the zip code, this service is called as
Service contract. It will be created using Service and
Operational Contract attribute.

Data Contract:

Data contract describes the custom data type which is
exposed to the client. This defines the data types, that are
passed to and from service. Data types like int, string are
identified by the client because it is already mention in
XML schema definition language document, but custom created
class or data types cannot be identified by the client e.g.
Employee data type. By using DataContract we can make client
to be aware of Employee data type that are returning or
passing parameter to the method.

IIS-hosted WCF services can make use of HTTP transport
security (for example, HTTPS and HTTP authentication
schemes such as Basic, Digest, and Windows Integrated
Authentication) as long as the IIS virtual directory that
contains the service supports those settings. The HTTP
Transport Security settings on a hosted endpoint’s binding
must match the transport security settings on the IIS
virtual directory that contains it

IIS Addressing Considerations

When hosting in IIS, you don’t have to worry about creating
or managing the ServiceHost instance. IIS takes care of
this for you behind the scenes. You simply map a .svc
endpoint to your service class, configure the service
endpoints and behaviors in web.config, and let Windows
Communication Foundation manage the process of creating and
configuring the ServiceHost instance at runtime.

In this hosting scenario, the base HTTP address is
determined by the IIS virtual directory housing the service
along with the name of the .svc file. You, as the
developer, really have nothing to say about the base
address since it’s fully controlled by the IIS addressing
scheme.

As a result, Windows Communication Foundation happily
ignores any base addresses you may specify in web.config in
this scenario. If you want to change the base address for
your endpoints, you’ll need to move the service to a
different IIS virtual directory.

Not only does IIS control the base address, it forces all
of your endpoints to actually use the same base address
(unlike self-hosting). This means that if you do specify an
absolute address for a particular endpoint, it must start
with the base address corresponding to the virtual
directory or you’ll get an exception. As a result, it
really only makes sense to use relative addresses when
hosting in IIS.

Windows Activation service.(WAS) .WAS built in top of IIS
which comes from Windows Wista OS

MSMQ uses paths and format names to identify a queue. Paths
specify a host name and a QueueName. Optionally, there can
be a Private$ between the host name and the QueueName to
indicate a private queue that is not published in the
Active Directory directory service.

Path names are mapped to “FormatNames” to determine
additional aspects of the address, including routing and
queue manager transfer protocol. The Queue Manager supports
two transfer protocols: native MSMQ protocol and SOAP
Reliable Messaging Protocol (SRMP).

The addressing of a queue in WCF is based on the following
pattern:

net.msmq: // <host-name> / [private/] <queue-name>

where:

•<host-name> is the name of the machine that hosts the
Target Queue.


•[private] is optional. It is used when addressing a Target
Queue that is a private queue.

No. Because public queues are created in the domain
controller, similar to any other public resources like
computer, user on the network.
you can create public queue, provided you are in the domain.

Correct format is : "net.msmq://MyHost/private/MyQueue"
where I've assumed the following :

- MyHost is your machine name
- MyQueue is name of your private MSMQ name

Only problem in your format was the '$' sign. Everything
else was good

The MsmqIntegrationBinding is intended for use with
existing, already-written native MSMQ applications. The
NetMsmqBinding is a lot better to use but only works if you
have WCF on both ends of the queue. Therefore, one of these
is always the clear choice for your queuing scenario
depending on what's on the other side. There's nothing
stopping you from hosting separate endpoints for each of
these bindings at the same time if you need communication
with both native and WCF clients. However, the two
endpoints need to be kept with separate queues because the
messages are not compatible.