Writing Business Logic: Why follow Patterns / Practices?

Posted by Sambeet Patra under .NET Software Development, Software Architecture

In this post I will explain tips to expose functionality and abstract details of your business logic. However, instead of focusing on the technical details I will focus more on the need to use practices. I will take you through a real life example to explain why it is important to put significant thoughts into this concept.

Before we start, let me explain the scenario I am trying to address. Often people challenge the need for patterns / practices / extensive architectural analysis for software development. The common response you get from developers is “So, whats new? I can write code to do that myself?”, or something like “How do I benefit from implementing this? It sounds so theoretical?”. These are all fair questions as long as the development work is done by an individual or by a small group of developers. The problem we face while working in enterprise deployments are (A) we have to manage a team environment where potentially large groups of developers will be working on the same project and (B) team members will change from time to time. When we take these factors into consideration, the importance of acrchitecture / patterns and practices and programming standards increase significantly. That said, lets jump straight into our example which will match very closely with typical day to day software development process. I will use C# / .Net to demonstrate the examples. But the concept is applicable to all languages / environments.

Consider a banking application that is being developed by your team. One of the developers is given the responsibility to implement business logic for money transfer. The feature involves withdrawing money from one account and deposit it to another account. While implementing the logic, the developer also wrote a utility to audit the transaction. So, the final implementation will look something like this

public class TransferManager
{
public void Withdraw(int accountId, decimal amount)
{
}

public void Deposit(int accountId, decimal amount)
{
}

public AuditTransfer(int fromAccount, int toAccount, decimal amount)
{
}
}

The developer has written methods to implement each step in the business process. Now, before even this module was put to use, the developer moved to another team and now you have a module developed by some one without a lot of documentation. Well, in a happy day situation, you will have ample documentation for all the work being done, but in reality documents do not provide the necessary information [or they simply do not exist!] in many cases. So what do you do now? As a user of this module, you start analyzing what has already been done and you try to map the work to the business functionality. So, you would use the Withdraw and the Deposit method and will not use the AuditTransfer [as, from the looks of it, it does not sound to be a part of money transfer process].As a result, you are likely to make mistakes due to lack of knowledge of the existing code.

This is where I make my first point. Always expose methods depicting the complete business process. This is because (A) you do not want the client to guess how they need to use your component. If you write wholesome functions, the client does not need to understand the details and needs to call only one function. So you will encourage writing code like the following:

public class TransferManager
{
public int TransferAmount(int fromAccount, int toAccount, decimal amount)
{
}
}

public class TransferUtility
{
public void Withdraw(int accountId, decimal amount)
{
}

public void Deposit(int accountId, decimal amount)
{
}

public AuditTransfer(int fromAccount, int toAccount, decimal amount)
{
}
}

Here, the manager class is supposed to expose methods for the clients and the utility class is used by the manager class to orchestrate business process details. But, we are not done yet. What is the guarantee that in future some client will not directly use the utility class? This can happen due to lack of knowledge right? This is where I will make a slight modification. I will declare all classes that are not manager classes as internal. The idea is, expose only those methods that are to be used by the client and Hide everything else.

public class TransferManager
{
public int TransferAmount(int fromAccount, int toAccount, decimal amount)
{
}
}

internal class TransferUtility
{
public void Withdraw(int accountId, decimal amount)
{
}

public void Deposit(int accountId, decimal amount)
{
}

public AuditTransfer(int fromAccount, int toAccount, decimal amount)
{
}
}

I can go on and talk about factory pattern / facade pattern etc. But, I think if you understand the philosophy of team development, you will be using these pattens without even knowing that you are using these. After all, patterns / practices are results of right thinking!

Windows Workflow Foundation - A New Programming Concept

Posted by Sambeet Patra under .NET Software Development, Software Architecture

Windows Workflow Foundation (WF) is a framework developed in .Net to build workflow-enabled applications. It provides an extensive and powerful base for design and development of systems that incorporate both system workflow and human workflow across a variety of scenario. The framework provides seamless development experience with other .NET Framework 3.0/3.5 technologies, such as Windows Communication Foundation and Windows Presentation Foundation.

