If SOA really is a revolutionary force on a par with OO, it is because it has emergent behavior. Here's some more information on emergence as a field of study and what it really means.

Earlier this week my employer, Magenic worked with the Microsoft office in Atlanta to set up a series of speaking engagements with some Atlanta-based companies. I had a good time, as I got some very good questions and discussion through some of the presentations.

In one of the presentations about SOA, an attendee challenged my assertion that “pure” SOA would lead to redundant business logic. He agreed with my example that validation logic would likely be replicated, but asserted that replication of validation logic was immaterial and that it was business logic which shouldn’t be replicated.

Now I’m the first to acknowledge that there are different types of business logic. And this isn’t the first time that I’ve had people argue that validation is not business logic. But that’s never rung true for me.

Every computer science student (and I assume CIS and MIS students) gets inundated with GIGO early in their career. Garbage-In-Garbage-Out. The mantra that illustrates just how incredibly important data validation really is.

You can write the most elegant and wonderful and perfect business logic in the world, and if you mess up the validation all your work will be for naught. Without validation, nothing else matters. Of course without calculation and manipulation and workflow the validation doesn’t matter either.

My point here is that validation, calculation, manipulation, workflow and authorization are all just different types of business logic. None are more important than others, and a flaw in any one of them ripples through a system wreaking havoc throughout.

Redundant or duplicated validation logic is no less dangerous or costly than duplicated calculation or manipulation logic. Nor is it any easier to manage, control or replicate validation logic than any other type of logic.

In fact, you could argue that it is harder to control replicated validation logic in some ways. This is because we often want to do validation in a web browser where the only real options are javascript or flash. But our “real” code is in VB or C# on the web server and/or application server. Due to the difference in technology, we can’t share any code here, but must manually replicate and maintain it.

Contrast this with calculation, manipulation or workflow, which is almost always done as part of “back end processing” and thus would be written in VB or C# in a DLL to start with. It is comparatively easy to share a well-designed DLL between a web server and app server. Not trivial I grant you, but it doesn’t require manual porting of code between platforms/languages like most validation logic we replicate.

So given the comparable importance of validation logic to the other types of business logic, it is clear to me that it must be done right. And given the relative complexity of reusing validation logic across different “tiers” or services, it is clear that we have a problem if we do decide to replicate it.

And yet changing traditional tiered applications into a set of cooperative services almost guarantees that validation logic will be replicated.

The user enters data into a web application. It validates the data of course, because the web application’s job is to give the user a good experience. Google’s new search beta is reinforcing the user expectation that even web apps can provide a rich user experience comparable to Windows. Users will demand decent interactivity, and thus validation (and some calculation) will certainly be on the web server and probably also replicated into the browser.

The web application calls the business workflow service. This service follows SOA principles and doesn’t trust the web app. After all, it is being used by other front-end apps as well, and can’t assume any of them do a good job. We’re not talking security here either – we’re talking data trust. The service just can’t trust the data coming from unknown front-end apps, as that would result in fragile coupling.

So the service must revalidate and recalculate any thing that the web app did. This is clear and obvious replication of code.

At this point we’ve probably got three versions of some or all of our validation logic (browser, web server, workflow service). We probably have some calculation/manipulation replication too, as the web server likely did some basic calculations rather than round-trip to the workflow service.

Now some code could be centralized into DLLs that are installed on both the web server and app server, so both the web app and workflow service can use the same code base. This is common sense, and works great in a homogenous environment.

But it doesn’t extend to the browser, where the replicated validation logic is in javascript. And it doesn’t work all that well if the web server is running on a different platform from the app server.

In any case, we have replication of code – all we’re doing is trying to figure out how to manage that replication in some decent way. I think this is an important conversation to have, because in my mind it is one of the two major hurdles SOA must overcome (the other being versioning).

TheServerSide.net just published an article of mine titled “The Fallacy of the Data Layer”, in which I basically carry some SOA ideas to their logical conclusion to see what happens. Unfortunately the sarcasm in the article was pretty well hidden and so the comments on the article are kinda harsh - but funny if you actually see the sarcasm

