09 Mar 2010 @ 7:09 AM 

Continue to my previous introductory post about AppFabric, it is very fundamental to know the architecture IIS 7.0 and WAS.  So, this post.

IIS 7.0 Architecture

In the above diagram, you can see two regions in Windows. The kernal mode and user mode, and you know that processes in the kernal mode touches the CPU and other hardwares without any interface and have the rights to access physical memory without any virtual address mapping. The user mode processes are our own applications along with Windowing Subsystem which also includes Windows Network Subsystem.  Processes in the user mode requires processes in the kernal mode such as thread scheduling, memory, cache or IO related activities. So, it would require a thread context switching means that kernal model thread has been created and the data in the user mode thread has been transferred into kernal mode thread.  Ahhh, I’m explaining too much about Windows processing.  Lets cut off.

IIS 7 Components

Application Pool and Worker Process

Worker process is a windows process which is specifically designed for hosting and running static, ASP or ASP.NET web applications in IIS.  w3wp.exe is responsible for loading the appropriate ISAPI (a lower level programming module for handling specific web application, for example aspnet_isapi.dll for ASP.NET) filters and starts a new worker process for a request.

Application pool is a grouping of web applications those are routed to one or more worker processes.  Processes in one application pool will not be impacted by another application pool’s failure.

Request Processing Pipeline and Modules

A request processing pipeline is created for every request.  In the previous versions of IIS, if a request is for ASP.NET application, the application needs to exit from the IIS pipeline and load aspnet_isapi for handling ASP.NET code which inturn creates its own request processing pipeline.  In II7, both IIS and ASP.NET request pipelines are combined and called as “Integrated Pipeline“.  This pipeline contains one or more modules.  Module is a component which contain a specific set of features for IIS to handle a request.  For example, BasicAuthenticationModule is a module for performing basic authentication and FileCacheModule is a module for caching files and file handles.

The integrated pipeline has following benefits:

  • Eliminating the duplication of features between IIS and ASP.NET, for example authentication
  • One inventory for all IIS modules
  • Performance…performance…

WWW Service and WAS

It is necessary that a dedicated component is required for listening for requests and managing application pools and worker processes.  In IIS 7, WAS (Windows Process Activation Service) is dedicated for this.  Requests coming from different transports like HTTP, TCP/IP, NetPipe and MSMQ are handled by respective listener adapters configured in the WAS.  When a request is coming which is directed to respective listerner adapters which passes the request to appropriate worker process, where the application manager directs the request to the specific application.

WWW Service (World wide web publishing service, simply w3svc) is the listener adapter for HTTP.  Apart from this, it manages the configuration stuffs required for HTTP related.

Protocol Listeners and HTTP.sys (Kernal Mode)

As its name reflects, protocols listeners receive appropriate requests and passes them to the IIS.  Note that protocol listener are kernal mode processes.  This model allows to handle any protocol, and the only thing we require is appropriate device drive as like as HTTP.sys for HTTP requests.

Whenever a HTTP request is entering into the server, HTTP.sys receives the requests and pass it to appropriate worker process if exists, otherwise it puts the request in the request queue.  When a response for a request is already in the response cache, it fetches that and reply it back without noticing and invoking worker process.

Tags Tags: , , , , ,
Categories: ASP.NET, AppFabric
Posted By: udooz
Last Edit: 09 Mar 2010 @ 07 21 AM

EmailPermalinkComments (0)
 27 Jul 2009 @ 8:31 AM 

So many frameworks, tools and platforms available for us to develop RIA applications.  One such framework from Gizmox is “Visual Web GUI” which provides unified approach to develop web applications using ASP.NET platform with “Empty-Client” model. 

The catchy point is you do not need to know too much about underlying technology.  You can also port WinForm applications into web.

You could be a win form developer or web developer.

How does it different from others?

Since I did not fully evaulate this platform, I can simply say “this framework clearly segregates the responsibilities between browser and server”.  Server does business processing and browser handles user interaction.  Looks very adhoc and no different.  Gizmox is termed this as “empty client”.

Empty Client

We are known and worked with “Thick”, “Thin” and “Fat” clients.  Empty?  Points taken from their web site is

