Team Foundation Server (TFS) and Visual Studio Team System (VSTS)

What is TFS?

It would not be correct to state that TFS is the replacement for Microsoft’s earlier source/version control software (VSS – Visual Source Safe), as I believe TFS is much more that just a source/version control software. If used correctly, it will help Application Lifecycle Management (ALM) and provide a platform for collaboration and when used with Sharepoint it really completes the entire picture (obviously there are other products and companies out there which provide similar capabilities, but this blog topic is going to focus on TFS).

A few of TFS salient features include

• Source/Version control (how obvious)


• Automatic Build process via Team Build which uses Microsoft MSBuild (to all those java developers MSBuild is equivalent to Ant, Maven, although to Ant’s credit there is a Microsoft version for Ant, called “nAnt” – how creative, if it was me I would have named it “bug” )


• Create Work Items and tie them to the different development code modules. Bug, Risk, Scenario, Task, Quality of Service Requirement, Requirement, Change Request etc they all constitute examples of work item types. NOTE: depending on the Process template that you select during the “Team Projects” creation wizard in TFS, some work items may not be available for use. Example: “Requirement” is available only if you select “MSF for CMMI Process Improvement” process template versus “MSF for Agile Software Development” process template. Having said that, TFS allows you to create new Work Item Types as well as create custom process templates. My frank opinion about all this custom stuff is this, try to use the out of the box process templates provided by TFS or use some already built process templates, e.g. there is one for SCRUM, do not be a hero and try to create your own process template as that would be a project in itself, unless you have a home grown Process Template that you inherit before the Project starts do not be a hero. Adding some new Work Types to existing Process Templates is not a big deal; but do not create a custom Process Template on your own or do that before any project work starts; else you will not be able to utilize the biggest benefit that TFS provides which is rapid application Lifecycle management/development with a common platform for team collaboration, as you will spent most of your time tweaking the custom Process Template assuming that its getting refined as you go along with the application development, not a good idea).


• Create work items automatically based on events, for example, say your built fails, that event will create a work item so that you can diagnose the cause of the problem, pretty neat.


• Integrates Testing efforts into the overall application development and provides one central repository for accomplishing the same (refer to my section on “What is VSTS?”)


• Provides tons and tons of out of the box reporting.


• TFS also provides Process Templates, two which are provided out of the box include




• MSF for Agile Software Development


• MSF for CMMI Process Improvement

I do plan to write a blog on Microsoft Solution Framework (MSF), which I think is a really good Framework to adapt and I think Microsoft did a good job of providing Process Templates with default Plans and Specifications which a Project can use and adapt to suite their needs, its this sample templates, one for Agile development and another one based on CMMI, is what I like about MSF; it really guides you at different stages within an Application Lifecycle Management/Development. I plan to dedicate a blog for MSF.

What is VSTS?

Visual Studio Team System (VSTS) is the big brother of Visual Studio.NET. It comes in various editions with each version providing increment features. If you want to try it out download the “Team Suite” edition as it contains all the features of other editions.

