gridGISTICS Blog

Four IIS7 Modules you should be "Aware" of

Ryan Turner — Thu, 14 Aug 2008 12:32:22 -0400

IIS7 introduces a great number of features which are greatly appreciated. (Yes I know Apache already had them - but I'm not going there). My favorite thing about IIS7 is the module based architecture. Its extensibility is allowing the IIS team and the community to drum up some really cool modules.

AwareReverseProxyModule

This has enabled gridGISTICS to develop a "Reverse proxy" module which takes the incoming IIS request and hands it off DIRECTLY to an Aware service. Better yet - it intelligently find the appropriate service with all the load balancing and ninjaness you'd expect from Aware. You can even choose what services to expose to the web directly from the Aware Enterprise Manager. How could this get even better? You already have it if you are using the latest version of Aware - you just need to install the module.

URL Rewrite Module

Almost Mod Rewrite (mod_rewrite) for IIS. Enables flexibility of URLs and beats the snot out of the HTTP redirection module that ships with IIS7.

linky linky

Application Request Routing Module

(I totally stole this paragraph from the link below)

Microsoft Application Request Routing for IIS7 is a proxy based routing module that forwards HTTP requests to content servers based on HTTP headers and server variables, and load balance algorithms. Application Request Routing can be used to:

Increase application availability and scalability.
Better utilize content server resources.
Facilitate application deployment including pilot management and A/B testing.
Lower management costs and create opportunities for shared hosters.

linky linky

PowerShell Provider

I'd like to pretend that I am all savvy with PowerShell - but I just haven't personally tapped its power yet. However - my team members that are ninjas with it - tell me its the only way to go. The IIS team thinks so too and here is their module for managing IIS via powershell.

linky linky

Technorati Tags: iis7,modules,gridgistics

LINQPad - Go Get It!

Ryan Turner — Fri, 13 Jun 2008 01:44:23 -0400

Really wanted to shed some light on a tool we recently discovered. Its free, its well written and so far I have yet to break it. ( a skill I normally possess)

LINQPad

Here is why you should stop reading this and download it already.

Its Free
Query DB's using LINQ without SQL Management Studio on the box.
Doesn't require Visual Studio
2 MB Executable (no install required)
Can be used as a C#/VB.NET scratch pad.
Can be used as a mean calculator.
Quick test harness for a C#/VB snippets
It contains tons of free examples and even demo data to hone your LINQ skilz
O and yeah its Free

Found it really useful to do ad-hoc queries on Aware audits.

Technorati Tags: tool,linq,linqpad

Kudos to Robert who told me about this thing ;)

Microsoft Web Deployment Tool - Beta 1 Go Live

Ryan Turner — Tue, 10 Jun 2008 10:50:08 -0400

Web Deployment Tool

It slices, it dices, it synchs and snapshots - the IIS team has released a tool which eases the pain of site migration.

Benefits:

Simplify web farm deployments
Migrate sites or entire servers
Snapshot sites or entire servers for backups or versioning
Determine the differences between two sites or servers
Determine what components your site depends on

Features:

Synchronization of IIS 6.0/IIS 7.0:
The sync operation provides administrators with a way to quickly synchronize a site or server and deploy changes to existing sites and servers. A synchronization allows you to synchronize one source with one destination. For example, you can synchronize two directory paths or two web servers. The sync can be performed with local or remote objects.

Snapshot of IIS 6.0/IIS 7.0:
The snapshot, or archive, functionality allows administrators or developers to quickly take an archive of their web site or server for rollback, restore or backup purposes.

Migration from IIS 6.0:
The migrate operation provides administrators with a way to migrate sites or entire servers from IIS 6.0 to IIS 7.0, including their settings and content. A migration is essentially a way of synchronizing, filtered by migration rules. For example, when migrating from IIS 6.0 to IIS 7.0, MS Deploy will check the value of some properties and see if it is the IIS 6.0 default. If it is the default, such as the log files directory, it will instead use the value set on the IIS 7.0 server. This enables a server admin to maintain new settings on IIS 7.0 while moving sites or applications from IIS 6.0.