According to this article, quoting Microsoft VP Muglia, WinFS probably won't show up for real until sometime in the next decade - the version of Windows Server after Longhorn Server.

And people were wondering why I wasn't so excited about WinFS and the related ObjectSpaces technology...

Now it looks like the primary feature of Longhorn Server will be componentization. Which is nothing to sneeze at and is probably far more important on a day-to-day basis than WinFS anyway.

I frequently seem to have non-technical things I'd like to blog about. I even dipped into them a bit by encouraging people to vote in November.

And while it is often said that blogs have no rules, I submit that blogs do have self-imposed rules and/or themes.

My motivation in establishing this blog was to have a forum for editorial comments on technology - .NET, SOA or whatever other technical areas catch my interest. If you are a reader of my blog, I assume you have overlapping interests around technology.

I don't assume you share all my other interests. And thus I've set up a separate personal blog. It is a forum for all my non-professional interests (things like religion, politics, hobbies, etc). This way I can keep posts on this blog entirely focused on technology, and still have a forum for my diverse other interests.

Now back to our regularly scheduled technology discussions...

Last night a group of top developers from the Minneapolis area had dinner with David Chappell. Great company, great food and great conversation; what more could you want?

The conversation ranged wide, from whether parents should perpetuate the myth of the Tooth Fairy and Santa all the way down to how Whidbey’s System.Transactions compares to the transactional functionality in BizTalk Server.

At one point during the conversation David mentioned that there’s not only an impedance mismatch between objects and relational data, but also between users and objects and between services and objects. While the user-object mismatch is somewhat understood, we’re just now starting to learn the nature of the service-object mismatch.

(The OO-relational impedance mismatch is well-known and is discussed in many OO books, perhaps most succinctly in David Taylor’s book)

I think that his observation is accurate, and it is actually the topic of an article I submitted to TheServerSide.net a few days ago, so look for that to stir some controversy in the next few weeks

I also heard that some people have read my blog entries on remoting (this one in particular I think) and somehow came to the conclusion that I was indicating that Indigo would be binary compatible with remoting. To be clear, as far as I know Indigo won’t be binary compatible with remoting. Heck, remoting isn’t binary compatible with remoting. Try accessing a .NET 1.1 server from a 1.0 client and see what happens!

What I said is that if you are careful about how you use remoting today you’ll have a relatively easy upgrade path to Indigo. Which is no different than using asmx or ES today. They’ll all have an upgrade path to Indigo, but that doesn’t imply that Indigo will natively interoperate with remoting or ES (DCOM).

(Presumably Indigo will interop with asmx because that’s just SOAP, but even then you’ll want to change your code to take advantage of the new Indigo features, so it is still an upgrade process)

What does “be careful how you use remoting” mean? This:

1. Use the Http channel
2. Host in IIS
3. Use the BinaryFormatter
4. Do not create or use custom sinks, formatters or channels

If you follow these rules you should have a relatively direct upgrade path to Indigo. Will you have to change your code? Of course. That’s what an upgrade path IS. It means you can, with relative ease, update your code to work with the new technology.

The organizers of HDC 04 should be proud. For their first outing in organizing a conference they've outdone themselves.

There are around 150 people here from the midwest area (Minnesota, Iowa, Nebraska, etc.) and also a few from as far away as Boston. I gather that they sold out in just 3 weeks and couldn't take more people because the venue just can't handle any more.

Next year they'll need a bigger hotel, because you just can't beat a day of dual-track content for $18 - lunch included.

As a Minnesotan, I am thrilled to see this kind of event and this level of interest in the midwest. When you consider that recent VS Live shows in Chicago only drew around 500 people, and that (venue permitting) the HDC's first outing would have topped 200 people this is really impressive!

