Elczar Adame's Shared Points on SharePoint

Archive for November, 2007

IIS 7.0 Configuration System


 

IIS 7.0 Configuration System

Let us step one level higher in our exploration. At the base of Internet Information Services 7.0 in Windows Server 2008, is an innovated and XML-based configuration system is established. Unlike the IIS 6.0 metabase, the entire configuration state is in files and no in-memory configuration store is used. With an administrative protection, the configuration is portable by merely copying it to other Web servers or sharing it. Nevertheless, the same configuration file could now be centrally shared across the Web servers group.

Configuration Levels

The server-wide configuration setting is stored in applicationHost.config file located at %windir%\System32\inetsrv\config directory which could be delegated in the <system.webServer> section of the root web.config file for application level settings. Moreover, the machine.config and web.config files located at %windir%\Microsoft.NET\Framework\v2.0.50727\CONFIG\ directory remain the global configuration settings for .NET Framework and ASP.NET respectively, and the <system.web> section of the root <web.config> continues to provide the application level settings.

Organization of Settings

The configuration file is logically organized by section. A section is an independent group of settings that defines the operation and extensibility of the server or an application. Being an independent unit, it cannot be nested. Below is an illustration:

<applicationPools>

            <add name="DefaultAppPool" />

            <add name="Classic .NET AppPool" managedPipelineMode="Classic" />

            <applicationPoolDefaults>

                <processModel identityType="NetworkService" />

            </applicationPoolDefaults>

</applicationPools>

Sections can be assembled into a section group. But unlike a section, a section group does not define any server nor application operation. Its sole purpose is to hierarchically organize logically-related sections. For this reason, it could be nested for further groupings. In the applicationHost.config, the sections groupings are defined through <configSections>. Below is the illustration:

<configSections>

<sectionGroup name="system.applicationHost">

<section name="applicationPools" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />

</sectionGroup>

<sectionGroup name="system.webServer">

      <section name="asp" overrideModeDefault="Deny" />

     

</sectionGroup>

</configSections>

applicationHost Section Groups

The applicationHost.config, as we have mentioned earlier, contains the server-wide configuration settings/sections that are group into system.applicationHost and system.webServer. The former contains global settings employed by the Windows Process Activation Service, while the later is used by the Web server engine and modules.

Aside from the section groups, we can incorporate a <location> tag in the configuration file. It is often employed for locking and unlocking a configuration section, to manage the application level delegation. It is done by defining the overrideMode value of a specific site. In the illustration below, the default document could not be changed in the root web.config file; otherwise, it would fire an exception.

<location path="Sample Web Site" overrideMode="Deny">

            <system.webServer>

                  <defaultDocument enabled="true">

                        <files>

                              <clear />

                              <add value="default.aspx" />

                        </files>

                  </defaultDocument>

            </system.webServer>

      </location>

Schema and Other Configuration Files

The configuration system is charted by a declarative schema located at %windir%\System32\inetsrv\config\schema directory, including IIS_schema.xml for IIS configuration settings, ASPNET_schema.xml for ASP.NET configuration settings, and FX_schema.xml for other .NET Framework configuration settings. Note that we need not to make any changes on the schema files. However, if necessary for us to create a custom section, we could add a separate schema file on the same directory.

Aside for the applicationHost.xml file, we could experience the presence of administration.xml and redirection.xml configuration files in the %windir%\System32\inetsrv\config directory. The former holds the settings necessary for the Internet Information Services Manager tool, and the later contains settings necessary to point a Web server to a remote/shared configuration files and schema.

 Hoping I have shared something.

 

 

 

 

Advertisements

IIS 7.0 – ASP.NET Integration


 

IIS 7.0 – ASP.NET Integration

This paper is an attempt to précis the ground-breaking integration of IIS 7.0 and ASP.NET in the Web sever core of Windows Server 2008, emphasizing the significant facets engrossed by the integration, and a demonstration that implements ASP.NET Forms Authentication for non-ASP.NET content types.

Significant Facets

