Course Serialization in .NET 4.5 has been released.
This course equips viewers with essential knowledge about serialization in the .NET Framework. No matter what .NET technology developers are using – whether it’s ASP.NET, WCF, Web API, or desktop applications – they will definitely encounter situations where serialization is needed. This course helps them understand the different alternatives and what is the best choice in each scenario.
Watch it here:
In a previous article I talked about how clients use WS-Security to authenticate themselves to services using variety of tokens. So if authentication is covered by WS-Security, what exactly does WS-Trust bring to the table?
To answer this, let’s consider the simple scenario of a client wanting to authenticate to a service. As you have seen before, the client will have to present its token to the service. So the first clear disadvantage is that the authentication logic is actually part of the service. Services should satisfy business needs only, and service developers should worry about business only. Anytime spent creating authentication logic is a wasted time from the perspective of business.
Now, what if the service – who used to accept username tokens for authentication – had its policy changed, and now requires client certificates? This requires change to the service policy and code because authentication logic is actually part of the service.
To run the samples download this solution:
I will point out what each project in the solution does in corresponding section.
In general WCF security can be configured using Bindings and Behaviors.
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.
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:
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.
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 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.
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.
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.
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.
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:
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.
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
My latest Pluralsight course is about software engineering. This course explains the building blocks of software engineering and explains the processes and methods. The requirement modeling and design modules in particular explain in detail topics relevant to software architecture…
http://www.pluralsight.com/courses/software-engineering-essentials
This article illustrates working with Duplex mode in WCF with concurrency set to Reentrant. In general, Duplex is one of the three message exchange patterns (MEPs) which are:
On the other hand, concurrency in WCF services deals with how many concurrent threads can access these services at one time.
A full discussion of MEPs and Concurrency in WCF is not the intent of this article; as a matter of fact, that would be the job of a full book. As such, this article assumes familiarity (but necessarily experience) of the following:
In Summary, there are two types of transactions:
Atomic transactions, which take short time to execute (typically seconds). These transactions satisfy all ACID attributes, and thus need to acquire data locks on resource managers such as SQL Server. If all operations within a transaction scope succeed, then the transactions is committed automatically, else if any operation fails the entire transaction is rolled back. This is done via a transaction manager such as DTC.
mohamad halabi's blog 