Design Approach for a reusable Shopping Cart Module

Posted by Sambeet Patra under Software Architecture, Web Services

Shopping Cart is a critical piece of an ecommerce website. It allows temporary storage of items selected till the user decides on placing the final order. In this article I will present a simple approach to design a shopping cart component that can be used in multiple web sites.

The primary goals of my approach are 

• Re-usability: As described earlier, the cart should be reusable.
• Extensibility: Each website can store custom data in the cart.

Design Considerations:

Shopping cart storage, by definition will hold product data for the user session till an order is placed. While a shopping cart can be conceived to have a definite schema, it is preferable to treat this design as a solution to maintain the shopping cart instead of mandating the structure of the data. Taking this into consideration, the shopping cart schema will be made flexible and the storage mechanism [for example the database] will be agnostic of the schema. In other words, we will consider serializing the shopping cart data and save it as a BLOB into the database.

One other fundamental requirements for the shopping cart solution is the ability to identify the cart for a user session. However, different sites may have different implementation to identify user session. Some sites may use cookies; the other sites may use server session ids. The shopping cart solution should be agnostic of the mechanism of user session identification.

Class Diagram:

The main components of the shopping cart application are depicted in the following diagram:

KeyValuePair: This is a simple structure to hold a key value pair. This structure will be used to maintain client specific data in the shopping cart.

Cart: Represents a Shopping Cart. The Cart class has an array of Cartitem classes to hold the cart line item details. It has some predefined fields to hold billing and shipping information. However, it will also have an array of KeyValuePairs to hold client specific data. For example, website 1 may be storing the user phone number whereas website 2 stores user region information. It will be difficult and practically impossible to identify all possible information that may be maintained by all the web sites using the shopping cart solution. The KeyValuePair array presents a simple option of storing additional attributes for the shopping cart without distorting the schema.

CartItem: Represents a line item in the cart. This also has an array of KeyValuePair to hold additional information.

CartManager: All classes explained so far form the overall schema of the cart. The CartManager implements and exposes functionalities to save / retrieve cart.

DB Design:

 The Cart class will be made serializable and the serialized data will be stored in the database. The advantage of serialized data is that we do not need to have a complex DB design and the design will not change when the cart schema changes. The DB design is presented below.

Note that the field CartData contains a serialized version of the Cart object.

Security Considerations:

The cart solution may require following functionalities

• Ability to encrypt the persisted data. This is applicable if the cart contains sensitive information. This may be achieved by encrypting the serialized cart information before saving it to the database.
• Client Authentication: If the solution is exposed as a web service, there may be requirement to restrict the usage of the cart solution only to specific web sites. This is achieved by using digital certificates to identify clients. Use of WS-Security specifications is recommended for use in web service.

Best Practices for Prototyping in Software Development - 4

Posted by Ravindra under Software Development Practices, Software Development Prototyping

This article is the fourth in series of articles on Prototyping in Software Development.

Who should be involved, how far you should go and when do you have to do Prototyping in a Software Development Project?

Often Prototyping in Software Development Projects will be done without planning and without involving the relevant stakeholders. This will lead to wrong expectations, initial budget overruns and customer satisfaction issues.

1. Who is Involved?
Prototyping can be done informally by anyone, regardless of their background or role in the project. It’s easy to make a simple but effective prototype by taking a bitmap from Adobe Photoshop, putting it into the Microsoft FrontPage Web site creation and management tool, and adding active buttons or links. These lightweight prototypes only go so far, and can become unwieldy for complex interactions.

For more formal prototypes by larger teams, a developer or project manager will often collaborate with a designer and a usability engineer. Together they’ll generate ideas, build a prototype that represents the best ideas, and then go into the lab to see how effective it is in solving user problems. Developers might get involved if they can spare the time, or if their technical expertise is needed. Often the designer or project manager will do most of the scripting or coding to build the prototype.

Treat this phase with importance, just like any other phase in SDLC and try identifying and involving the relevant stakeholders at all stages in the prototyping stage.

2. When Do You Build a Prototype?
Depending on the scope of the prototype and the level of detail required, prototypes can be built at any time during the project. Most often they are created early in the project, during the planning and specification phase, before developers write any production code. That’s when the need for exploration is greatest, and when the time investment needed is most viable. If developers instead of program managers or designers are prototyping, scheduling time becomes even more important because you need to make sure the work invested in the prototype is accounted for in the development schedule. Planning for any UI release should include some level of prototyping.

