Aracılığıyla paylaş

Web services aren’t distributed objects

  • Makale

Why do we continue to try forcing a distributed object model into the world of web services? Nowhere in the name is there any hint that web service architecture has anything to do with distributed objects. Nowhere is there an implication that there are even objects involved in web service architecture. Sure, underneath the covers, in the private service implementation there are certain to be some kind of objects, if the service was written any time in the last decade or so.

But objects on the outside? Where did that notion ever come into play? Werner Vogel did a great piece [1] back in December 2003 that tried to dispel some of the myths that keep creeping in. I keep reading that article, and talking to developers around MBS, to see why web services keep getting lumped in with distributed object architectures. The only reason I can come up with is that the development community has had OO on the collective brain for quite a while and anything that looks like it might fit into the CORBA, DCOM, or RMI mold is dismissed as another distributed OO attempt. Web services will never take off until we start thinking in terms of services.

It’s really hard to do that though. Objects have all those nice characteristics that are pounded into our heads in school: data abstraction, information hiding, loose-coupling, separation of code from data… Wait a minute here. Aren’t those all things that web services provide too? Maybe that’s the reason we keep getting wrapped around the axle when we try to build new systems in a web services world. We want all that goodness, and the thing we’re taught to use is OO, so it must be the case that OO and web services are equivalent architectures. What can we do about it though?

Well, one of the key tenets of OO is that we should only ever deal with an object via its public interface. That means we shouldn’t worry about what’s inside the object, and we probably never should be shown what’s inside the object. That’s all good. What if we just change all occurrences of “object” in the preceding sentence with “service”? Close, but no cigar. Why? Because there’s a programming model difference between objects and services. When I create a solution using OO techniques I get to assume that I can create an object instance and hang on to it for as long as I want. I might even decide to pass it to another object instance for consumption. As the developer I probably get to hold on to precious resources, even though I don’t know that I’m doing it, because I get to control the object lifetime.

Hmm. That doesn’t sound right. What if one of those precious resources is a row in a table somewhere? (I know, it’s pretty hard to hold on to a row, but it’s not too hard to create a database transaction that holds a row.) Maybe the issue is that there are two levels of processing involved. Maybe the Smalltalk guys had the terminology right. Maybe what we send to an object is a message. That sounds right. Now, if we replace “object” with “service” we get to send messages to services. We don’t get to hold on to the “object” because it’s not there any more, it’s been replaced by a service.

Ok, so this is a lot of rambling. Is there a point? Sort of. The point is that we need to change the way we think about the programming model when we talk about building distributed systems using web services. We don’t get to control object lifetimes, we don’t get to hold on to precious resources, we don’t get to control transactions across multiple services. Instead, we get to ask a service to go do something for us and we let the infrastructure handle the how.

What’s the tie-in to CRM? Only that there are no distributed objects in the product. It’s all web services, and the “objects” are simply data structures that barely pass for documents. Why all that XML in the first two releases? Well, that was the technology available to us when we started and that technology solved the problem of getting programmers away from thinking that they needed to create objects and call methods.

[1] https://weblogs.cs.cornell.edu/AllThingsDistributed/archives/000343.html

Comments

  • Anonymous
    December 01, 2004
    Great post -- I need to pass it around. I get questions frequently about how my O/R Mapper plays with web services, and yet the two topics are quite orthogonal -- although apparently .NET makes it so easy to create web services that many fail to see that there is a fundamental difference.
  • Anonymous
    December 05, 2004
    >>Nowhere is there an implication that there are even objects involved in web service architecture.

    I don't agree with the statement. You are forgetting that the original acronym SOAP stood for Simple Object Access Protocol. Although they changed it in 2001 (or some date like that?). But it was marketed as the simple object access protocol for a long time.

    Also....Even CRM is using the deprecated RPC-Encoded method. RPC stands for Remote Procedure Call.

    So sure......this was all not well thought out, so thus we are having problems changing peoples mindset.
  • Anonymous
    December 06, 2004
    The comment has been removed
  • Anonymous
    December 07, 2004
    SOA and Web Services are just glorified, horribly complicated screen scraping.
  • Anonymous
    December 11, 2004
    i made an object classes reference , runtime error appears that it says, error generating xml document , plz help
    reply to fzeineh@yahoo.com
  • Anonymous
    May 18, 2006
    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 perhgaps 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 unsyncronized 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.  


    Thank you for listening  :-)  
  • Anonymous
    May 19, 2006
    Jim Whitescarver replied to a very old post I made  while ranting about distributed software, SOA,...