For The Developers! : LHS Feature Of The Week

WS08 Feature of the Week #14 - Sub-queues in MSMQ 4.0

jolson — Wed, 30 Jan 2008 00:19:03 GMT

What are sub-queues? Subqueues are implicitly created local queues that are logical partitions of a physical queue. Applications can use subqueues to group messages. Subqueues are implicitly created when opened, are deleted when empty, and have no open handles. Messages cannot be sent to a subqueue. Messages can be received from subqueues, moved between the main queue and its subqueue, or moved between a pair of sibling subqueues.

Subqueues do not have their own properties or state, but share the properties and state of their parent queue. For example, a subqueue does not have its own quota, access control list (ACL), or transactional type. Subqueues share the quota of the main queues. Messages in the subqueues consume the quota of the main queue. Subqueues cannot be created under journal and other system queues, or other subqueues. If journaling is enabled, copies of messages that are removed from a subqueue are sent to the journal queue of the main queue.

So why sub-queues? MSMQ-based applications often require messages to be grouped based on some criteria. Previously, the only way to do this was to create several queues and when a message arrived in the main queue, move the message into a specific queue based on some selection criteria.

Here’s the thing: moving messages between physical queues is a resource-intensive process. If you are wanting to build a high performance application, it is best to try to avoid this resource-intensive process. But if you were building an application based on MSMQ 3.0, this was not very feasible. Now, the new sub-queues feature enables you to logically group messages within a single queue without the need of creating another physical queue.

- MSDN Documentation

- WCF Examples

WS08 Feature of the Week #13 - Windows Process Activation Service (WAS)

jolson — Fri, 18 Jan 2008 22:11:57 GMT

What is Windows Process Activation Service? Windows Process Activation Service, also referred to as WAS, is a new component in IIS 7.0 that manages application pool configuration and worker processes instead of the WWW process. This enables the same configuration for both HTTP and non-HTTP sites to be used. Thanks to this separation (and in combination with the new modular architecture of IIS 7.0), you can even host non-HTTP sites without the WWW Service even being installed in the first place.

How does Windows Process Activation Service work? Taken directly from the documentation:

“The WAS process model generalizes the IIS 6.0 process model for the HTTP server by removing the dependency on HTTP. This allows WCF services to use both HTTP and non-HTTP protocols, such as Net.TCP, in a hosting environment that supports message-based activation and offers the ability to host a large number of applications on a given machine."

What scenarios does this enable? Since WAS is not specific to HTTP sites, you can use WAS to host non-HTTP sites as well. But what do we mean by “non-HTTP sites?” Well, simply put, WAS can be used to host sites built on technologies like Windows Communication Foundation, for example. If you are using WCF with WAS, are you limited to listening over HTTP? Not at all. In fact, that is the beauty and power of WAS. You can be hosting a WCF service within WAS that is using a netTcpBinding, netMsmqBinding, etc. As an extension to this, since WAS supports both HTTP and non-HTTP sites, this also means that you can be hosting a service that exposes itself over both HTTP and NET.TCP as well.

WS08 Feature Of The Week #12 - IIS7 Administration API

jolson — Fri, 11 Jan 2008 23:28:39 GMT

Hello everyone, and welcome back after our winter break hiatus. We have a lot of cool features to cover in the coming weeks that will especially show off the power of Windows Server 2008 as an application server. So, this week we will kick off the new year by taking a short little peek at the new management API coming in IIS7.

What is new in IIS7 Administration? IIS7 provides a comprehensive managed-code API that allows complete manipulation of the XML configuration files and convenience access to server objects. IIS7 includes Microsoft.Web.Administration, which is a new management API for the web server that enables editing configuration through complete manipulation of the XML configuration files and also provides convenience objects to manage the server, its properties and state. The configuration editing aspect of the API provides programmatic access to read and write configuration properties in the IIS configuration file hierarchy and specific configuration files. The object management aspect of this API provides a series of top-level administration objects for direct management of the server (i.e. sites, application pools, worker processes, etc.).