Late in a project, smaller prototypes can help resolve tough design and technical issues. A quick HTML mock-up of how a dialog box or Web page should behave can help answer a developer’s question or give other teammates a feel for what the desired experience should be. In some cases, a strong program manager or designer can implement the behavior in Microsoft JScript development software and approximate much of the programming logic that developers will need to think through.

The time it takes to create a prototype can vary tremendously, depending on the scope and precision of what the end result needs to look like. An informal prototype could mean a few hours of work by one person; a more organized effort can involve weeks of effort by an entire team.

3. How Far Should You Go?
In your prototype, build only as much of the design as you need. It’s okay to have buttons that don’t work, or text that never updates. As long as you can experience the interactions you want to explore, it’s fine to use smoke and mirrors for the rest.

Here are a few reasons why you should focus your efforts carefully:

3.1 Cost of building the prototype.
You want to minimize the cost involved in building the prototype. The challenge with prototyping is recognizing the minimal investment needed to effectively answer your questions about the design. This is where usability studies are critical, because they clearly identify the parts of your UI that need the most work. Even without usability studies, you should clearly define what user problems you’re trying to solve, or what tasks you’re trying to improve, with the design in your prototype.

3.2 Limited lifetime.
Prototypes should have clearly defined lifetimes. Is the end goal a presentation at a team meeting? An executive review meeting? A spec review? A usability study? Convincing yourself, with your devil’s advocate hat on, that the design solves a user problem? Once the needs for these specific objectives are met, the prototype should be set aside. The basic mindset is that the code or bitmaps generated in a prototype will be left behind in most of the cases. There might be exceptions where code or visuals live on in the product, but the expectation should be that this won’t be the case.

3.3 Risk of overwhelming the team and setting wrong expectations.
Showing prototypes to developers and teammates can be tricky. An overly complex or elaborate prototype, with amazing visuals and animation, can overwhelm people. You should always have a sense for how far to go and how much of what you’re creating in the prototype you want to be taken seriously.  This is important because to build this amazing visuals with full functionality will be a challenge and will take more effort.

So the general practice that is preferable to follow is to involve people who can later be part of the design and development team, try writing code and scripts during prototype phase in a language that can be easily merged and scaled to the actual language and projects that you use as part of the subsequent phases in your projects.

Best Practices for Prototyping in Software Development - 3

Posted by Ravindra under Software Development Practices, Software Development Prototyping

This article is the third in series of articles on Prototyping in Software Development.

Tips and Techniques in User Interface Prototyping during Software Development

The following tips and techniques should prove valuable during the prototyping phase of your SDLC (Software Development Life cycle), these can also be used as guidelines, best processes and practices for User Interface Development:

Consistency: Most important thing you can possibly do is ensure your user interface works consistently. If you can double-click on items in one list and have something happen, then you should be able to double-click on items in any other list and have the same sort of thing happen. Put your buttons in consistent places on all your windows, use the same wording in labels and messages, and use a consistent color scheme throughout. Consistency in your user interface enables your users to build an accurate mental model of the way it works, and accurate mental models lead to lower training and support costs.

Set standards and stick to them: The only way you can ensure consistency within your application is to set user interface design standards, and then stick to them. Preferably since Prototyping is done in an Agile manner, you should follow Agile Modeling Standards in all aspects of software development, including user interface design.

Be prepared to hold the line: When you are developing the user interface for your system you will discover that your stakeholders often have some unusual ideas as to how the user interface should be developed. You should definitely listen to these ideas but you also need to make your stakeholders aware of your corporate UI standards and the need to conform to them.

Explain the rules: Your end users and business users need to know how to work with the application you built for them. When an application works consistently, it means you only have to explain the rules once. This is a lot easier than explaining in detail exactly how to use each feature in an application step-by-step.

Screen Navigation:

Navigation between major user interface items is important. If it is difficult to get from one screen to another, then your users will quickly become frustrated and give up. When the flow between screens matches the flow of the work the user is trying to accomplish, then your application will make sense to your users. Because different users work in different ways, your system needs to be flexible enough to support their various approaches. User interface-flow diagrams should optionally be developed to further your understanding of the flow of your user interface.

Navigation within a screen is important. In Western societies, people read left to right and top to bottom. Because people are used to this, should you design screens that are also organized left to right and top to bottom when designing a user interface for people from this culture? You want to organize navigation between widgets on your screen in a manner users will find familiar to them.