Analysis of IIS 6.0 Installed Features:
The analyze operation allows administrators to check what components are installed on the source server. In this way, they can determine if features are present that they will need in IIS 7.0 or that require more advanced setup than simply copying files. For example, ASP.NET requires more than a file copy and will need to be installed on the destination server.

Troubleshooting and Validation Features:
For validating an operation, the -whatif flag allows administrators to see what actions would happen when they perform an operation. This is especially useful for performing sync or migration, when they want to validate what changes will be made before performing them. For troubleshooting, the -verboseLevel flag allows administrators to get rich detail about what operations are being performed, and upon failure, the ability to diagnose the problem.

NEW FEATURES in this version!

PowerShell Support:
PowerShell cmdlets are included, allowing you to use the Microsoft Web Deployment Tool conveniently with PowerShell. For more information about how the PowerShell cmdlets work, see the Help file as well as the Microsoft Web Deployment Tool walkthroughs.

Enhanced Dependency Checking:
The dependencies that are checked for a web site or server can now be viewed on IIS 7.0 as well as IIS 6.0. They can be turned off on a granular level, such as disabling the drive space dependency check while still running the other dependency checks, or disabling the check for a single ISAPI script map. Additionally, when you view dependencies, you will be able to see the “trigger” for the dependency (what location(s) in configuration caused the Microsoft Web Deployment Tool to say that the module/component is a potential dependency).

Aware Server VS.NET Productivity Chart

Darrell Legault — Wed, 14 May 2008 12:45:00 -0400

I recently did a quite lengthy post on 67% increase in productivity.

http://blog.gridgistics.net/post/2008/05/Aware-Server-6725-More-Productive-than-VSNET.aspx

I just wanted to post a quick summary based on that post.

Aware Server	VS.NET 2008	Result
Built in F5 debugging of services and workflows.	Create your service, then configure your environment, and then create and code your testharness.	· Aware Server 54% faster to develop WCF services. · Aware Server – now prior WCF knowledge required. · Aware Server treats workflow development (WF) the same as service (WCF) development.
One click deployment – Any environment.	Deploy to your machine running IIS.	· Aware Server is “One Click” deployment of services. · Aware Server allows you to quickly test your services locally, and then deploy them to be shared with all developers.
Versioning services and running them side by side.	No built in versioning capabilities	· Aware Server will let you easily version and run those versions.
Provisioned endpoints.	Developer must create the endpoints.	· Aware abstracts protocol from the developer and puts it into the hands of operations.
Automatic service call load balancing	You need to setup and configure your own load balancing solution.	· Aware automatically scales your services by load balancing your service calls across all machines running your services.
Provisioning Conditions.	You need to setup your service on every machine you want it to run on.	· Setting up Aware Services to run on one server, or 1,000 servers. One policy will take care of all deployment and configuration for ALL of your servers.
Re-deployment will automatically run your new code.	Re-deployment is only local on your own machine.	· If an Aware Server policy is setup to run your service on 5 machines, when you redeploy that service Aware Server will automatically re-deploy the new code to all 5 machines.
Provisioning time schedules.	You would have to code/manage a schedule yourself.	· Aware Server automatically will run services when you want them to run, where you want them to run.
Zero configuration.	You need to know the URL of the machine of the services you wish to call	· Aware Server was designed from the ground up with Services Virtualization in mind to eliminate service location configuration.
IIS is not required, Although you can use IIS as well.	IIS is required to host your services.	· Aware Server offers you the flexibility of using whatever you hosting model you want.

Technorati Tags: Aware Server,gridGISTICS,VS.NET Productivity

Aware Server ASP.NET Deployment - 5 Reasons Why You Need It.

darrell legault — Wed, 14 May 2008 12:25:00 -0400

