In the latest event in the discussion about SOA and objects with Steve, he responds to me the following: “I’d argue that you are passing objects, they’re just wrapped up in messages.”

Steve, yes, my point is to support your previous assessments that what matters is not how are your objects on the inside done or how much logic they may have, but the WSDL and the XSD, and the policy, applied to your service (in a WS based service). But to understand my point, I’ll go back to what I said here: the ASMX is evil in the sense that it convinces people there’s no difference between expressing an object in XML (serialization) and passing XML messages around. This assumption is only valid in simple cases.

Let’s make a simple comparison: Is a word document better off being a dump of the object layout in word, or as an xml document? Which one is tightly couple and a maintenance hell? Which one can support versioning and the open content model, and things like inherit by extension? Response: The first was the word file format, a mess to keep backward compatible according to office devs, and difficult to envolve. And it was exactly that, an OLE Stream file…

Objects limit you to a CLR view. The problem with starting from saying you map objects in XML is that you:

1.      Restrict your view of how other systems are going to consume your web service, that won’t use the same objects as you, or the same language, or the same platform, or even the same paradigm. There ARE going to be a lot of people using batch files to query web services. I’m already doing it, and it’s far more productive for certain tasks than code.

2.      Restrict your view on how extensible your data will be. An object can only be modified through inheritance or interfaces in the .net world. In the xsd world, validation is there, inheritance by restriction and inheritance by extension. These intrinsic values of XML are lost when you try to stick with objects.
Let me expand a bit. When you map on objects, you either map to an XmlNode for the open content model, or you die upon deserialization. You are sensitive to changes in the data being sent. If you deal with an xml message, you don’t really care what is happening in the extension points you provide. You’ll always be able to ignore the data not interesting to you, and access what you need. You’re more open.

3.      End up providing a bad message format, as you don’t design your xsd first. I agree that not everybody agrees on contract design first, but I strongly do, and believe that the architects around the world should unite to speak as one voice for schema design first. Why design first? Because you can then talk about the schema as being the contract of your service, and very early know what your service is doing, why, and how. And you let other people expand it.

I’m not saying asmx is the source of all things evil (although I’m tempted). I’m saying that to think about the object mapping feature of asmx as the way to go works only in simple cases no gateway no proxy no router no header processing no non-.net or no non-oolanguage cases. As soon as you try and move forward… It becomes so much more complex.

In his post, Steve Eichert talks about whether objects used in SOA may or may not contain behavior. I’m just reproducing the comment I was nearly going to make on his post:

It seems to me that this debate is absolutely wrong in the first place. You don't pass OBJECTS around in a SOA architecture, so questioning whether behavior must or must not be included is absolutely faulty. As a matter of fact, because objects are used on the inside boundary, you can use them or not, with behavior or not, and you can even use batch scripts to execute something on your message. That’s right, nothing prevents that.

If you do use objects on the back end to "map" your messages, then certainly you can include whatever you want in them. This is an implementation detail on the inside frontier of your SOA, it is not a valid architecture question.

But this doesn’t really answer any question. The fact is, are we tightly coupled inside the service? Yes, we use types, version binding, in a .net environment. Whatever we do, the inside boundary of the service is extremely tightly coupled compared to the outside. But as always, doesn’t mean you don’t have to be layered and as loosely coupled as possible in the inside.

Hey hey hey… just noticed that the new URL to your beloved blog got up again in the googlescore:

·         Sebastien gets me to position 8 (up)

·         Lambla gets me to position 1, 2 and 3 (up)

·         TheTechnologist in positions 2 to 7 (up)

·         Longhorn related topics slipped away, as I’m spending more time on SOA and geeky topics than on longhorn (not enough hours in a day!)

·         An exception for Longhorn + peer2peer where I have the first position with my previous googlejuice report (how to break google better than just blogging about a position in google!)

·         A special note with IIsapiRuntime in position 10, and AppDomainFactory in position 12…

Why is that relevant? Because most of the people getting on this blog come from google. Now on the frightening bits:

·         Veme Republique (fifth republic, the current French constitution) gets me into position 6… So does “Regime parlementaire”. Pretty frightening, as even though public law and constitutional law is a passion for me, I’m far from being an expert. But just to push the matter further, I’m going to post an entry again on the so called VIeme republique, the infamous project by some French political Trotskyites to go back to the previous parliamentary regimes. Should prove to be interesting!

·         “Marketing bullshit” where it seems I absolutely rule. Fair enough.

·         But nothing on my other mother country, Monaco, which I’m going to visit sometime in March. I have a piece to write about that too, but it will take more time.

You know the most frightening part? Just talking about the googlerank actually increases your googlerank. A pretty weird consequence of the current algorithm used on google!