Web Apps simply provide you the ability to get your web applications up and running in Azure without worrying about all the details you have to worry about in traditional on premise deployment.
Within the boundaries of your organization, these are some of the concerns that you and other organization teams have to care about whenever you want to get a web applications online:
- Web server settings (ex: IIS) such as application pool, security, required handlers, access permissions, to name few
- Server setup; including OS management, patching, upgrades
- Network settings including security and firewalls
- Not to mention of course the sizing issue, of how much hardware to order and set up
With Web Apps, you just have to focus on the business and leave these (boring) concerns to Azure.
Let’s build a simple example to see Web Apps in action. I will create a default MVC web app, hook it up to Azure AD, and make it online – all in a matter of minutes. Obviously real world applications require much more than this simple example would demand, but the idea to show here is that you are free from time consuming concerns: try to do the same exact example on premise, and it will take you hours if not days.
WordPress.com is excited to announce our newest offering: a course just for beginning bloggers where you’ll learn everything you need to know about blogging from the most trusted experts in the industry. We have helped millions of blogs get up and running, we know what works, and we want you to to know everything we know. This course provides all the fundamental skills and inspiration you need to get your blog started, an interactive community forum, and content updated annually.
App Services are a set of platform as a service (PaaS) services that hide the complexity of building applications on Azure and allow you to focus on the business and delivering quick results. This is another step in the enhancement of PaaS offerings which started way back with cloud services and web and worker roles.
App Services consist of various services (which is being updated, such as Functions which extended the original App Services): Continue reading
In a recent implementation, I was building a WCF intermediary which receives messages and does some processing and then route these messages to a set of services that are not under my control.
One of the requirements, was that in specific cases I had to edit the incoming Security header and set misunderstand to 0 instead of 1. As I said, I have no control over the destination services, therefore I cannot use the ValidateMustUndestand service behavior nor the fine grained UnderstoodHeaders property of the message headers to bypass validation at these services.
So in the intermediary I built an inspector which intercepts the message just before being sent to the destination services. It then removes the incoming Security header after it preserves the content, then creates a custom header with mustunderstand set to false, then injects this header instead of the old one.
I was setting an ADFS 3.0 lab setup and thought I would share couple of gotchas – nothing particularly new here but could save someone some time.
Gotcha #1: Use Different Federation Service Name
In my case, I wanted to set my federation service on the same domain controller machine. This is of course not realistic in a production setup, but it’s common in a lab setup as you’d be preparing a POC or just playing around with stuff.
In this case, you cannot have the Federation Service name the same as the server name. In other words, my machine FQDN is “dc1.lab1.local”. Therefore I cannot have my federation service URL as: https://dc1.lab1.local/adfs/ls.
Instead I need to create a different service name; say for example “fs1.lab1.local”. So the URL will be https://fs1.lab1.local/adfs/ls.
In this post we will examine some of the techniques used to build the Payment Upload process. You will see transactions, debraching messages, streaming and using XLANGMessages.
The Business Process
In the previous post we saw the main bill upload process. What I left out was the process that handles failed message routing.
The Famous Failed Routing Error
In the previous post, I showed you how correlation is vital for the correct operation of a business process. However, this correlation – being based on matching field values – is subject to failure.
For example, in our process, say that the bank sent the Bill Confirmation Rq, with a wrong AsyncRqUID. Using correlation BizTalk will try to route the message to running Ox instance but it won’t be able to do so.
In order to see this, drop a bill request message into the folder. Now while the process is waiting for the confirmation rq message, edit the asyncrqid. Now drop the message in the confirmation request folder. If you examine now the event log you will see the famous error: “The published message could not be routed because no subscribers were found”. This happened because BizTalk was not able to match the correlation and no other subscribers were found for the message.
The Business Process
The first process is the Bill Upload Process:
This starts a series of articles about a BizTalk business process scenario. The entire solution can be downloaded from here:
The Scenario is a modification of a real business case for a payment gateway.
The gateways acts as a medium between vendors and banks:
DTC and the 2 Phase Commit Protocol
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.
In the previous article we understood WS-Trust and WS-Federation and saw briefly how they are used with WCF. Now let’s see an example of how to configure a WCF service to delegate authentication to an STS.
Here I will configure my WCF service to delegate authentication to ADFS. The federation service namespace is “fs1.lab1.local”.
The following section sets the service certificate; the one that will be used to access the service over SSL (this is a self-signed certificate using makecert):