My prediction is that Windows Communication Foundation will turn out to be a huge sucess for Microsoft, and we plan to utilize it on Ellis (project name).

Much has been written about the latest buzzword to emanate out of the cubicles of IT shops and, surprise surprise, it's another acronym. SOA stands for Service-Oriented Architecture, and has been around for many years. In recent months it has taken off, with vendors, professional service firms, webzines, and my plumber Jim all providing their own definition and explanation, pro and con. In the vendor space, IBM is now packaging 13 (not a typo) websphere and Tivoli products around SOA. However, finding a common understanding, let along simple definition of SOA is not easy.

So what is all the buzz about? Wickepedia defines SOA as such:

In computing, the term Service-Oriented Architecture (SOA) expresses a perspective of software architecture that defines the use of services to support the requirements of software users. In an SOA environment, nodes on a network[1] make resources available to other participants in the network as independent services that the participants access in a standardized way. Most definitions of SOA identify the use of Web services (i.e., using SOAP or REST) in its implementation. However, one can implement SOA using any service-based technology.

And the definition goes on and on like this, smelling very much like the latest brew to come pouring out of the IT department down in the bowels of the company's basement.

As the technical architect on a project that is on the SOA path, considerable effort has been spent trying to determine what SOA truly means to a project, and to the company's strategy and growth plans.

As my current project evolves I plan to keep an active journal detailing what goes right, and not so right related to SOA. For this first post, here's a quick summary of what SOA means to me, and how it most relates to the success or failure of the engagement:

SOA is not so much an architectural framework, or a set of architectural best practices, or a specific vendor solution, as it is a guiding principal or philosophy around the purpose a software project or packaged vendor solution lives for. Those people controlling the purse strings in an organization are very concerned about the real ROI a project is forcasted to bring back. What SOA brings to the table, more than anything else, is the opportunity for greatly expanded returns the investment in the project required. This is accomplished through the extensibility and ubiquity. An example might help to best describe this.

If I did everything correct as the software architect on a project to custom build a solution.. everything "by the book", and created course-grained, stateless interfaces that abstracted the complexity away from the consumer, and incorporated other best practices into its design.. BUT, I used a .NET remoting solution as the transport protocol because it offers higher performing working software, the central tenet of SOA has just been violated.

That is, my solution may be solid in every way, except I just forced my new partner, or the latest company merger to move away from their Sun/Java shop.. and the huge costs associated with it, and instead, to spend lots of money and resources purchasing Windows, and .NET, because the "perfect solution" you created requires .NET on both the client and server. The reach of the service interfaces created, and extending them to my business partner just got more expensive.

Forcing the consumers of your services into one particular vendor's technology in order to be used might be a perfectly valid solution.. perhaps the best solution, but it's not SOA.

By utilizing XML, web services, SOAP, and other vendor-neutral technologies, your services just became available to a far larger pool of consumers. By creating a framework that is consumable by whomever.. or whatever platform is the preferred flavor of your organization, an investment in a long term growth strategy can be more easily realized.

A challenge presented to developers when designing smart client apps includes keeping the solution's assemblies, which must communicate at some point with one another, as loosely coupled as practically possible.

Reaching this goal will greatly increase the "intelligence" of the software tool as the capability to version your app increases. The "smart" in smart client application design, among other things, is the capability to keep the code base as feature-rich as possible, with minimal impact to both the developer tasked with creating and managing the source (relatively speaking), as well as the end user consuming the updates on the client.

At the same time, designing strongly typed objects can reduce the headache of building and managing over time the interaction these objects have with the user interface layer of the application.

How do you design components that need to communicate with each other, while removing the constant dependency inherent with early bound objects in a way that is repeatable, and easy to manage? The following image illustrates this pattern, with a description below.

A popular requirement to display data in a custom .NET Winform application is to structure the data in a hierarchical tree-view format. However, the built-in support for this type of display is limited. Using the ComponentOne FlexGrid control, one can build a set of data tables into a Dataset object, and then relate them together. However, getting this setup, and moving the data into the Flexgrid requires a considerable effort.

Another way to get this result is to use a FlexGroup control from ComponentOne. It implements Outlook-style grouping and filtering using the FlexGrid. However, the control is not included in any of ComponentOne's developer suites. Instead, they provide the source code to the control, and it's up to you to build an instance that can then be used in your project.

Steps
1. Download the FlexGroup sample code under the FlexGrid control at the ComponentOne website: http://www.componentone.com/pages.aspx?pagesid=113

2. Once the download is complete, exract the compressed files and run the FlexGroup.vbproj VB.NET project.

3. View the properties window for the FlexGroupVB project file and change the Output type from a Windows Application to a Class Library.

4. Re-build the solution. When complete you can close this solution.

5. Open your solution. From the Toolbox, click the Customize Toolbox option. In the .NET controls section, browse to the Bin directory of the FlexGroup folder you downloaded. There, you will find the compiled control named FlexGroup.dll. Add this to your Toolbox. Back at your Form, the FlexGroup control is now a selectable item in the Toolbox. Select it and drag or paint it onto a form.

6. Set the control's Grid.Datasource property equal to a Dataset table. Run the project and display the form. You will see a display that looks like the example shown below.

Additional Note
The Dataset you use should be a flat result set with parent/child relationships built in.
For example:
Author1 BookA
Author1 BookB
Author1 BookC
Author2 BookX
Author2 BookY
Author3 BookZ

