Can someone explain to me the semantic difference between passing messages in a Service Oriented architecture versus the traditional OO method of passing objects? What's the difference here? I know we're talking about very loosely-coupled method signatures, but what exactly might that look like? A single method that takes in an xml document and returns an xml document? "Flattened" methods where the arguments are primitives (strings, ints, etc)? I noticed that Indigo allows one to define "DataContract" objects which can be passed...

Anyone with experience in this area care to comment?

Jeff...

Message: - command + additional information for the command, in one message.

object: - data + behavior on the data.

When you pass an object over a wire, you actually only pass the data ! . So you pass less than an actual message.

Otis wrote:

Message: - command + additional information for the command, in one message.

object: - data + behavior on the data.

When you pass an object over a wire, you actually only pass the data ! . So you pass less than an actual message.

So, traditionally, then (at least in SO), the message is a single XML document? Is the XML document "typed"? Meaning, does the receiving method expect an XML document that conforms to a specific spec, or is there a single method for all calls that just receives any XML document and returns the appropriate XML document in return?

//message must conform to foo
public XMLDocument PlaceOrder(XMLDocument message)

//message must conform to bar
public XMLDocument UpdateOrder(XMLDocument message)

OR

public XMLDocument PassMessage(XMLDocument message)

Obviously, I'm not an XML guru, but I'm curious about the "agreed upon" method of passing messages.

Jeff...

In properly designed systems, the message has a fixed format. Like EDI uses So you can have more than one message type, but each type is defined with fixed fields and meanings.