The management classes reside in the Microsoft.Web.Administration namespace. The classes provide a weakly-typed interface to access configuration sections and convenience objects with properties and methods representing attributes of the configuration (like the path of a virtual directory) or actions to take on the object (like recycling an application pool).

Resources

How To Use Microsoft.Web.Administration

LHS Feature Of The Week #11 - Transactional NTFS + USB Flash Drive

jolson — Sat, 02 Dec 2006 01:02:46 GMT

Hello everyone, and welcome back to the “Feature Of The Week” newsletter. This week, we will revisit a prior Fear Of The Week technology that we discussed in order to show off a cool capability of that technology. If you are a developer wanting to mess around with TxF (Transactional NTFS), you should especially read on :).

Did You Know? Did you know that on Vista, Transactional NTFS will work with an NTFS-formatted USB Flash Drive? It’s true! If you want to play around with Transactional NTFS and how it can interact with SQL, for instance, but you only have one hard drive, you don’t have to worry about Secondary Resource Managers and all that hubbub, gizmos, doodads, and what-cha-ma-call-its. Just pop in that NTFS-formatted USB Flash Drive, and play around until your heart’s content.

Since the USB Flash Drive is not the system drive (well, we hope it’s not the system drive in this case :P), you can circumvent the need for secondary Resource Managers when wanting to test out interoperability scenarios with Transactional NTFS (like TxF + WCF, TxF + SQL, TxF + MSMQ, etc.).

Happy Coding :).

Generic Transactional NTFS Links...

Documentation

Windows SDK

Videos/Webcasts

[Video] Vista Transactional File System
[Webcast] The Revolutionary Vista TxF Infrastructure
[Webcast] Developing Apps For Vista With TxF

Blogs

LHS Feature Of The Week #10 - Application Recovery and Restart

jolson — Sat, 02 Dec 2006 00:56:46 GMT

Hello everyone, and welcome back to the “Feature Of The Week” newsletter. This week’s newsletter will be short and sweet. We will go over the new Application Recovery and Restart API. The API itself is very small and very simple to use (which, in my opinion, is “A Good Thing” TM).

What is Application Recovery and Restart? Application Recovery is a set of technologies that give applications the opportunity to control what actions are taken on their behalf by the system when they (the application) fail.

If the application registers a callback with the RegisterApplicationRecoveryCallback function, the system will execute the recovery callback on application failure. The application can that take action to do things like attempting to recover documents. If the application has not registered for recovery, the system attempts to diagnose and report the problem.

If the application registered a callback with the RegisterApplicationRestart function, the system will automatically restart the application after the recovery or diagnosis is completed. If the application has not registered for restart, the system will simply close the application.

Documentation

Screencasts

Windows Vista Restart & Recovery APIs from Managed Code

LHS Feature Of The Week #9 - Restart Manager

jolson — Tue, 14 Nov 2006 03:21:22 GMT

Hello everyone, and welcome back to the “Feature Of The Week” newsletter. In this week’s edition of the “Longhorn Server Feature of the Week”, we will be taking a look at a new feature in Vista and Longhorn Server: the Restart Manager.

What is the Restart Manager? The primary reason software updates require a system restart during an installation or update is that some of the files that are being updated are currently being used by a running application or service. The Restart Manager enables all but the critical system services to be shut down and restarted and guarantees that blocking DLLs and resources are unloaded. This frees files that are in use and allows installation operations to complete.

Using the Restart Manager DLL, an installer can use the Restart Manager to register files that should be replaced during the installation of an application or update. Then during a subsequent update or installation, the installer can use the Restart Manager to determine which files cannot be updated because they are currently in use. Installers can direct the Restart Manager to shutdown and restart applications or services based on the file in use, the process ID (PID), or the short-name of a Windows service.

What scenarios does this enable? The Restart Manager API can eliminate or reduce the number of system restarts that are required to complete an installation or update.

Notes – Applications that use Windows Installer, version 4.0, for installation and servicing automatically use the Restart Manager to reduce system restarts. Custom installers can also be designed to call the Restart Manager API to shutdown and restart applications and services.