There is also a property named .ShowGroups. If this is displayed you can drag and drop columns into a Grouping section located just above the grid, allowing the user to customize the groupings displayed. In my example below I have chosen to hide this feature so I can control the look and feel of the user interface.

One "gotcha" I found was dealing with sibling columns. For example, City, State, and Zip are attributes of an address and thus siblings to each other. If you allow each of these columns in the dataset, the display of the data appears less fluid and appealing. I got around this by including sibling columns together as one column (e.g. City + state + zip as Address).

Introduction

Ask a group of web developers about the critical importance of data validation and you’re sure to get many heads nodding, for they know all too well the security of their own job depends on how successful they are at executing this task. Sites that lack data validation features are sure to invite errors downstream as that information is stored, processed, and ultimately, relied on erroneously.

Since the inception of web sites that did more then simply act as fancy brochures there’s been scant resources for the web developer to utilize for this purpose, and often times, getting data validation to work properly felt like fitting round pegs into square holes to effectively provide a web site with the proper data validation necessary to capture reliable information.

Background

One of the truisms that most web developers I’ve spoken to agree on is that end-users of a website are innately ignorant and will mess up data entry in a web form if given the chance. It is therefore the job of web developers to make his or her pages utilize a client-side scripting language, such as JavaScript to verify the data being entered. What needs to be validated is often up to the web developer. It is his or her duty to determine how extensively he needs to fool-proof his web form. Often times you just need to make sure that required fields are entered. Other times you need to ensure that the correct data type is entered; and still other times you need to make sure a user's input conforms to a certain standard (such as telephone numbers, social security numbers, etc.).

Let's look at an example. Let us say that you are wanting to collect information from your users about how they rate your site. You may have a form asking for the following fields:

• Their full name
• Their e-mail address (which you make optional)
• A rank for the site ranging from 1 – 10

We would want to write a JavaScript function to ensure that the name field had a value in it, and that the site ranking had a value between 1 and 10 in it. Let's take a look at what the JavaScript would look like (code is incomplete due to space and tag usage limitations):


SCRIPT LANGUAGE="JavaScript"

function ValidateData() {
var CanSubmit = false;
// Check to make sure that the full name field is not empty.
CanSubmit = ForceEntry(document.forms[0].txtName,"You supply a full name.");
// Check to make sure ranking is between 1 and 10
if (CanSumbit) CanSubmit = ValidRanking();
return CanSubmit;
}
/SCRIPT
And submitted here:
FORM NAME="frmSiteRanking" METHOD="GET" ACTION="SiteRanking.asp" ONSUBMIT="return ValidateData();"


This is one small example of validating data prior to the introduction of ASP.NET. In this world, developers had to write all of their own validation routines and cut and paste them in the various ASP scripts that needed to employ various validation techniques. Imagine needing to write similar scripts for every last form input value that an end-user might mess up. All in all, it was a real headache. This is where ASP.NET form validation server controls come into play.

ASP.NET to the Rescue

Validation Web controls are ASP.NET Web controls designed specifically to validate form field entries. For example, ASP.NET contains a RequiredFieldValidation control, which, as its name suggests, can be used to ensure that the user enters a value into a form field (such as a TextBox). Specifically, ASP.NET provides the following form field validation controls:

1. RequiredFieldValidator - Checks to make sure the user entered a value.
2. CompareValidator - Compares a form field's value with the value of another form field using relations like less than, equal, not equal, etc.
3. RangeValidator - Ensures that a form field's value is within a certain range.
4. RegularExpressionValidator - Makes sure that a form field's value corresponds to a specified regular expression pattern.
5. CustomValidator - Checks the form field's value against custom validation logic that you, the developer, provide.
6. Validation Summary - display a summary of the results from all validation controls on the page.

By default, page validation is performed when a control, such as button, ImageButton, or LinkButton is clicked. You can prevent validation from being performed when a button control is clicked by setting the CausesValidation property of the button control to false. This property is normally set to false for a cancel or clear button to prevent validation from being performed when the button is clicked.

Let’s take a closer look at one of these controls in greater detail.

RequiredFieldValidator

Footprint

asp:RequiredFieldValidator
id="ProgrammaticID"
ControlToValidate="ProgrammaticID of control to validate"
InitialValue="value"
ErrorMessage="Message to display in ValidationSummary control"
Text="Message to display in control"
ForeColor="value"
BackColor="value" runat="server"
/asp:RequiredFieldValidator


Use the RequiredFieldValidator control to make an input control a mandatory field. The input control fails validation if the value it contains does not change from its initial value when validation is performed. This prevents the user from leaving the associated input control unchanged. By default, the initial value is an empty string (""), which indicates that a value must be entered in the input control for it to pass validation.
Note Extra spaces at the beginning and end of the input value are removed before validation is performed. This prevents a space being entered in the input control from passing validation.

Example
The following example demonstrates how to use the RequiredFieldValidator control to make a TextBox control a mandatory field:

form runat="server"
Name:asp:TextBox id="Text1"
Text="Enter a value" runat="server"
asp:RequiredFieldValidator id="RequiredFieldValidator1" ControlToValidate="Text1"-->links validator to text box
Text="Required Field!"
runat="server"
asp:Button id="Button1" runat="server" Text="Validate"

Conclusion

Instead of the web developer needing to write extensive client-side JavaScript to validate this field the Validation Control does much of the work itself by linking validation rules to any HTML input control requiring similar examination. Significant time is saved, and the developer can focus on what really counts… the actual content being developed, instead of the minutia of old-style, client validation code.