Code Camp - San Diego

This year I made it to the Pre-Code Camp Dinner. It was great meeting fellow contributors and technology enthusiasts. On Sunday, I'll be speaking on Business Rules Engines . See you there.

Service Infrastructure

A good infrastructure is key to a successful SOA implementation. So what exactly is infrastructure? Infrastructure typically refers to the functional and non functional requirements of a service that are not a part of the business logic itself. In other words features such as brokered communication, mediation, security, administration and monitoring all qualify as infrastructure. The infrastructure may also be responsible for providing transaction management, resource management, provisioning, etc.

So how much infrastructure do we need? The answer: It depends. It's like asking how many features are needed before we ship a version of a product. The answer: It depends. Some features are crucial while others are nice to have. There are many factors to consider before investing in infrastructure. Remember the purpose of technology is to help the business profit ^[1]. One of the biggest considerations is build vs buy. I will cover the build vs buy debate in a future blog.

What is available from Microsoft? Microsoft currently has the .Net Framework 3.5, Visual Studio 8 and BizTalk Server 2006 R2 and is investing some of the top engineering talent in its OSLO initiative. Microsoft WCF is definitely a major leap in technology for building distributed applications on the Windows platform. However it's not immune to any poor design choices employed by a SOA practitioner.

When building SOA applications a good design discipline is separating infrastructure components from business/application components. It sounds like a no-brainer, but believe me I have seen many implementations that muddy the waters by not separating them. Keeping them separate allows for the infrastructure and business logic to change at different rates.

In my next blog, I will present a reference architecture and discuss service invocation. Cheers!

Service Interface Design

I define a “service” as logical grouping of discrete components you interact with via message exchanges. When building services employing an interface that exposes any native object schema nails you to a specific language set. (at least on the implementation side of things). The goal should be create a universally accessible messaging apparatus that permits a service to process requests irrespective of its language base. The best approach is to allow publishers and consumers of the message to work with their own view of a request.

In a pure messaging model, a message should be self describing which means you can't possibly know what the contents are until you get it. Upon receipt the message is analyzed and processed in context. An intermediate layer can mediate the request if needed.

The Verdit. - “String In – String Out”.

Notice that I didn't say XML in - XML out. XML could be the structure but the fact that the format is XML is happenstance.

“Show Me the Money!”

Recently, I was presenting “Building Agile Enterprise Applications” to an audience of developers and one of the them asked me if there were any “best practices” that I would recommend for building SOA applications. Now I do not profess to be any SOA guru, but I would like to share my experience and views on application development and building architecturally rich solutions.

The main objective of a business is to generate profit. In simple accounting terms profit = total revenue – total expenses. So, the lower the cost, the better the probability of profit. In an effort to reduce cost, businesses utilize technology. Therefore, when building software always remember that the objective of technology is to help the business profit.

But technology has its own cost. One of the ways to reduce the total cost of ownership (TCO) of technology is leveraging existing assets. Service Orientation is all about leveraging existing assets while being able to compose them into new applications easily. SOA isn’t a new approach; some of the notions behind SOA have been around for years. However, building SOA applications poses several challenges specifically as it pertains to composing, consuming and managing services. Stay tuned for more blogs on this topic.