Resources

Documentation

LHS Feature Of The Week #8 - Windows Error Reporting

jolson — Tue, 14 Nov 2006 03:19:00 GMT

Hello everyone, and welcome back to the “Feature Of The Week” newsletter. This week, we take quick dive into some of the enhancements that have been made to Windows Error Reporting (WER) in Vista and Longhorn Server.

What is Windows Error Reporting (WER)? Windows Error Reporting enables users to notify Microsoft of application faults, kernel faults, and unresponsive applications. Microsoft can use the error reporting feature to provide customers with troubleshooting information, solutions, or updates for their specific problems. Developers can use this infrastructure to receive information that can be used to improve their applications.

What’s new in Windows Error Reporting? Windows Error Reporting isn’t actually new to Vista and Longhorn Server. However, there are some pretty cool enhancements to Windows Error Reporting that you can find in Vista and Longhorn Server. Developers can use the new API to create reports for many types of events, not just applications crashes and hangs. Also, developers can now create custom reports, customize the reporting user interface, and submit reports to Microsoft. Using Windows Quality Online Services, they then can access their report data, create solutions, and deliver these solutions to their users.

Resources

Documentation

LHS Feature Of The Week #7 - Boot Configuration Data

jolson — Tue, 14 Nov 2006 03:15:18 GMT

Hello everyone, and welcome back to the “Feature Of The Week” newsletter. This week, we will be looking at the robust replacement for boot.ini in Windows Vista and Longhorn Server: Boot Configuration Data.

What is Boot Configuration Data? Boot configuration data (BCD) provides a store that is used to describe boot applications and boot application settings. The objects and elements in the store effectively replace Boot.ini. The data in the store can be managed by a command-line utility, bcdedit.exe, or using the classes implemented by the WMI provider.

How does Boot Configuration Data work? When you start your computer, the first code that executes is the BIOS. The BIOS reads the master boot record (MBR) from the boot device and transfers control to the boot code stored in the MBR. The boot manager reads the boot entries from the Boot Configuration Data store so they are available to the loader and displays a boot menu to the user. The boot environment provides a native API for primitive graphics and other system support. Boot applications are pieces of code that are located on a boot device and run in the boot environment.

The following are examples of application objects:

• The Windows Boot Manager

• The Windows OS Loader

• The Windows Memory Tester

Example – Now, with the absence of the boot.ini file, this is how you would enable Kernel debugging on a system as a boot option: “bcdedit /debug true”

Resources

Documentation
- Windows SDK

LHS Feature Of The Week #6 - Windows Remote Management

jolson — Tue, 14 Nov 2006 03:13:08 GMT

Hello everyone, and welcome back to the “Feature Of The Week” newsletter. This week, we will take a short little peek at the new Windows Remote Management infrastructure in Vista and Longhorn Server.

What is Windows Remote Management? Windows Remote Management (WinRM) is the Microsoft implementation of the WS-Management protocol, a standard SOAP-based, firewall-friendly protocol that allows hardware and operating systems from different vendors to interoperate.

The WS-Management protocol specification provides a common way for systems to access and exchange management information across an IT infrastructure. WinRM and IPMI (Intelligent Platform Management Interface), along with the Event Collector, are components of the Windows Hardware Management features.

What scenarios does this enable? Using WinRM scripting objects, the WinRM command-line tool, or the Windows Remote Shell command line tool, you can obtain data from local and remote computers. You can also obtain hardware data from WS-Management protocol implementations running on non-Windows operating systems. WinRM can also supply standard WMI (Windows Management Instrumentation) data, but it handles remote connections via the SOAP-based WS-Management protocol rather than DCOM.

Resources

Documentation
- Windows SDK

LHS Feature Of The Week #5 - Task Scheduler 2.0

jolson — Tue, 14 Nov 2006 03:10:41 GMT

Hello everyone, and welcome back to the “Feature Of The Week” newsletter. In this fifth installment, we will take a short little peek at a series of enhancements coming in Vista and Longhorn Server to the Task Scheduler.

