Enterprise Services features in Indigo and more

Some highlights of the CTS366: Implementing Indigo Endpoint (Secure, Reliable and Transacted messaging) by Ingo Rammer and Steve Swartz.

Indigo distinguishes to sorts of standards: Basic Profile and WS Profile. Basic is neccessay if you like to interface with heterogeneous services and/or ASMX web services.

There are three types of security gates (mechanisms to protect access to resources at the service endpoints) available:

  1. On host by file and url permissions
  2. On methods contract by attributes
  3. Imperative (i.e. programmatic) checking at service level

Built-in impersonation by attributes or IDisposable impersonation context:

public double Add(double n1, double n2)

using (ServiceSecurityContext.Current.WindowsIdentity.Impersonate())
{ return n1+n2; }

Service does not automatically associate authenticated user with current principal of your thread.

You will specify this like so

  <behavior configurationName=”FlowPrincipal”>
    <serviceSecurity  threadPrincipalMode=”UseWindows” />

and make sure that the service uses this behavior by specifying it in the endpoint

<endpoint address=”Calculator” behaviorConfiguration=”FlowPrincipal“ />

Reliable Messaging gives you the characteristics of TCP when using HTTP connections. That means messages arrive guaranteed in order in a session. Using it is as simple as specifying it.

      orderedSession=”true” >

You can couple the binding transaction with the transaction that is running inside of a behavior (controlled by an attribute)

public class CalculatorService : ICalculator
AutoEnlistTransaction=true, AutoCompleteTransaction=true)]
  public double Add(double n1, double n2)

The mechanism is better than the one Enterprise Services (ES) uses, because you can set these up at a operation (method) level instead of just at the service (component) level.

You can set flowTransaction attribute on your binding to required or not permitted, in which case it is forbidden to send a transaction to a binding.

The queuing mechanism is the twin brother/sister of ES Queued Components. It features a Poison Queue on the service to avoid that messages keep returning in the queue when they fail the service side transaction.

public interface: IPurchaseOrder {…}

class PurchasingService: IPurchaseOrder

You need some configuration to configure the queuing settings of the service (instead of inside the registry like in ES):

  <binding configurationName=”MyQueueBinding” msmqAuthenticationMode=”None” msmqProtectionLevel=”None” maxRetries=”2″ maxRetryCycles=”3″ retryCycleDelay=”0:0:10″ rejectAfterLastRetry=”false” />

A very nice feature is that you set up the client to drop dead letters at an Indigo MSMQ endpoint. You read these dead letters from the queue with another service, but one running at the client (!).

Indigo also demoed a nice application that sends an image in 100 messages.

<binding configurationName=”OrderedImageBinding”>
  <reliableSession ordered=”true”/>

He used a soap router that dropped messages randomly ans showed how these were automatically resend when reliableSession was specified (ordered or unordered and even after killing the receiving service).

Great, great talk (9+)

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s