Last night was a pre-event party, and I enjoyed several great conversations ranging from SOA to VB to generics to hunting and fishing. Got to love it! Sam Gentile and I had a long running and very enjoyable discussion that covered SOA and the future of VB. As he said, I got him to spend more time talking about VB than he’s spent in the last three or more years total - glad I could broaden some horizons

I just finished reading through Ted Neward’s Effective Enterprise Java book (ISBN 780321130006) and it is a must read for any enterprise .NET developer.

I hear it now. “What?! A Java book for .NET developers? Rocky, you’ve gone over the edge!”

No, I haven’t gone over the edge, and YES, absolutely a Java book for .NET developers.

It would be extremely foolish for any enterprise developer to read only .NET or Java information. It isn’t like either technology as a monopoly on smart, eloquent technical experts. On top of that, the two platforms are so similar at an architecture and software design level that the same guidelines and best practices apply equally to both.

So yes, go out and read Ted’s book. Every single item in the book has direct applicability to .NET. Sure you’ll need to translate some terminology to the .NET world, but that’s a minor thing. The important thing is that you’ll learn a whole lot about the good, the bad and the ugly when it comes to creating enterprise applications.

The truisms for minimizing network costs (latency, bandwidth, etc.) are universal. The tradeoffs when dealing with shared state and mapping state between objects, databases and XML are universal. The need to reduce locking and blocking are universal. The OO design patterns that address these issues in Java are exactly the patterns that apply in the .NET space as well.

And since this is a book about enterprise issues, there’s relatively little code and you can safely ignore virtually all of it. No offense to Ted, but this book doesn’t need any of the Java code. I’m sure he put it in there to make it actually feel like a Java book. No, the value is in the sometimes irreverent yet thorough discussion of the issues and the tradeoffs involved in addressing those issues.

Honestly, if this book used more universal terminology and skipped the few code examples it has, it would be a universal must-have resource for any modern enterprise platform – Java, .NET or whatever. I contend that it still fills this role, albeit with the need for .NET readers to mentally translate some terminology into our world. And that’s a small price to pay.

I will be speaking at VS Live San Francisco, Feb 6-10, 2005.

As part of the event, I'll be doing a full day pre-con workshop covering distributed object-oriented archtiecture, design and programming concepts based on the concepts and code from my Business Objects books. This means that the workshop not only provides a lot of good theory, but also very practical demonstrations on how to apply that theory using the CSLA .NET framework. I will not only cover the framework as described in the books, but also all the enhancements to the framework since that point - including the most recent enhancements present in version 1.5 of the framework.

This Thursday is the American Thanksgiving holiday. Over the years it has become a general holiday for giving thanks for all that we have, both as a country and as individuals. There is great power in spending time thinking about good things – things worth being thankful for. Whether you thank God, the Goddess, the fates or the universe in general, this is a time for reflection and thanks.

And so I wanted to take this opportunity to list some things for which I’m thankful:

• I am glad that I am not alone in my constant seeking of the deeper truth behind the mysteries of the universe and God.

The fact that we live in a universe filled with complexity and wonder is a gift to be treasured.

• My wife, who is the best and most wonderful person and friend I could ever hope for
• My sons, who are a constant source of joy and energy and hope for the future
• My parents, who have been there through thick and thin and have truly shown that blood is thicker than water
• My brother, who has always been a best friend – and his family, who also great friends
• My in-laws, who have taken me in as their own son
• My friends, steadfast and true
• My colleagues and friends at Magenic and in the broader computer industry, who are an inspiration in many ways

I am fortunate indeed to travel through life in such company as this!

I am also thankful for all the support I get from people who’ve read my books and articles, or have seen me speak at conferences or user groups. I get a regular stream of emails from around the world, and I count myself lucky to be able to interact with so many wonderful people.

• Minnesota, land of 10,000 lakes and huge tracts of wilderness and of sun and snow – all of which replenish my spirit
• The ability to hunt and fish and hike and camp and canoe and to truly enjoy this awesome state
• Our incredibly interesting and diverse politics – unique in many ways; ever changing, unpredictable and not overly tied to the quagmire of the national parties