Visual Studio Team System is tightly integrated with TFS and provides capabilities to interact with TFS directly from the development IDE used by developers for application development. Team Explorer is one such plug-in that you use a lot. Team Explorer is used to access the TFS. In TFS you create what’s called “Team Projects” (do not confuse this with Visual Studio Projects, as Team Projects can contain more than just .NET code, example – project documents like Coding Standards, System Design documentation, build reports, testing reports, work items etc). Think of “Team Project” as a logical name for your overall project used by everyone for project team collaboration, in fact when you create a Team Project, it will also ask you to create a “Team Project Site” within WSS (Windows SharePoint Services – do not confuse this with the big brother SharePoint Server (MOSS), this is just the mini-me version that used to come before as a service within Windows Server 2003, but Microsoft now removed this from Windows Server 2008 and provide the same as a separate download, in short if you install Windows Server 2008 it does not install WSS, you will have to download this software separately (maybe Microsoft realized that by doing that both products(Windows Server and WSS) lifecycle can be decoupled from each other. TFS can also be integrated with SharePoint Server (MOSS), but you will have to install the TFS and SharePoint Server on separate physical boxes which could sometimes become overkill for small/medium size projects).

One thing that VSTS provides which the Visual Studio.NET does not provide is IDE capabilities for performing Testing and integrating that with TFS. Now you can do unit testing with Visual Studio.NET but that’s just stand-alone and is not integrated with the overall picture of testing. The edition that supports testing is “Test Edition”, however if you have the “Team Suite” edition you are all set. Each edition of VSTS is there for a purpose. The “Test Edition” was meant for testers, I recommend buying the “Team Suite”, that way you are all set (I usually go to an electronic store with a budget to buy a camera with bare minimum features and I end up buying the most expensive one, that way I know the basic features are there and I have some more, which for all practical purposes I will never use but it’s the peace of mind, a little secret, I still do not know all the features that came with my camera, all I know is how to zoom and click and connect to USB drive of my computer to share and archive the same).

VSTS “Team Suite” as well as “Test” edition provides means for you to create Test Projects. Test Projects are like any other project you have created within Visual Studio.NET in the past (Examples of other Projects are: Windows Forms Projects, ASP.NET Web Application Projects) but are used specifically for testing just like how ASP.NET Web Application Project is used for building dynamic web applications. Once the Test Project is created there are various Test Templates that you can use to add to the Test Project

• Unit Test


• Database Unit Test


• Web Test


• Load Test


• Ordered Test


• Generic Test


• Manual Test (text format)


• Manual Test (word format)

A few features of VSTS that I feel emphasizing include:

• Helps you select a code class and method and create a test stub by few clicks


• You can also define Code Coverage which will tell you how much code within the application modules got tested, you can also define color coding to highlight areas of code that has not being tested yet.


• It’s integrated with TFS; you can publish test results to TFS for other team members to review.


• Its integrated to work with the overall Project Management process e.g. you can attach a test result with a work item defined in the TFS “Team Projects”


• There are many more features and this is not a complete list ………………

The various Test Templates are explained below in details

Unit Test

Once you have finished your class and say you wish to test the class methods, you can create a Unit Test which can create stubs that would invoke your class methods. The steps that you need to perform are pretty simple, all you have to do is select the class/method you wish to unit test and right click to select the correct context menu option in order to create a unit test stub class. With the Code Coverage enabled you will be able to monitor what percentage of your code was tested. The Unit Test class that gets created is like any other C#/VB.NET class which you can modify for further control on your testing. For Example, you can attach a data source and abstract the values that you are passing to various methods into a database table (something that I recommend you do as this will help you refine your testing as you progress with your coding efforts).

Database Unit Test

This is basically to test the database stored procedures and functions

Web Test

I once worked on a project where I had to screen scrap an application using Windows C++ SDK and most of my time was spend in just writing a utility to record and playback the mouse clicks/positions and key strokes and I never achieved perfection, but the job was done as the scraping exercise was a one time exercise (thank god). Well if you have developed an ASP.NET web application you can use the Web Test to do testing of that Web application. The steps are pretty sleek

• Start the VSTS recording to record each and every action that you perform on the web application. (I would recommend creating Web Test that test a few web pages of the application that cover some business functionality, that way you can perform incremental testing and not get slowed down by creating one big Web Test, in short do what you do when you unit test a class, one class at a time, in this case one small business flow at a time, which should translate into one or two web page interactions)


• Stop the recording. This will result in VSTS creating a map which converts all the web interaction into a tree structure which you can view from the “Web Test Editor” window.

Within this Web Test Editor Window you can configure the following

• You can add new Web Request in the flow, delete exiting Web Request or edit properties of exiting Web Request
  
• In each Web Request (which represents a web page logically). You can set properties that are based around the HTTP request. For Example, you can define whether the request is a “GET” or a “POST”; you can define what the request timeout is etc.
  
• You can define Extraction Rules for the request, think of this like reading the HTTP response. You can define extraction rules to do that extraction from the HTTP response.
  
• You can define Validation Rules, this is where you can compare the extracted value with say the “expected” value which you can retrieve from a database or a file and make a determination to pass or fail the test using Asset statements.
  
• You can also define properties that apply to the entire Web Context, for example, you can define Username and Password at the Web Test level so that it applies to all the web pages within a web context.
  

You can also test Web Services using Web Test. The steps invoked are a bit different since there is not much to record. But you can record and stop to create the Web Request Tree and then access the Tree in “Web Test Editor” window to configure testing the exposed web methods. At that point of time your testing experience will be similar to what you had when you were testing individual class methods during Unit Testing.

It’s also possible to create coded Web Test. In order to convert a recorded Web Test into a Coded Web Test you will have to right click the recorded Web Test in the Web Test Editor and select the “Generate Code” option from the context menu. VSTS will basically create C#/VB.NET classes that would act as a stub for the Web interaction that got recorded. Once these classes get created, there are events/methods defined within the classes that you can consume/override to have granular control on the web test. For Example, you can create Validation Rules/ Extraction Rules using C#/VB.NET classes that are provided for the same and add them dynamically through the exposed API. You can override events like PreWebTest, PostWebTest, PreRequest, and PostRequest where you can write your custom code.

For Example, you can write code in the “PreRequest” event to log the parameters passed to the web request.

When I was working on a project, to custom built an application that would interact with a web page, I had to do everything manually and use my Windows C++ SDK skills (remember Spy++ guys) to interact with Internet Explorer, now VSTS Coded Web Test encapsulates that and provides us managed code classes in C#, VB.NET to achieve the same. It’s a great bonus for all of us who want to have more control on the testing without spending days trying to use Windows C++ SDK and all the complexity involved with pointers, memory management, processes and what not.

Load Test

I remember I was working on one project where I had to write custom program that would simulate the interaction with the web application. This program was multi-threaded and was tightly coupled to the custom Web application I wanted to test. I used this program to perform load testing as I had this program run from multiple machines with each machine running multiple threads, there by simulating multiple users assessing the application and hence achieving my load/stress/performance testing efforts. I did not take the program to the next level, which is to create a windows service that can run from each machine and in turn can co-ordinates with a central server Windows Service. VSTS Load Test provides all this out of the box. In the VSTS terminology, we have a “rig” that consist of a controller and multiple “agents”, each agent is deployed on a machine that is dedicated for testing and the controller is like a co-coordinator (no testing is done by the controller; it’s the agents who perform the actual testing). The concept is pretty easy to understand. If you have built distributed application then you can easily understand what this architectural approach of rig-controller-agent is. The controller uses a SQL Server database to store the data that it collects during load testing from each agent. You can use this information to see trends and perform further analysis to identify potential bottlenecks.

When you add Load Test to a Test Project you will have to define Scenarios. For each Scenario you will have to provide the following information

• Test Mix – in short what test (Unit Test/Web Test) you will like to include in the Load Test. Define properties like - how many users to simulate, how much Think Time etc


• Browser Mix – specify different browsers to use for testing


• Network Mix – DSL, Broadband, Dialup etc

Once you run the Load Test, the generated Test Results have tons and tons of reports that you can use for analysis. You can create a Results Store in a SQL Server Database for persistence. Typically, when you install the controller on a machine, you will also be asked to create the Results Store (in short what SQL Server instance to use for persistence). Do not confuse the Results Store database with what TFS uses to store the published Test Results for a build that contains .NET solutions with projects that include tests (e.g. Unit Test, Web Test etc) as a part of the Built. TFS has its own database schema that it uses to store published Test Results which is not the same as the SQL Server database we use for storing Load Test Results; in short the load test results are typically stored in a separate SQL Server database and/or schema than the TFS database. You can publish any Test Results for any test (Web Test, Load Test, Unit Test etc.) to TFS for other team members to take a look at the test results. As soon as you publish the Test Results to TFS, that’s when the TFS database comes into picture. I know it sounds confusing, but it’s important to know which databases come into picture and when.

Ordered Test

If you want to run a set of test in a specific order, then you can use Ordered Test list. I was a bit confused when I started using Ordered Test list because there is something called “Test List Editor”, where you can group all the tests within a group referred to as “Test List”. At first I thought the order in which you add individual tests (e.g. Unit Test, Generic Test, Web Test etc) will define what order the tests will get executed. This is not true. If you wish for that, then you will have to create an “Ordered List” and then add the “Ordered List” to the “Test List”. I am not sure why Microsoft designed it that way, when you can just add an attribute in the “Test List” and do a ordering that way (I am a simple man, with simple solutions, I am pretty sure there are good reasons for Microsoft to do it that way, and its my lack of imagination, or they already have what I am saying and its just that I did not see it)

One thing to note about “Test List”, if you wish to include a “Test” from your Test Project into a build, you will have to create a “Test List”, as the Wizard for creating a Build Definition file does not see the Test directly, although there are other options like including tests from a “DLL” which can be used as an alternative, if you really do not wish to create a “Test List”

Generic Test

You select this “Test” type if you wish to include a wrapper around a third-part test. There are some guidelines/rules that the third-party test has to adhere to in order to participate in the overall testing efforts.

Simple guidelines/rules like

• Must be able to execute from command line


• Must return a Boolean value of either True or False


• Ensuring that the third-part test writes test results into a XML file using a XSD schema provided by VSTS. This allows VSTS to display the test results within its IDE (e.g. in its “Test Results” window)

Lets say you wish to send information to another executable, how would you design that interaction (assuming that you are not doing inter-process communication and all that complexity that goes with it). You would basically use XML to send inputs and XML to read outputs from the third-party executable, and you will define schemas to control the schematics of the XML; this is what the Generic Test does.

Manual Test (text format as well as word format)

If your project does not have a budget for doing automated testing, you can use this Test type to perform manual testing. VSTS provides sample boiler plate for Unit Test Specifications which you can use to document the steps that you are going to perform manually for this test and to capture the expected and actual results. This is the traditional way of doing testing. The benefit you get with VSTS/TFS is that by using a common platform for collaboration, you can increase team co-ordination and/or communication (Example, the Manual Test could be tied to Work Items within TFS, this allows the tester to co-ordinate with the developer(s) involved with the code the tester is testing, a work item could be a Task, Bug etc).

Where does TFS and VSTS Testing Meet?

TFS is providing you a platform for team collaboration at a level which I believe will help you develop an application in a much cohesive way. VSTS is very much integrated with TFS. Areas where VSTS integrates with TFS include

• You can use VSTS as an IDE (more specifically the Team Explorer) to navigate the “Team Projects” that you have created in TFS.


• You can configure automated builds from VSTS.


• You can publish “Test Results” from VSTS to TFS (you can also do that using the command line utility “MSTest” but the IDE provides a click and publish capability with ease of use in mind)


• Obviously you can use VSTS for application development and use the TFS “Source Control” feature to check-in and check-out code for versioning

There are so many features in TFS/VSTS that I will end up writing a book. I do plan to write another blog for Microsoft Solution Framework (MSF) and explain how it ties into TFS/VSTS.

Windows Communication Foundation (WCF) and its use in SOA based applications

Before I start with Windows Communication Foundation I would like to give a brief history tour of what I have encountered over the years the direction Microsoft is taking with regards to distributed systems/communication.

DCOM/MTS/COM+/MSMQ/JMS/.NET Remoting/BizTalk/Web Services ……

Microsoft introduced the DCOM architecture for distributed systems and it was its vision to use that as a standard within the Microsoft product suites for distributed communication. In the mean time the open source communities was trying to push for CORBA (Microsoft as well, although half-heartedly was supporting it, not that I blame Microsoft, if I invent something I would want the client to buy the item from my store, what’s wrong with that mind-set)
Java thought it should also do something different and hence came up with RMI. Everyone was trying to address the one big problem, how do we come up with a standard that will allow distributed communication but everyone was thinking for their own platforms (DCOM for Microsoft, RMI for Java). CORBA did start out as the first step towards accomplishing distributed communication across heterogeneous environments. It how ever lacked the support from the giants over a period of time (remember everyone wants to sell their own product mentality).

Microsoft and Java also came out with standards to provide asynchronous communication MSMQ/JMS (still trying to sell their own product).

Microsoft came out with a fancier distributed standard terminology called COM+ (The plus is just their way of saying we merged all our earlier standards like DCOM, MTS etc and added a few more features so that the developers will have to learn and learn for ever, and the recruiters now have something more to demand) and then finally .NET Remoting (their managed code saga, with all the leaks in C++ code written by clumsy developers, they learned from Java the mantra of managed code, although VB programmers were already in some areas benefiting from that, more specifically they did not have to worry about memory management related issues like C++ programmers had to).

Microsoft as well as Java had standards around transaction management (MTS and JTS), Microsoft got ride of the term MTS and now they have that built in to the COM+. JTS is Java’s specification which keeps evolving with releases as well.

BizTalk was used by Microsoft primarily as a Middleware Solution to provide collaboration between heterogeneous systems (Mainframe, Unix, Windows etc) by providing adapters that can talk with those specific environments and then doing some XML/XSLT to do some translation before forwarding the information to the other environment (think of BizTalk as a traffic police). There are many heavy weights in this middleware quadrant and really BizTalk falls more in the middleware technologies versus distributed systems/communication. But I thought of mentioning it just to give an idea.


Then came a beacon of light, Web Services and everyone was talking about how we can sell products from other stores as well as ours; in short, how do we have a distributed communication that is truly platform independent. Now wasn’t CORBA suppose to achieve that, in theory yes; however; it was a much more complicated implementation for the broader community to understand and adapt. Web services used the XML fever and used terms like SOAP, WSDL to provide some standards around distributed communication over the internet (wow I am already excited). Microsoft and Java both were fed up of fighting so they also accepted Web services with a caveat. Their earlier implementation specifications were not exposing Web services that can be easily consumed by each other; resulting in the existence of Basic Profile (BP) (I might have the facts wrong it could be BP and then the issue). Anyways, Web Services also lead to the concept called Service Oriented Architecture (SOA) and everyone was hooked up to SOA which brings me to my next section “What is SOA?”


What is SOA?

SOA stands for Service Oriented Architecture, as if that’s going to tell anything. Before I start describing the theory it’s important that we understand what the “Service” part of SOA means. First of all “Service” does not automatically means “Web Services”, Web Services can be considered as one possible implementation option for SOA applications; although not the only one, remember I still haven’t talked about Windows Communication Foundation (WCF). Think of service in the context of business and try to build SOA applications by putting the hat of a business analyst and ask yourself the question what part of my business could serve as a service to others. A simple example will be Stock Analysis Service (its purpose could be to provide you with some statistical analysis of a particular stock, Mutual Fund, ETF etc). The data within that service could be exposed as XML message (SOAP).

The theory
The four tenets of SOA are

• Tenet 1: Boundaries Are Explicit
• Tenet 2: Services Are Autonomous
• Tenet 3: Services Share the Schema and Contract, Not the Class
• Tenet 4: Service Compatibility Is Based on Policy

I am not going to describe everything about SOA, do some goggling and you will have tons and tons of articles talking about SOA as a concept. But, the long story short in all these articles is to remember what the “Service” in SOA stands for; and try to build SOA applications with that in mind. With that I finally move to WCF


What is WCF?

I keep thinking WCF stands for Windows Communication Framework, but it’s actually Windows Communication Foundation.
Microsoft finally decided it’s long since they have talked about change so they came up with WCF as the new buzz word for distributed communication. WCF provides a unified programming model for service oriented applications. If you have worked on .NET Remoting then some of the terms used to define WCF components (like channel) will help you understand where Microsoft is heading with WCF. However, the similarity stops there, WCF provides a much decoupled architecture than .NET Remoting and also provides the promise of supporting DCOM, MSMQ, COM+, Windows Services, .NET Remoting etc the earlier standards defined within the context of distributed architecture/communication. So what’s the difference now, let’s start by asking yourself a question, if you have a requirement where you do not want to change code and at the same time affect the behavior of the methods/functions exposed by your components how will you design your component interfaces. One possible answer will be to
o Define generic data types as arguments
o Send data as XML
o Make the methods refer to a configuration file so that changing the contents of the file will result in different behavior

I am pretty sure as an architect you might have designed your application component interfaces using some of the above mentioned techniques at some point of time.

Now WCF provides that as a standard unified programming model. When you work with WCF think of data as messages (SOAP, XML, REST) and think of WCF methods exposing data as messages (SOAP, XML, REST) versus thinking in the traditional terms like interface with .NET specific data types. In fact, think of messages and XSD schemas versus classes and objects when information is passed between WCF services and WCF clients. WCF service will expose data types that are never .NET specific but the data types will be defined in the context of XSD schema (once again think of schemas and not classes).


Basics building blocks of WCF Services

WCF was introduced as a part of .NET framework 3.0 and 3.5. The basic building blocks of WCF include

o Service – this is the exposed business interface (remember this is a concept – think as a business analyst)
o Service Contract – this defines the methods/functions exposed by the interface along with signature
o Data Contract – used to map complex .NET data types to corresponding XSD data types (remember messages should not contain any .NET specific data types)
o Endpoints – Applications define one or more endpoints for a WCF service and that’s how they make the WCF service available to the clients. Endpoints define the - Address of the service, the Binding supported by service, and the Service Contract implemented by Service. The term “ABC” is typically used to define how a WCF Endpoint is exposed. “A” stands for “Address, “B” stands for Binding and “C” stands for “Contract”
o Bindings - they identify how a service and client endpoints communicate with each other. You can define them declaratively in code or in a configuration file the later provides more decoupling from code. You can do both, but the code settings will override what’s in the configuration file (If you have worked on J2EE and JEE 5/6 then this should be familiar territory, remember Java annotation and all the configuration files of Java web.xml, ejb-jar.xml, application.xml etc.) Binding will provide information such as Transport (HTTP, TCP etc), Protocol (Security, Transaction etc), message encoding (text, binary etc) used for the WCF service at both ends (client as well as server hosting the WCF service). WCF provides tons of out of the box WCF bindings BasicHttpBinding, WSHttpBinding, NetTcpBinding etc.


WCF Hosting Options

WCF services need a hosting environment to expose the WCF services to the client. If you have done .NET Remoting then you know what I am talking about, .NET Remoting server component can be hosted in a console application, IIS or a windows service). WCF service also provides a variety of hosting options
o Stand-alone console application (also referred to as self-hosting)
o Windows Service
o IIS – this supports only HTTP protocol.
o Windows Process Activation Service (WAS) – only supported in Vista or Windows Server 2008 – this is my preference as it not only supports HTTP but also supports other protocols like TCP plus provides the benefit of application pooling and all the other things IIS provides minus the need for Web Server.

