Article: Web Services are not Distributed Objects

Discussions

News: Article: Web Services are not Distributed Objects

  1. Web services are frequently described as the latest incarnation of distributed object technology. This misconception, perpetuated by people from both industry and academia, seriously limits broader acceptance of the true Web services architecture.

    This article may not have anything to do with .NET or Java per se but considering the hype Web Services has been getting, it makes a strong case in trying to get rid of certain myths surrounding specifically the fact that Web Services are somehow trying to be the Uber-Distributed Object technology.

    To my mind, getting rid of the myth that Web Services necessarily mean HTTP in some form or the other will probably go a long way in easing everyone's thinking of what the technology can possibily accomplish in the face of CORBA/DCOM/RMI.

    Here is a link to the article:

    http://weblogs.cs.cornell.edu/AllThingsDistributed/archives/000343.html

    Some popular myths the article tries to address with fairly solid explanations are:

    * Web Services Are Just Like Distributed Objects
    * Web Services Are RPC for the Internet
    * Web Services Need HTTP
    * Web Services Need Web Servers
    * Web Services Are Reliable Because They Use TCP
    * Debugging Web Services Is Impossible

    scoot over to the article for more...

    Threaded Messages (40)

  2. Web Services - wire protocol[ Go to top ]

    Almost every vendor and columnist has their definition of Web Services.

    Is web services a wire protocol like SOAP or XML-RPC?

    Or is Web Services a mode of transmitting business data - i.e. a la EDI or ebxml?

    Does it include directory services? Or are directories just an addition to web services?

    Are Web Services an incarnation of distributed computing? i.e. a la DCOM or CORBA

    A complained often heard is that computing does not have neatly defined genealogy as in Biology - but then where is the fun ;)

    Hari Mailvaganam
  3. Well, I don't know....[ Go to top ]

    Perhaps it's my messaging background showing, but I grokked Web Services as more of a Point to Point messaging wrapped around XML documents architecture, with some frosting on top (UDDL).
  4. Well, I don't know....[ Go to top ]

    "Web Services as more of a Point to Point messaging wrapped around XML documents architecture"


    You're not far off, to me it's just a way of wrapping what's worked fine for years in huge damn great big wrappers called XML so that if a human wants to read it (as you do) it reads like a newspaper, well the simple stuff does anyway. Just to leave room for future expansion they took out useful things like binary, security, serializable code etc. etc. that all comes in "WebServices II the Revenge!"

    Now Microsoft feels they can finally do something "useful" in the server world. By convincing gullible vendors like Sun and IBM that WebServices are important they can actually take part and at the same time slow the server side vendors down, it's a brilliant plan.

    I would object (no pun intended) to calling it "distributed objects". To me that implies that (a), you can dynamically distribute your object as in RMI e.g. JavaSpaces, and (b), it’s an object.

    The thing sitting at the end of an SOAP call is not really an object, you might have written it as such but by using WebServices it's lost most of its object features.

    WebServices is 95% hype and 5% useful, fortunately I work on the useful bit. :-)

    -John-
  5. More than technical quibbling[ Go to top ]

    The best quote I found in the article was this one:

    Distributed object technology is very mature and robust, especially if you restrict its usage to the environment for which it was designed: the corporate intranet, which is often characterized by platform homogeneity and predictable latencies. Web services’ strength is in Internet-style distributed computing, where interoperability and support for platform and network heterogeneity are essential.

    With all of the hype around web services right now, a lot of literature is making the following assertion:

    SOA == Web Services == Good For All

    which is just a hunk of nonsense. You can do SOA without Web Services, and there is a whole range of problem domains where SOA is not very helpful.

    Anyway, I think the article makes some good points in describing the intent of web services, their current state, and how they are different than other transports. So the real focus of Web Services is interoperability, which is currently a limited win given the state of web services standards, and there is no specific reason to want to use a web service unless interoperability is a technical requirement. I think that's the message of the article and I think there is some value in the statement.
  6. More than technical quibbling[ Go to top ]

    Dave,

    Maybe you can enlighten us by explaining what SOA means then?

    My take is that its as vacuous a statement at web services.

    So the right equation should read.

    SOA = Vacuous Technology = Web Services

    Carlos
  7. More than technical quibbling[ Go to top ]

    Maybe you can enlighten us by explaining what SOA means then? My take is that its as vacuous a statement at web services. So the right equation should read. SOA = Vacuous Technology = Web Services

    I often break up my systems into services, but they are not web services. The web services movement has unfortunately co-opted this term.

    SOA <> Web services
  8. More than technical quibbling[ Go to top ]

    Bill,

    Can you explain the difference between a "service" and an "object". Maybe more specifically a "service" and a "collection" of functions.

    Carlos
  9. More than technical quibbling[ Go to top ]

    Okay, I've got to admit this SOA (i.e. Service Oriented Arch.) and Web Services seems to be a lot of smoke and mirrors.

    SOA is just a new buzword for what they called Web Services however its equally vacuous. Web Services had its focus on Web, which would imply HTTP (isn't that what the Web runs on top of?). But let's be a bit lax with our definitions by saying Web implies a standard open transport mechanism.

    So that begat SOA, with particular emphasis on the word Services. So that brings up a new question. What in the world is a service? Is it just not a bunch of methods collected together? How is that a paradigm shift?

    Carlos
  10. More than technical quibbling[ Go to top ]

    Can you explain the difference between a "service" and an "object". Maybe more specifically a "service" and a "collection" of functions.

    A simple explanation is that a service is a chunk of functionality that your application provides. This chunk of functionality represents business logic encapsulated within a well-defined interface. So your application essentially becomes a loosely coupled collection of services (some of which can be reused in other applications). This provides a nice separation of concerns and localizes changes. Some services can even be reused between applications (like security and user management to name a couple). Services are often fronted with Session Facades (usually a session bean or a plain POJO).

    Does that make it clearer? SOA is actually a concept that has been around quite a while and is a very good way to design applications (especially enterprise systems containing multiple applications that share certain functionality). Web services are just one way to implement a service where interoperability is a concern.
  11. More than technical quibbling[ Go to top ]

    Can you explain the difference between a "service" and an "object". Maybe more specifically a "service" and a "collection" of functions.

    >
    > A simple explanation is that a service is a chunk of functionality that your application provides. This chunk of functionality represents business logic encapsulated within a well-defined interface. So your application essentially becomes a loosely coupled collection of services (some of which can be reused in other applications). This provides a nice separation of concerns and localizes changes. Some services can even be reused between applications (like security and user management to name a couple). Services are often fronted with Session Facades (usually a session bean or a plain POJO).
    >
    So why does the above statement sound like market-speak?

    What differentiates your definition from a distributed object interface? How does a chunk of functionality become "loosely coupled"? What do you mean by "well-defined" interface and how does that differ from an object interface? Point me to an example of a service that provides security or even user management in a loosely coupled manner.

    Carlos
  12. SOA vs OOP[ Go to top ]

    What is the difference between a Service and a Component / Object or other construct??

    Simple. A service is defined solely by an interface. At design time, an application built from services is a collection of interfaces sequenced together. A UI accesses the interfaces.

    Implementation may be defined at design time, but changed at deploy time. The service may be implemented on any platform and accessed through any protocol (http, smtp, native java, COM, jca, EJB, etc). This allows for hot-swapping of services, changes in topology, etc. Try doing that just with Java classes.

    Dave
  13. Hi all !
    We used to talk about component vs. objects... Now it's services vs. objects.
    Guess what ? components and services mean the same.

    It's because components meant COM components, and (web)services were designed to allow HTTP access to COM (or whatever the new name for COM) components...

    My understanding of the biggest differences:
    - objects have a reference (you can access THAT particular object, instance)
    - service access is through a factory (it's just as if you always get a new instance, even if pooling is used)
    - objects are distributed because they can reference other objects
    - services are orthogonal to each other: they cannot expose a reference to other services. They can use other services, but not publicly reference a particular instance of a service.
    - objects can model a factory too, of course... (activation frameworks of Corba or RMI)

    The confusion comes from the implementation of services using objects...

    So services are groups of procedures (with in and out params), while objects are usually many objects connected to each other (design-patterns goes here), each with a little behavior and state (encapsulated data), the whole forming a system.

    Objects and Services ARE very different.

    My 2 cts
    Chris
  14. So services are groups of procedures...

    Hey that's what a functor is.
  15. Chris,

    "So services are groups of procedures (with in and out params), while objects are usually many objects connected to each other (design-patterns goes here), each with a little behavior and state (encapsulated data), the whole forming a system. "

    That's more like it.

    Now maybe you want to add a little bit more constraints like asychronous channels and no implicit states.

    Carlos
  16. SOA vs OOP... components anyone ?[ Go to top ]

    Here's a definition of my own that I've whipped up:

    http://www.manageability.org/blog/stuff/what-is-a-web-service

    (1) Distributed
    (2) Introspective (Discoverable?)
    (3) No Implicit State Sharing
    (4) Asycnhronous
  17. SOA vs OOP... components anyone ?[ Go to top ]

    (5) Provides some benefit(or service)to an Actor
  18. Hi all,

    What about Tuxedo, CICS or Sybase Open Server... (I only used Open Server in the past).
    I think they were the first Service-based infrastructure available.
    But they did not use any standard (XML, SOAP, HTTP, name your favorite W3C standard)...

    They did provide Authentication, transaction support, were distributed, isolated from each other, etc...
    They lacked the marketing. OpenServer was just a technology to write stored procedures (*procedures*) in C. These were 0% BS, 100% functionality and performance.
    This contrasts sharply to new Service technologies, which are 80% BS, 20% functionality and 5% performance.

    I guess that's why I can't see the REVOLUTION of services... It's just an old (but easy to understand) technology revamped with W3C standards. Nothing new.
    We need it, as we needed it before.

    Just my opinion...
    Chris

    PS: HTML applications remind us the old days of terminal based applications... it's no surprise Web Services remind me of other old stuff :-)
  19. christophe,

    I guess the design philosophy of Web Services is to give you practically nothing in the hopes that you can't hang yourself with nothing.

    Kick ass technology gives just too much and has all these unknown dependencies that create stove pipe like applications. It's time to go back to the basics where nothing talks to each other except through self discovering messages.

    Everything else will be tagged on some time in the future when the committee finally figures it out!

    Carlos
  20. More than technical quibbling[ Go to top ]

    What differentiates your definition from a distributed object interface?

    There is no difference. The interface of a service is more coarse grained. A service typically encapsulates a number of business objects that are related in purpose. It's really nothing new - simply a common design pattern.
  21. service vs components/objects[ Go to top ]

    I got this from Novells docs.

    "The major difference between a service and a component is that the service is the unit of deployment. The service is the actual application that is invoked when the server receives a client request. Services are registered with the server, and may be published via a UDDI registry. Components reside within services, and perform units of work for the service."
  22. service vs components/objects[ Go to top ]

    "The major difference between a service and a component is that the service is the unit of deployment.

    Hey that's what a J2EE module is.
  23. service vs components/objects[ Go to top ]

    "The major difference between a service and a component is that the service is the unit of deployment.

    >
    > Hey that's what a J2EE module is.

    A component is a deployable and replaceable part of a system. A component can implement and provide many services.
  24. service vs components/objects[ Go to top ]

    No disrespect to Novell, which has a lot of smart people, but I don't like that definition at all. I don't think that "component" has a well-understood meaning in the context of web services. In the EJB world, component does have a well-defined meaning, usually taken to be a deployable unit, generally meaning a session facade and all of the objects/classes required to implement it. Many web service tools tend to relate a web service interface to a session facade, so it isn't clear that there would (or should) be multiple "components" per web service.
  25. Service vs. Object[ Go to top ]

    Objects are already well defined as encapsulated entity or state with related functionality. A service is essentially a Use Case.
  26. Service vs. Object[ Go to top ]

    A service is essentially a Use Case.

    Hey that's what a session facade is.
  27. Service vs. Object[ Go to top ]

    One might be better off saying that a service represents one or more coherent steps within a use case. In general, web services should be coarse-grained and should represent an entire use case, whereas a generic "service" might reasonably be implemented as a more fine-grained interface. I'm kind of splitting hairs.
  28. More than technical quibbling[ Go to top ]

    Bill,

    >
    > Can you explain the difference between a "service" and an "object". Maybe more specifically a "service" and a "collection" of functions.
    >
    > Carlos

    Here is my understanding of SOA:

    http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html

    Your comments are welcome.

    Hao
  29. General quibbling[ Go to top ]

    The author seems to think RPC and Web Services are somehow technically different, and it's just not so. I can exchange a document with RPC as a transport. And the marketplace has tools to turn RPCs (e.g. stateless session beans) into Web Services. If you use your imagination, you can always make one of the RPC parameters the key for finding an object (much like C++ passes the object reference as the first function argument under the covers) and you're object-oriented in some sense.

    >Maybe you can enlighten us by explaining what SOA means then?
    Well, since programming generation #1 was spaghetti code (or arbitrary message passing), generation 2 was structured procedures (or RPC request/response), and generation 3 was objects (CORBA/EJB), and Web Services doesn't offer all the 3G stuff because it's a stateless protocol, then "Service Oriented Architectures" must be 2nd or 2.5-generation, where the focus was function (RPC) or data (document) orientation but not both at the same time. Unless you look at XML over a message bus, which goes back more to spaghetti in terms of flow control ;-).

    I really only think Web Services does one good thing; it standardizes stuff that all platforms were already doing in similar ways (making function calls and serializing data), thereby making more integration possible and making the tools market stronger (admittedly at a high bloat cost, so I'm hoping Sun's FWS takes off). Getting the security/reliability/statefulness/transactionality/OO/GC features incorporated is a pain because platforms don't all do it in similar ways; so don't hold your breath. If you need reliability, try SOAP/RPC over a reliable & transacted JMS queue with a durable subscriber instead of TCP/HTTP, or just make your SOAP/HTTP idempotent. If you need security, turn on HTTPS and make accounts. If you need objects, make the object reference a parameter.

    So going back to "Peter's" statement, WS will be (and already has been) a flop in the ways of previous wide-area DC systems; rampant interoperability requires standardization at all layers, especially the application layer which is the hardest. So don't hold your breath for public web services making the Internet self-aware anytime soon. But hopefully some enterprises will get more of their systems talking to each other at lower cost to them.

    Cheers
    ~Chuck
  30. More than technical quibbling[ Go to top ]

    Dave,

    >
    > Maybe you can enlighten us by explaining what SOA means then?
    >
    > My take is that its as vacuous a statement at web services.

    I could point you to a place where you can read up about SOA and I'd probably be wasting my time. The last person in the world who'd be serious about wanting to know exactly what the hoopla is about a technology w/o ridiculing it would be you. But hey, what do I know... Here goes:

    http://staff.newtelligence.net/clemensv/PermaLink.aspx?guid=b379fb50-70b2-48b1-9d56-7cc5377022e5
    http://staff.newtelligence.net/clemensv/PermaLink.aspx?guid=6868ac5d-16cc-4863-bde4-11f663691c76
    http://staff.newtelligence.net/clemensv/PermaLink.aspx?guid=278c5ee8-2dcb-4010-ac8c-9e54dcd05b61

    --Dilip
  31. More than technical quibbling[ Go to top ]

    Dilip,

    Sometimes it's helpful to play "devil's advocate".

    The prevailing problem is that the industry is really making this up as we go along. We just tag alone cool sounding terms like "web services" and SOA, however we don't really know what it is, we just know what it'g going to achieve. That is , SOA is going to cure cancer, but we just don't know exactly how its going to do this!

    However, when it it happens to do it, we'll just tell everyone that we knew it all along! Folks, let's just admit it, it's all one big scam. SOA is now the big buzword that will achieve frictionless integration across the enterprise and the world.

    Interesting, though the analysts are in disagreement, Gartner believes SOA isn't the way to go and is now promoting something called ESB (Enterprise Service Bus)!

    Carlos
  32. It seems kinda pointless to discuss what a web service is, and what it is not. As far as I know, there is no formal specification that even defines what a web service is.

    This article is a lot of hair splitting.
  33. The article's last sentence states:

    "Web services are about interoperable document-centric computing, not distributed objects".

    Okay, that's a good start. But is this all, or are we all just making it up as we go?

    Carlos
  34. The article's last sentence states: "Web services are about interoperable document-centric computing, not distributed objects".

    JAX-RPC isn't necessarily document centric, but it is web service. The two things that distinguish web service are firewall and XML. Any application that pushes XML through anonymous firewalls is a web service.
  35. Brian,

    Well then, I guess your definition differs from the authors definition.

    Is JAX-RPC compliant with WS-I Basic Profile? If not, then maybe it isn't a web service as defined by the standards body.

    However, who gave the other the mandate to define what webservices meant?

    Carlos
  36. Is JAX-RPC compliant with WS-I Basic Profile? If not, then maybe it isn't a web service as defined by the standards body.

    I like your point, since at least it provides a razor for precisely determining what is or isn't a web service. Of course some JAX-RPC styles are WS-I compliant, and at least one JAX-RPC style isn't. I naively wonder if JXTA is WS-I compliant?
  37. I naively wonder if JXTA is WS-I compliant?


    I seriously doubt it.

    Carlos
  38. If the essence of web services is transporting XML documents, why require the documents to be XML formatted?
    Therefore transporting a document of any type using any type of mechanism is a web service.
    So back when I used to sneaker-net Word documents on floppy disk - I was part of a prototypical web service.
    If I download an XHTML web page (document) to my browser am I consuming a web service?
    Ok - kidding aside - XML provides a excellant way to format and add context to information. How clients care to consume this information is up to the client. The amount of implementation specific information embedded in XML is something to consider but probably would cut down on interop. I have thought about providing Python classes along with the formatted data. The consumer could use the provided Python classes to contain and operate on the data.
    I guess I hate to hear what 'web services are NOT'. This sounds like trying to determine when we can legally call our apps 'web services'.
    Lets think about what web services can be.
  39. Mike,

    I think that's where Vogel's in complete delusion. I mean who really cares what kind of XML document format is going under the wire, the point is to deliver easy interoperability.

    What that means is there's some concrete definition that you can discover that allows the automagic generation of a stub that takes into account all the details of interoperability. So I got this EDI message that's shipped via FTP, I should be able to discover that and be able to build a stub that handles all the low level plumbing. So think CPA in ebXML or maybe even WSDL.

    Of course, nobody has yet figured out automagic semantic interoperability, that of course is in the same league of Star Trek's universal translator. But let's ignore that little detail for a moment and consider what's close to reality.

    Carlos
  40. I have a basic question. WS is going to thrive or not? I am currently looking into new projects based on WS. Can any experienced WS developers give out opinions about the future of WS based on experiences??
  41. I have a basic question. WS is going to thrive or not? I am currently looking into new projects based on WS. Can any experienced WS developers give out opinions about the future of WS based on experiences??


    Yes, yes and yes.

    We have implemented a number of WS projects all with success. However, you get to stay yourself away with RPC and stick with the whole concept of "loose coupling".

    Hao