Describing SOA

A colleague, Nigel Bakker, and I recently were asked to present a SOA training course, while finding content was easy, we battled to find a coherent definition of SOA that encompasses the enterprise elements of this paradigm as well as the application level element.

We came up with the following:

• Service Orientated Architecture (SOA) is an Enterprise Architecture Style
• SOA is not a methodology it is an approach or mindset usually called a paradigm
• SOA needs a firm foundation or the enterprise will fail as every piece of the SOA should contribute.
• Service Orientated Application Design (SOAD) provides this foundation.
• SOA is both a business and IT architecture approach, whilst SOAD is an application design approach aligned with and supporting SOA.

A Thomas Erl quote was useful
“Service-orientation is a design paradigm comprised of a specific set of design principles. The application of these principles to the design of solution logic results in service-oriented solution logic. The most fundamental unit of service-oriented solution logic is the service.”
The interesting point he makes is that the focus here is on “solution logic” which is exactly the scope that applies in building an application using “service orientation”, but can equally apply when building cross application services

Building Service Orientated Applications using Windows Communication Foundation

SOA is a big business buzzword tossed into conversations at board meetings and at executive briefings. At this level, however, SOA really refers to connecting disparate systems across application, department, corporate, and even industry boundaries. This is the “Big” SOA concept, and this is the realm of the enterprise architect.

This is the space of multimillion rand Service Bus applications, SAP systems and other wonderful products. But the fact still remains that a chain is a strong as its weakest link, if the systems hooked up to the top of the range Service Bus are not rock solid and can not be trusted to produce the correct results all the time, then the some of the true potential of the investment is lost.

The path to “Big” SOA begins with a solid base and the ideas presented in this paper will provide you with the tools you need to achieve this.

As businesses struggle to reap the rewards of their investment in a SOA approach, the importance of “Little” SOA is becoming lost in the marketing hype and scramble by vendors to sell you their version of service orientation.

This paper offers practical advice for building Service Orientated Applications, using service oriented programming (SO) as an approach, that shows that every component can be a service while still maintaining the technical requirements that modern applications are required to exhibit and in most cases surpassing what many application frameworks offer to date.

By building a solid “Little” SOA base, the platform is set at an enterprise level to realise the composition and reuse that is the value proposition of SOA, as without a “Little” SOA that is properly portioned, rock solid and composeable, attempts to realise more will fail.

I hope to share some of the best practices, techniques and tools that I have learned from the last two years of applying WCF to the construction of service orientated applications and also to provide an insight to application architects on how to achieve the non functional specifications that many projects only play lip service to.

The paper can be found at:
http://www.box.net/shared/3oce5tvf8f

WCF datacontracts and IDataErrorInfo

For those of you who are using WCF you not be aware of an interface that when implemented on your DataContracts allows you validate and reject invalid values.

This can be leveraged in either ASP.NET or WPF by binding the UI controls to the DataContract to give you client side input validation.

Its use is well documented in WPF , MCV framework, but iI could find nothing around using it on DataContracts. Of course you can only take advantage of this if you are WCF to WCF.

This post is not about using IDataErrorInfo, but solving a particular prolem related to its use.

Problem statement :

When using IDataErrorInfo in an inheretence hierachy we run into problems when the property that needs to be validated is on the base class. The reason for this is that it is the subclass that is casted to IDataErrorInfo and then validates. We need a way to ensure that properties are also validated in the base class.

As a first solution you’ll probably try something like;

(base as IDataErrorInfo)[“PropertyToValidate”] ,but this does not work, as the base keyword is invalid in the above statement.

A second solution would be to have a method on the base class and then have it validate its property, something like;

string Validate(string columnName)
{
Return (this as IDataErrorInfo)[“PropertyToValidate”]
}

But this also fails as it will cast the subclass instance into IDataErrorInfo and then validate the subclass.

So we have to come up with a solution that will ensure that the correct class’s properties be validated.

Solution :

The solution to this problem is actually a combination of the two proposed solutions above. We have the subclass call a method on the base to do the validation, but we also have the IDataErrorInfo methods call this same method to do the validation.

This way even if our subclass does not implement IDataErrorInfo, but only want’s the base class to do the validation it will still work. See code example below.

Base Class Definition:

public abstract class BaseClass : IDataErrorInfo
{
protected string m_Error;
public string BaseClassProperty { get; set; }

string IDataErrorInfo.Error
{
get
{
return m_Error;
}
}

string IDataErrorInfo.this[string columnName]
{
get
{
return Validate(columnName);
}
}

protected internal string Validate(string columnName)
{
m_Error = String.Empty;

if (columnName == "BaseClassProperty")
{
if (String.IsNullOrEmpty(BaseClassProperty))
{
m_Error = "BaseClassProperty not set.";
}
}

return m_Error;
}
}

research by E. Landsberg

Using IT to survive the economic crisis

Sun Tzu wrote 2500 years ago in The Art of War: So it is said that if you know your enemies and know yourself, you will fight without danger in battles.

So if a business knows is processes and has clear goals, and acknowledges that IT complexity and over specification is the enemy. Good things ensue.

In this tough financial climate businesses that figure this out will find themselves reducing IT costs and squashing process complexity. These organisations will emerge from the financial downturn as the winners and will be positioned to quickly take advantage of new opportunities. i economic