In my paper on Web Server in Windows Server 2008, I have pointed out that ASP.NET is no longer employed with the Web server as a standalone application framework. It serves by now as a platform for extending the IIS Web server, facilitating ASP.NET components to turn into constituents for its request processing pipeline.

In the previous versions of IIS, ASP.NET request is passing through a native IIS processing before it will be forwarded to an ASP.NET ISAPI assembly (aspnet_asapi.dll) for managed code processing. On the other hand, other content types may be accommodated through native IIS request processing, like in the case of static file, or by other ISAPI extensions. Thus, non-ASP.NET requests could not enjoy the ASP.NET managed modules.

In IIS 7.0, however, ASP.NET is no longer implemented as an IIS ISAPI extension. The native process model of IIS and the managed process model of ASP.NET are unified into a sole process model. With the integration of ASP.NET runtime, IIS 7.0 made both native (C++ API) and managed (ASP.NET) modules available to any type of request. In other words, ASP.NET modules are now relevant to any content type including ASPX page, HTML page, and other content types. Additionally, this integration results to a unified modules and handlers configuration. It has eliminated, furthermore, duplication of some strides in the request processing pipeline, such as authentication and authorization.

Demonstration

1.       As we have mentioned earlier, this section will demonstrate the extensibility of ASP.NET Forms Authentication to non-ASP.NET content types. We will start by creating a database using ASP.NET SQL Server Setup Wizard. To do this, let us open our Visual Studio Command Prompt and execute aspnet_regsql. In this demonstration, we will name our database as ASPNETDatabase.

2.    Using Visual Studio 2005, we will create a Web site and call it ASPNETWebSite.

3.    Subsequently, we will add two static files: an HTML page with a title of HTML Page, and an image file.

4.       After that, we will add a Login.aspx page, and we will include a Login control as:

<asp:Login ID="Login1" runat="server"></asp:Login>

5.    To preliminary implement Forms Authentication to our Web application, let us open our web.config file and change the <authentication> mode value from Windows to Forms, then we will add some values to our <authorization> element. The results will be:

 

<authentication mode="Forms"/>

<authorization>

            <deny users="?"/>

      </authorization>

 

6.    After completing the previous task, we will open our Intenet Information Services Manager and add a Web site, we will name it ASPNET Web Site, pointing the Content Directory to the location of our Web application.

7.    In the ASP.NET area of our ASPNET Web Site Home, let us do the following:

a.        Set Connection String: Server=ServerName;Database=ASPNETDatabase;User ID=UserName;Password=Password

b.    Add .NET User

8.       Lastly, we will add some values in the <modules> section of our applicationHost.config to make it <modules runAllManagedModulesForAllRequests="true">. It is located at %windir%\System32\inetsrv\config\applicationHost.config.

By default, even though that our application pool is set to Integrated mode, ASP.NET modules are configured with managedHandler precondition. It means that only ASP.NET request will be carried out by managed modules. Now, if we want to employ ASP.NET modules to all our requests, we can write the following in the web.config file of our Web application right after the <configuration> element:

<system.webServer>

            <modules>

                  <remove name="FormsAuthenticationModule" />

<add name="FormsAuthenticationModule" type="System.Web.Security.FormsAuthenticationModule" />

                  <remove name="UrlAuthorization" />

<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />

            </modules>

</system.webServer>

 

Otherwise, like what we have did in this step, we can set the runAllManagedModulesForAllRequests of the <modules> element to true to shape all managed modules to carry out any type of request notwithstanding of their repective managedHandler precondition.

 

9.    At this moment, we will notice the following:

a.    A corresponding application pool is created with an Integrated Managed Pipeline Mode. This means the ASPNET Web Site we have created benefits the IIS 7.0 and ASP.NET integration. Thus, ASP.NET forms authentication is functional even to our HTML pages and image file. To explore, you can downgrade it to Classic mode, and browse the site. There you will notice that the HTML page and the image file do not require authentication.

b.    Since our Web application is configured for forms authentication, Forms Authentication component is coordinately enabled in IIS,  and the connection string we have set is automatically reflected in web.config file of our Web application. This underlines the unified configuration results of the integration.

