What do people mean by document-oriented?

To me document-oriented is just a style that implies large-grained operations with human readable parameters (generally 1 big one each way), which ultimately points to #2 for me.

I don't personally care much about the lower-level programming model. I care more that the interfaces map to complete, meaningful business transactions (as opposed to managing intermediate business states). I presume document-oriented web services are the next EDI, so when I think document-oriented, I often think about schemas that will be published outside of organizational boundaries. Internal systems can be document-oriented, too, of course, but the relative ease of formally documenting web services and document schemas makes the document-oriented style particularly well suited to cross-organizational business transactions.

If you think about it, the RPC-ish style you described kind of defines it's own schema - the arguments that are allowed to be passed to the method. To me, document-oriented means not using this schema, but using a formally defined (in an XSD or XSD fragment in a WSDL document) one.

One of my favorite (not neccesarily most useful) classes in .NET is CallContext. It allows you to pass out-of-band information. I believe defining your web service interfaces using formal schemas allows for more flexibility in the same way.

Finally, if you are already working with XML anyway, why tease out discrete parameters just to make a method call. Working with XML is the defacto way to pass information around now.

To a large part, it's about the programming model - mapping XML to statically typed programming language defeats the purpose of using XML in the first place. Even worse is starting with the programming language interface and generating WS contracts from there.

In fact, though, these arguments really have not much to do with RPC, which is one of many different useful communication patterns; it's just that WS in their first real incarnation tried to hard to be as "easy" as CORBA, DCOM or RMI and only afterwards people noticed that this leads to lots of problems ...

I touched on this in my last post. The problem with use the XML DOM instead of typed data structures is that eventually that data that you are sending or receiving will have to end up into some sort of structure. This, assuming that you're not going to pass XML DOM structures to all your business logic components.

The question for those that advocate the document centric approach is, why duplicate this unpacking code in each client? Why not make it generic and map the XML to your classes?

I think this argument is different to the schema first versus generated WSDL debate. I think you can be schema first and not document-centric.

The easiest way to understand what document-oriented means is to visualize a system as if it was realized in the physical world as a process driven by paper forms. If your service processes something that corresponds to a completed form, then it is part of a document-oriented system. The closer your programming constructs are to the logical design of this sort of form, the more document-oriented your service is.

Tim,
It's interesting that 3 of your 4 suggested interpretations talk about the programming model when you're not on the wire.

1. You can choose to break the input/output messages and map their contents to individual method arguments, or make a method with one input message parameter and one output message parameter without changing what gets sent/received on the wire.
2. You can de/serialize your message parameters to a stream, xml, or a strong type without changing what gets sent/received on the wire.
3. You can map request/response pairs to method calls, or to different sending and recieving services without changing what gets sent/received on the wire.

Number 4 impacts what you have on the wire, but, I feel I can be message/document-oriented whether I use actions and reuse message definitions where appropriate, or whether I prefer to have a distinct message for everything...

I think being message-oriented has a lot to do with the way you look at the edges of your system in terms of the contracts you define, and the types of exchanges you employ.

If I were to say a system is message-oriented, I think I'd be saying that the conversations held at system boundaries involve the exchange of messages.

A message has been defined in a few different places: Enterprise Integrations patterns says it is "an atomic packet of data that can be transmitted on a channel."[1] Don Box et. al have defined it as "a complete unit of data available to be sent or received by services. It is a self-contained unit of information exchange..."[2] These are fine definitions, but I know they didn't help me a ton in thinking about "message-orientation" because I already thought of messages as kind of atomic in nature. I think the idea that helps me most is putting the messages in the context of conversations.

Request response is one type of conversation that is very useful and shouldn't be dismissed just because it is common. That said, when you think about other factors of "service orientation" like the impact of autonomy on the way you treat data, then I think several other conversation styles become useful... anyway. I think that's what message-oriented means... you are thinking first about the messages and the exchanges... programming model, while important, is something that is a separate piece of work.

[1]http://www.enterpriseintegrationpatterns.com/MessagingComponentsIntro.html
[2]http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnwebsrv/html/introwsa.asp

It means document-in, document-out; that I know I can submit a document to any service, and get a document back in return. This requires that all services expose a common operation. This is also where the loose coupling commonly associated with document orientation comes from.

Tim,

I recently had a post on my blog where I discuss some of the differences between the Microsoft and Java web frameworks.

http://developernotes.com/archive/2005/02/01/263.aspx

CAN YOU HELP MR IN DEFINE WHAT IS MEAN BY DOCUMENT ORIENTATION?

IS THE STYLE THAT IMPLIES A LARGE GAIN OPERATION

IS THE STYLE THAT IMPLIES A LARGE GAIN OPERATION

I'm WAY behind on my blog reading (and writing) ... so, in an attempt to recify that, I'm going back...

It is a way to create WS where you don't have to specify any method name or parametres, so the body of the message has a free schema. The opposite of the document-oriented is the RPC-oriented that must send a method name with a set of parametres and must receive the return value with some optional output parametres.