This perhaps sounds like an extract from the marketing text from the Microsoft brochure. But upon careful analysis you are bound to discover interesting facts about WF. WF takes a radically different approach towards conceptualizing workflow based systems. Since it breaks the conventional assumptions of application development, people find it difficult to understand how WF works and whether there is any benefit in adopting this framework. In this article, I will explain the key concepts driving the design of WF and present the framework features at a high level.

What is a Workflow?

A workflow is a sequence of activities that typically involves decision making. Here is a very simple example. The following is the workflow to process shipment request of goods from a warehouse.

• Receive the order.
• Identify if inventory is available.
• If sufficient inventory is not available,
  • Inform the requester about a back order situation.
  • Request refill of inventory to the vendor.
  • Wait for 3 days and check if a refill confirmation has been received.
• Once the order is processed, inform shipment agency for a pick up.
• Verify after 1 day and escalate if items have not been picked up.

There is nothing complex here from a business perspective. Let us look at the graphical representation of the workflow:

Each step is an activity with definite rules and restrictions. So, simply put, a workflow is a set of activities ordered in a definite sequence. An activity can be anything from execution of instruction to decision making.

So, Why a framework for Workflow?

If we have to design a software solution for the above process how do we go about it?

Following the conventional approach we will build windows / web based application and implement the individual steps.However, there are some constraints involved in this:

• Some of the steps involve manual intervention and decision making. For example, consider the step for receiving resolution when we escalate to courier agency. The flow from this point is entirely dependent on the courier agency. We do not know when the courier agency is going to respond back. So we need to write software that “reacts” to real life events. As developers / architects we will promptly implement a user interface to accept this event as an input from the user. However, in today’s world people look for end to end integration and it may not always be acceptable to expect the user to manually trigger such events through a UI.
• Not all workflow are composed of continuous steps. There are cases where there is predefined pause in the process. Consider the verification of verification of inventory refill after 3 days. The process comes to a waiting point here for 3 days. How do we write program for such cases? Technically it is possible to write programs that pause for a specific period of time. But it is not a scalable solution and if the system goes down the process terminates abruptly.
• As discussed in the first two points, using the traditional approach this process cannot be implemented by a UI based program itself. There needs to be some additional components for monitoring / asynchronous processing of certain events in the workflow. This is where the overall design becomes complicated. As a result, we have another potential issue to deal with. What if there are changes in the process. Let us say we have changed the courier and now there is a different set of rules / constraints to create shipping instructions. Imagine how many components we will need to change on an already existing complicated design.

The problems discussed here arise mainly because we are trying to solve workflow that can execute over a considerable period of time using programming approach that primarily deals with real time execution. Implementations like this pose a number of question in the mind of the developers. An elegant implementation needs to consider the following aspects

• How do you maintain information the state of the workflow for this length of time?
• How can the complications of asynchronous inter process communication be simplified?
• How can changes be applied to an existing process while the workflow is in execution?
• How do you handle human intervention?

Enter, Windows Workflow Foundation

WF adopts the following key strategies to address workflow requirements:

Framework Based Approach: WF is not a tool, it is a framework which is inbuilt to .Net. Developers can make use of the graphical workflow designer available in the VS 2008 [or VS 2005 extension]. However, they can also choose to write code to implement the workflow. In either case, it is the same framework that provides the workflow capability. Further, as with any other .Net feature, WF can be implemented in multiple languages. SO why is a framework based approach so critical? Consider the example above. Each activity or step requires us to implement logic in a specific problem space. The technology / solution for communication with shipping courier may be completely different from the solution for communicating with vendor. WF allows us to be able to implement the Workflow steps in a distributed manner andd yet orchestrate the overall flow as a single workflow.

Common Technology: Since WF is a part of the core .Net framework, it can be used by any .Net based solution. Microsoft products like Biz Talk Server, Microsoft Dynamics CRM etc are soon going to adopt WF to implement workflow requirements.

