Service Implementation C# Help

The implementation of the service can be marked with the attribute (ServiceBehavior), as shown with the class Room Reservation Service:

The attribute [ServiceBehavior] is used to describe behavior as is offered by WC services to intercept the code for required functionality, as shown in the following table.

To demonstrate a service behavior, the interface IStateService defines a service contract with two operations to set’and get state, With a stateful service contract, a session is needed. That’s why the
SessionMode property of the service contract is set to SessionMode, Required. The service contract also defines methods to initiate and close the session by applying the Is Initiating and
Is Terminating properties to the operation contract:

The service contract is implemented by the class State Service. The service implementation defines the Instance Context Mode. Per Session to keep state with the instance:

Now the binding to the address and protocol must be defined. Here, the basic Http Binding is assigned to the endpoint of the service:

If you start the service host with the defined configuration, an exception of type InvalidOperationException is thrown. The error message with the exception gives this error message: “Contract requires Session, but Binding’ Basic Http Binding’ doesn’t support it or isn’t configured properly to support it.”

Not all bindings support all services, Because the service contract requires a session with the attribute [ServiceContract] (SessionModeSessionMode Required). the host fails because the configured binding does not support sessions.

As soon as you change the configuration to a binding that supports sessions (for example, the wsHttpBinding), the server starts successfully:

Now a client application can be created. In the previous example, the client application was created by adding a service reference. Instead of adding a service reference, you can directly access the assembly containing the contract interface, and use the Channel Factory <TChannel> class to instantiate the . channel to connect to the service.

The constructor of the class Channel Factory <TChannel> accepts the binding configuration and endpoint address. The binding must be compatible with the binding defined with the service host, and the address defined with the End point Address class references the URI of the running service.

The CreateChannel() method creates a channel to connect to the service. Then, you can invoke methods of the service, and you can see that the service instance holds state until the Close() method is
invoked that has the Is Tenninating operation behavior assigned:

With the implementation of the service, you can apply the properties in the following table to the service methods, with the attribute [OperationBehavior].

Error Handling

By default, the detailed exception information that occurs in the service is not returned to the client application. The reason for this behavior is security. You wouldn’t want to give detailed exception
information to a third party using your service. Instead, the exception should be logged on the service (which you can do with tracing and event logging), and an error with useful information should be returned to the caller.

You can return SOAP faults by throwing a Fault Exception. Throwing a Fault Exception creates an untyped SOAP fault. The preferred way of returning errors is to generate a strongly typed SOAP fault.

The information that should be passed with a strongly typed SOAP fault is defined with a data contract
as shown with the State Fault class:

The type of the SOAP fault must be defined using the Fault Contract Attribute with the operation contract:

With the implementation, a Fault Exception <TDetail> is thrown. With the constructor you can assign a new TDetail object, which is a StateFault in the example. In addition, error information within a Fault Reason can be assigned to the constructor. FaultReason supports error information in multiple languages.

With the client application, exceptions of type FaultException <StateFault> can be caught. The reason for the exception is defined by the Message property; the StateFaul t is accessed with the Detail property:

In addition to catching the strongly typed SOAP faults, the client application can also catch exceptions of the base class of FaultException <Detail>: FaultException and CommunicationException. By catching Communication Exception,you can also catch other exceptions related to the WCF communication.

Posted on October 31, 2015 in Windows Communication Foundation

Share the Story

Back to Top
Share This