Given my career, I could live almost anywhere. People ask “why Minnesota?” But Minnesota is beautiful in the summer, fall, winter and spring. Every season has something different to offer.

• I am thankful for the freedoms we enjoy in America. Recent events, global and domestic, have driven home the incredible value of the freedoms guaranteed in the Bill of Rights, and I think have shown how fragile they are in the face of adversity
• Thank you to the men and women in the armed forces, now and over the past 200+ years. Regardless of the political rights or wrongs, the people serving in our military are brave, selfless and deserve our gratitude

Is our country perfect? No. But we are collectively always striving for better. Better for us and for our children. I am thankful to live in a nation founded on the idea of freedom of expression, religion and the pursuit of happiness.

• I have been fortunate enough to travel to many parts of the world. I love seeing different peoples, different countries and different cities. Every time I travel it reminds me that we are all much more alike than we are different, and that gives me great hope for the future of mankind
• I have also been fortunate enough to travel in much of the US. Like the rest of the world, the peoples of the US are more alike than different. Yet it is our diversity that is compelling, and which makes us strong and for that I am thankful

I’ve been to Spain, California, New York, Canada, Mexico, Florida, Britain, France, Morocco, Alabama, the Netherlands, Australia and many other places. Everywhere I’ve been there’s a constant drive for human dignity, for the betterment of the world and love for children. People work and eat and sleep and play and love. We are all much more alike than we are different.

I believe that most people around the world spend their time in labors of love not hatred, and for that I am forever thankful.

For some time now I’ve been writing relatively cautionary entries on service-orientation. Speculating whether it is really anything new, or is just another communication scheme not unlike RPC, DCOM, RMI and others before. It seems that Grady Booch is of a similar mind, suggesting that SOA is not the be-all-and-end-all of architectures, and that it may not be an architecture at all.

In a couple weeks I’m giving the keynote at the Heartland Developer’s Conference in Des Moines. I’ll be talking about service-orientation from a historical perspective. How does it relate and compare to procedural, object-oriented and component-based schemes, as well as client/server and n-tier. In putting together the presentation, I had to formalize a lot of my thoughts on the topic, and the more I’ve considered it, the more skeptical I have become that service-orientation or SOA is a tangibly new thing.

If it is tangibly new, then it is a new way of thinking or conceptualizing the problem space, not a new technology solution. Web services, SOAP, XML and related technologies are merely incrementally new twists on very old ideas. In and of themselves they offer nothing terribly new from an architecture perspective.

But SOA itself isn’t about technology. It is about a new way of modeling reality. It is very data-centric and thus is diametrically opposed to object-orientation. It is much more similar to the older procedural world-view, where data is passive and procedures are the only active entities in a system.

But it isn’t really procedural either, at least not in a traditional sense. This is because procedural design has an underlying assumption that procedure calls are virtually free. In an SO model, service calls have very high overhead – or at least we must assume they do, because that is one possible (and likely) deployment scenario.

Ultimately SO appears to be procedural programming, with the addition of high overhead per call (thus forcing serious granularity changes in design) and dynamic negotiation of the communication semantics (protocol, orthogonal services, etc.) – though there’s no real implementation yet of this dynamic negotiation… And even that isn’t really an architecture thing as much as technological coolness.

So in the end, SO is procedural programming redux, with the caveat that the procedures are very expensive and should be called rarely. Kinda boring in that light…

Or, as I’ll say in my keynote, SO could be emergent (as defined here and here). It could be that the new combination of old concepts and simpler ideas combine to make something new and unexpected. Something that isn’t obvious. Much the same way the simple moves of individual chess pieces combine to create a highly sophisticated whole. The end result is certainly not obvious based on the simplicity of the core rules. And if SO is emergent, then it is far from boring!!

Only time will tell. The next decade will be quite interesting in this regard.

Rocky Lhotka discusses VB.NET's focus on business application development.
(from TheServerSide.NET)