The Four Tenets of SOA

John Evdemon has the following to say of SOA in his article with the same title how true is this statement.

'SOA has become a well-known and somewhat divisive acronym. If one asks two people to define SOA one is likely to receive two very different, possibly conflicting, answers. In many ways SOA is a bit like John Godfrey Saxe’s poem about the blind men and the elephant – each of the men describes the elephant a bit differently because each of them are influenced by their individual experiences (e.g. the man touching the trunk believes it’s a snake while the one touching a tusk believes it’s a spear). Mr. Saxe’s elephant is much easier to describe because it exists as a physical entity - SOA, however, is a much harder to describe since design philosophies are not available as a physical manifestation. '

e above is just the begining of wonderful article and it is quite difficult to reproduce the same.

The SOA tenets originally appeared back in 2004 when Don Box published an article on MSDN called "A Guide to developing and Running Connected Systems with Indigo" (Indigo is what's known today as Windows Communication Foundation or WCF for short).

Don continues to define and explain he following 4 tenets:

• Boundaries are explicit
• Services are autonomous
• Services share schema and contract, not class
• Service compatibility is determined based on policy
  

The interesting fact is that Microsoft's Harry Pierson (a.k.a. DevHawk) suggests that Microsoft's own 4 tenets for SOA should be retired because, well, they are, in Harry's opinion, useless - at least they are not useful anymore.

He says, "I would say that the tenets' job is done and it's time to retire them. Once you accept the service-oriented paradigm, what further guidance do the tenets provide? Not much, if any"

If this statement surprises you read the article: Retire Microsoft's Four SOA tenets?

A Performance Comparison of Windows Communication Foundation

Windows Communication Foundation (WCF) is a distributed communication technology that ships as part of the .NET Framework 3.0. The following article concentrates on comparing the performance of WCF with existing .NET distributed communication technologies.

A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies

Here is the conclusion taken from the above article:
To summarize the results, WCF is 25%—50% faster than ASP.NET Web Services, and approximately 25% faster than .NET Remoting. Comparison with .NET Enterprise Service is load dependant, as in one case WCF is nearly 100% faster but in another scenario it is nearly 25% slower. For WSE 2.0/3.0 implementations, migrating them to WCF will obviously provide the most significant performance gains of almost 4x.

WCF vs Remoting

The following blog does the comparison between WCF and Remoting.

WCF vs. Remoting (with DataSet)- performance comparison

Here is the conclusion taken from the above article:
Sending DataSet with .NET Remoting is faster than sending it with WCF. Maybe there is some other way to improve the WCF in case of sending DatSet but I haven't found it yet. I'll post the test project somewhere (maybe on codeproject) so it could be examined.

He further refined his test in the following blog

WCF vs Remoting - adjustments to my results

Here is the conclusion taken from above article:

The WCF and .NET Remoting are really comparable in performance. The differences are so small (measuring client latency) that it does not matter which one is a bit faster. WCF though has much better server throughput than .NET Remoting and WCF does much more than.

Delegate and Events

People often find it difficult to see the difference between events and delegates. C# doesn't help matters by allowing you to declare field-like events which are automatically backed by a delegate variable of the same name. In this posting, I will just touch the surface so that it will tickle you to go ahead read the references that are given at the end of the posting.

In his blog Roy Osherove has the following comments:

Here’s how you define a delegate in a class:

public class SampleDelegate
{
public delegate void DoSomethingDelegate(int num1, int num2);
public DoSomethingDelegate MyDelegateCallback;
}

And here’s how you declare an event of this delegate:

public class SampleEvent
{
public delegate void DomSomethingDelegate(int num1, int num2);
public event DomSomethingDelegate MyDelegateCallback;
}

Notice that syntactically, the only difference is that you place an “event” keyword before the delegate variable declaration.

So what’s the “event” keyword adding to this?
Well, to understand this, consider SampleDelegate in the code above. If you are using this class, as a client you could set it’s delegate variable like this:

SampleDelegate c = new SampleDelegate();
c.MyDelegateCallback += new SampleDelegate.DoSomethingDelegate(this.Calculate);

This simple code adds a new target to the delegate’s invocation list and the same code will work for SampleEvent.

SampleEvent c = new SampleEvent();
c.MyDelegateCallback += new SampleEvent.DomSomethingDelegate(this.Calculate);

There is no difference what so ever so far. But consider this code which, instead of adding a new target to the delegate’s Invocation list, simply sets the delegate to a new delegate:

SampleDelegate c = new SampleDelegate();
c.MyDelegateCallback = new SampleDelegate.DoSomethingDelegate(this.Calculate);

This piece of code will work just fine with SampleDelegate, but if you try to use it on SampleEvent, where there is the event keyword declared, youwould get a compilation error.

In essence, declaring the event keyword prevents any of the delegate’s users from setting it to null. Why is this important? Image that as a client you would add to the delegates invocation list a callback to one of my class’s functions. So would other clients. All is well and good. Now suppose someone, instead of using the “+=”, is simply setting the delegate to a new callback by using simply “=”. They basically just threw the old delegate and its invocation list down the drain and created a whole new delegate with a single item in its invocation list. All the other clients will not receive their callbacks when the time comes. It is this kind of situation that having the “event” keyword is aiming to solve.

In conclusion: an event declaration adds a layer of protection on the delegate instance. This protection prevents clients of the delegate from resetting the delegate and its invocation list, and only allows adding or removing targets from the invocation list.

For a deeper insight refer to the Jon Skeet's article - Delegates and events. Also Julien Couvreur's article C# events vs. delegates is worth reading.

Humor hour - Something to make you smile!

Kids Are Quick
____________________________________
TEACHER: Maria, go to the map and find North America.
MARIA: Here it is..
TEACHER: Correct. Now class, who discovered America?
CLASS: Maria.
____________________________________
TEACHER: John, why are you doing your math multiplication on the floor?
JOHN: You told me to do it without using tables.
______________________________ ____________
TEACHER: Glenn, how do you spell 'crocodile?'
GLENN: K-R-O-K-O-D-I-A-L'
TEACHER: No, that's wrong
GLENN: Maybe it is wrong, but you asked me how I spell it.
____________________________________________
TEACHER: Donald, what is the chemical formula for water?
DONALD: H I J K L M N O.
TEACHER: What are you talking about?
DONALD: Yesterday you said it's H to O.
__________________________________
TEACHER: Winnie, name one important thing we have today that wedidn't have ten years ago.
WINNIE: Me!
__________________________________________
TEACHER: Glen, why do you always get so dirty?
GLEN: Well, I'm a lot closer to the ground than you are.
_______________________________________
TEACHER: Millie, give me a sentence starting with 'I.'
MILLIE: I is..TEACHER: No, Millie..... Always say, 'I am.'
MILLIE: All right.... 'I am the ninth letter of the alphabet.'
_________________________________
TEACHER: George Washington not only chopped down his father's cherry tree, but also admitted it. Now, Louie, do you know why his father didn't punish him?
LOUIS: Because George still had the axe in his hand.
______________________________________
TEACHER: Now, Simon, tell me frankly, do you say prayers before eating?
SIMON: No sir, I don't have to, my Mom is a good cook.
______________________________
TEACHER: Clyde, your composition on 'My Dog' is exactly the same as your brother's. Did you copy his?
CLYDE: No, sir. It's the same dog.
___________________________________
TEACHER: Harold, what do you call a person who keeps on talking when people are no longer interested?
HAROLD: A teacher
__________________________________

Five Steps to Improved Performance

With the limited time available for tuning, and the extent of improvement that is typically needed, it is vital to focus on those areas that have the highest potential for payoff, rather than to expend effort on improvements that have a negligible overall effect. You may find yourself spending weeks or even months tuning the software without seeing significant improvements. It is usually caused by speculation on the cause of performance problems and a random approach to improvements. The steps below allow you to quickly identify problems, focus your effort on the areas of the software that have the greatest potential for improvement and estimate the relative payoff for potential improvements.

Step 1: Figure Out Where You Need to Be

You should define precise, quantitative, measurable performance objectives. You can express performance objectives in several ways, including response time, throughput, or constraints on resource usage. Some examples are: “The response time for a transaction should be one second or less with up to 1,000 users.” or “CPU utilization should be less than 65% for a peak load of 2,000 events per second.”

When defining performance objectives, don’t forget that your needs may change over the product’s lifetime. For example, your current performance objective may be to process 10,000 events per second. However, in two years, you may need to be able to process 30,000 events per second. It is a good idea to consider future uses of your software so that you can anticipate these changes and build in the necessary scalability.

Step 2: Determine Where You Are Now

Begin by quantifying the problems and identifying their causes. Which uses of the software are causing problems? Typically, these are the most frequent uses. If you don’t have good documentation (like UML sequence diagrams) for these uses, it’s a good idea to do this now. Then, identify the workloads (transaction or customer-call volumes, event arrival rates, and so on) that are causing problems.

Focusing on the architecture provides more and potentially greater options for performance improvement than tuning. By focusing on the architecture, you can identify opportunities for changing what the software does.

Now you will later need to take measurements of the scenarios under operational conditions. This will allow you to understand the system performance parameters such as CPU utilization, I/O rates and average service time, network utilization, message size, and so on. This, in turn, will allow you to identify the bottleneck(s)—the device(s) with the highest utilization. Then, profile the processing steps in the performance scenarios to identify the “hot spots.” The overall impact of improvements gained from addressing these hot spots will be far greater than that of random improvements.

Step 3: Decide Whether You Can Achieve Your Objectives

Before you dive into tuning your software, it’s a good idea to stop and see if you can actually achieve your objectives by tuning. If the difference between where you are now and where you need to be is small, then tuning will probably help. You may even be able to achieve your performance objectives without making changes to the code by tuning operating system parameters, network configuration, file placements, and so on. If not, you’ll need to tune the software.

Performance remedies range from low-cost (and, usually, low-payoff) automatic optimization options (e.g., compiler optimizations) to high-cost (and, potentially, high- payoff) software refactoring or re-creation. Intermediate options are to optimize algorithms and data structures and/or modify program code to use more efficient constructs.

Once you’ve identified the hot spots, some simple calculations will help you decide if you can meet your performance objectives by tuning the software. If not, you may need to explore other alternatives, such as adding more processors. If it is, then you can proceed with confidence as you tune the software. You might also create software models that depict the end-to-end processing steps for performance scenarios. The models will help you quantify the effects of more complex solutions, particularly those that involve contention for resources.

Step 4: Develop a Plan for Achieving Your Objectives

Once you have identified potential remedies, you can rank them based on their payoff. Then apply them starting with those that have the highest payoff. You determine the quantitative performance improvement by estimating the new resource requirements.

Create a list of options that compares the performance improvement versus the costs to determine the best candidates. Note that you may not always choose the option with the best performance improvement because other factors may make it less desirable. For example, the option with the best performance improvement may be risky because it uses an unfamiliar new technology. Or, a change with a high performance payoff may negatively impact another important quality such as maintainability or reliability. You may elect to correct problems with hardware. Be sure to use the models to evaluate this option too. Sometimes the problem is caused by software and no amount of hardware will correct it.

Step 5: Conduct an Economic Analysis of the Project

Upon completion, gather data on the time and cost for the performance analysis, time and for software changes (include coding and testing), hardware costs if applicable, software distribution costs when applicable, and all other costs of the project. Then gather data on the effect of the improvements. These may include savings due to deferred hardware upgrades, staff savings (ie. If fewer staff members are required to use the software), revenue increases (ie. when you can increase the number of orders processed), and so on. It is also a good idea to review the changes made to see if they could have been predicted earlier in the software’s life. If your problems could have been prevented, compare the costs and benefits of detecting and correctingproblems earlier versus detecting them after problems occurred. Then use this data on your next project to determine whether it is worthwhile to spend a little more effort during development to prevent problems.

Cost-Benefit Analysis

The process involves, whether explicitly or implicitly, weighing the total expected costs against the total expected benefits of one or more actions in order to choose the best or most profitable option. Using this process can provide a high payoff for a relatively small cost.

An Ounce of Prevention

Once you run into trouble, tuning the software is likely to be your only choice. However, it’s important to realize that a tuned system will rarely, if ever, exhibit the level of performance that you could have achieved by designing in performance from the beginning. The key to achieving optimum performance is to adopt a proactive approach to performance management that anticipates potential performance problems and includes techniques for identifying and responding to those problems early in the process. With a proactive approach, you produce software that meets performance objectives and is delivered on time and within budget, and avoid the project crises brought about by the need for tuning at the end of the project.

Note: This content is cut down version of the following:
Five Steps to Improved Performance by Lloyd G. Williams and Connie U. Smith

Databinding in WPF

Data binding in the user interface layer is nothing new. It has been around for quite some time, in various UI platforms, both for desktop and Web applications. The basic idea is that you "bind" the visual elements (controls) in a user interface to the data objects they are meant to display. The binding infrastructure then manages the data interactions from then on, so that modifications to the UI controls are reflected in the data objects, and vice versa. The major benefit of using data binding is that it reduces the amount of code the application developer needs to write.

The architects of some earlier UI platforms have done a good job integrating data binding with the rest of their framework. WPF's architects have done an amazing job integrating data binding with all aspects of their framework. Data binding in WPF is ubiquitous and seamless. It is so powerful and flexible that it literally forces you to change the way you think about designing and developing user interfaces.

With one simple API you can bind to domain/business objects, XML data, visual elements, ADO.NET data containers, collections, and basically anything else you can think of. You can use value converters to execute arbitrary data manipulation operations when bound values are passed back and forth. You can perform data validation by creating custom validation rules and applying them to a binding. The list goes on. Data binding in WPF is really a huge step forward.

A comparison

A developer typically creates a class to represent an entity (table) in the database, whereby CRUD operations are performed by calling methods on the objects, e.g; for class Employee, objEmployee.Save(), objEmployee.Load(), objEmployee.Update(), objEmployee.Delete() etc. Also, everytime the values in the object change, the developer has to manually write code to update each of the UI elements that display the values stored in the object's members. The same holds true when the values on the UI change. With WPF, you can lessen your code greatly by binding the object directly with the UI (each of object's members data-bound to individual UI elements) using XAML syntax. Adnan Farooq Hashmi does a very good comparison between the older approaches and the new approach in his blog.

