Radovan has written an interesting piece entitled Flying Data and Business Process, which reminded me of some thoughts I had a while ago.

If you look at some of the stuff written about Web services, or XML in general, you might get the feeling that there is a huge conflict between different views on how to architect systems “the right way”. I don’t believe that this is necessarily the case; I’ll try to elaborate a bit.

If you follow accepted design patterns in an object-oriented approach, you are likely to hide a lot of detail between interfaces. Objects are responsible for doing something; what private data they use remains hidden to the outside user.

A component-based approach enhances this idea by creating components as larger entities (in the broadest sense of the term) that hide a lot of both operations and data behind a few, coarse-grained methods. It’s a pretty well-accepted fact that this coarse-grained aspect is a critical factor for achieving useful component abstractions; this is enhanced enormously once you are talking about components that can be invoked remotely, as the cost of operation invocation becomes ridiculously high.

What, then, is a service? Does it have the same granularity as a component, as approaches that simply turn J2EE session beans into SOAP-accessible service implementations seem to suggest? I don’t think that this is the right way, and I seem to be not alone with this view. The emphasis on data in more advanced service approaches shows that for one, the granularity is even higher, and additionally, that the data becomes much more important than a set of operations.

Should we thus abandon OO and CBD approaches? Is the answer to expose all of our data in the form of XML documents?

Unsurprisingly, I don’t think so.

Just as once you are talking about components, it becomes irrelevant whether you have implemented your component with a procedural or object-oriented language, a service consumer couldn’t care less about that type of component or app server or runtime environment you used to implement your service. But still, this doesn’t mean that you should simply expose all of your implementation data, since this is going the tightest coupling one can imagine — a coupling between a client and the utmost implementation detail: the persistence schema.

So what am I getting at?

My view is that while the by now classic approach of hiding information and exposing only the absolute minimum still holds true for the most of the data, you should treat the data used for interaction in a loosely-coupled scenario differently. Objects are an excellent implementation technique. Components, especially those deployed in an advanced infrastructure, such as a J2EE application server, greatly enhance your productivity by freeing you of tedious middleware-related tasks. But neither are in any way appropriate for communication across company boundaries, and this is the place where you should aim for very few, document-oriented service interfaces.