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)

“If you choose not to decide you still have made a choice” - Rush

According to this article yesterday's turnout was the highest in 3 decades, with just under 60% of eligible voters actually giving any thought regarding what happens to them.

It boggles my mind that over 40% of Americans chose to allow the rest of us decide their fate.

Look around you. Of every five people you see, two of them abandoned their civic and patriotic duty yesterday. Effectively they surrendered their rights as American citizens and gave them to the rest of us.

What are you people? Apathetic? Disillusioned? Dim?

To make matters worse, we already have people claiming that Bush had a “decisive” victory. Nothing is decisive when nearly half your population has decided to be voiceless chattel...

What this really means is that the results are more along this line:

So Bush’s “decisive” victory is due to less than 1/3 of the eligible voter support.

Regardless of your political leanings, if you are a US citizen it is your civic duty to get out and vote, so please make sure to take the time today and make it to the polls.

If Minneapolis is any indication, allow extra time this year. There are already lines, and there are a lot people doing same-day registration as well.

I realize that we are all autonomous entities (to tie this to SOA). This means we have self-determination and can make our own choices to do or not do things. Just like the entities that make up services.

But self-determination is the secondary definition. Autonomy's primary meaning is self-governance. And if you don't vote today then you are giving up that primary meaning to the rest of America. You are allowing others to choose your future and the future of our nation.

Just think what will happen when SOA becomes reality in our software. We’ll have autonomous entities (the implementation behind a service) deciding whether it wants to do its “civic duty” or not. Because these entities are autonomous, they’ll be programmed with self-determination and self-governance. They can say “no, I don’t feel like waiting in that queue” and just blow off client requests.

For decades our industry has been trying to create software models of the real world. SOA finally acknowledges that software entities need to be autonomous to reflect the real world. Some 40% of US citizens are likely to exercise their autonomy today by choosing to avoid self-governance and to give that responsibility to the rest of us. If 40% of our software entities started exercising their autonomy in a similar fashion I wonder what would happen…

The point being that service-oriented design might allow us to model the real world better than procedural or OO or component-based design. But maybe that's not all it is cracked up to be, because real world systems aren't particularly reliable and certainly aren't deterministic...

Be a reliable and deterministic autonomous entity - get out and vote!

Here is a good summary of service-oriented concepts and tenents.

The only quibble I have is that the first section of the document combines SOA and web services into a unified concept. I think this is too limiting, but at the same time it is workable, since services do imply a design that may be distributed. Whether you use web services or some other technology to do the distribution, the fact is that the principles listed in the document will apply.

Pat Helland reminds me (us?) that technology is fun, but there are much bigger and more important things in life.

Not only did his blog entry bring tears to my eyes, but it reminded me that discussions of VB vs C# or Java vs .NET are intellectually enjoyable, but pale in comparison next to things like Bush vs Kerry or my mother's recovery from last week's hip surgery or the excitement of my son at Best Buy last night when he bought the expansion for Star Wars Galaxies. Those things have real and tangible meaning and value.

Whether we program with or without semi-colons or with a J or an N really don't matter at all in comparison...

This is actually a shameless plug regarding me being quoted in the press...

In the very same Enterprise Architect magazine whose article I maligned in my previous blog entry I am actually quoted in a different article. Check in the Editors Note and you'll find that Jim Fawcette does a good job of paraphrasing a statement I made about SOA during a discussion panel at VS Live in Orlando this fall.

In the just published Enterprise Architect magazine is an article titled “SOA: Debunking 3 Common Myths”. The first and third myth I generally agree with. The second is problematic on several levels.

The myth in question is that SOA implies a distributed system. The author explains that SOA does not imply a distributed system, but rather is merely a message-based architecture of providers and consumers. So far I’m in agreement. SOA can be done in a single process. Whether that’s wise or not is another discussion, but it certainly can be done.

Then the author goes on to suggest that a good architecture should include a Locator service so service providers can be moved to other machines if needed. Again, so far so good. This kind of flexibility is very important.

But then we get my point of disgreement. The closing statement is that “services (and SOA) do not imply any distribution semantics”. Say what?

If you are going to actually have the option of running a service on another machine, then you must design it to follow distributed semantics from day one. You must design it with course-grained, message-based interfaces. You must ensure that the service provider never trusts the service consumer and visa versa. You must ensure that there is no shared state between provider and consumer - including that they can't share a database or any other common resource.

In short, you must design the service provider and consumer with the assumption that they are running on separate machines. Then, having written them with distributed semantics, you can choose to collapse the physical deployment so they run in the same process on the same machine.

Failure to view SOA as a distributed architecture is a big mistake. In SOA there’s the absolute implication that the provider and consumer may be distributed. Philosophically we are designing for a distributed scenario. The fact that we might not be distributed in some cases is immaterial. SOA means you always design using distribution semantics.