c.    The user we have provisioned is stored in the aspnet_Users table of our ASPNETDatabase.

10. Now, its time for us to explore http://Server Name:Port Number/File Name to appreciate the extensibility of ASP.NET Forms Authentication.

Hoping to share you something.

 

WCF in Windows Server 2008 – Part II


 

WCF in Windows Server 2008

Part II of II : non-HTTP Transports 

Groundwork

As we have brought up previously, the objective of this piece is to carve up basic and high-level considerations on Windows Communication Foundation in Windows Server 2008. We have focused on HTTP transport implementation in Part I, and we will hub on non-HTTP transports in this part. Along the demonstration section, we will seek to enhance our previous WCF service and WPF client applications, then we will attempt to put in plain words some of the fundamental codes.

Review

In the previous part, we have given attention on one of the three constituted technologies of Application Server Core in Windows Server 2008, the Windows Communication Foundation. It is a new service-oriented programming model, edged by .NET Framework 3.0, to intercommunicate and interoperate with other applications.

We have also mentioned that in hosting a distributed WCF application in the Internet Information Services 7.0, it entails employment of Windows Process Activation Service (WAS) to facilitate activation and communication over network protocols including HTTP, NET.TCP, NET.PIPE, and NET.MSMQ.

 

Non-HTTP Transports

In TCP-based communication, the messaging session between machines is established before exchanging data. Each machine is identified through a logical IP address. In the process of delivering a unit of information on a network, the TCP manages the fragmentation of message into packets (a unit of transported information), and the reassembly of the same message from packets. Moreover, the same protocol resends lost packets and guarantees that no data fragment is duplicated.

In the heart of WCF TCP transport is the TCP Port Sharing service. It is a Windows service that allows TCP ports, over Intranet, to be shared across applications that are using WCF for communication. By principle, it is faster than HTTP protocol, but it is no more than for WCF-WCF communication.

A named pipe, on the other hand, is an object in the Windows operating system kernel, including a section of shared memory. It can be employed to grant communication channel between processes on the same computer or between processes on different computers across a network. For WCF, moreover, it is employed using net.pipe schema and ideal for an on-machine implementation of message delivery between WCF applications.

MSMQ, running as an NT service, is one of the features of Windows Server 2008. It is employed by WCF for its queued communication using net.msmq schema. The MSMQ Managers manages message-transfer from a Transmission Queue to a Target Queue. Unlike other transports, queued transport puts into operation the isolation between service, client, and transport. Hence, the transacting parties can fall short without producing an effect on the real communication. Furthermore, it provides reliable communication in spite of failures of the sender and receiver by backing up the message in their corresponding message store.

To endow with consistent communication, MSMQ employs transactional messaging where message is communicated under a transaction. Transaction is a set of operations designed in such a way that if one operation fails, the entire transaction will not be sent to queue.

Additionally, MSMQ provides an asynchronous communication pattern. Hence, the sender needs not to wait for the message to be received and processed by the receiver. Sent message may remain in the Transmission Queue, based on the defined value, until it is sent to the Target Queue. Else, it will be transferred to a Dead Letter Queue.

Demonstration

1.    Primarily, we will verify if non-HTTP protocol is supported. Let us open our Internet Information Services Manager. Click our WCFService site, then click Bindings. In the Site Bindings dialog box we could identify the protocols that are supported.

2.    To complete the configuration, we will open the applicationHost.config file of our IIS at %SystemDrive%\Windows\System32\inetsrv\config directory and add some values to the <enabledProtocols> tag of our Web site. In this case, the results will be:

 

<site name="Default Web Site" id="1" serverAutoStart="true">

<application path="/WCFService" applicationPool="DefaultAppPool" enabledProtocols="http,net.tcp,net.pipe,net.msmq">

<virtualDirectory path="/" physicalPath="C:\inetpub\wwwroot\WCFService" />     

      </application>

      <bindings>

<binding protocol="https" bindingInformation="*:443:" />

<binding protocol="http" bindingInformation="*:80:" />

<binding protocol="net.pipe" bindingInformation="*" />