Human Factor: A real life workflow involves interactions among people. Applications interacting on behalf of people need to be much more flexible and extensible. A person taking part in a workflow process may make decisions that are unpredictable and unforeseeable. Users can decide to cancel a process unexpectedly. WF accommodates such scenario by exposing functionalities to adopt human factor. It is possible to add steps / makes changes to a workflow in execution using the WF features.

Hosting: A workflow system is effective only if it is self sufficient. Since WF is an integral part of the .Net framework, any windows process can be used to host workflows. So, the host for running workflow processes can be a windows service / console application / even a UI program.

Reactive Programs : A key Concept

Before we delve deep into the WF architecture fundamentals, it is necessary to understand the key concept that has made WF feasible. We have already discussed that real life workflows may not be a step of sequencial operations and we have to account for unpredictability especially because of manual intervention. This concept prompted the WF architects to look at program with a different approach.

Think of a situation where you are subscribing to a new website. You will typically go though a number of screens and input a lot of information before the registration is complete. Now, the web site takes you to the next screen only when you submit the information in one screen. So, the registration process comprises of a set of steps, each requiring an action from the user. This simple example explains the reqality of real life workflows, where programs “react” to external events. WF frameworks enables you to design workflow where each individual component can be made to execute upon the occurence of an external event. This event can be a completion of another task, an input from the user, a signal from another system etc.

The other key concept is maintaining the state of a process. Think of the subscription process where you have to go through several pages. What if the website goes down before you are done? Or, what happens if you remain idle for a long time on one specific page? Chances are, you will have to start all over again. This is definitely not an acceptable situation for business critical workflow systems. WF builds in the capability to persist the current state of the workflow. A workflow will resume even after you restart your workflow system.

WF Architecture Overview

Workflow Designer: This is a ui based component that lets you design workflow visually. However, this does not force you to use any specific application or tool. It is possible to embed the design capability to other GUI systems.

WF Base Activity Library: A workflow is a combination of activities in a specific order. The activity library is an out of the box list of activities provided by WF that can be readily used in your workflow.

Custom Activities: WF allows you to extend the existing activities and define your own custom activity that can suit your specific needs.

Workflow: This is what you design using the above 3 components.

.Net Runtime Support: The .Net runtime includes WF specific functionalities that can be used to execute workflows. This has built in capabilities to manage life cycle of the workflows.

Workflow Types

As described earlier, WF supports system as well as human workflows in a unified manner. System workflows execute activities in pre-defined fashion, where as human workflows are unpredictable. To cater to such disparate needs, WF provides two types of workflows: sequential and state machine. Sequential workflows are suited for system workflows where as the state machine workflows are capable of responding to events as and when they occur.

Sequential Workflow:

The example shown above was designed using the visual designer for sequential workflows. This depicts the inventory workflow [I have skipped some steps to keep the example simple here]. The entire workflow is designed using the out of the box activity types provided by the .Net framework. Here are some key items:

Code: This activity type empowers the developer to write custom code that is executed when the workflow reaches this point. In the example I have implemented ReceiveOrder, BlockInventory and ShipInstruction using Code activity types.

IfElse: This activity type executes the activities defined in two or more possible paths based on whether a condition is met. The inventory check is performed using this type of activity and then the control either shifts to VendorPO or BlockInventory depending on the result of the check. The condition can be defined using custom code.

CallExternalMethod: This type of activity is used to call methods in an external component. This is useful when the workflow spans across multiple applications. In the example the VendorPO is implemented using an CallExternalMethod activity. InvokeWebService is another activity type that can be used in a similar situation to call a web service.

HandleExternalEvent: This is a very useful type to handle asynchronous events. In this example, once we place a VendorPO, we do not know when we will receive the inventory. We have already discussed that conventional programming practice cannot be used to effectively implement this type of business process. This is where the HandleExternalEvent type comes into picture. This type can be used to define an external event that will resume the workflow from this point onwards.

State Machine Workflow:

Unlike the sequential workflow, the state machine workflow is event based. This is useful when we are dealing with processes that depend on real life events. Think of a sales process. In simplest of terms, a sales process involves identifying contacts and working with the contacts to close a sale. These are processes where you cannot predict the sequence of events or the duration.