ASP.NET is the most widely used application development environment within VS.NET. As such, people waste much time designing and building ways to help them deploy their applications to their web farms (from staging, to QA, to production).

One of Aware Server's powerful features is the ability to package and deploy and configure ASP.NET applications across many machines and may environments.

Details on how can be found here Aware Server ASP.Net Web Deployment

The following are 5 simple reasons why Aware Server ASP.Net Deployment is 100 times easier and better than any other web deployment tool.

Command line vs UI point and click
1. Aware Server: Intuitive GUI allows for point, click, run your web.
2. MS Deploy: learning curve of what commands to do what, then write your script.
Setup of tools (remote service)
1. Aware Server: No tools, just publish, then deploy your ASP.NET application all of the machines at once.
2. MS Deploy: msi installation, remote service setup, scripting etc...
Versioning
1. Aware Server: Publish another version to your environment, then deploy it. Want to rollback? Just use the Aware wizard and republish your previous version.
2. MS Deploy: Another script, with hard coded configuration of source/remote machines. And hope that the old code was saved somewhere safe.
Environments
1. Aware Server: Just deploy your manifest to the environment, then publish. Then just as you would do with services or business processes, use the Aware Promotion wizard to promote your ASP.NET application to another environment.
2. MS Deploy: determine what machines are apart of an environment, write a script that will use those machines, as the environment changes, re-write your script.
Multi Machine Publishing
1. Aware Server: Just select the IIS machines you want to target and publish, no coding or scripting.
2. MS Deploy: You need to know each machine and then develop script to deploy to those machines.

Technorati Tags: Aware Server,gridGISTICS,ASP.NET Deployment,VS.NET productivity

Service Extensions

Dan Haligas — Wed, 14 May 2008 09:45:34 -0400

Service extensions inside Aware Server v3 can be used to build services that can have external algorithms or code attached to them by application administrators in a Lego type fashion. The blog refers to the Extensions sample that ships with the Aware SDK.

Imagine the following service contract:

   1:  [ServiceContract(Namespace = "urn:mynamespace", Name = "InsuranceClaimsService")]

   2:  public interface IInsuranceClaimsService

   3:  {

   4:      [OperationContract]

   5:      Double ComputeTotalClaim(String claimNumber, String state, Double carValue);

   6:  }

Now lets define a service extension point for our service. Imagine we want to be able to plug different tax calculators into different instances of our service without having to recompile or touch our insurance claims service implementation. So lets define a TaxCalculator extension that our insurance engine will use to compute the tax associated to a car.

   1:  /// <summary>

   2:  /// This interface will be our extension point for allowing others to provide

   3:  /// TaxCalculatorExtension implementations

   4:  /// </summary>

   5:  [DataContract]

   6:  [Serializable]

   7:  public abstract class TaxCalculatorExtension : ServiceExtension

   8:  {

   9:      /// <summary>

  10:      ///

  11:      /// </summary>

  12:      /// <param name="manifestReference"></param>

  13:      /// <returns></returns>

  14:      public override sealed Boolean CanBeAssociatedTo(ManifestReference manifestReference)

  15:      {

  16:          //

  17:          // We can open the .aware file as xml in the ExtenableServices project to get the guid for that

  18:          // service.

  19:          //

  20:          // We only want to be associated to that type of service.  This limits what the management console

  21:          // shows to the user for associating extensions to your service.

  22:          //

  23:          return manifestReference.Id == new Guid("c7ff37eb-d286-475f-ad78-097e963a5d68") && manifestReference.Version == "1.0.0.0";

  24:      }

25:

  26:      /// <summary>

  27:      ///

  28:      /// </summary>

  29:      /// <param name="state"></param>

  30:      /// <param name="carValue"></param>

  31:      /// <returns></returns>

  32:      public virtual Double ComputeTax(String state, Double carValue)

  33:      {

  34:          return 0.0;

  35:      }

36:

  37:      /// <summary>

  38:      ///

  39:      /// </summary>

  40:      public override sealed Boolean AllowMultiple

  41:      {

  42:          get

  43:          {

  44:              //

  45:              // We only want one of these at most attached to our service

  46:              //

  47:              return false;

  48:          }

  49:      }

  50:  }

