Software Technology : Deep Dive

Working with Windows 7 Event Tracing using .NET:- Part 4

2012-03-31T08:28:00.000-07:00

Working with event trace sessions : Create and configuring trace sessions

Let see how to create trace sessions using a GUI based controller application. This GUI based controller application is non other than our perfmon.exe. Use the following steps to create new trace session for your custom provider.

Open performance monitor by running the perfmon.exe in command prompt.

Once performance monitor is opened, browse to Event Trace Sessions tree node. You will see Trace Sessions already configured to listen for event from system event providers. Our goal is to create a similar kind of trace session for our custom provider.

(j File Action View Window Help
•*hTU IL ___
Performance 1 Name Status
Monitoring Tools h Circular Kernel Context Logger Running
Performance Monitor Audio Running
3 Data CollectorSets Running
> User Defined
> F. System EventLog-Application Running
J Event Trace Sessions EventLog-DebugChannel Running
Startup Event Trace Sessions EventLog-ForwardedEvents Running
> E Reports EventLog-Microsoft-Windows-... Running
AppFabric Event Collector Sessi... Running
EventLog-Microsoft-Windows-... Running
EventLog-Microsoft-Windows-... Running
EventLog-System Running
Microsoft Security Client Running
Microsoft Security Client WMI ... Running
NtfsLog Running
EventLog-Working With ETW P... Running
UBPM Running
WcesLog Running
WdiContextLog Running
WMZuneComm Running
MpWppTracing-03112012-1204... Running
WUDFTrace Running
Trace session for custom provi... Running
EMSMQ Running
SftFS Running
MSDTC_TRAC E_SESSION Running" src="file:///C:/Users/armalik/AppData/Local/Temp/msohtmlclip1/02/clip_image001.png" width="376" height="384">

Right click on the right panel and click on New-> Data Collector Set. This will open 'Create New Data Collector Set' wizard.

SftFS Running
MSDTC_TRACE_SESSION Running
New Data CollectorSet
Refresh
Export List...
View
Arrange Icons
Line up Icons
Help" src="file:///C:/Users/armalik/AppData/Local/Temp/msohtmlclip1/02/clip_image002.png" width="489" height="327">

Wizard window.

k7j ® Create new Data Collector Set.
How would you like to Create this new data Collector set?
Name:
- Data CollectorI
‘ ‘ Create from a template (Recommended)
How cIa I ‘nork with templates?
G Create manually (Advanced)
How do I choose data collectors man n
[ Next 1 [ finish [ Cancel j" src="file:///C:/Users/armalik/AppData/Local/Temp/msohtmlclip1/02/clip_image003.png" width="497" height="384">

Provide Trace session name as 'Trace session for custom provider'. Click on 'Next' to open provider selection wizard view.

® Create new Data Collector Set.
Which event trace providers would you like to enable?
Eroviders:
[ Afld... ]
[ Remove j
Properijes:
Property value [ edit...
Next ] [ Finish j [ Cancel j" src="file:///C:/Users/armalik/AppData/Local/Temp/msohtmlclip1/02/clip_image004.png" width="497" height="384">

Click on 'Add' and select your custom provider from the list operating system has enumerated for all the registered providers. Our provider will also be listed here as we have already register it with the system. Click Ok to confirm the provider selection.

Choose Event Trace Provider:
LIÎ1 With ETW Provider
WPC Trace
WPD API Trace
WPD APISQM Trace
WPD Bluetooth MTP Emumerator Driver Trace
WPD BusEnumService Trace
WPD ClassExtension Trace
WPD Classlnstaller Trace
WPD Composite Driver Trace
WPD FSDriver Trace
WPD ShellExtension Trace
WPD ShellServiceObject Trace
WPD Types Trace
WPD WCNCSvc Trace
WPD WCNWizard Trace
WPD WiaCompat Trace
WPD WMflMCnmnat Trare
[ 0K N Cancel J" src="file:///C:/Users/armalik/AppData/Local/Temp/msohtmlclip1/02/clip_image005.png" width="388" height="384">

Which event trace providers would you like to enable?
Next ] [ Finish j [ Cancel j
Eroviders:
Working With ETW Provider
Properijes:
[ Agd... j
[ ßemove J
Property
value
Keywords(Any)
Keywords(All)
Level
Properties
4
0x0
0x0
0x00
0x00000000
‚„" src="file:///C:/Users/armalik/AppData/Local/Temp/msohtmlclip1/02/clip_image006.png" width="497" height="384">

Configure the trace session by customizing it to listen for specific keywords and verbosity levels. Select the keywords row from Properties list and click on 'Edit' button to view the available keyword name. In our case we see only two keywords which we defined in instrumentation manifest file.

G Authmabc
Value Des cription
ApplicabonsDevelopedForBankingDomain
Working With ET\1 Provider/Analytic
[ 0K ] [ Cancel ]
Applications Develc
Working With ETW
“,
Manual
0x800000000000000 1" src="file:///C:/Users/armalik/AppData/Local/Temp/msohtmlclip1/02/clip_image007.png" width="386" height="384">

Enable the check option for both the keywords values.

Similarly configure the required levels as well. After the configuration your wizard view show look as following.

Which event trace providers would you like to enable?
Eroviders:
Working with ETW Provider [ Afld... j
[ ßemove J
Properties:
Property value A [tZ]
Keywords(Any) 0x8000000000000001
Keywords(All) 0x0
Level 0x11
Properties 0x00000000
4 11E
Next ] [ Finish j [ Cancel j" src="file:///C:/Users/armalik/AppData/Local/Temp/msohtmlclip1/02/clip_image008.png" width="497" height="384">

Click on 'Next' button.

Provide directory path where your want to save the collected events data. What value you give here is important in case you want to view your events using Windows Event Viewer. To view your events using Event Viewer you must provider following directory path to save the events data.

%SystemRoot%\System32\Winevt\Logs\

Wizard view after providing the directory path.

® Create new Data Collector Set.
Where would you like the data to be saved?
Root directo,y:
%SystemRoot%\System32Winevt\Logs\J [srowse.JJ
Next Finish 1 [ Cancel j" src="file:///C:/Users/armalik/AppData/Local/Temp/msohtmlclip1/02/clip_image009.png" width="497" height="384">

Click on 'Next' button.

Change the option to 'Start this collector set now' as show in below image and click 'Finish' button.

Create the data oellector set?
Runas
cDetault>
. Qpen propeitles for this data collector set
t Ra.t this data colector set nod
•:‘saxeanddose
j fiet [ÐnishllCancdl" src="file:///C:/Users/armalik/AppData/Local/Temp/msohtmlclip1/02/clip_image010.png" width="497" height="384">

We are done with creating trace session and it is up and running. Ready to listen for the event published by your custom provider.

Trace session for custom provider Running
CircuIar Kernel Context Logger Running
P.nn;nn" src="file:///C:/Users/armalik/AppData/Local/Temp/msohtmlclip1/02/clip_image011.png" width="408" height="79">

At this point if you run the console application we created, trace session will collect all the published events this application will fire.

Working with Consumer application

Once we have create a trace session for a event provider, all the events from that provider are collected via trace sessions and are logged in log files. We will use Windows Event Viewer as Consumer application to view all the published events from our console application. Use the following steps to view the events.

Open Windows Event Viewer by running eventvwr.exe in command prompt.

Expand 'Applications and Services Logs' node. You will see a new entry has been created for the channel you had defined in instrumentation manifest file. Expand 'Working with ETW provider' and select 'Analytic' node to view all the events published by our console application .

k Event Viewer (Local)
Custom Views
E Windows Logs
4 Applications and Services Logs
BitLocker-Provisioning-Microsoft-IT
Hardware Events
Internet Explorer
fr] Key Management Service
frj Media Center
> ji Microsoft
fr] Microsoft Office Alerts
j Microsoft-lE
> ji Microsoft-IEDVTOOL
[, Microsoft-IEFRAME
I MPJLoq
Windows PowerShell
¿ i Working With ETW Provider
IR Analytic
fl Saved Logs
; Subscriptions
Analytic Pagel
J
Next Page [ ßacktoTop j
J_i To make this Analytic, Debug or Classic event log easier to navigate and manipulate, first save it in .evtx format by using the
Level
Date and Time
Source
Useful
15-03-2012 01:42:07
Working With ETW Provider
Useful
L
15-03-2012 17:09:52
Working With ETW Provider
„
Event 1, Working With ETW Provider
E &a I D eta
Person Eat Event. Person First Name Arun, Person Last Name Malik
X
Log Name:
Source:
Event ID:
Level:
User
QpCode:
More Information:
L
Working With ETW Provider/Analytic
Working With ETW Provider Logge4: 15-03-2012 01:42:07
1 Task Category Component Person
Useful Keywords:
Computer
Operation Eat
Event Log Online Help" src="file:///C:/Users/armalik/AppData/Local/Temp/msohtmlclip1/02/clip_image001.png" width="565" height="382">

Issue with Moles : Not able to read unit test configuration file when test case method is set to run under Moles host type.

2012-03-28T07:40:00.000-07:00

While writing unit test cases using moles to create fake objects, I came across an issue where, test methods were not able to the configuration file provided for unit test case assembly. This issue was occurring only when the test method were marketed with HostType("Moles") attribute. I verified the location of configuration file being used by checking the properties of AppDomain in which the test case method was running. Following is a screen shot of what I show.

It is clear from screen shot that the AppDomain was setup to use "Microsoft.Moles.VsHost.x86.exe.config" configuration file instead of using configuration file generated for the unit test case assembly.

After performing some debugging , I could find out that the problem was with the moles executable which I had installed using standalone moles installer. When you install moles using in standalone installer, moles instrumentation runtime (Microsoft.Moles.VsHost.x86.exe)does not set the AppDomain to use right config file (test assembly config), Instead AppDomain is set to use the configuration file of moles runtime executable.

To resolve this issue , I installed moles using Pex installer (download). when you install moles using Pex installer, moles runtime executable does set AppDomain to use right configuration file (config file of unit test assembly). See the below screen shot , ConfigurationFile property is now referring to unit test assembly's config file path.

Hence , using moles installed through Pex installer allows the test cases to happily read the config information provided in test case assembly's config file.

Working with Windows 7 Event Tracing using .NET:- Part 3

2012-03-15T13:20:00.000-07:00

Download sample code

Links : Part 1, Part 2, Part 4

Creating Event Provider Assembly and using it in your application.

In this article I will show you how to generate .NET c# provider code using MC.exe and compile the generated code into an assembly so that you can easily use that assembly in any of your application to write the events which you have defined in the manifest file.

Follow these steps to generate the provider code in .NET and to compile the code into a .NET assembly.

1. Generate .NET c# code with the help of the manifest xml file we have already created. Generated c# code is completely type safe and you do not need to worry about all the constants their values and where to use all those in the code. All this is handled by MC.exe. Use the following command in visual studio 2010 to generate the provider code in c# language.

MC.exe -h <target location> <namespace name for generated class> <manifest xml file path>

MC.exe -h c:\ProviderFiles CustomProvider c:\ProviderFiles\EventProviderManifest.xml

You will see the generated c# class file in your target location. Something similar to the following.

2. Generate an assembly by compiling the generated C# class file. Use the following in visual studio 2010 command prompt.

Csc.exe /out:c:\ProviderFiles\CustomProvider.dll /unsafe /t:library c:\ProviderFiles\EventProviderManifest.cs

You will see the generated assembly file in your target location. Something similar to the following.

Congratulation!

You have just created a custom windows event provider assembly which can be loaded in any of your .NET application to publish all your events defined in the instrumentation manifest file.

Let’s use the provider assembly we have just created in a .NET application to publish the events. I am creating a simple console based application which will publish person eat event. Code of console application is present in MyApplicationUsingMyProvider.cs file. Following is the code snippet for console application.

using System;

namespace MyApplicationUsingMyProvider

{

class Program

{

static void Main(string[] args)

{

CustomProvider.PROVIDER_GUID provider = new CustomProvider.PROVIDER_GUID();

provider.EventWritePERSON_EAT_EVENT("Arun", "Malik");

Console.WriteLine("Event published successfully.");

Console.WriteLine("Press any to exit...");

Console.ReadLine();

}

Note that how the MC.exe has used the symbol value from <Provider/> element from manifest xml to generate the class name. Refer Part 2

Let’s compile the MyApplicationUsingMyProvider.cs into a console application and run it. Use following commands in visual studio 2010 command prompt.

Csc.exe /out:<target exe path> /r:<path of custom provider dll> /t:exe <console app cs file path>

csc.exe /out:c:\ProviderFiles\MyApplicationUsingMyProvider.exe /r:c:\ProviderFiles\CustomProvider.dll /t:exe c:\ProviderFiles\MyApplicationUsingMyProvider.cs

You will see the generated console application in your target location. Something similar to following.

So, we have successfully created a custom provider and used it in a simple console based application. If you run that application and try to see the published events in either windows event viewer or any of the consumer application, you will be disappointed. Reason is that there is no link has been established yet between the consumer applications and your provider. This link is Trace session and we need to create one which will listen for the published events from our custom provider. In the Part 4 of this series I will show you how to use one of the GUI based controller application to create and configure Trace session which will listen and collect the published events from your provider.

Links : Part 1, Part 2, Part 4

Working with Windows 7 Event Tracing using .NET:- Part 2

2012-03-15T12:51:00.000-07:00

Download sample code

Links : Part 1, Part 3, Part 4

Working with Windows Instrumentation Manifest file

In this article, we will see how to create an instrumentation manifest file from scratch by defining a custom provider metadata and its supported events metadata in an xml file. We will use predefined xml elements and attributes for doing this.

Let’s create a blank xml file and add required elements one by one.
Add Element to Identify Provider: You can put more than one Provider information in single instrumentation manifest. To identify a particular provider, we use <Provider/> element and specify the values for following attributes.

Name: Name of your provider.
Guid: GUID to uniquely identity this provider in the system.
resourceFileName: Path of assembly in which the resource file generated after the compilation of
manifest file is embedded. We will see how the compile the manifest file.
messageFileName: Path of assembly in which the message file generated after the compilation of manifest file is embedded. We will see how the compile the manifest file.
Symbol: Used to refer the class of this provider in the code generated by MC.exe (manifest compiler).
Message: The localized display name for the provider. The message string references a localized string in the stringTable section of the manifest.
Sample xml snippet:

Add Element to define channels: Channels are used by Consumer applications like Windows Event Viewer to collect events for certain group of audiences. You use <channel />Element to define new channels. Values for the following attributes must be provided in each <channel/> element.
Chid: An id to uniquely identify the channel in the list of channels defined under a provider. This same attribute is used to attach the channel with specific event type defined using <Instrumentation\Events\Provider\Event/> element.
Name: Name of channel, must be unique among all the channels defined in same provider element.
Type: This value can be set to one the four types: Admin, Analytic, Debug and Operational. Component should write events under correct channel types, as each channel type is used by different set of audiences to analyses the application issues.
Enabled: To specify if the channel is enabled or not.
Isolation: Isolation level defines access permissions for the channel. There are three isolations are available: Application, System and Custom.
Message: The localized display name for the channel. The message string references a localized string in the stringTable section of the manifest.
Sample xml snippet:

Add Element to define Severity levels: Severity levels are used to group the published events. These are also used by consumer applications to query the events and trace session uses them to limit the events which are provided to consumer applications in real time or written in log files. You use <level />Element to define new levels. Values for following attributes must be provided in each new level element.
Name: Name of the Level. Must be unique among all the levels defined under same provider.
Value: Level value. It can be between 16 to 225.
Symbol: Used to refer the constant created for this Level in the code generated by MC.exe (manifest compiler).
Message: The localized display name for the channel. The message string references a localized string in the stringTable section of the manifest.
Sample xml snippet:

Add Element to define task and opcodes: Tasks and opcodes (operation codes) are used to logically group the published events. You define new tasks for each component of your application and a new opcode for each type of operation performed in that component. Because of this grouping consumer applications can easily query for events published for particular operations performed in particular component. You use <task />Element to define a new tasks and use <opcode /> element to define task specific operation codes. Values for the following attributes must be provided in each new <Task/> element.
Name: Name of the Task. Must be unique among all the levels defined under same provider.
Symbol: Used to refer the constant created for this Task in the code generated by MC.exe (manifest compiler).
Value: Value assigned to the Task. It can be between 1 to 239.
Message: The localized display name for the channel. The message string references a localized string in the stringTable section of the manifest.
Sample xml snippet:

Add Element to define Keywords: Keywords are used to classify different types of events. You might create one keyword to classify all your database accesses in your application and another one to classify write accesses to the database. You associate keywords with events when you define new events using <event> element. Keywords are used by consumer applications to limit the number of events it listens for. You use <keyword /> element to define a new keywords. Values for the following attributes must be provided in each new <keyword /> element.
Name: Name of the Keyword. Must be unique among all the Keywords defined under same provider.
Mask: Bit value assigned to the Keyword. This value is checked by Trace Sessions to limit category of events they want to listen for. You can specify bit values in the range from 0x0000000000000001 through 0x0000800000000000 (bits 0 through 47).
Symbol: Used to refer the constant created for this Keyword in the code generated by MC.exe (manifest compiler).
Message: The localized display name for the channel. The message string references a localized string in the stringTable section of the manifest.
Sample xml snippet:

Add Element to define event data Template: Each published event carry some data with it. This data has specific meaning in the context of published event. You use <template /> element to define a new data template. Values for the following attributes must be provided in each new <template /> element and use <data /> element to define template specific data items.
Attributes of Template element
Tid: unique identifier of the template defined in the provider.
Attributes of Data element.
Name: Name assigned to the data item.
Type: Data type for the data item.
Sample xml snippet:

Add element to define Events: Each provider defines all the events it can publishes in manifest file. You use <event/> element to define each new event. Attributes you set in <event/> element are based on who is going to consume your published events. Following are attributes you set in <event/> element.
Value: The event identifier. The identifier must be unique within the list of events that you define for your provider.
Level: Level of verbosity. This value either comes for the Levels you have defined or from the level predefined in winmeta.xml. If your event is targeting Admin channel, you cannot use your custom level value. Only possible values for Admin channel events are win:Critical, win:Error,win:Warning and win:Information.
Symbol: Used to refer the event descriptor created for the event in the code generated by MC.exe (manifest compiler).
Message: The localized display name for the channel. The message string references a localized string in the stringTable section of the manifest. To add event specific data items in message use substitution parameters. For Example to use third data item in you message use %3.
Template: An identifier of the template that defines all the data items an event can carry along with it. Specify the identifier of a template that you defined in the manifest.
Task: The name of a task that identifies the component or subcomponent that generates this event. Specify the name of a task that you defined in the manifest.
Opcode: The name of an opcode that identifies an operation within the task. Specify the name of an opcode that you defined in the manifest or one of the opcodes defined in Winmeta.xml.
Channel: If your users are going to Windows Event Viewer to view your published events, this attribute should be set with one of the channel you have defined manifest.
Sample xml snippet:

Download complete manifest file from sample code.
At this stage, we have successfully completed an instrumentation manifest file. Next step is to register all the information defined in manifest file with Operating system. Once registered, operating system can fetch this information at the time you create new trace sessions or in inside Event Viewer to parse your message data elements and show them at proper places in the view.
Follow these steps to register the manifest with operating system.

1. Compile the manifest file and generate message file. Use following command in visual studio 2010 command prompt.
MC.exe -r <target location> <manifest file path>
MC.exe -r c:\ProviderFiles EventProviderManifest.xml
You will see the generated files in your target location. Something similar to the following

2. Generate native resource file from message file you just created in above step. Use following command in visual studio 2010 command prompt.
RC.exe <message file path>
RC.exe c:\ProviderFiles\EventProviderManifest.rc
You will see the generated native resource file in your target location. Something similar to the following.

3. Generate a .NET assembly and embed the native resource file you have just created in above step. Use the following command in visual studio 2010 command prompt.
csc.exe /out:<target assembly path> /win32Res:<resource file path> /t:library <some .cs file path>
csc.exe /out:c:\ProviderFiles\EventProviderManifest.dll /win32Res:c:\ProviderFiles\EventProviderManifest.res /t:library c:\ProviderFiles\temp.cs
You will see the generated assembly in your target location. Something similar to the following.

4. Next step is to update the instrumentation manifest file by updating the resourceFileName and messageFileName attributes of Provider element. Something similar to following.

5. Last step is to register manifest xml file with operating system by running the following command. Use visual studio 2010 command prompt to run this command.
Wevtutil im <instrumentation manifest file path>
Wevtutil im c:\ProviderFiles\EventProviderManifest.xml
If the above command runs successfully, you have registered the manifest with operating system successfully.
Till now we have seen how to work with instrumentation manifest and register it with the operating system. In part 3 of this series, I will show you how to create a provider assembly, which can be used in your applications to publish all the events you have defined in instrumentation manifest file.

Links : Part 1, Part 3, Part 4

Working with Windows 7 Event Tracing using .NET:- Part 1

2012-03-15T10:44:00.000-07:00

Download sample code

Links : Part 2, Part 3, Part 4

Event Tracing Architectural components

Instrumentation Manifest: This is an XML file used to define the metadata about events you want to publish from your application using Windows ETW APIs. Same metadata is used by operating system, consumer applications and trace sessions to understand the meaning of published event and its content.

See how to create an instrumentation manifest file from scratch.

Event Provider: Event provider can be any application or component which is using ETW APIs and publishing windows tracing events. Generally you put all your code specific to ETW APIs in a separate assembly and use it in all your applications to publish the events. Each provider is associated with an instrumentation manifest file, which defines all the possible events your provider code can publish.

See how to create a provider assembly and use it in your application to publish events you had defined in instrumentation manifest file.

Trace Sessions: Trace Sessions listens for all the events published by your event provider. Event provider does not know what all Trace sessions are listening for the events it is publishing. Multiple trace sessions can be created to listen for the events created by single provider. Trace sessions are created and configured using controller applications. See how to create and configure a Trace session.

Event Consumers: These are the applications which use Trace sessions as the source of the events. Same consumer application can listen for multiple trace sessions at same time. It can listen for the events in real time from the trace sessions which are configured to put the events in memory buffer or from log file generated by trace sessions configured to put events in log file. See how to use Windows Event Viewer, standard event consumer application provided by operating system.

Session Controllers: These are the applications you use to create new trace sessions and configure them to listen for the events published by your event providers.

See how to work with GUI based session controller application.

Below figure shows how all these components are logically associated with each other.

Now we know the high level component of windows event tracing infrastructure. A developer has to work with all these components to successfully enable their application to use windows event tracing.

In the next articles of this series, I will show you how to define your custom events using instrumentation manifest file, create your own event provider assembly which can be used in any of your application to publish custom events. I will also show you how to configure new Trace Sessions which will listen to your custom events and how to view all the collected events using Windows Event Viewer.

Links : Part 2, Part 3, Part 4

WCF Extension Points, How to extend WCF framework to add custom features in WCF runtime.

2012-02-23T10:54:00.000-08:00

In one of my SOA based software system, I had a requirement of intercepting the service method calls to automatically logging the method calls on entry and exit of the service method call without putting any logging statements inside the service method implementation and to have some default exception handling logic again without putting any try catch blocks inside service method implementation. The implementation of these features was giving us more cleaner implementation of business functionality inside service methods by abstracting away the implementation of crosscutting concerns like exception handling or logging in my case.

To implement the above feature I was looking for the way to get execution control even before it goes to my service methods. Good news is that WCF itself helped me and gave the control with the help of it's extension points. Lets see how?

Proxy and Dispatcher

WCF works on messages which are send between client and service. Every time client wants to call a service method, it sends a message to service with help of Proxy running in the client process. Job of the Proxy is to take the client request and convert it into a message which is than further serialized and transferred to the service. At service end this message is received by Dispatcher. Dispatcher takes the message and desterilizes the content into appropriate CLR type, finds out which method has to be called on behalf of the client and calls that method.

Both Proxy and Dispatcher provides many extension points using different interfaces. When you implement these interfaces in your own class and register those class with WCF runtime (we will see how?), Both Proxy and Dispatcher calls the implementation in your class at the time of message processing.

Lets see what all interfaces are provided via WCF framework to intercept the message processing.

IParameterInspector : Called before and after invocation to inspect and modify parameter values.

IDispatchMessageFormatter/IClientFormatter : Called to perform serialization and deserialization.

IDispatchMessageInspector/IClientMessageInspector : Called before send or after receive to inspect and replace message contents.

IDispatchOperationSelector/IClientOperationSelector : Called to select the operation to invoke for the given message.

IOperationInvoker : Called to invoke the operation.

Registering your inspector class with WCF runtime

You use WCF behaviors to register your inspector classes with WCF runtime. When the ServiceHost initializes the service, it looks into app.config/web.config file for the behaviour to apply and also reflects over all the attributes applied on service contract methods to check if any attribute has been applied which is implementing any behaviour interface. If it finds one, it creates an instance of that attribute type and calls appropriate methods of behaviour interface, implemented by attribute class, to you give you a change to register your interceptors during service initialization. There are following types of behaviors provided via WCF

IServiceBehavior: Allows you to register your inspectors at Service level.
IEndpointBehavior: Allows you to register your inspectors at Endpoint level.
IContractBehavior: Allows you to register your inspectors at Service Contract level.
IOperarionBehavior: Allows you to register your inspectors at each Operation level.

All these behavior interfaces are having same methods but the method signatures are different so that your only get those runtime objects which comes under the scope you want to extend. Following are the methods available in each behavior interface.

Validate: Called just before the runtime is built—allows you to perform custom validation on the service description.

AddBindingParameters: Called in the first step of building the runtime, before the underlying channel is constructed—allows you to add parameters to influence the underlying channel stack.

ApplyClientBehavior: Allows behavior to inject proxy (client) inspectors. this method is not present on IServiceBehavior.

ApplyDispatchBehavior:Allows behavior to inject dispatcher inspectors.

Now you know what all classes and interfaces are available from WCF to extend its runtime, lets extend the runtime to intercept the service method calls and log the entry and exit of method call automatically (without writing logging code in service method implementation).

Following are the classes involved in my solution. To make the sample as simple as possible I have create all these classes and interfaces in single WCF project.

Code for LoggingAttribute.

Note how this class is inherited from Attribute class and implementing IOperationBehavior. Methods of IOperationBehavior will be called by ServiceHost at the time of service initialization process to give you a chance to register your inspectors. In this example I am registring LoggingInspector instance.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Web;

using System.ServiceModel.Description;

namespace SampleService

{

public class LoggingAttribute : Attribute, IOperationBehavior

{

public void AddBindingParameters(OperationDescription operationDescription, System.ServiceModel.Channels.BindingParameterCollection bindingParameters)

{

//for this example no implementation is required in this method.

}

public void ApplyClientBehavior(OperationDescription operationDescription, System.ServiceModel.Dispatcher.ClientOperation clientOperation)

{

//for this example no implementation is required in this method.

}

public void ApplyDispatchBehavior(OperationDescription operationDescription, System.ServiceModel.Dispatcher.DispatchOperation dispatchOperation)

{

//Register your inspector class

dispatchOperation.ParameterInspectors.Add(new LoggingInspector());

}

public void Validate(OperationDescription operationDescription)

{

//for this example no implementation is required in this method.

}

Code for LoggingInspector.

See how LoggingInspector is implementing IParameterInspector interface and providing the logging functionality.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Web;

using System.ServiceModel.Dispatcher;

namespace SampleService

{

public class LoggingInspector : IParameterInspector

{

public void AfterCall(string operationName, object[] outputs, object returnValue, object correlationState)

{

//Your can put any logging code here. here is the dummy one.

Console.WriteLine(string.Format("Method exit : {0}",operationName));

}

public object BeforeCall(string operationName, object[] inputs)

{

//Your can put any logging code here. here is the dummy one.

Console.WriteLine(string.Format("Method entry : {0}", operationName));

return null;

}

Code for ISampleService service contract interface.

Here I am applying my own custom attribute to enable automatic logging on IncrementNumber method.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Runtime.Serialization;

using System.ServiceModel;

using System.ServiceModel.Web;

using System.Text;

namespace SampleService

{

[ServiceContract]

public interface ISampleService

{

[OperationContract]

[Logging]

int IncrementNumber(int number);

}

Code for SampleService implementation.

Note that there is no logging related implementation inside IncrementNumber method implementation.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Runtime.Serialization;

using System.ServiceModel;

using System.ServiceModel.Web;

using System.Text;

namespace SampleService

{

public class SampleService : ISampleService

{

public int IncrementNumber(int number)

{

return number++;

}

Why WCF when there are other technologies to implement distributed software systems?

2012-02-23T08:23:00.000-08:00

Need for distributed software systems.

How do you create distributed application?

At architectural level you design your software systems by breaking the business functionality into multiple components and than deploy these components on separate process and machine boundaries. All these components running on separate process and machine boundaries has to have some communication between them using some protocol so that they can collaborate to achieve the overall business functionality.

There have been many technologies available to develop the components and deploy them in distributed manner. Following are some the examples

.Net Remoting

COM and DCOM
CORBA and RMI
Microsoft Enterprise Services

So what's wrong in using the above technologies to create distributed apps?

There is nothing wrong creating a distributed application using these technologies until your application is going to be used outside the organization or department and not going to interact with other applications in future. When the need to interact with other application comes in, it becomes really hard to achieve the desired interaction among applications because of the mismatch in data structures and protocol stack between your and other applications. Interoperability becomes an issue because of proprietary standards and protocol stacks used to develop the applications. Other than interoperability issues, all these technologies has a limitation where firewalls can block the communication between components.

How do you tackle with interoperability among distributed components?

We use web service technology in which components are exposed to other components using xml based open web standards (SOAP , WSDL, HTTP). These standards are acceptable throughout the software industry. As these standards are based on XML and HTTP which are supported on all platforms, components exposed using these standards are easily accessible between different platforms, ex a components running on windows platform can be accessed via components running on Unix platform. Following are some of the web service elements which makes interoperability possible.

Standard protocol: Functionality is exposed via interfaces using one of the few standard Internet protocols such as HTTP, SMTP, FTP, and so on. Mostly used protocol is HTTP.

Service description: Web services need to describe their interfaces in detail so that a client knows how to “consume” the functionality provided by the service. This description is usually provided via an XML document called a WSDL document. (WSDL stands for Web Services Description Language.)

Finding services: Users need to know what web services exist and where to find them so the clients can bind to them and use the functionality. One way for users to know what services exist is to connect to the listing of services. These listings are implemented via Universal Discovery, Description, and Integration (UDDI) repositories.

From above text it should be clear that there are many technologies available to implement distributed components with there own specific advantages and disadvantages and you should web services to expose your components outside your organization or department boundaries because of its open standards support all around in software community.

Now imagine that your organization or department needs to develop an application which has to be used internal to your organization and will also be accessed from outside your organization or department. You might go and use .NET Remoting to expose your serviced components for internal users and will have to used web services to expose same components to the users outside your organization. But if you do this your code base for the components will have the knowledge for both the technologies being used to expose the functionality as a service. Your developers will be investing more time in dealing with the technology implementation rather than the business functionality implementation.

What if you can abstract away the fact from your code base that your component is going to be exposed using multiple protocols and technologies? What if you can enable or disable any protocol in your already running component without stopping it or doing any code changes? All these features were kind of dream before WCF came in market.

WCF introduction

(Develop once and use anywhere)

WCF is new Microsoft technology, actually a framework build upon .NET framework, which makes it really easy to develop serviced components and deploy them using multiple communication protocols. It supports net.tcp, net.pipe, HTML, HTTPS and MSMQ communication protocols. Biggest advantage of using WCF is that the knowledge of what all protocols are being used to expose your component is completely abstracted from the component code. WCF framework is highly extendible as well. It provides so many extension points using them your can implement your own protocols and control almost all the expects of exposing your component as service.

Following are main goals of WCF

Unification of existing technologies: WCF subsumes the best of all the distributed technologies. WCF brings together the efficiency of ASMX, the gift of merely adopting transactions with Enterprise Services just through using attributes, the extensibility and flexibility of .NET Remoting, the supremacy of MSMQ for building queued applications, and WSE’s interoperability through WS-*. Microsoft took all these capabilities and built a single, steady infrastructure in the form of WCF.

WCF As a Service-Oriented Development Tool: WCF offers that foundation for service-oriented applications by supporting all the four tents of SOA mentioned in my post.

Coexisting with Existing Technology: WCF takes all the capabilities of the existing technology stacks while not relying upon any of them. All your existing investments will run side by side with WCF. Applications built with these earlier technologies will continue to work unchanged on systems with WCF installed. It also provides you with an opportunity to communicate with, or even replace, existing Windows communications APIs and technologies, including ASMX, ASP.NET web services, Web Services Enhancements (WSE), Enterprise

Services, System.Messaging, and .NET Remoting.

Service Oriented Architecture

2012-02-03T10:38:00.000-08:00

Problem :

In todays business environment, where customer requirements and demands are changing frequently and businesses are operating in heterogeneous markets, business process automation requirements are becoming more complex and new changes to business processes are coming so frequently. Business are asking for software systems which are highly integrated, easy to modify , highly scalable and customizable so that the changes to business processes and requirements can be accommodated easily with less cost and efforts.

To achieve all these business need, software systems has to be highly modular, business functionality from different business units should be divided into distributed components and these components should be accessible in location transparent way and should be highly interoperable. System components should be deployed across process and machine to deal with performance bottleneck, to introduce security boundary and to facilitate enterprise level reuse.

Question is how do we do it?

Here, Service Oriented Architecture Comes as rescue. SOA is an architectural style or I would say a reference architecture which guides architects on, how they should decompose business functionality into components and how does the functionality of these components is available to other components. SOA brings the concepts of public contracts, policies and interoperability. Because of these concepts, system components can communicate with each other without worrying about the technology, other component has been implemented. SOA also posses some constraints on component design and the design of communication links between components.

What is Service?

The term service has different meaning at different level of abstractions. At system architecture level, service is a business functionality which is distributable and is accessible to consume in some way. It is a window through which business functionality cab be reached.

Consider the application architecture in Following figure. The client application represents an Agency Management

System that includes many chunks of business functionality such as Certificate Issuance, General Ledger, CRM, and Reporting. The client application coordinates access to these features by consuming business components directly. In

this case, components are not distributable in such a way that they can be location transparent, thus they are not services.

So how do you implement a service in SOA?

You expose your system components as serviced components using different distributed technologies. Some of the technologies you can use are : Enterprise Services, a .NET Remoting component, an ASMX web service , or a WCF service. Any of these technologies can be useful in exposing the business logic in such a way that the client can reach that functionality at remote locations in a distributed environment, without communicating directly with the business

components.

Following is an updated diagram of Agency Management System. Here each business functionality is exposed using one of the distributed technologies. Serviced components are reached using DCOM over TCP,.NET Remoting components via RPC over TCP,ASMX web services via SOAP over HTTP, and WCF services via SOAP over any protocol.

The point is that services are not necessarily web services—they are merely chunks of business functionality exposed in some way such that they respect the tenets of SOA.

Some of the constraints SOA poses on serviced components

Service boundaries are explicit : Services are responsible for exposing a specific set of business functionality through a well-defined contract, where the contract describes a set of concrete operations and messages supported by the service. Services completely encapsulate the coordination of calls to business components in response to operations it exposes to clients. Implementation details behind the service are unknown to clients so that any technology platform could be invoked behind the service without impact to the client. In addition, the location of the service isn’t important to the client as long as the client knows where to reach it. All the distributed technologies provide a way to expose your system components by following this constraint.

Services are autonomous : Services encapsulate business functionality, but they must also encapsulate other dependencies of the business tier. In this way the entire service should be moveable or even replaceable without impact to other services or system functionality. A service represents a major chunk of business functionality that owns its own business components, data access components and data storage if applicable. It should be able to perform key functions without external dependencies. This is what is meant by atomicity.

Clients and services share contracts, not code : As service boundaries are explicit, Contracts are used to define this boundary to client application. The contract must not change once published, or must at a minimum remain backward compatible to existing clients.

Compatibility is based upon policy: While contracts describe the business functionality available at a service boundary, policy describes other constraints, such as communication protocols, security requirements, and reliability requirements.

If the above information is useful, Please provide your valuable feedback.

Thanks.

Hosting WCF/Workflow Service in IIS directly from Visual Studio 2010 and start debugging by just hitting F5 on Visual Studio.

2012-02-01T11:25:00.000-08:00

Problem :
When you develop a WCF/Workflow service using Visual Studio and try to run it, by default Visual Studio runs it under web development server. Here the problem is that the web development server is a light weight host and does not support reach features which comes with IIS. For example web development server does not allow you to run a WCF/Workflow service, which is configured to use NET TCP binding. There are many more such features which does not come with web development server.
As a developer we all want to, just hit the F5 button and start debugging. But if your WCF/Workflow service is configured in such a way that it can only run under IIS, it becomes really tricky to start debugging it.
The common approach we generally follow is to find out in which w3wp.exe our service is running and than attach the Visual Studio to that process.
In following text, I have shown another approach in which Visual Studio can be configured to run together with IIS. With this configuration your WCF/Workflow Services runs under IIS as soon you hit the F5 and you can start debugging without any hassles.

Create WCF/Workflow service. See how to create basic Workflow WCF Service.

Configure IIS to host your WCF/Workflow service.

(Note :- You can skip following steps if you already a some IIS website configured on port 80 and NET

TCP binding is configured. )

Open IIS Manager.
Add new application pool.

Select 'Application Pools' node from the left hand side tree view.

Click on 'Add Application Pool' link from 'Actions' panel at right hand side.
Give Some name to your application pool. I have given name as 'WorkflowService'. In below steps I will refer your application pool as 'WorkflowService'.
Change .Net Framework Version to 4.0
Click 'Ok'

Add new 'Web Site Application' for your services.

Select 'Sites' node from the left hand side tree view.
Right click on 'Sites' node and click 'Add Web Site'
Give Some name to your Web Site. I have given name as 'WorkflowService'. I have given name as 'WorkflowService'. In below steps I will refer your website as 'WorkflowService'.
Change Application Pool name to 'WorkflowService'
Provide some directory path to create IIS virtual directory for this new web site.

Provide host name as 'localhost'

Click 'Ok'

(Note : While clicking on Ok button you might get a message saying that some other website is already configured to run on port number 80. You just need to close the already running website and start your newly created website.)

Configure NET TCP Binding

Right click on 'WorkflowService ' web site and click on 'Edit Bindings' to open 'Site Bindings' dialog.

Click on 'Add' button to open 'Add Site Binding' dialog.

From 'Type' dropdown select 'net.tcp'.
Type 808:* in Binding Information text box.
Click Ok.

Enable NET TCP Binding on Web Site.

Select 'WorkflowService' website node from left hand side tree view.

Click on 'Advanced Settings' from 'Actions' panel at right hand side.
Update 'Enabled Protocols' field by adding comma delimited value as 'net.tcp' at the end of the existing value.
Click 'Ok'

Configure Visual Studio Project settings to use IIS as service host instead of default web development server.

Select your service project in Solution Explorer and press ALT+ENTER to open project properties dialog.
Click on 'Web' tab on project properties dialog.
On 'Web' tab page, select 'Use local IIS Web Server' radio button.

Click on 'Create Virtual Directory' button to link your website project with IIS.

(Note: This step will fail if Visual Studio is not running in Administrator privileges.)

At this stage you have successfully configured IIS and Visual Studio to work together and help you debugging your WCF/Workflow services by just hitting on F5 button on Visual Studio.

If the above information is useful, Please provide your valuable feedback.

Thanks.

Create Workflow WCF Service using Visual Studio 2010.

2012-02-01T06:16:00.000-08:00

Create Workflow WCF Service.

Open Visual Studio 2010.

Setup the Workflow WCF Service project using 'WCF Workflow Service Application' template.

Rename ‘Service1.xamlx’ to ‘WorkflowService.xamlx’.

Update 'ReceiveRequest' Activity properties.

Open the Property Window for ‘ReceiveRequest’ activity.

Change ‘OperationName field value to ‘PingService’.

Change ‘ServiceContractName’ to ‘WorkflowService.IWorkflowService’.

Update Workflow Variables in 'Variables' pane.

Click on 'Variables' tab just below the Workflow Designer Area to open it.

Change the 'Variable Type' column of 'data' variable to 'String' type.

Add new activity to implement some logic for Workflow Service.

Open ToolBox Window.

Open 'Primitives' Category.

Drag ‘InvokeMethod’ activity between 'ReceiveRequest' and 'SendResponse' Activities on Workflow Designer.

Write some code which will be invoked by workflow.

Add new class to project with name ‘WorkflowServicePingImp’.

Add a static method to the ‘WorkflowServicePingImp’ class with the name ‘PingResponse’. This method will take a string argument and return a string value as response.

Compile the solutions.

Update 'InvokeMethod' Activity properties to invoke our implementation from 'WorkflowServicePingImp' class.

Open the Property Window for ‘InvokeMethod’ activity.

Change the 'TargetType' field value to ‘WorkflowServicePingImp’.

Change the 'MethodName' field value to ‘PingResponse’.

Change the 'Parameters' collection by adding new parameter with 'Value' field as 'data' , 'Direction' as 'In' and 'Type' as 'String'.

Change the 'Result' field value to 'data'.

Run and Test the Workflow Service Directly from Visual Studio 2010.

Right click on 'WorkflowService.xamlx' file and click on 'Set As Start Page' to set it as start up page for the project.

Press F5 to run the solution. ( Visual Studio will run the workflow service in development server in some arbitrary port.)

WCF test client will comp up.

Double Click on 'PingService' node on left hand side tree view.

Put some string in the 'Value' column in 'Request' panel.

Click on 'invoke' button.

Output will be shown in 'Response' panel.

If the above information is useful, Please provide your valuable feedback.

Thanks.