Word your messages and labels effectively: The text you display on your screens is a primary source of information for your users. If your text is worded poorly, then your interface will be perceived poorly by your users. Using full words and sentences, as opposed to abbreviations and codes, makes your text easier to understand. Your messages should be worded positively, imply that the user is in control, and provide insight into how to use the application properly. For example, which message do you find more appealing “You have input the wrong information” or “An account number should be eight digits in length.”

Furthermore, your messages should be worded consistently and displayed in a consistent place on the screen. Although the messages “The person’s first name must be input” and “An account number should be input” are separately worded well, together they are inconsistent. In light of the first message, a better wording of the second message would be “The account number must be input” to make the two messages consistent.

Understand the UI widgets: You should use the right widget for the right task, helping to increase the consistency in your application and probably making it easier to build the application in the first place. The only way you can learn how to use widgets properly is to read and understand the user-interface standards and guidelines your organization has adopted.

Look at other applications with a grain of salt. Unless you know another application has been verified to follow the user interface-standards and guidelines of your organization, don’t assume the application is doing things right. Although looking at the work of others to get ideas is always a good idea, until you know how to distinguish between good user interface design and bad user interface design, you must be careful. Too many developers make the mistake of imitating the user interface of poorly designed software.

Use color and styles appropriately: Color and styles should be used sparingly in your applications and, if you do use it, you must also use a secondary indicator. The problem is that some of your users may be color blind and if you are using color to highlight something on a screen, then you need to do something else to make it stand out if you want these people to notice it. You also want to use colors in your application consistently, so you have a common look and feel throughout your application.

Align fields effectively: When a screen has more than one editing field, you want to organize the fields in a way that is both visually appealing and efficient. I have always found the best way to do so is to left-justify edit fields: in other words, make the left-hand side of each edit field line up in a straight line, one over the other. The corresponding labels should be right-justified and placed immediately beside the field. This is a clean and efficient way to organize the fields on a screen.

Expect your users to make mistakes: How many times have you accidentally deleted some text in one of your files or in the file itself? Were you able to recover from these mistakes or were you forced to redo hours, or even days, of work? The reality is that to err is human, so you should design your user interface to recover from mistakes made by your users.

Justify data appropriately. For columns of data, common practice is to right-justify integers, decimal align floating-point numbers, and to left-justify strings.

Your design should be intuit able: In other words, if your users don’t know how to use your software, they should be able to determine how to use it by making educated guesses. Even when the guesses are wrong, your system should provide reasonable results from which your users can readily understand and ideally learn.

Don’t create busy user interfaces: Crowded screens are difficult to understand and, hence, are difficult to use. Group things effectively. Items that are logically connected should be grouped together on the screen to communicate they are connected, whereas items that have nothing to do with each other should be separated. You can use white space between collections of items to group them and/or you can put boxes around them to accomplish the same thing.

Take an evolutionary approach. Techniques such as user interface prototyping and Agile Model Driven Development (AMDD) are critical to your success as a UI developer.

Best Practices for Prototyping in Software Development - 2

Posted by Ravindra under Software Development Practices, Software Development Prototyping

This article is the second in series of articles on Prototyping in Software Development.

Tools and Technologies that can be used in Usability Engineering, prototyping during Software Development

There are several different tools and technologies you can use for creating prototypes, each of which has its advantages and disadvantages. Consider the type of design work you’re trying to prototype and the goals of your prototyping effort as you decide which tool or technology is right for you.

Paper - For usability studies or quick reviews, paper is often the fastest way to prototype a design idea. Using Photoshop, mspaint, or any tool you are comfortable with, produce screens that express the design, and print them out on paper. If you make enough screens, you can simulate walkthroughs, allowing test users to make choices and experience the design. However, for prototypes of moderate complexity, generating paper prototypes can be cumbersome. Highly interactive things like games or chat rooms can not be simulated well on paper. Also, the more elaborate the tasks, the more pages you might need to have handy.

Microsoft .NET: This is the fastest technology for creating Windows-style and Web based UI prototypes. The Web browser object makes it easy to integrate HTML UI with your standard Windows-style components. While it’s true that an experienced C/C++ developer might be able to generate UI faster in C/C++, this creates the temptation to reuse code from the UI prototype in your production code. It takes discipline to recognize that the goals of a quick and dirty UI prototype are highly divergent from high-quality engineering. Make sure you know what kind of code you’re writing, and that your team or manager understands what will be discarded.