I’ve been involved in yet another discussion about whether people should use Remoting (vs DCOM/Enterprise Services or ASMX/WSE), and I thought I’d share some more of my thoughts in this regard.

One key presupposition in this discussion is often than we’re talking about communication across service boundaries. The train of thought goes that Microsoft (at least the Indigo team) seems to indicate that the only cross-network communication we’ll ever do in the future is across service boundaries. In short, n-tier is dead and will never happen. Anywhere n-tier would exist should be treated as crossing a service (and thus trust) boundary.

I consider that assumption to be fundamentally flawed.

Just because the Indigo team sees a future entirely composed of services doesn't mean that is a correct answer. When MSMQ first came out the MSMQ team was telling everyone that all communication should be done through MSMQ. Filter through the absurd bias of the product teams and apply some basic judgment and it is clear that not all cross-network communication will be service-oriented.

The idea of crossing trust boundaries between parts of my application incurs a terribly high cost in terms of duplicate logic and overhead in converting data into/out of messages. The complexity and overhead is tremendous and makes no sense for communication between what would have been trusted layers in my application…

In a world where service-orientation exists, but is not the only story, there's a big difference between creating a n-layer/n-tier application and creating a set of applications that work together via services. They are totally different things. 

I totally agree that neither Remoting nor DCOM/ES are appropriate across service boundaries. Those technologies are not appropriate between applications in general.

However, I obviously do not for a minute buy the hype that service-orientation will obviate the need for n-tier architectures. And between tiers of your application, ASMX/WSE is a very limited and poor choice. As an example, ASMX/WSE uses the highly limited XmlSerializer, which is virtually useless for transferring objects by value. Between tiers of your application either Remoting or DCOM/ES are good choices.

Application tiers are just application layers that happen to be separated across a network boundary. By definition they are tightly coupled, because they are just layers of the same application. There are many techniques you can use here, all of which tend to be tightly coupled because you are inside the same service and trust boundary even though you are crossing tiers.

I’ve personally got no objection to using DCOM/ES between tiers running on different servers (like web server to app server). The deployment and networking complexity incurred is relatively immaterial in such scenarios.

But if you are creating rich or smart client tiers that talk to an app server then the loss of no-touch deployment and the increased networking complexity incurred by DCOM/ES is an overwhelming negative. In most cases this complexity and cost is far higher than the (rather substantial) performance benefit. In this scenario Remoting is usually the best option.

Of course, if you can’t or won’t use Remoting in this case, you can always hack ASMX/WSE to simulate Remoting to get the same result (with a small performance penalty). You can wrap both ends of the process manually so you can use the BinaryFormatter and actually get pass-by-value semantics with ASMX/WSE. The data on the wire is a Base64 byte array, but there's no value in being "open" between layers of your own application anyway so it doesn't matter.

There's a performance hit due to the Base64 encoding, but it may be worth it to gain the benefits of WSE. And it may be worth it so you can say that you are conforming to recommendations against Remoting.

For better or worse, Remoting does some things that neither DCOM/ES nor ASMX/WSE do well. You have the choice of either using Remoting (with its commensurate issues) or of hacking to make DCOM or ASMX/WSE do what Remoting can do. Neither choice is particularly appealing, and hopefully Indigo will provide a better solution overall. Only time will tell.

Jason Bock has been trying strange stuff with generics.

I have as well, with the intent of addressing some uses for CSLA .NET 2.0. Here’s one important concept I’ve figured out:

Public Class BaseClass

  Public Function BaseAnswer() As Integer

    Return 42

  End Function

End Class

Public Class AddMethod(Of T As {New, AddMethod(Of T)})

  Inherits BaseClass

  Public Shared Function GetObject() As T

    Return New T

  End Function

End Class

Public Class StrangeMethod

  Inherits AddMethod(Of StrangeMethod)

  Public Function GetStrangeAnswer() As Integer

    Return 123321

  End Function

End Class

Public Class TestAddMethod

  Public Sub Test()

    Dim extendedBaseClass As StrangeMethod = StrangeMethod.GetObject

    extendedBaseClass.BaseAnswer()

    extendedBaseClass.GetStrangeAnswer()

  End Sub

End Class

The primary benefits are:

1)      The consumer (the Test method) doesn’t have to deal with generic syntax at all – yea!

2)      The code inside the generic can be minimized – very little code needs to be in the AddMethod class. This is good, because debugging inside generics is limited compared to inside regular classes. Most code can be put into BaseClass rather than AddMethod, and AddMethod can include only code requiring the use of generics (unlike my trivial example here).

3)      By keeping as much code as possible in BaseClass we gain better polymorphism. Generics aren’t polymorphic, so the fewer public methods in a generic the better. Putting public methods into a base class or interface is far preferable in most cases.

4)      Note that AddMethod is constrained to only be used through inheritance. I thought this was a neat trick that helps enforce this particular model for using generics. AddMethod is only useful for creation of a subclass.