The world of data binding

Josh Smith explores the world of data binding, and how it is put to use in the WPF Horse Race demo application in his article. His article will tickle your taste buds and you will desire more and for this you can turn on to the msdn article by Shawn Wildermuth where he gives a detailed explantion of the same. I guess that the wpf is incomplete with out the mention of binding converters and Amit has posted the following artcle WPF Binding Converter Best Practices.

Binding with LINQ to SQL

LINQ to SQL is an object-relational mapper (ORM) tool that generates business objects that match your database structure. When using LINQ to bind in a WPF interface, LINQ object already define the INotifyPropertyChanged interface, which means change notification is possible for any values edited from another process. Brian Mains has touche well on this topic in his good article 'WPF Data Binding, With LINQ'.

The Allure of Distributed Objects

This is a very interesting section taken from 'Patterns of Enterprise Application Architecture' by Martin Fowler. It throws light on on how we at times fall into the Allure of Distributed Objects. A careful thought has to be given when designing such solutions.

There is a recurring presentation that I used to see two or three times a year during design reviews. Proudly the system architect of a new OO system lays out his plan for a new distributed object system—let's pretend it's a some kind of ordering system. He shows me a design with separate remote objects for customers, orders, products, and deliveries. Each one is a separate component that can be placed on a separate processing node.