The CanBeAssociatedTo routine allows you to ensure that derived versions of this extension type are only applied to your service (guid and version make up a unique manifest inside Aware). The Aware Enterprise Manager will use this routine to limit the extensions that can be applied to a service.

The AllowMultiple allows you state that multiple of this extension type may be applied or just one. In our sample we want at most one tax calculator extension attached to our service.

The ComputeTax routine and any other virtual routines in this class define our extension points for tax calculators.

For good measure let's provide a default implementation of our tax extension.

   1:  /// <summary>

   2:  ///

   3:  /// </summary>

   4:  internal class DefaultTaxCalulator : TaxCalculatorExtension

   5:  {

   6:      /// <summary>

   7:      ///

   8:      /// </summary>

   9:      /// <param name="state"></param>

  10:      /// <param name="carValue"></param>

  11:      /// <returns></returns>

  12:      public override Double ComputeTax(String state, Double carValue)

  13:      {

  14:          return carValue * .07;

  15:      }

  16:  }

In our host file for our service we can override the AddHostExtensions event and attach our default extension if one has not been added to us already.

   1:  /// <summary>

   2:  ///

   3:  /// </summary>

   4:  /// <param name="sender"></param>

   5:  /// <param name="e"></param>

   6:  private void InsuranceClaimsServiceHost_AddHostExtensions(object sender, HostExtensionsEventArgs e)

   7:  {

   8:      //

   9:      // Check for an extension added from the outside otherwise add our default one

  10:      //

  11:      if (e.Extensions.Find<TaxCalculatorExtension>() == null)

  12:      {

  13:          e.Extensions.Add(new DefaultTaxCalulator());

14:

  15:          //

  16:          // Extensions are accessible in any operation using OperationContext.Current.Host.Extensions.Find<TaxCalculatorExtension>

  17:          //

  18:      }

  19:  }

Now take a look at the implementation of our IInsuranceClaimsService.

   1:  /// <summary>

   2:  ///

   3:  /// </summary>

   4:  /// <returns></returns>

   5:  ///

   6:  /// <summary>

   7:  ///

   8:  /// </summary>

   9:  Double IInsuranceClaimsService.ComputeTotalClaim(String claimNumber, String state, Double carValue)

  10:  {

  11:      //

  12:      // We know at least our DefaultTaxCalculator will be here

  13:      //

  14:      TaxCalculatorExtension taxCalculator = OperationContext.Current.Host.Extensions.Find<TaxCalculatorExtension>();

15:

  16:      //

  17:      // Use the tax calculator to finish the computation.  this could be our default one or

  18:      // one provided from the outside

  19:      //

  20:      return taxCalculator.ComputeTax(state, carValue) + 15000;

  21:  }

Notice how use the Extensions.Find method which is native to WCF on the current OperationContext. We grab our extension and call its compute tax routine.

Now lets implement an extension on the outside. To do this we create a new Service Extension project (project template that ships with Aware).

