Keep it Simple

// practice, the distance between dream and achievement

Tag: WCF (page 1 of 8)

WCF – Message security

Message level security encrypts request / response messages using WS-Security specifications. It encloses security credentials and claims with every message. Each message either signed or encrypted.

Message Security provides end-to-end channel security and is independent of transport protocol. In short mutual authentication and message security are delivered at the message level.

Continue reading

WCF – Transport security

The default client credential type for NetTcpBinding is Windows Authentication. For Windows Authentication to work both client and server must be in the same domain, or mutually trusting domains (which in your case you do not have).

If both client and server were on the same domain, WCF would handle the mechanics of Windows Authentication “behind the scenes”. And when both client and server are on the same machine they are effectively within the same domain, so Windows can use its own mechanisms to handle the encryption and decryption. It will only do this within mutually trusting domains, though.

Continue reading

WCF – Instance Management

Session is a well understood term for all of us and as per our common understanding, it is (well, less or more) some duration in which entities recognize each other. Some of us might have played with it in ASP.NET as well. The concept is almost similar in WCF although the technique and usage are a bit different.

In WCF, there is always a service class instance that handles incoming service requests. These instances may already be there (at server when request arrives) or may be created as needed. In WCF, the concept of session is mainly to manage these service instances so that server can be utilized in an optimized way. At the server, there is one special class named InstanceContext that creates/loads service class instance and dispatches requests to it.

Continue reading

WCF – Transaction Flow

A Transaction is a set of complex operations, where failure of any single operation causes entire set to fail.

A successful transaction, that transfers the system from one consistent state (A) to another consistent state (B), called a committed transaction.

When you write a transactional service, one must abide by four core properties, known as ACID (atomic, consistent, isolated, and durable), and they are not optional.

  1. Atomic : To qualify as atomic, when a transaction completes. all individual operations must be made, as if they were one indivisible operation.
  2. Consistent: any transaction must leave the system in consistent state (that makes sense), so transaction is required to transfer the system from one consistent state to another.
  3. Isolated : No other entity (transactional or not) is able to see the intermediate state of the resources, for obvious reasons (as they may be inconsistent).
  4. Durable : For a transaction to be durable, it must maintain its committed state, even if there is a failure (power outage, hardware failure). The transaction must survive, regardless of the type of failure.

Continue reading

Older posts

© 2017 Keep it Simple

Theme by Anders NorenUp ↑