The Empty Client approach combines for the first time on web, the best of both desktop and web environments. An optimized protocol makes server side power, typically achieved with “Thin client” available for data centric web applications, with “Thick Client” scalability and performance.

They assured that this framework lets developers create desktop-like Web applications in no time using their existing skill sets with no re-learning, no retooling, and without the traditional complexities of the web. It also eliminates traditional security concerns, by facilitating literally Empty clients – no open services, no data, no logic, or any other exposed security hazards are left on the client.

The server is all in their approach.  Client only captures data and send it to server, and display data from server.  Even server provides display format of the data.

This model is mainly useful in cloud computing.  However, I do not know wy making the powerful client as “dump” and overloading the server.

Visit http://www.visualwebgui.com/Developers/Introduction/tabid/556/Default.aspx for more details.

Tags Tags: , , , ,
Categories: ASP.NET
Posted By: udooz
Last Edit: 27 Jul 2009 @ 01 46 PM

EmailPermalinkComments (0)

Source code for this article can be downloaded from http://udooz.net/index.php?option=com_docman&task=doc_download&gid=2&Itemid=5

This article is continuation of Part I.  In this part, I explain the different data binding options in ASP.NET AJAX 4.0 templates.  Just a recap that I’ve consumed an ADO.NET data services to fetch AdventureWorks’s Product table records.  In this article, I explain how to update/add new record from client side.

Bindings

Template supports the following bindings:

  • One-time – The expression is evaluated only once when the template rendering happen
  • One-way Live Binding – The expression is evaluated and update the value, if items in the data source changed
  • Two-way Live Binding – If the data source value changed, the value in the expression updated.  And if the value in the expression is updated, it will update data source also.

The below diagram depicts the binding.

ASP.NET 4.0 Live Binding

In the above diagram, the red dashed arrow shows one-time data binding.  Once the data from data source has been fetched by DataView using AdoNetDataContext.  The one-way live binding has  been shown as purple shadowed arrow.  The purpose shadow here is whenever a data updated at data source, it is being updated to data view through AdoNetDataContext.  The two-way live binding has been shown as  green shadowed two-head arrow.  In this case, data context should have the knowledge about update operation on data source and provide an interface to data view to send the modified values.

The these three bindings, ASP.NET AJAX provides the following expression convention:

  • {{ <data_item_name> }} – One-time (can be used on any HTML controls for example <p>{{ Name }}</p>)
  • { binding <data_item_name> } – One-way if other than user input HTML controls for example <td>{ binding Name } </td)
  • {binding <data_item_name> } – Two-way  if INPUT HTML controls for example <input type=”text” sys:value=”{{ binding Name }}” />)

Here, the input controls binds the values using sys:value attribute for two-way binding.

Before going into the updatable data source, let us see how can we design master-detail layout to display Product name and Product details.

Master-Detail Layout

 

<body xmlns:sys="javascript:Sys"
xmlns:dataview="javascript:Sys.UI.DataView"
sys:activate="*">
  <form id="form1" runat="server">
 
<div>
      <!--Master View-->
     
<ul sys:attach="dataview" class=" sys-template"
          dataview:autofetch="true"
          dataview:dataprovider="{{ dataContext }}"
          dataview:fetchoperation="Products"
          dataview:selecteditemclass="myselected"            
          dataview:fetchparameters="{{ {$top:'5'} }}"
          dataview:sys-key="master"            
      >
         
	<li sys:command="Select">{binding Name }</li>
     </ul>
      <!--Detail View-->
     
<div class="sys-template"
          sys:attach="dataview"
          dataview:autofetch="true"
          dataview:data="{binding selectedData, source={{master}} }">
          <fieldset>
            <legend>{binding Name}</legend>
            <label for="detailsListPrice">List Price:</label>
            <input type="text" id="detailsListPrice"
                sys:value="{binding ListPrice}" />
           
            <label for="detailsWeight">Weight:</label>
            <input type="text" id="detailsWeight" sys:value="{binding Weight}" />
           
             
          </fieldset>
          <button onclick="dataContext.saveChanges()">Save Changes</button>
     </div>
 </div>
  </form>
</body>

Selectable And Editable