Macromedia Director or Flash: This is one of the most popular UI prototyping tools among designers. It is most useful for multimedia or non-standard GUI designs, or for prototypes that require significant animation. It’s high flexibility makes it cumbersome for Windows-style UI compared to Visual Basic. However, a proficient Director user can generate Windows or Web UI without difficultly.

HTML: Dream weaver, FrontPage and other HTML editors allow for fast creation of simple prototypes. The latest technologies based on LAMP tools can also be used for faster turnaround times during the prototyping phase. To express an idea, you can often create bitmaps that illustrate a sequence of user interaction, and place them into FrontPage. Then you can create link areas to connect the pages, and simulate how you can interact with the design. Java Script and DHTML take things to another level, allowing for very sophisticated logic and interaction. If you are using HTML to prototype your Web site, the warning just described for C/C++ applies here as well don’t fall into the trap of confusing quick prototype code with production-quality engineering.

Ajax - This is the latest technology that uses Web 2.0 concepts to create user friendly presentation Layers, with this you can break up the page/screen into a variety of small UI elements, like a header, a navigation menu, a sidebar, etc and then we should be able to create reusable snippets of code

Also, most importantly by using Ajax in prototyping, you are prepping up the site for web Application Integration. The general structure of an Ajax prototype is remarkably similar to the structure to how a Engineer would incorporate the design into a web Application framework. They don’t have to dig through endless lines of presentation code, rather each function is nicely separated into it’s own HTML file.

Best Practices in Prototyping in Software Development - 1

Posted by Ravindra under Software Development Practices, Software Development Prototyping

This article addresses the needs of prototyping in Software Development , this will be the first part in the series of articles on Prototyping in Software Development.

1. Why Prototype?
Prototyping is a means of exploring ideas before you invest in them. The best reason to prototype is to save time and resources. So, for a minimal investment, you can find usability and design problems and adjust your UI before you invest heavily in the final design and technologies.

On examining the needs of your particular project, you might come up with reasons for creating a prototype other than saving money. Is the goal to explore a new interface model? Make modifications to one part of the existing design? Investigate a new technology? It’s important to be clear about why you’re building what you’re building before you start. If you begin with clear goals, you can be direct and effective in your efforts. The reasons for creating prototypes fall into three basic categories:

1.1 Proof of concept.
Among some teams there are disagreements about the future direction of a project. You can use a prototype to prove that an idea or new approach has merit or value. A prototype can help illustrate that an idea works, express its qualities in a visual and interactive way, and/or motivate team members to think about the problem from another perspective.

1.2 Design exploration.
If you design interactive things, the only way to explore how something will be used is to create a mock-up and interact with it. Sometimes the mock-up is tied to a usability study, where parts of the prototype can be evaluated in a structured way. Sometimes it’s just a way to clearly express to a developer how something should work or look. In many cases, a designer might simply be experimenting, in an effort to get a sense for what approach might work. Anyone on the team can use prototypes to explore design issues, although designers are generally the most skilled. Design explorations should be directed at trying to solve specific problems that you’ve recognized in your product.

1.3 Technical exploration.
Developers investigating implementation approaches to a problem often try out different coding techniques to see if they work well. Using HTML, Jscript, SQL, DHTML, FLASH, ACTION Script, PHP or specific coding approaches within each technology have different tradeoffs. Sometimes a prototype represents an exploration into what technology will work well to support a certain UI or web feature.

Sometimes prototypes are created for a combination of these reasons. If a team plans well enough, they can allot time for a developer and a designer or project manager to work together on a prototype. In such cases, it’s extremely important to clearly define the goals and the contributions each team member is expected to make. You want everyone to be clear on what the goals are, what’s at stake, and what the potential outcome will be.

2. Who is Involved?
Prototyping can be done informally by anyone, regardless of their background or role in the project. It’s easy to make a simple but effective prototype by taking a bitmap from Adobe Photoshop, putting it into the Microsoft FrontPage Web site creation and management tool, and adding active buttons or links. These lightweight prototypes only go so far, and can become unwieldy for complex interactions.

For more formal prototypes by larger teams, a developer or project manager will often collaborate with a designer and a usability engineer. Together they’ll generate ideas, build a prototype that represents the best ideas, and then go into the lab to see how effective it is in solving user problems. Developers might get involved if they can spare the time, or if their technical expertise is needed. Often the designer or project manager will do most of the scripting or coding to build the prototype.

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!

