DTC and the 2 Phase Commit Protocol

Transaction Managers

Atomic Transactions rely on automatic commit and rollback actions. Therefore they need a system to manage these actions implicitly. The name of this system is Transaction Manager.

There are multiple kinds of transaction managers, each used for a certain transaction protocol. For a detailed discussion check my WCF Transactions Pluralsight course. But for the sake of this discussion, we care about the WS-AT protocol, and a particular Transaction Manager – called the Distributed Transaction Coordinator – or DTC.

DTC is familiar to most developers, and is capable of managing transactions across process and machine boundaries.

DTC and Atomicity

So DTC has a tough challenge: while the Consisteny, Isolation, and Durability attributes are managed by Resource Managers (RMs), DTC must preserve the atomicity attribute, and it must do this over multiple participants that are most probably distributed over multiple machines.
Continue reading →

Sample Code

To run the samples download this solution:

https://onedrive.live.com/redir?resid=14EFC3E5B4AB67D8!870&authkey=!AJealHHKthHAuyU&ithint=file%2czip

I will point out what each project in the solution does in corresponding section.

Steps Overview to configure WS-Security in WCF

Bindings and Behaviors

In general WCF security can be configured using Bindings and Behaviors.

• Using Bindings you can configure message protection and authentication types.
• Using Behaviors you can configure credentials to be used for message protection and authentication as well as credential validation settings

Security Configuration settings – just like the majority of WCF configurations – can be set in the configuration files or programmatically. There are some exceptions to this rule where some configuration can be set only by code; for example, setting usernames and passwords can only be done programmatically in order not to allow developers to hard code these values in the configuration file.

Overview of steps to configure WS-Security

WCF provides a configuration model to set every aspect of WS-Security. This configuration can be achieved in 3 steps:

In Step1, we set the Basic Message Security Settings:

• First, you configure the service to use a binding that supports WS-Security. As is the case in most examples in this course, I will be using the WSHttpBinding
• You then set the service to use Message security. For some bindings, this is the default security mode anyway, but explicit configuration is required when you need to edit the default settings.
• Then you select the sensitive data you want to secure. Recall that a main advantage of message security over transport security is the ability to selectively secure parts of the message, thus reducing overhead.

Continue reading →

The Need for Security Standards

Communicating systems or services have to deal with tough challenges when it comes to secure messaging. If a system is sending a message to another, this requires the implementation of important security measures.

1. First, the receiving system must authenticate the sender before accepting its message. It must verify that the sender is indeed whoever claims to be.
2. During transmission, intruders may be able to peek into messages. If these messages contain sensitive data, then data privacy becomes an issue. Intruders must not be able to understand what they just saw.
3. Another concern during transmission, is Data Accuracy – or Integrity – which means that If an intruder intercepts the message and modifies it, this modification must be detected by the receiving system.

The WS-Security Standard

WS-Security is the foundation layer on top which other security standards are created. The WS-Security standard also uses another two important standards, these are XML-Encryption and XML-Signature. These standards were created to secure XML documents independent of SOAP and the WS-* stack. But the WS-Security standard then used these standards to secure SOAP messages.
Continue reading →

The Case for Reliable Messaging

The success of interaction between a service consumer and a service provider, is clearly dependent on how much reliable the underlying transport protocol is. However when it comes to networks, we know that even in the most reliable setups, all sorts of things can go wrong.

Let’s consider some scenarios of common problems that might occur during communication between a client and a service.

Scenario 1:

Lets start by the simplest of scenarios: a client tries to send a message to a service. However, during transmission, something goes wrong on the wire, and the message cannot be delivered.

In this case, there should be a way for the client to be notified about the transmission failure, so that it can send the message again.

Scenario 2:

In this scenario, the message is actually received at the service. However, before the service could confirm (or acknowledge) the client that it received the message, again there was a problem in the network, and the service does not receive the acknowledgment. In this case, the client risk sending the same message again, which will result in message duplication at the service side.

Continue reading →

Need for MTOM

Exchanging different types of binary files between business entities is a common business need. To be transmitted within a SOAP message, these files must be represented as binary data.

Using the default SOAP serialization, only characters are allowed to be transferred within a SOAP XML message. Therefore, for binary data to be transferred within a SOAP message, it must be encoded as characters using base64 encoding.

Binary data encoded as base64 is represented as text. This text is then transferred as part of the SOAP message. Now, this can drastically increase the message size, which can become an issue especially over low-bandwidth networks.

Continue reading →

SOAP is NOT Dead!

This is not another REST vs. SOAP discussion. There are endless debates on this topic, that you hardly need yet another view.

This section just tells one thing: While REST has become the preferred choice to build web services, SOAP is not dead just yet.

To understand why SOAP is not dead yet, you need to recall that today, the use of web services can be broadly divided into three set of scenarios:

• Web services that manipulate data entities (or what are commonly called web resources in the web space); these services are known as Web APIs
• Web APIs that are built using the REST architectural style (where hypermedia takes central stage)
• And ‘traditional’ SOAP-based Web services that are used commonly in application or enterprise integrations

Practically there is no competition in the web domain: Web APIs and REST have become the dominant choices for building services that manipulate web resources.

However, in the domain of application and integrations such as middlewares, ESBs, and SOA; SOAP is very much still alive.

So Why is SOAP Still Alive?

Now the reason SOAP is still alive is not necessarily because it’s better than WebAPI/REST in this domain. This is debatable as WebAPI/REST advocates believe WebAPI/REST can be used for enterprise integrations even better than SOAP ever did. While SOAP advocates believe that SOAP and the WS-* standards capabilities still make them the better option for certain scenarios.
Continue reading →