An unordered list shows the master details, here the product name (line 15).   This line also indicates that the list item is selectable using sys:command=”Select”.   For maintaining master-detail or selectable item, primary key needs to be specified.  The  sys-key  property of data view refers that primary key.  In this example, I call the primary key as “master” (line 13).  Also, you can see that I’ve passed a filter option using fetchparameter property of data view (line 12).  In this example, I request the ADO.NET data service to give only top five records using its filter syntax.

Whenever an item in the master list is selected, the details view needs to be notified.  The widget for the details view and binding details should be identified using regular sys:attach=”dataview” and dataview’s data property.  In this example, dataview:data=”{binding selectedData, source={{master}} }” specifies that binding with data view with sys-key name “master”.  The fieldset is used to show set of values for a product.  Here, the list price and weight can be editable.

Once an item has been edited, this needs to be notified to the data source through data context.  The button with caption “Save Changes” specifies that whenver this button is clicked, save the items in the details view into data source through data context’s saveChanges() method.  The corresponding data source’s update option should be set on data context’s set_saveOperation().  The following JavaScript code explains this.

 

var dataContext = new Sys.Data.AdoNetDataContext();
dataContext.set_serviceUri("AWProductDataService.svc");
dataContext.set_saveOperation("Products(master)");
dataContext.initialize();

The ADO.NET Product data service’s Products(id) method is used on set_saveOperation.  An item can be updated, when Product service of ADO.NET data service is being invoked with product primary key as argument.  Here, again I’m referring master layout’s “master” sys-key as primary key of Product.

The output of the above code is

ASP.NET 4.0 Live Binding

The top one is master view where Sport-100 Helmet, Red is selected and the details has been shown in the bottom page.  You can edit and update the data source.

The selecteditemclass property of data view is used to show the selected item.

Tags Tags: , ,
Categories: ASP.NET
Posted By: udooz
Last Edit: 27 Aug 2009 @ 08 26 PM

EmailPermalinkComments (0)
 24 Apr 2009 @ 9:02 AM 

Sample VS2008 Project is available at http://snipurl.com/asp_net_extendercontrol_sample.zip

This is the continuation  of ASP.NET Extender Control: Decorating & Componentizing Web Controls with Client Behavior.  In this walkthrough, the following things are explained:

  • Decorating or extending web control behavior.  A mouse hover effect which is implemented in JavaScript would be applied to controls of  type Button.
  • Packaging client side implementation along with the extender control assembly.

The client side implementation should consume  ASP.NET AJAX JavaScript API, in order to get the benefit of this.

As explained in previous section,  this walkthrough explains how to add mouse over and mouse out effect to controls of type Button.

Steps

  1. Implement decorator class based on ExtenderControl
  2. Implement client side behavior
  3. Make client side script as ASP.NET AJAX web resource
  4. Consume extender control

Decorator Class Implementation

Based on your application architecture and/or decorator usage, define the decorator class either within web project or separate assembly.  HoverExtension is the decorator class which extends ExtenderControl.

Based on figure 3 in the previous post, the following are the steps need to be completed:

  1. Define decorated properties in control
  2. Map control and client side properties
 

using System;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Collections.Generic;

namespace Udooz
{
    [TargetControlType(typeof(Button))]
    public class HoverExtension : ExtenderControl
    {
        private string _hoverCssClass;

        public string HoverCssClass
        {
            get { return _hoverCssClass; }
            set { _hoverCssClass = value; }
        }
        private string _normalCssClass;

        public string NormalCssClass
        {
            get { return _normalCssClass; }
            set { _normalCssClass = value; }
        }

        protected override IEnumerable<ScriptDescriptor> GetScriptDescriptors(Control targetControl)
        {
            ScriptBehaviorDescriptor descriptor = new ScriptBehaviorDescriptor("Udooz.HoverExtension", targetControl.ClientID);
            descriptor.AddProperty("hoverCssClass", this.HoverCssClass);
            descriptor.AddProperty("normalCssClass", this.NormalCssClass);           
            return new ScriptBehaviorDescriptor[] { descriptor };
        }