This is where State Machine workflow comes into consideration. The workflow type is built around a set of statuses or checkpoints in the overall process. Consider the diagram below. It is possible for us to identify the different states of the sales process i.e. NewContact, ContactVerified, ContactClosed and ContactLost. Then we need to design the events that move the status of the workflow from one state to the other state.

Here is a summary of the commonly used framework activities used in a state machine workflow.

State: Represents a “Checkpoint” in the business process.

EventDriven: This consists of a set of activities that get executed when an event is received while the workflow is in a specific state.

StateInitialization: Defines a set of activities that get executed when a state is reached in the workflow.

StateFinalization: Defines a set of activities that get executed when a state is exited in the workflow.

SetState: Changes the current state of the workflow.

Summary

In this article I presented a very high level overview of WF. It takes a while to learn the intricate details of this new framework, but once you understand the capabilities, you can design and develop powerful workflow applications with least amount of effort.

.Net: Using ThreadStatic Attribute in Multithreaded Applications

Posted by Sambeet Patra under .NET Software Development

Writing multithreaded programs in .Net requires a good understanding of the threading functionalities available in the .Net Framework. ThreadStatic attribute is a useful keyword in multithreaded programs. As far as functionality is concerned, ThreadStatic attribute is a variation of the static keyword. Static variables have one instance throughout the lifecycle of the program. A variable marked with [ThreadStatic] has one instance per thread in the program.
The syntax is shown below in C#

[ThreadStatic]
static int myVariable;

The program below demonstrates how this attribute changes the behavior of a variable.

using System;
using System.Threading;

class Program
{
public static int timesAccessed = 0;

[ThreadStatic]
public static int timesAccessedInaThread = 0;

static void Main(string[] args)
{
Program myProg = new Program();

//define the threads
Thread thread1 = new Thread(new ThreadStart(myProg.Func1));
Thread thread2 = new Thread(new ThreadStart(myProg.Func2));

//start thread1
thread1.Start();
//wait for thread1 to finish
thread1.Join();

//start thread2
thread2.Start();
//wait for thread2 to finish
thread2.Join();
}

public void Func1()
{
timesAccessed++;
timesAccessedInaThread++;
Console.WriteLine(”value of accessed in Thread1: ” + timesAccessed.ToString());
Console.WriteLine(”value of accessedInaThread in Thread1: ” + timesAccessedInaThread.ToString());
}

public void Func2()
{
timesAccessed++;
timesAccessedInaThread++;
Console.WriteLine(”value of accessed in Thread2: ” + timesAccessed.ToString());
Console.WriteLine(”value of accessedInaThread in Thread2: ” + timesAccessedInaThread.ToString());
}
}
Here timesAccessed is a static variable and timesAccessedInaThread is a ThreadStatic variable. These variables are accessed and changed in two different threads. Note the output of the program:

value of accessed in Thread1: 1
value of accessedInaThread in Thread1: 1
value of accessed in Thread2: 2
value of accessedInaThread in Thread2: 1

Here the threadstatic variable has a different copy for each thread. Hence, the change in value in thread1 does not impact the value in thread2.

Windows Communication Foundation - An Overview

Posted by Sambeet Patra under .NET Software Development, Service Oriented Architecture (SOA), Software Architecture, Software Development Platforms, Web Services, Workflow Systems

Windows® Communication Foundation (WCF) is the unified communication programming model in the .Net framework for building service-oriented applications. In this article I will explain the facets of WCF. I will also build a simple WCF service to demonstrate the concepts.

Why WCF?

WCF is the part of the .NET Framework. It unifies the various communications programming models existing in the Microsoft platform into a single model.

For the past few years, Microsoft distributed solutions have mostly been composed of ASP.NET Web Services / Web Service Enhancements (WSE) extensions / Microsoft Message Queue (MSMQ) and .NET Remoting. Each of these technologies has its own benefits and drawbacks. WCF does not attempt to replace these, nor does it provide a solution that tries to compete with these technologies. WCF is merely a framework that