What is the Task Scheduler API? The Task Scheduler API is an API that enables you to automatically perform routine tasks on a chosen computer. The Task Scheduler does this by monitoring whatever criteria you choose to initiate the tasks (referred to as triggers) and then executing the tasks when the criteria is met.

What enhancements have been made in 2.0 over 1.0? The following Task Scheduler 2.0 changes are introduced in Windows Vista:

Isolating user actions in separate sessions
Credentials managements using new security services (S4U and CredMan)
Removed limitations on the number of registered tasks
API changes:
- Scripting support: interfaces are now derived from IDispatch, providing full support for script development
- Task Scheduler schema: allows you to create/manage tasks through XML-formatted docs.
- New Triggers: new time, calendar, and event triggers. All triggers support repetition, delay, start, and stop boundaries.
- Task settings: can now prioritize tasks, define multiple instance policies, start a task only when it is available or only if the network is available, restart on failure, and set an execution time limit
- New actions: a task can be scheduled to send an email, show a message box, start an exe, or fire a COM handler.

What scenarios does this enable? The Task Scheduler can be used to execute tasks such as starting an application, sending an email, or showing a message box. Tasks can be scheduled to execute:

When a specific system event occurs
At a specific time (even on a daily, weekly, monthly, or monthly day-of-week schedule)
When the computer enters an idle state
When the task is registered
When the system is booted
When a user logs on
When a Terminal Server session changes state

LHS Feature Of The Week #4 - Kernel Transaction Manager

jolson — Tue, 14 Nov 2006 03:07:21 GMT

Hello everyone, and welcome back to the “Feature Of The Week” newsletter. As mentioned last week, this week we will look at the component that enables new technologies like Transactional NTFS and the Transactional Registry in Vista and Longhorn Server: the Kernel Transaction Manager.

What is the Kernel Transaction Manager? The Kernel Transaction Manager (KTM) is a transaction management service. It makes transactions available as kernel objects and provides transaction management services to system components such as Transactional NTFS (TxF).

KTM is scalable; it will work on both large-scale applications and small-scale applications. KTM provides isolation across all types of operations, allowing a consistent view of data. You can use the transaction scope to “bracket” the sections of your application, providing atomicity for some operations and not others. KTM helps with concurrency problems. It does not affect performance, and it is available everywhere. KTM can be used to provide transactions for file management scripts and backups. During backups, KTM can provide a consistent snapshot between the registry, file system, and databases.

What scenarios does this enable? The Kernel Transaction Manager enables the development of applications that use transactions. The transaction engine itself is within the kernel, but transactions can be developed for kernel- or user-mode transactions, and within a single host or among distributed hosts. Transaction-aware applications have complete flexibility in the granularity with which they use transactions. For example, it is possible for an application to access some files under transactional control and access others using operations that are not part of a transaction.

Resources

Documentation
- Windows SDK

LHS Feature Of The Week #3 - Transactional Registry

jolson — Sat, 30 Sep 2006 03:28:59 GMT

Hello everyone, and welcome back to the “Feature Of The Week” newsletter. In this week’s newsletter, we will continue on the “Transactions Bandwagon” by discussing the Transactional Registry. This newsletter will be short and sweet as, truth be told, this feature still needs to have a bit more documentation than it has today.

So, sit back, relax, and enjoy the Longhorn Server Feature Of The Week!

What is the Transactional Registry? The Transactional Registry (TxR) is an enhancement to the Registry that allows all registry operations to be performed within the scope of a transaction. This is made possible by a new transaction infrastructure in the kernel that allows operating system services to participate in transactions via the new Kernel Transaction Manager.

What scenarios does this enable? The Transactional Registry (TxR) is also fully capable of communicating with the MS Distributed Transaction Coordinator, meaning that TxR operations can participate in transactions that are leveraging any other Resource Manager that DTC is capable of working with. What does this mean to you? It means that you can now have an application that not only encompasses database calls, operations to the file system, as well as operations to the Registry.