One difference between .NET Remoting and WCF hosting is that in WCF hosting you can use the configuration files to define and configure the service/hosting behaviors. .NET Remoting does not provide such granular standard (not that I am implying you cannot define your own configuration files to decouple some of the deployment related changes that you may have to do as you move from one application environment to another, WCF on the other hand however gives that to you, this is one more way of decoupling the various moving parts of WCF from each other providing better flexibility)

The beauty of WCF is that if you define a WCF service that is exposing some business functionality which needs to be accessed in an intranet environment, you will typically host the WCF service in WAS or Windows Service and use TCP as the transport channel. You can also decide not to use SOAP but rather REST just to avoid the verbose nature of the SOAP protocol. Down the road say you want to expose this WCF service via HTTP you can configure IIS to host the WCF Service and expose the information via HTTP(S); with no coding changes. That’s the beauty of decoupling WCF provides.


SOAP and its use in WCF

As I mentioned earlier, WCF uses messages to exchange data and since SOAP (Simple Object Access Protocol) is all about messages, its obvious that it is the accepted message format in most of the WCF implementations I have worked on. SOAP came into existence when the fever of Web Services was high and was used as a standard for exchanging data between web services and its clients. WCF does not restrict you to use SOAP you can also use REST or define your own format but I would suggest the use of SOAP as it’s an accepted standard. The only place where you should consider alternative is if you are worried about performance, but trust me 95% of the time SOAP is fine.
If you use SOAP then all the SOAP format standards that apply to SOAP like envelops, body, faults etc apply in WCF as well.