• provides a base to develop and expose functionalities through any of the above technologies
• empowers the developer to write code that deals with business logic only and “configure” [instead of write code any more] WCF to host the code using one of the one of these distributed frameworks.

Further, it is important to understand that there is a learning phase associated with WCF unlike some of the other .Net technologies [ASP.Net / Web Services etc]. But there is a good enough reason for this. Most of the distributed technologies discussed earlier provide inbuilt features that help developers write code to support specific scenarios. But WCF goes a step further; it mandates standards that need to be followed to write services. Also, since it provides support for most of the existing distributed technologies, the developer needs to understand how these technologies have been conceived to co-exist. Simply put, while other technologies provided “features” and “libraries” and let developers dictate the end result, WCF enforces some well thought out best practices, thereby reducing possible mistakes during conceptualization / development of distributed applications.

WCF Architecture

The following image shows the basic architectural layout for WCF.

• Service Contracts: We will explore this in detail later on. Contracts define the details of the functionalities that are exposed in a service.
• Application Implementation: This is the implementation code for the contracts. This is written by developers.

Note that once you have defined the contracts and written the implementation of the contracts, all other aspects of hosting the service can be configured using the WCF framework. For most of the standard requirements for hosting services, WCF can be configured to provide the right solution without a single line of coding. We will explore the components of the WCF framework in detail. Here is a very high level description of what WCF provides.

• Runtime: As the name suggests, WCF framework provides extensive runtime support for various hosting scenarios. These include requirements like Transaction / Remote Invokation / Life Cycle Management / Exception handling etc.
• Messaging: This layer consists of channels that process the incoming / outgoing messages one by one. This layer is responsible for implementing the WS standards / encoding / support for protocols like HTTP and TCP. Developers familiar with the WSE (Web Service Enhancements) tool will find that this is really the next improved version of the WSE functionalities.
• A service is a program; like other programs, it needs to be hosted either as an independent executable or using a hosting service. The activation features deal with this aspect. WCF Services can also be hosted, or run in an executable managed by an external agent, such as IIS or Windows Activation Service (WAS). A WCF service can also be run automatically as a Windows service.

Service Contracts

Services publish contracts that provide the constituents of the intended functionalities. A contract, in WCF is nothing but an improvisation of interfaces. In fact a contract is an interface with a specific attribute so that the WCF framework recognizes it. The following code snippet demonstrates how a contract is declared. 

 

Once contracts are established, the developers will write the implementation of the contract. This is no different from implementing the interfaces that form the contracts. This is a significant value-add as we are now writing code without any idea about how it is going to be hosted / exposed to the consumers. This will allow the developers to focus on the business logic completely.

In the following sections, we will explore how the implementation can be exposed using WCF.

End Points

WCF exposes services to the outside world via an endpoint. The end points define the characteristics of the WCF hosted service.

The ABC of End Point:

• Has an Address. This is a uri that specifies the location of the endpoint.
• Has a Binding associated. A binding specifies what protocols are used to access the service. WCF includes predefined bindings for common communication standards such as SOAP over HTTP, SOAP over TCP etc.
• Is linked to a Contract. The end point makes this contract available to the service consumers.

When a client wants to access the service via an endpoint, it not only needs to know the Contract, but it also has to adhere to the binding specified by the endpoint. Thus, both client and server must have compatible endpoints. Keep in mind that it is possible to define end points that make the service compatible with consumers of the traditional ASP.Net web services.

Understanding Bindings

As I mentioned earlier, WCF provides a framework to write distributed services and it provides a platform for the developers to focus on business functionality without worrying about the underlying technology. So how does WCF provide the platform features? The key here is “Binding”. A binding consists of one or more binding elements. Each binding element handles a specific non-functional aspect of a service, such as whether it supports transactions, the kind of security the service incorporates, the standards for data transport etc. Binding elements are grouped together to create a binding that is required for the service we are developing.

So how does binding add value?

• WCF provides several out of the box implementations of bindings which represent some of the commonly used techniques. Think of all the previous distributed technologies in the Microsoft world. WCF will have one or more binding implementations representing the strength of the each of these technologies.
• Use of bindings does not require any coding unless you want to write your own specific binding implementation.
• Interoperability is one of the key requirements for services. Chosing the right binding will make the service interoperable without writing any code.