        protected override IEnumerable<ScriptReference> GetScriptReferences()
        {
            ScriptReference reference = new ScriptReference();
            reference.Assembly = "HoverExtension";
            reference.Name = "Udooz.HoverExtension.js";
            return new ScriptReference[] { reference };
        }
    }
}

Define decorated properties in control

The TargetControlTypeAttribute (line 10 ) enables to specify to which web controls this decorator can be applied.  HoverExtension can only be applied to Button type.  The next step is to define decorated properties for the server side so that it can be used in ASPX page. NormalCssClass and HoverCssClass are two properties defined to set style name for normal and hover state (line 15 – 26).

Map control and client side properties

As discussed in the previous post, the decorated class implements IExtenderControl’s methods GetScriptDescriptors (line 28-34) and GetScriptReferences (line 36-42).  The ScriptBehaviorDescriptor does two things here:

  • Based on the target server control given as an argument in the constructor, it specifies the client class to target control’s client ID (line 30).
  • Map the server side properties to client side properties (line 31, 32).

The ScriptReference is used to specify on which assembly the client behavior script file will be included (line 39) and the script file name (line 40).

Client Side Behavior Implementation

Based on figure 3 in the previous post, the following are the steps need to be completed those are implemented in HoverExtension.js:

  1. Define decorated properties for client side
  2. Implement client side behavior
 

Type.registerNamespace('Udooz');

Udooz.HoverExtension = function(element)
{
    Udooz.HoverExtension.initializeBase(this, [element]);

    this._hoverCssClass = null;
    this._normalCssClass = null;
}

Udooz.HoverExtension.prototype =
{
    initialize: function() {
        Udooz.HoverExtension.callBaseMethod(this, 'initialize');             
        $addHandlers(this.get_element(),
                     { 'mouseover': this._onMouseOver,
                         'mouseout': this._onMouseOut
                     },
                     this);

        this.get_element().className = this._normalCssClass;
    },

    dispose: function() {
        $clearHandlers(this.get_element());

        Udooz.HoverExtension.callBaseMethod(this, 'dispose');
    },

    _onMouseOver: function(e) {
        if (this.get_element() && !this.get_element().disabled) {
            this.get_element().className = this._hoverCssClass;
        }
    },

    _onMouseOut: function(e) {       
        if (this.get_element() && !this.get_element().disabled) {
            this.get_element().className = this._normalCssClass;
        }
    },

    get_hoverCssClass: function() {
        return this._hoverCssClass;
    },

    set_hoverCssClass: function(value) {
        if (this._hoverCssClass !== value) {
            this._hoverCssClass = value;
            this.raisePropertyChanged('hoverCssClass');
        }
    },

    get_normalCssClass: function() {
        return this._normalCssClass;
    },

    set_normalCssClass: function(value) {
        if (this._normalCssClass !== value) {
            this._normalCssClass = value;
            this.raisePropertyChanged('normalCssClass');
        }
    }
}

// Optional descriptor for JSON serialization.
Udooz.HoverExtension.descriptor = {
    properties: [{ name: 'hoverCssClass', type: String },
                    { name: 'normalCssClass', type: String}]
}

// Register the class as a type that inherits from Sys.UI.Control.
Udooz.HoverExtension.registerClass('Udooz.HoverExtension', Sys.UI.Behavior);

if (typeof (Sys) !== 'undefined') Sys.Application.notifyScriptLoaded();

A client side class Udooz.HoverExtension is defined.  The constructor initialize the given “element”.  The element reference is the target web control which will be given by ASP.NET at run time using ASP.NET AJAX $create() method.

Define decorated properties for client side

There are two properties normalCssClass (line 56-65) and hoverCssClass (line 45-54) defined.

Implement client side behavior

The mouse over and mouse out events are registered (line 17-21) and those handlers are defined (line 32-42).

Make Client Side Script As ASP.NET AJAX Web Resource

To package the HoverExtension.js into HoverExtension.dll, this script needs to be declared as web resource so that ASP.NET AJAX identifies and consumes this as web resource and invoke this via ScriptResource.axd handler.  In the AssemblyInfo.cs file of HoverExtension.dll, the following code needs to be added.

 

[assembly: System.Web.UI.WebResource("Udooz.HoverExtension.js", "text/javascript")]

 

Consume Extender Control