WCF Sessions, Transactions and Security

WCF allows Sessions and define bindings that support Sessions (e.g. NetTCPBinding, WsDualHttpBinding etc)

Now if you have worked with EJB or with .NET Remoting you will understand what Instancing means. In the context of WCF it refers to the lifetime of the WCF Service instance. Following three options are supported
o PerCall
o PerSession
o Single

Does it not ring a bell (.NET Remoting has something similar, EJB in Java have stateless, stateful beans)
WCF has tons of attributes (NOTE: Microsoft allows declarative configuration via attributes, Java does it via annotation – wow how innovative) that you can define within code as well as in configuration files to control the Session behavior for a service.

WCF also allows transactions and have attributes that can define transaction boundaries as well as API that can help you define the outcome of a transaction. If you have worked in COM+ or in EJB, the WCF transaction capabilities will be easier to understand.

WCF allows security to be defined at
o Transport level – the transport layer is used to encrypt the message as well as pass security information. Typically NetTcpBinding is used for this.
o Message level – the message is encrypted and is also used to pass security information (needs support of XML and WS-Security). Typically WsHttpBinding is used for this

The Authentication and Authorization options in WCF are much the same as you would have for a Web application or a COM+ component. WCF also supports declarative as well as code based authentication/authorization and there are tons of attributes/configuration XML elements defined for that.


Miscellaneous topics

WCF in my opinion provides a much decoupled architecture. Some areas where WCF can be used include
o SOA implementation (remember the WCF service protocol can be TCP it does not have to be a web service with HTTP(S) in order for it to be SOA)
o You can use Windows Workflow Foundation (WF) and make it consume a WCF Service.
o You can have BizTalk consume a WCF Service
o You can define RESTful WCF services and not use SOAP as the message protocol.
o You can expose WCF service information as a RSS / ATOM feed (Syndication) for blogs
o You can expose WCF Services and have Windows Presentation Foundation (WCF) consume the same.

The options are endless, but one thing is for sure WCF is the new baby for distributed communication and time will tell if that’s going to stay for the next couple of years or Microsoft will come out with another architecture and we will all get exited with that dumping WCF.

NOTE: Although I may sound a bit skeptical in my blog, I believe its not just Microsoft but others (Java included) who also keep changing their standards (remember EJB 2.1 nightmare and now its EJB 3 (thanks to hibernate)). That’s what I like about my industry and my job, it never gets boring.