Distribute an application by putting different components on different nodes.
I ask, "Why do you do this?"
"Performance, of course," the architect replies, looking at me a little oddly. "We can run each component on a separate box. If one component gets too busy we add extra boxes for it so we can load-balance our application." The look is now curious as if he wonders if I really know anything about real distributed object stuff at all.

Meanwhile I'm faced with an interesting dilemma. Do I just say out and out that this design sucks like an inverted hurricane and get shown the door immediately? Or do I slowly try to show my client the light? The latter is more remunerative but much tougher since the client is usually very pleased with his architecture, and it takes a lot to give up on a fond dream.

So assuming you haven't shown this book the door I guess you'll want to know why this distributed architecture sucks. After all, many tool vendors will tell you that the whole point of distributed objects is that you can take a bunch of objects and position them as you like on processing nodes. Also, their powerful middleware provides transparency. Transparency allows objects to call each other within a process or between a process without having to know if the callee is in the same process, in another process, or on another machine.

Transparency is valuable, but while many things can be made transparent in distributed objects, performance isn't usually one of them. Although our prototypical architect was distributing objects the way he was for performance reasons, in fact his design will usually cripple performance, make the system much harder to build and deploy, or, usually, do both.

Performance Myths

Many organizations have used a "fix-it-later" approach to performance. This approach advocated concentrating on correctness and deferring consideration of performance until the testing phase. Performance problems detected then, were corrected by adding additional hardware, tuning the software (usually in a crisis-mode), or both.

Because it is based on several performance myths, this approach can be dangerous. These myths include:

Performance problems are rare: The reality is that the number, size and complexity of systems has increased dramatically and todays developers are less expert at dealing with performance than their predecessors. As a result, performance problems are all too common.

Hardware is fast and inexpensive: The reality is that processor speeds have increased dramatically, but networks are far slower. Furthermore, software threading issues cause performance problems despite the availability of hardware resources. No one has an unlimited hardware budget, and some software may require more resources than the hardware technology can provide.

Responsive software costs too much to build: This is no longer true thanks to SPE methods and tools. In fact, the "fix-it-later" approach is likely to have higher costs.

You can tune it later: This myth is based on the erroneous assumption that performance problems are due to inefficient coding rather than fundamental architectural or design problems. Re-doing a design late in the process is very expensive.