Now, let us look at some of the standard bindings provided by WCF:

• BasicHttpBinding: This binding is based on the WS-I Basic Profile 1.1. It uses the HTTP / HTTPS transport protocols. Use this binding to maintain compatibility with client applications previously developed to access ASMX-based Web services.
• WSHttpBinding: This binding implements the WS-* specifications to implement transactions and secure, reliable sessions. It supports HTTP / HTTPS protocols. Messages can be encoded as XML or by using the Message Transmission Optimization Mechanism (MTOM). MTOM is a preferrable mechanism for messages that contain binary data.
• WSDualHttpBinding: This is similar to WSHttpBinding, however it is suitable for bi-directional communication between the client and server without synchronizing the individual messages [as opposed to a typical request-response model].
• NetTcpBinding: This TCP transport protocol and messages are encoded using binary encoding. While is has better performance compared to HTTP protocol, it is not as interoperable as HTTP based protocols. It supports transactions and secure communications.
• NetMsmqBinding: This binding uses Microsoft Message Queue (MSMQ) as the underlying messaging platform. This handles scenarios where messages are delivered asynchronously [in other words, messages are queued]. Hence, the server need not be running all the time for the protocol to function.

An Example

We still need to discuss a few other aspects of WCF framework. But let us build a sample application with whatever we have discussed so far. We will create a WCF service for the tax service contract we had created earlier.

I have presented the steps to create the service below. I assume that you are familiar with Visual Studio .Net and have Visual Studio 2005 with .Net 3.0 add on or Visual Studio .net 2008 installed in your computer. 

• Create a new project of type “WCF Service Library”.

    

• Once the projected is created, add the following classes. This represents the sample contract we had created earlier:

     

    

    

 

Compile the project once and make sure that it compiles properly. Till now we have defined a contract and implemented it. Now, we will write the necessary configuration to implement the service. For our example, we will host the service in IIS and expose it as a basic HTTP web service. [I will explain hosting later on].

• Open IIS administration console and create a virtual mapped to the folder where you have the project. Add web.config file to the project. Note that this may sound a bit confusing and you may wonder why we did not create a web service project in the first place! I am just trying to make a simple point here. WCF DOES NOT HAVE to be hosted in IIS. It is just one of the options available.

• Now, add a file named TaxService.svc to the project. The content of the file should be as shown below.

• The svc file stores the details of which assembly and class implement the contract. In this case I have mentioned the TaxServiceImpl class in the mytaxservice assembly [which is the output of my project]. This way, we completely detach the contracts from the implementation and we also abstract it from the outside world. If we ever come up with a different implementation for the same contract, we just need to update the svc file.
• Since the service is being hosted in IIS, make sure you reconfigure the project property to define the output under the bin\ folder as opposed to bin\Debug. Also make sure that you configure the virtual to use the right version of  ASP.Net.

    

• Now it is time to define the end point for the service. We will just be adding a few items in the config file to define the end point and then expose the service to the consumers. Here is the content of the web.config file.

Let us now try to explore the configuration details. Let us ignore the <behavior> tag for a moment. We will get to it in the next section.

• The <serviceModel> represents the configuration details for WCF Web service.
• <services> includes the details of all the services offered by the deployment. The name attribute indicates the namespace and the class that implements the service.
• A service can be exposed in different manners. This is achieved by including a number of endpoints that expose the service with specific bindings.
• The address attribute in the <endpoint> tag is kept empty as we want to keep the address relative to the address of the virtual for now. The contract attribute is self explanatory as it mentions the contract that the endpoint exposes. The binding element indicates the binding of the contract. Here we are using basic HTTP, which is one of the many readily avaiable bindings in the WCF framework. In other words, merely choosing this binding sets up the service as a simple web service we used to develop using the ASP.Net asmx files. Once you get into the finer details of WCF, you will realize that changing the behavior of the service is all about coming up with the right configuration.

The Behavior Tag