After adding a reference to our shared library (contains both the service contracts and service extension definitions) we implement a greedy tax calculator which returns 50% tax every time.

   1:  /// <summary>

   2:  ///

   3:  /// </summary>

   4:  /// </summary>

   5:  [DataContract]

   6:  [Serializable]

   7:  public sealed class GreedyTaxCalculator : TaxCalculatorExtension

   8:  {

   9:      /// <summary>

  10:      ///

  11:      /// </summary>

  12:      public GreedyTaxCalculator()

  13:      {

  14:      }

15:

  16:      /// <summary>

  17:      ///

  18:      /// </summary>

  19:      /// <returns></returns>

  20:      public override string ToString()

  21:      {

  22:          return Description;

  23:      }

24:

  25:      /// <summary>

  26:      ///

  27:      /// </summary>

  28:      /// <param name="state"></param>

  29:      /// <param name="carValue"></param>

  30:      /// <returns></returns>

  31:      public override Double ComputeTax(String state, Double carValue)

  32:      {

  33:          return carValue * .5;

  34:      }

35:

  36:      /// <summary>

  37:      ///

  38:      /// </summary>

  39:      [Browsable(false)]

  40:      public override String Category

  41:      {

  42:          get

  43:          {

  44:              return "Insurance Tax Calculators";

  45:          }

  46:      }

47:

  48:      /// <summary>

  49:      ///

  50:      /// </summary>

  51:      [Browsable(false)]

  52:      public override String Name

  53:      {

  54:          get

  55:          {

  56:              return "Greedy Tax Calculator";

  57:          }

  58:      }

59:

  60:      /// <summary>

  61:      ///

  62:      /// </summary>

  63:      [Browsable(false)]

  64:      public override String Description

  65:      {

  66:          get

  67:          {

  68:              //

  69:              // This will show in the notes column in the management console

  70:              //

  71:              return "Takes the car value and return 50% tax";

  72:          }

  73:      }

  74:  }

The overridden properties above are only used by the tools to provide verbose descriptions for this extension. After this we are done and ready to test. Publish both your service and your service extensions projects into Aware.

As shown above they are both deployed into Aware. Next we need to provision 2 instances of our Insurance Claims Service. One that uses the default tax calculator and one that uses the greedy one.

To do this go into the Aware Enterprise Manager and go to the Service Provisioning Policies tab. Click the 'Create New' button to create a new provisioning policy. Enter 'Insurance Claims' for the name of the policy and switch to the Included Service Manifests tab.

Add our service by clicking the 'Add Service Manifest' button and enter an additional attribute in the Additional Attributes section with a key of Tax and a value of Default. Then add our same service again.

For the second instance of our service add an additional attribute with a key of Tax and a value of Greedy. Before clicking save switch to the Extensions tab in the lower section of the screen. Click the Add Extension and select the Greedy Tax Calculator from the popup and click Apply.

Click Save and switch to the Service tab in the Enterprise Manager to see that we have 2 instances of our insurance service running and that each have an attribute attached to them with a key of Tax.

We can then use this attribute to route requests to different instances of our service. The client code is listed below.

   1:                  ServiceAttributes attributes = new ServiceAttributes();

   2:                  attributes["Tax"] = "Default";

3:

   4:                  using (InsuranceClaimsServiceClient client = new InsuranceClaimsServiceClient(attributes))

   5:                  {

   6:                      Double result = client.ComputeTotalClaim("122344x", "GA", 5600);

   7:                      Console.WriteLine("Claim result = {0}", result);

   8:                  }

9:

  10:                  ServiceAttributes attributes2 = new ServiceAttributes();

  11:                  attributes2["Tax"] = "Greedy";

12:

  13:                  using (InsuranceClaimsServiceClient client = new InsuranceClaimsServiceClient(attributes2))

  14:                  {

  15:                      Double result = client.ComputeTotalClaim("122344x", "GA", 5600);

  16:                      Console.WriteLine("Claim result = {0}", result);

  17:                  }

Above we call the insurance service twice. The first call is directed to the default tax calculator instance and the second is directed to the greedy instance. If you recall from our implementations above we add 15000 to whatever tax is computed. So for the first one our default tax will be 15000 + .07 * 5600 = 15392 and for the greedy one it will be 15000 + .5 * 5600 = 17800.

This really shows off how we can use the same binary bits (deployed service manifest) and change the behavior of the service through configuration and extensions. Tax algorithms can now be implemented independent of the insurance claims service and can be assembled at provisioning time depending on customer need, etc.