Preview: Next week we will take a look at the technology that makes the Transactional NTFS and Registry possible: the Kernel Transaction Manager. Stay stuned!

LHS Feature Of The Week #2 - Remote Differential Compression

jolson — Sat, 23 Sep 2006 02:32:00 GMT

[Update: Added link to RDC Whitepaper and blurb about RDC dogfooding in DFS Replication (thanks cfsbloggers)]

Hello everyone, and welcome to the second installment of the “Feature Of The Week” newsletter. This week, we will take a short little peek at a feature coming in Vista and Longhorn Server called Remote Differential Compression.

So, sit back, relax, and enjoy the Longhorn Server Feature Of The Week!

What is Remote Differential Compression? Remote Differential Compression (RDC) allows applications to synchronize data between two computers in an efficient manner. The synchronization efficiency is made possible by using compression techniques to minimize the amount of data sent across the network.

What makes RDC different from other differencing mechanisms? RDC is different from patching-oriented differencing mechanisms, such as Binary Delta Compression (BDC), which are designed to operate only on known versions of a single file. RDC makes no assumptions about file similarity or versioning. Because differences between files are computed on the fly, RDC is ideally suited for synchronizing files that are different or have been updated independently.

What scenarios does this enable? RDC is suitable for applications that move data across a wide area network where the data transmission costs outweigh the CPU cost of signature computation. RDC can also be used on faster networks if the amount of data to be transferred is relatively large and the changes to the data are typically small.

Dogfooding RDC. It's important to note that we are actively dogfooding RDC internally. One of the current examples of that dogfooding is that RDC is actively being used for DFS Replication, available on Windows Server 2003 R2.

Resources

Documentation
Code
- If you have the latest Windows SDK installed, you can find a simple Client/Server example using RDC in the following directory: %INSTALL_DIR%\Samples\winbase\RDC

Enjoy!

[Crosspost from Managed World]

LHS Feature Of The Week #1 - Transactional NTFS

jolson — Sat, 23 Sep 2006 02:17:00 GMT

Hello everyone, and welcome to the “Feature Of The Week” newsletter. In the Feature Of The Week Newsletter, we visit a new feature coming in Longhorn Server every week. The goal is that these are nice, short, and efficient to minimize the amount of effort required by you, the reader. With every Feature Of The Week, we will provide links to more resources in case you want to spend more time diving into the feature covered.

So, sit back, relax, and enjoy the Longhorn Server Feature Of The Week!

What is Transactional NTFS? Transactional NTFS is an enhancement to NTFS that allows all file operations on an NTFS file system volume to be performed within the scope of a transaction. This is made possible by a new transaction infrastructure in the kernel that allows operating system services to participate in transactions via the new Kernel Transaction Manager.

What scenarios does this enable? Transactional NTFS is also fully capable of communicating with the MS Distributed Transaction Coordinator, meaning that TxF operations can participate in transactions that are leveraging any other Resource Manager that DTC is capable of working with. What does this mean to you? It means that you can now have an application that not only encompasses database calls, but also operations to the file system as well (think of Document Management solutions). With transaction enhancements being made to the new SMB 2.0 protocol, you can also now contain distributed file operations within a transaction as well.

Resources

Documentation
- Windows SDK
Videos/Webcasts
- Video - Vista Transactional File System
- Webcast - The Revolutionary Vista TxF Infrastructure
Blogs
- Jim Johnson
- Jason Olson

Enjoy!

Longhorn Server Feature Of The Week

jolson — Fri, 22 Sep 2006 23:01:00 GMT

I am starting a new category/feature on this blog. It is something that I've started to do internally and I hope to share with all of you :).

The feature is called the Longhorn Server Feature of the Week. Every Friday, I will talk about a new/enhanced feature coming with Vista or Longhorn Server. They will be nice, short, and sweet. The goal is to make them short so that it doesn't take hardly time at all to read it, and will provide links to follow up on if you want to do some more investigation regarding the feature.

So, with that said, I'm going to post both last week's feature and this week's feature in a few moments.

Enjoy :).