Behaviors modify or extend the functionality of a service. In the example, the serviceMetadata tag indicated that the Service publishes metadata. Also, the security behavior controls impersonation and authorization, while the transactions behavior controls enlisting in and auto-completing transactions.

In the example we used the serviceMetadata tag to ensure that httpGetEnabled is set to true. This enables us to view the published metadata for the service. To understand what this means, browse to http://localhost/mytaxservice/TaxService.svc and view the metadata for the Tax Service. Now set the value of httpGetEnabled to false and revisit the above url. You will notice that a message comes up stating that the service metadata is not available.  

The Client?

Note that we did not write a sample client while implementing the sample application. So, what is different for a WCF client? Does it need to be aware of the fact that the service is hosted in WCF? Well, in stead of answering this question with a Yes or No, let me reiterate two distinct goals of WCF:

• It provides a framework to write service oriented application. Per definition, services are supposed to be interoperable and hence the client does not need to know the implementation technology of the service. WCF has conformed to this behavior and writing a client for a service created by WCF is no different from writing the client for a service written by any other technology.
• WCF also brings in all the strengths of various Microsoft technologies. Certain technologies are not necessarily interoperable. In such cases the clients needs to know at least the endpoint details of the service. In other words, you will need to write WCF-aware clients that have end points defined to communicate with the service. Needless to say, the binding of the client endpoint has to match the service endpoint.

Hosting of WCF

A host application has to perform a number of tasks. Some common requirements include

• Starting and stopping the service
• Listening for requests from a client application and directing them to the service
• Sending any responses from the service back to the client applications
• Providing diagnostics features

You can use the following options to host WCF services.

• IIS: We already saw this in the sample application. The IIS provides a number of readymade features. It provides automatic activation, diagnostics, on demand compilation and the ability to change application while it is live.
• Create a custom .Net application that the user runs to start and stop the service. While this gives you ultimate control you have to write all the code to provide the functionalities for hosting.
• Host the WCF service in a Windows service so that the WCF service is available as long as Windows is running. Also this is a favorite for administrators as they are well versed with Windows services.
• Use Windows Activation Services, or WAS if you are using IIS 7.0

Conclusion

In this article I presented a high level overview of WCF. WCF offers many configurable and extensible features for developers and support personnel to customize every aspect of service deployment. Even though it takes a while to understand the various components of WCF, the knowledge pays rich dividends as it empowers you to host production ready applications with the least amount of effort.

Useful References

http://msdn.microsoft.com/en-us/netframework/aa663324.aspx
http://netfx3.com/content/WCFHome.aspx

 

About the Author

The author is a seasoned Electronic Business Solutions architect at Silicus and has led several large scale software development projects for e-Commerce, CRM and Business Process Management solutions across multiple industries.

A Comparative Analysis of SQL Server Reporting Services and Crystal Reports

Posted by Sambeet Patra under .NET Software Development, Software Architecture, Software Development Platforms, e-Business Software Solutions

The objective of this post is to present differences between SQL Server Reporting Services (known as SSRS) and the Crystal Reports suite. Since it is impractical to identify the “better product” without the context of a specific deployment scenario, I will focus on laying out the high level differences and let the readers draw their own conclusions.

(A) Product Maturity

Crystal Reports has 11 major releases and it is currently at the XI version. Since the early conception, the product has been focused on end to end reporting needs and has matured comprehensively over the last few years. There is a general misconception about the common issues with Crystal Reports especially in the .Net community. Many people do not realize that the embedded crystal reporting features in Visual Studio .Net 2003 was a limited edition of Crystal Reports 9 which has been out of date for a number of years now. The newer versions have matured significantly and provide features to seamlessly integrate with .Net applications.

SSRS, on the other hand is only 2 versions old. The first version was released in 2004 as an Add-On to SQL Server 2000. However, there are significant feature expansions in the next release [SSRS 2005]. While this product is relatively new, Microsoft had the advantage of analyzing the existing reporting solutions in the market and implementing the most sought after features in SSRS.

(B) The Product Suite

