Web services and objects revisited

Jim Whitescarver replied to a very old post I made  while ranting about distributed software, SOA, and object-oriented development. I wanted to post this directly instead of letting it disappear in the background that are blog comments.

 

Let me preface this by saying that I think we're talking about different aspects of the same problem and that we're probably more in agreement than not. The primary point I was trying to make in my post was that people shouldn't write consumer applications that assume a web service has a stateful, connected, transaction-supporting, object-oriented interface. On the flip side, service authors shouldn't write services that are stateful, connected, transaction-supporting, etc.

 

Granted, exposing existing objects or object-oriented systems using a service-oriented pattern is one of the great things about SO architectures. The model provides for cross-platform and interoperable access to existing applications. This is goodness.

 

Indeed, it is clear that most people that design web services seem to have no interest in exposing objects at all.  But does that mean using web services to expose objects is a bad thing?  I don't think so.

 

The point is that there are two distinct applications of web services in the enterprise.  Exposing services, and exposing objects.  Exposing objects rather than services is often a good idea.   Exposing a public interface to an object as a web service is an easy to employ feature of many web service tools.  The web service is then simply a technology neutral RMI where the XML is just a serialization of the invocation and response which may be totally transparent to the programmer.

 

This usage can be valuable in providing real object access across heterogeneous systems and between implementation languages.

 

If you can really avoid independent object environments that require some coordination then perhaps EJBs alone will work.  You may never need to access a your EJBs from Perl, VB, over the Internet or other environment.  Web services is certainly not the most efficient way to communicate.

 

In distributed applications involving a mix of VB, Perl, PHP, JavaScript, Java, C++, Python and Ruby, I advocate web services for all remote object access making the implementation language and enterprise environment of the objects completely transparent.  If all our objects are homogeneous we won't need this functionality.

 

I do get your point, and agree.  I just wanted to point out how web services can be used to make systems more object oriented and give ubiquitous access to real world objects rather than each environment having its own unsynchronized independent representation of common objects.

 

I do not mean to be contrary here, but I do like to consider both sides of these sort of issues deeply.  We should not overlook this mechanism if it can simplify the integration of our systems.

 

 Agreed Jim, and thanks for the comments.