<binding protocol="net.msmq" bindingInformation="localhost" />

<binding protocol="net.tcp" bindingInformation="808:*" />

      </bindings>

</site>

 

NOTE: Enabled Protocols property does not have corresponding user interface in Windows Server 2008 Beta 3.

 

3.    Now we will open the WCF Service application we have created in Part I.

4.    In the Solution Explorer, let us open the Service.cs file.

 

Notice that the System.ServiceModel is being referenced. It is the namespace that brings Windows Communication Foundation to existence. As the name suggests, this is what we referred as WCF service model.

 

Other noticeable attributes that characterizes the service model are the [ServiceContract] annotation for the interface (dispatching) and the [DataContract] annotation for the data definition (serialization).

 

5.       Let us add a Namespace to our [ServiceContract] attribute and an Action named parameter to our [OperationContract] attribute. The results will be:

[ServiceContract(Namespace="http://tempuri.org/IService&quot;)]

public interface IService

{

    [OperationContract(Action="Operation:String")]

    string Operation(string Value);

    [OperationContract(Action="DataOperation:String")]

    string DataOperation(Profile Value);

}

An incoming SOAP message is dispatched to a corresponding method based on the Action attribute of an operation contract. Thus, a message with Operation:String action is identified with Operation method, its target operation contract.

 

6.       Upon enhancing our service contract, let us as well carry out basic enhancement on our [DataContract] attribute by adding a Namespace named parameter and some named parameters to our [DataMember] attribute. The results will be:

[DataContract(Namespace="http://tempuri.org/Profile&quot;)]

public class Profile

{

    string firstname;

    string lastname;

 

    [DataMember(Name="First", Order=0)]

    public string FirstName

    {

        get { return firstname; }

        set { firstname = value; }

    }

 

    [DataMember(Name = "Second", Order = 1)]

    public string LastName

    {

        get { return lastname; }

        set { lastname = value; }

    }

}

The data contract is defined for serialization, where the data in the incoming SOAP message is mapped to a corresponding .NET object. In the above code, the SOAP payloads to the .NET string data type. The [DataContract] annotation signifies that we are using the default serialization engine of WCF. This engine serializes fields annotated with [DataMember].

By data contract, WCF service communication is directed through the SOAP body. If required to channel data through header, we can create a message contract and specify the message header and message body fields respectively. To wit:

[MessageContract]

public class Message

{

    [MessageHeader]

    public HeaderMessage HeaderMessage;

 

    [MessageBodyMember]

    public BodyMessage BodyMessage;

}

7.    The next step is to revisit the service implementation we have made in Part I and do an enhancement on its behavior through [ServiceBehavior] attribute. The results will be:

 

[ServiceBehavior(Namespace="http://tempuri.org/IService&quot;, ConcurrencyMode=ConcurrencyMode.Multiple)]

public class Service : IService

{

    public string Operation(string Value)

    {

        return "Hello: " + Value;

    }

 

    public string DataOperation(Profile Value)

    {

        return "Hello: " + Value.FirstName + " " + Value.LastName;

    }

}

8.    Let us open our web.config file and extend our service endpoints to non-HTTP protocols by adding the following <endpoint> attributes to the <system.serviceModel> section of the file:

 

<endpoint binding="netTcpBinding" contract="IService" />

<endpoint binding="netNamedPipeBinding" contract="IService" />

Unlike in self-hosting, IIS hosting does not require us to specify the endpoint address because it is already provided by the location of our .svc file.

9.    Lastly, let us to build our enhanced WCFService.

10. Now, let us open the WPFClient Windows application we have created in Part I and update our Proxy service reference. To do this, right-click the Proxy.map file under the Service References folder, then click Update Service Reference.

11. In app.config file, we will notice additional entries for net.tcp and net.pipes protocols in both <bindings> and <client> sections. Since the service contract interface could not be loaded with multiple <endpoint> configuration, we need to select preferred endpoint in the <client> section, then omit the others.

12. With this, we could rebuild and execute our application enjoying various types of communication protocols.

Tag Cloud