Crystal Reports suite has 3 main components. The designer interface allows users to design report layout. The server is the hosting environment for the reports and it helps manage / schedule reports. The suite provides extensive library to integrate with the various development platform.

SSRS, in contrast, is a .Net based reporting system. If you do not want to work on .Net platform, SSRS is not the right solution for you. SSRS has a design interface integrated into Visual Studio .Net. The Report Server hosts reports and the report manager is used to manage / schedule reports and the related data sources.

(C) Licensing

Crystal Reports provides various editions for designing reports. There is embedded edition available with Visual Studio .Net at no extra cost. This edition helps developers design reports in the Visual Studio .Net environment. There are stand alone design suites available to design reports without the need of Visual Studio .net environment. This package is sold as a per user license. The crystal server license is sold separately.

SSRS is slightly confusing in terms of licensing costs involved. It is available for free when you buy SQL server license. However in large enterprises you would like to separate out the reporting infrastructure. The reason being, SSRS is extremely resource intensive and tends to take up a lot of RAM / CPU, thereby reducing the bandwidth available to the SQL server itself. This forces organizations to buy additional licenses of SQL Server just so that they can install SSRS in an isolated environment.

(D) Report File Format

Crystal Reports are stored in binary format. The crystal reports object model can be used to programmatically access and manipulate the report components.

The reports created using SSRS are stored as plain XML text. This can be opened in a text editor and changes can be made without opening the Visual Studio .Net report designer. You may tend to assume that this is a convenient option to make changes to the report; But keep in mind that the report XML can get extremely complex and it takes a lot of effort to accurately understand and parse the XML. You are much better off using the Visual Studio .Net designer interface. The XML based format allows vendors to conveniently write third party tools for SSRS. Also, Visual Studio .Net 2005 has an inbuilt feature to design client reports that do not require an SSRS back end to be hosted. This report format is derived from the existing xml format.

(E) Data Binding

Data binding is the process of obtaining data from an underlying source and attach it to an interface. This is an important aspect in report development [in fact, display of data is what reports are all about!!]. Crystal Report allows a single data source per report. If data is to be obtained from multiple database tables, then you have to join the tables to get a single resultset. To display multiple content sets in the reports coming from multiple data sources you will have to design and include multiple sub reports in the main report.

SSRS is flexible in this regard as it allows any number of datasources per report. It is easy to design reports with unrelated sections displaying data from different data sources.

(F) Report Design Features

There are endless debates on differences in the design capabilities between Crystal Reports and SSRS. While it is impossible to provide a complete and detailed list, I will compare some of the common features:

WYSIWYG Capability: Since Crystal Reports has matured over a number of major releases, the designer interface helps articulate the exact look and feel for the intended report. SSRS however has minor issues which will probably be resolved in forthcoming versions.

Report Structure: Crystal Reports takes a Section based approach. There are predefined sections in a specific order [i.e. page header / page footer / group header / footer / body etc] and the designers customize each section to achieve the desired look and feel. SSRS takes a different approach. it is possible to drag / drop and customize report elements onto the report deign interface. This provides better flexibility in defining the structure of the report.

Formula / Calculations: Crystal Reports provides a wide range of predefined formulas that can be readily used in the reports. SSRS provides all the basic functions, but it does not match up to Crystal Reports in terms of the extent of predefined functions provided.

Extensibility: SSRS provides options to write custom code or make calls to external .net assemblies from the report.

Managing Data Flow / Sections: Crystal Report provides better features to manage page breaks / section breaks / spacing paragraphs etc. SSRS does not do an equally impressive job. These features are highly desirable in generating reports for finance / insurance / banking.

Summary

Both tools provide extensive features to build reports in your application. While Crystal Reports takes credit for being in the field for so many years, SSRS provides exciting features in the .Net platform. Before deciding on the product that is right for you, make sure you identify your primary report requirements and then evaluate the products to decide on the most appropriate one.

About the Author

The author is a seasoned Electronic Business Solutions architect at Silicus Technologies (An Offshore Software Development Company) and has lead several large scale software development projects for e-Commerce, CRM and Business Process Management solutions across multiple industries.