Browse by Tags

• WCF: Security Sessions and Service Throttling

  WCF includes support for establishing a security session through a simple configuration attribute. The primary reason of a security session is a shared security context which enables clients and services to use a faster, symmetric cryptographic exchange. WCF sessions should not be thought of in terms of HTTP based sessions, since the former are initiated by clients and the latter by the servers. In other terms, WCF sessions are there to support some kind of shared context between a particular client and a service. This context can be anything, and is not limited to security contexts. The attribute that establishes a security session and shared context is called, well, establishSecurityContext and is present in binding configuration. An example of such a binding would be: <bindings> <wsHttpBinding> <binding name="SecureBinding"> <security mode ="Message"> <message clientCredentialType="Certificate" establishSecurityContext="true"/> </security> </binding> </wsHttpBinding> <bindings> This binding allows HTTP based communication, demands message based security (think WS-Security) and uses certificates to sign/encrypt the message content. The attribute establishSecurityContext is set to true , which actually enforces a WS-SecureConversation session between the client and the service. The following is a simplified version of what is going on under the covers: Client instantiates the service proxy No message exchange is taking place Read More... Posted Tuesday, February 27, 2007 11:04 AM from Matevz Gacnik's Weblog | 0 Comments Filed under: .NET 3.0 - WCF;Architecture

• WCF: Reliable Message Delivery Continued

  In the previous post we discussed possible scenarios and methods for configuring reliable message delivery in WCF. Let's look further into this great WCF feature. Delivery assurances can have a large impact on the way your code processes incoming messages. Especially, ordering can be of importance if your code relies on ordered message delivery. Since configuration can be changed by any WCF service administrator there is a knob in WCF which lets you demand the appropriate binding . The knob is in a form of a declarative attribute, called DeliveryRequirementsAttribute . Here's how it's used: [DeliveryRequirements(RequireOrderedDelivery = true, QueuedDeliveryRequirements = QueuedDeliveryRequirementsMode.Required)] interface IServiceContract { int Operation(int a, int b); } DeliveryRequirementsAttribute can be set on any service interface or service class implementation. It has three properties: QueuedDeliveryRequirements which has three possible values, Allowed , NotAllowed and Required . Setting NotAllowed or Required makes the binding either demand or prevent WS-RM usage. Setting Allowed does not make any requirements. RequireOrderedDelivery demands a binding that supports and has ordered delivery turned on . TargetContract property is applicable only when the attibute is applied to a class definition. Since WCF service interfaces can be implemented by multiple classes, one can specify a specific interface for which the queued delivery requirements are defined. The specified contract Read More... Posted Monday, February 19, 2007 6:50 AM from Matevz Gacnik's Weblog | 0 Comments Filed under: .NET 3.0 - WCF;Architecture

• WCF: Reliable Message Delivery

  Windows Communication Foundation includes concepts which enable the developer to insist on reliably delivering messages in both directions. The mechanism is actually transport agnostic and allows messages to be flown reliably from client to service and replies from service to client. Underneath, WS-ReliableMessaging (WS-RM) implementation is used. Click here for Microsoft's specification. Content is the same. WS-RM is based on a concept of a message sequence . You can think of it in terms of a session, although it does not carry HTTP session semantics (remember, it's transport agnostic). A communication initiator (RM source) sends a <CreateSequence> element inside the message body to establish a RM sequence. Service side (RM destination) responds with either <CreateSequenceReponse> or <CreateSequenceRefused> , in cases where new sequence is not welcome. After the sequence is initialized, there is an additional SOAP Header in messages. It identifies the message number being transferred. The following is a simple example of headers of the first two messages: <S:Envelope> <S:Header> ... <wsrm:Sequence> <wsrm:Identifier>http://webservices.gama-system.com/RM/Service</wsrm:Identifier> <wsrm:MessageNumber>1</wsrm:MessageNumber> </wsrm:Sequence> </S:Header> ... <S:Body> ... </S:Body> </S:Envelope> <S:Envelope> <S:Header> ... <wsrm:Sequence> <wsrm:Identifier>http://webservices.gama-system.com/RM/Service</wsrm:Identifier> Read More... Posted Sunday, February 18, 2007 3:24 PM from Matevz Gacnik's Weblog | 0 Comments Filed under: .NET 3.0 - WCF;Architecture