Build the HoverExtension project and refer this into a ASP.NET 3.5 web project. The page should register HoverExtension type and can use wherever require.

 

<%@ Register Assembly="HoverExtension" Namespace="Udooz" TagPrefix="udooz" %>

Before consuming the control, the actual styles should be required.

 

<style type="text/css">
.Hover
{
    background-color:Red;
    border-color:Yellow;
}

.Normal
{
    background-color:Aqua;
    border-color:Blue;
}
</style>

 ASP.NET AJAX ScriptManager is required for runtime behaviors.

 

 
<pre>
 

<asp:ScriptManager ID="ScriptManager1" runat="server" />

 The actual button control definition and extender control usage would be

 

 
<pre>
 

<asp:Button ID="button" Text="Extended Button" runat="server" />       
<udooz:HoverExtension ID="extender1" HoverCssClass="Hover" NormalCssClass="Normal" TargetControlID="button" runat="server" /> 

When executing this page, ASP.NET AJAX creates the following for extension.

 <span lang="EN">
<script type="text/javascript">

//<![CDATA[

Sys.Application.initialize();

Sys.Application.add_init(function() {

$create(Udooz.HoverExtension, {"hoverCssClass":"HighLight","normalCssClass":"LowLight"}, null, null, $get("button"));

});

//]]>

</script>
Tags Tags: , , , ,
Categories: ASP.NET, JavaScript
Posted By: udooz
Last Edit: 25 Apr 2009 @ 08 22 AM

EmailPermalinkComments (2)

Problem

ASP.NET server controls componentize (or encapsulate) the UI behaviors in a manageable way so that enhancements or modification is much simpler.  These are like swiss-army-knife, somebody use server side and client side features in balanced way, others may heavily stick with either server side or client side.  The major reason for people stick with server side code is to avoid client side script managebility.  Unlike ASP.NET controls those can be componentized in assemblies, JavaScript needs to be deployed separately in an uncontrollable way.  The problem with this are:

  • Resolving script path
  • Client side code control

Another problem is to decorate or extend a web control on demand basis is not standardized.

Forces

  • To apply new or common behaviors to one or more web controls without affecting the controls.
  • To send/generate extended feature set  on demand basis.
  • To encapsulate client side behavior (none other than JavaScript files) within ASP.NET server control assembly.
  • To separate group of concerns between client script and server side code.
  • To control control’s client script path.  
  • To manage and control’s client behavior.

Solution

Encapsulating client script with .NET assembly is one of the feature introduced in ASP.NET AJAX.   By this feature, ASP.NET 3.5 introduces “System.Web.UI.ExtenderControl” which enables you to extend or decorate one or more web controls without interrupting the actual controls.

ExtenderControl

ExtenderControl is the decorator here which in turn implements IExtenderControl interface. (See figure 1)

Figure 1

Figure 1

It contains two methods,

  • GetScriptDescriptors - Implementer can return collection of ScriptDescriptor, each can include client side script behavior such as client types to create, properties to assign and event handlers to register.  One nice derived class of ScriptDescriptor is ScriptBehaviorDescriptor.
  • GetScriptReferences – Implementer can return collection of ScriptReference, each can include actual JavaScript file detail.

From a decorator perspective, ExtenderControl facilitate you with some additional properties.  See figure 2.  It does not allow you for custom rendering. (See figure 2).

Figure 2

Figure 2

The TargetControlID is used to assign the extended behavior to a control in the page.

Example

In this example, you can understand how extender and its associated classes works, and how ASP.NET AJAX helps you to decorate a web controls and how to componentize client side behavior in to .NET assembly.  Figure 3 depicts how it is working.

Figure 3

Figure 3

Part 2 of this post will explain this in detail with sample.

Tags Tags: , , ,
Categories: ASP.NET
Posted By: udooz
Last Edit: 24 Apr 2009 @ 07 40 AM

EmailPermalinkComments (1)
\/ More Options ...
Change Theme...
  • Users » 1
  • Posts/Pages » 54
  • Comments » 39
Change Theme...
  • VoidVoid « Default
  • LifeLife
  • EarthEarth
  • WindWind
  • WaterWater
  • FireFire
  • LightLight