You are designing a Windows client application by using Microsoft NET Framework 4 and Microsoft Visual Studio 2010. The business logic layer of the application is implemented by using Windows Communication Foundation (WCF). You write the following code segment in the middle tier:
<ServiceContractO> —
Public Interface lWcf Service
<OperationContractO> —
<FaultContract(GetType(ApplicationException))> —
Sub ProcessData(ByVal d As Data)
End Interface
The Process Data service method is a long-running operation. You need to ensure that the application meets the following requirements:
"Users can continue to use the user interface while the Process Data service method is running.
"Message delivery is reliable.
What should you use?
A. A Session full One-Way operation on Process Data with a proxy-based synchronous class invocation
B. A Session full Request-Reply operation on Process Data with a proxy-based asynchronous invocation
C. A Session less One-Way operation of Process Data with a proxy-based synchronous class invocation
D. A Session less Request-Reply operation on Process Data with a proxy-based asynchronous invocation
Correct Answer: D
Explanation/Reference:
Because you want to continue to use the interface, the Session Full is not a option (throw A,B) becuase you want a reliable delivery you use request/reply to catch possible exceptions. this work because the invokation was async. See under… local memory
Reference (from http://msdn.microsoft.com/en-us/library/ms733070.aspx) ONE WAY
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 specify 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 and 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 errors 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.
[OperationContractAttribute(IsOneWay=true)]
void Hello(string greeting);
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 back to the caller. For example, the following C# code example shows a basic service operation that takes one string and returns a string.
[OperationContractAttribute]
string Hello(string greeting);
This operation signature dictates the form of underlying message exchange. If no correlation existed, WCF cannot determine for which operation the return value is intended.
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.
[OperationContractAttribute]
void Hello(string greeting);
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.
For an example of creating a service, and a client that accesses that service, see How to: Create a Duplex Contract and How to: Access Services with a Duplex Contract. For a working sample, see Duplex. For more information about issues using duplex contracts, see Duplex Services.