Best Practices and Guidelines for Process Tailoring in Software Development

Posted by Ravindra under Software Development Processes

Best Practices and Guidelines for Process Tailoring in Offshore Software Development

What is Tailoring in Software Development?
Tailoring in Software development is the process of extracting a set of processes, tasks and artifacts from the organizations established processes, tasks and artifacts so as to best suit a project to achieve its objectives.

Practices and Guidelines

It is very important that we have a set of tailoring guidelines that will guide the development teams to let them decide what is best for the projects. The guidelines must also specify is that what is Tailorable and what is mandatory. For example in a software development project if a project manager says that the project need not maintain a project management plan then it should be not acceptable as per the tailoring guidelines. So basically there will be some processes, tasks and artifacts that will have to be developed and maintained in a software development project.

So these guidelines must take into account multiple aspects before being released as part of the organization quality management system. These aspects must look into the current state of process implementation, customer’s needs and objectives, project characteristics etc.

Organizations that are offerings services for different types of projects like Full life cycle development, maintenance, QA, Technical support must also look into coming up with life cycle models for each of these type of software projects. These life cycle models must go hand in hand with the Process tailoring guidelines established at the organization level.

The following steps can be considered as some important points that can help in coming up with the tailoring tasks at the project level.

STEPS AT PROJECT LEVEL
Identify Project Characteristics
Identify the characteristics of your software project. These characteristics will be useful in formulating a project strategy and in tailoring processes.

Formulate a Project Strategy
Based on the characteristics of your project, formulate a strategy by referring to Process tailoring guidelines that are established at the organization level.

Select a suitable Quality Management System (QMS) process
In QMS, processes must be defined for the different types of projects; example
· Development (Agile, Maintenance, Waterfall etc.)
· Maintenance projects
· QA Projects
· Technical Support Projects

The tailoring guidelines for project management and configuration management must be made applicable to all projects.

Select lifecycle model for the Software development project and tailor process element accordingly. For each process element, you can decide to do one of the following:

· Implement the process element as per guidelines
· Waive the process element
· Replace the process element
· Add a new process element

Waivers and replacements from the tailoring guidelines and new process elements not defined in the tailoring guidelines should be highlighted in Project Management Plan as Deviations and appropriate process must be followed in getting approvals for the waivers and deviations.

In my next article I will highlight the use of collaboration tools like Project Server and SharePoint and demonstrate how we can use simple features to come up with an effective way of performing process tailoring for software development projects. This will also address the fulfilling of GP 3.1 in CMMi Ver. 1.2 – Establishing projects defined process. We will understand more about Projects Defined process.  

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.

Degin and Review of Business Layers - Quick Tips

Posted by Sambeet Patra under Software Architecture

In a typical 3-tier application, designing the business layer is a key factor in making the application robust and maintainable. Here are some tips on designing the business layer in a Multi Layered Architecture. These tips can be put into practice while designing / developing / reviewing the business layer.

1. Identify the responsibility and boundaries of the layer. In a typical 3 tier [data-business-presentation] application, a business layer should not expose functions specific to a presentation component. Similarly, the business layers should not even know the details on data source. One way to achieve this is to consider a layer as the end point of the application and identify the functionalities without thinking of the consumers of the current layer.

2. Develop apis that represent wholesome logical functionalities. For example, if you are writing a banking application, there should be one api in the business layer to transfer money. The user of the layer should not have to call multiple apis to first withdraw money from one account and then deposit in the other account. If you rely on the users of a layer to call multiple apis to execute a business process, you are effectively not abstracting the functionality.

3. Implement data validation in the business layer. Many people leave the data validation responsibility to the presentation layer and make an assumption that the business layer will get the right data all the time. But in reality, the presentation layer changes most often and the validation routines may not be full proof all the time. So, it is a much more reliable practice to keep the business layers self sufficient in terms of data validation. Extending this argument, during the course of the project lifecycle, make it a point to implement unit testing for the business layer apis.

4. It is imperative that the detailed implementation of the business layer be abstracted from the users. Publish interfaces that contain business api definitions. Provide well defined options to obtain implementation of the interface [a great example is the factory pattern]. Apart from these, make sure all other utility classes are made internal to the business layer.

5. Always think of scalability while designing a business layer. When implementing query methods, make sure the methods implement paging to limit the amount of data retrieved. Also, the methods should be state-less.