These are the old pages from the weblog as they were published at Cornell. Visit www.allthingsdistributed.com for up-to-date entries.

August 26, 2003

Web Services are NOT Distributed Objects

I wrote an article for IEEE Internet Computing about how there are still many misconceptions about the fundamentals of web services, titled 'Web Services are NOT Distributed Objects: Common Misconceptions about Service Oriented Architectures'. It deals with the confusion about web services and distributed objects, with web-services & RPC, that there are more than just HTTP bindings, the relation between web services and web servers, (un)reliable web services and about why debugging web services is hard but not impossible

The article is still in 'draft mode', but should be relatively stable. I would very much appreciate feedback and comments, but keep in mind that the audience of the article is the general IT professional, not the web service specialist.





UPDATE!!

The text below was the first draft of this article. Many comments improved the article before it was published.

The full and final text of this article is now available from this page.

I am leaving the draft article online at this page to show the evolution of the article.





Web Services are not Distributed Objects: Common Misconceptions about Service Oriented Architectures

Werner Vogels
Dept. of Computer Science, Cornell University
vogels@cs.cornell.edu

Web services are frequently described as the new incarnation of distributed object technology. This is a serious misconception, made by people from industry and academia alike, and this misconception seriously limits a broader acceptance of the true web services architecture. Even though the architects of distributed systems and internet systems alike have been vocal about the fact that these technologies hardly have any relationship, it appears to be difficult to dispel the myth that they are tied together. In this article I revisit the differences between web services and distributed objects in an attempt to make it clear that web services are an internet-style distributed systems technology that does not rely on, or require, any form of distributed object technology.

Unfortunately, the mix-up about web services and distributed object systems is not the only misconception that is commonly heard. There are at least a dozen other popular statements about web services that are partially incorrect or just plain wrong. This article also contains clarifications of a number of these common misconceptions about web services.

Misconceptions

When I visited the WWW 2003 Conference Peter M. asked me

Dont you think that web services will fail, just like all the other distributed object technologies people have tried to build?

Peter is a smart and gifted Internet architect, but this statement baffled me. How is it possible that someone like Peter still views web services as distributed object technology? Peter is not alone in his stubbornness in continuing to address web services as distributed objects. Many developers, architects, managers and academics still see web services as the next episode in the continued saga of distributed object technologies such as CORBA, DCOM and RMI. Web services and distributed objects systems are both distributed systems technologies, but that is where the common ground ends. They have no real relation to each other, except maybe for the fact that web services are now sometimes deployed in areas where in the past the application of distributed objects has failed. If we look for relationships within the distributed technology world it is probably more appropriate to associate web services with messaging technologies, as they share a common architectural view, but address different types of applications.

Web services are based on XML documents and document exchange, and as such one could call the technological underpinning of web services document-oriented computing. Exchanging documents is a very different concept from requesting the instantiation of an object, requesting the invocation of a method on the specific object instance, receiving the result of that invocation back in a response, and after a number of these exchanges, releasing the object instance.

This misconception does not stand by itself; there are about a dozen similar statements that I frequently encounter that fall more or less in the same category. Popular ones are: Web services is just RPC for the Internet, or You need HTTP to make web services work. Below I will try to address a number of the more popular misconceptions. First, however, I will try to establish what actually a web service is in its purest, minimalist form. I believe much of the confusion comes from press and vendor hype, which lacks the technical depth needed to make people understand the real concepts. Of course, the political bickering among standards bodies such as WC3, OASIS, and WS-I doesnt help to clarify the simple, interoperable nature of web services.

Minimal web services defined

To realize why most of these issues are misconceptions, it is necessary to cut through all of the hype we have seen in the press and from vendors. If we bring back web services to a minimalist core there are three components that make up a web service:

  • The Service. This is a software component that is capable of processing an XML document it has received through some combination of transport and application protocols. How this software component is constructed, whether object-oriented techniques have been used, if it operates as a stand-alone process, is part of a web or application server, or is merely a thin layered front-end for a massive enterprise application is not of any importance. The only requirement for a Service Process is that it is capable of processing certain well-defined XML documents.
  • The Document. The XML document that is sent to a service to be processed is the keystone of a web service, as it contains all the application-specific information. The documents a web service can process are described using an XML schema, and two processes that are engaged in a web services conversation need to have access to the same description to make sure that the documents that are exchanged can be validated and interpreted. This information is commonly described using the Web Services Description Language (WSDL).
  • The Address. Also called a port-reference, this is a protocol binding combined with a network address that can be used to access the service. This reference basically identifies where the service can be found when a particular protocol (e.g. TCP or HTTP) is used

In principle this should be enough to build a web service, but in practice at least one more component is added to it:

  • The Envelope. This is a message encapsulation protocol that ensures that the XML document to be processed is clearly separated from other information the two communicating processes may want to exchange. This allows, for example, routing and security information to be added to the message without the need to modify the XML document. The protocol that is used for almost all web services is SOAP, which originally stood for Simple Object Access Protocol. This naming was a mistake as the protocol has nothing to do with accessing objects, and since the SOAP 1.2 specification [6] the protocol name is now used without expanding the acronym. The SOAP message itself, also called the soap-envelope, is XML and consists of two possible elements: a soap-header, in which all the system information is kept, and a soap-body, which contains the XML document that is to be processed by the web service.

These 4 components are all that it takes to use a web service. Whether you use your text editor to construct a SOAP message to send in an email, or use an automatically generated proxy-client from within your favorite programming language, this is all that is needed to make it work.

The document-oriented distributed computing world of web services is all about the design of the documents you want to exchange. Protocols and addresses are necessary only as glue to get the documents to the right places. Although web services are centered around documents, this does not mean these documents are targeted to be read by humans. The goal of web services is to enable machine-to-machine communication at the same scale and using the same style of protocols as human interface centered World Wide Web.

Not a misconception: web services are really simple.

At its core, web services technology is really simple; the only thing it does is use standard Internet protocols to move XML documents between service processes. This simplicity guarantees that its primary goal of interoperability can be achieved.

The simplicity also means that many of the more complex distributed applications cannot be easily built without adding other technologies to the basic web services. Over time we will see that the issues the vendors are now bickering about, such as reliability, transactions and asynchronous processing, will become reality in an interoperable manner. The process around security extensions, for example, gives us reasonable hope that vendors are capable of reaching agreement on a set of interoperable primitives.

On the other hand the process around reliable messaging has many of the distributed system specialists scared to death. In an attempt to preempt the release of the reliable messaging specification by IBM, Microsoft, BEA, and Tibco [3], a consortium lead by Sun Microsystems and Oracle published a reliable messaging specification [2] that was little more than a cut-and-paste effort from the reliability section of ebXML. This was clearly a specification that was released too early under vendor-political pressure, as the specification was ambiguous in many places, incomplete in others, and riddled with errors throughout the document. Any company implementing this specification would end up with a very unreliable system, and as such this specification is a disservice to the community. If there is one threat to web services succeeding at large scale, it will be vendor politics.

As I described in the previous section, document-oriented computing centers around the design of the document, the rest of the web service glue is just support technology to get the document to the right place in the right manner. In contrast with the simplicity of the basic web service technology, the documents can be extremely rich and complex. For example, a web services system I have worked on for the US Air Force publishes flight plans that can easily be up to a megabyte in size. Encoding these rich documents in XML ensures that the documents are extensible at predefined places without breaking any of the existing document consumers.

Misconception #1: Web services are just like distributed objects

Given the strong similarities between web services and distributed objects, it is understandable why the misconception exists that they are the same thing. After all, both have some sort of description language, both have well-defined network interactions, and both have a similar mechanism for registering and discovering available components. What contributes to the misconception that these are similar technologies is that many tool vendors provide simple object-oriented techniques for implementing web services, which give them the appearance of distributed objects. A number of these vendors have a long history in selling distributed object technology and as such have a strong interest in molding web services such that they appear to be a next step in the evolution of distributed object systems.

A first thing to realize however is that the current state of web services technology is very limited compared to distributed object systems. The latter is a well-established technology with very broad support, strong reliability guarantees, and many, many support tools and technologies. For example, web services toolkit vendors have only just started to look at the reliability and transactional guarantees that distributed object systems have supported for years.

An important aspect at the core of distributed object technology is the notion of the object life cycle: objects are instantiated by a factory upon request, a number of operations are performed on the object instance, and sometime later the instance will be released or garbage collected. A special case is the singleton object, which does not go through the instantiate/release cycle. But in both cases the object is identified through a reference, and this reference can be passed around between processes to provide a unique mechanism to access the object. Objects frequently contain references to other objects, and distributed object technology comes with extensive reference management techniques to support correct object lifetime management.

This notion of object reference is essential; without it there is no distributed object system. It is also important to realize that with this reference the caller has a mechanism to return to the same object over and over again and as such access the same state. Distributed objects systems enable state-full distributed computing. The state of the object is access through a well-defined interface that is described typically in an interface definition language (IDL).

Web services have none of the characteristics of distributed object systems. There is no notion of an object, object reference, factories or life cycle. There is no notion of an interface with methods, data structure serialization or reference garbage collection. The only technology web services have is XML documents and document encapsulation.

With a bit of a stretch, one could force an analogy between a web service and a singleton object. However, such a singleton object would need to be very restrictive to make the comparison work. At the basic level web services cannot offer any of the state-full distributed computing facilities that distributed objects systems support as basic functionality.

The difference between the two technologies is also obvious when we look at how information flows between client and server or producer and consumer. In the distributed object system the richness of the information flow is encapsulated in the interfaces an object supports, but in a web services system, the richness of the information flow comes from the design of the XML documents that are passed around.

Another important difference between these two technologies is in the style of distributed computing that they enable. Distributed object systems enable what is often called statefull computing; the remote object on the server can contain data and state that the client can operate on during the lifetime of the object. If a reference to an object is handed to different application, that process will encounter the same state when accessing the referenced object. Web services however have no notion of state, and they fall into the category of distributed system techniques that enable stateless computing. In web services the state of the interaction is contained within the documents that are exchanged. Whether a service is ever able to be truly stateless is disputable; if a web service document includes a customer identification number, which the service then uses to retrieve customer information (state) from a database, does this still constitutes stateless-ness? Identifying stateless versus stateful distributed components should be seen as a way of categorizing technologies, more than strict architectural guidance. In the context of this categorization distributed objects and web services are in opposite camps.

At the basic level web services have no notion of a relationship between two service invocations at the same service or at related services. The distributed systems that can be built without identifying relationships between components in a computation are very limited and as such one of the first advanced web service specifications that was released dealt with Coordination [1]. This enables multiple services and their consumers to establish a context for their interaction. It is a misconception to see this context as a weak form of object references, as it references an ongoing conversation and does not reference any state at the services.

Distributed object technology is very mature and robust, especially if you restrict its usage to those environments which it has been designed for: the corporate intranet with often homogenous platforms and predictable latencies. The strength of web services is in the internet-style distributed computing, where interoperability and support for heterogeneity in terms of platforms and networks are essential. Over time web services will need to incorporate some of the basic distributed systems technologies that also underpin distributed object systems, such as guaranteed, in-order, exactly-once message delivery. It is unlikely however that web services can simply adapt the technology used in the distributed object systems to achieve the same properties.

There are two known approaches in which web services and distributed object technologies can work together. First, there is the approach of wrapping certain objects from an object system, such as J2EE, with a web service. This has of course its limitations and cannot be done for just any object. See Steve Vinoskis article on interaction models [5] to learn more about this approach. A second approach that can be observed is to use web service protocols such as SOAP as the transport layer for the distributed object system. This is sometimes used to tunnel object specific interactions over HTTP. It is however a poor mans choice as alternative solutions such as GIOP are better suited for that interaction pattern.

Misconception #2 Web services is RPC for the Internet

RPC provides a network abstraction for the remote execution of procedure calls in a programming language. It provides mechanisms for identifying a remote procedure, for deciding which arguments to the procedure are in arguments and as such need to be provide to the remote procedure at invocation time, and which arguments are out arguments and need to be presented to the caller at completion time. It also includes extensive mechanisms for handling errors both at the runtime and the programming level.

Web services in their basic form provide only a networking abstraction for the transfer of XML documents, and the processing of these documents by a remote service entity. Web services have a notion of actor or role that identifies the service that should consume the document, but there are no predefined semantics associated with the content of the XML document sent to the service.

An RPC-style interaction could be implemented using pairs of SOAP messages and a transport such as HTTP. One would use certain fixed rules for encoding the arguments in an XML document and rules for returning the results to the caller.

The original web service architects assumed that this would be a popular form of using web services and even included a specific encoding in the SOAP specification called RPC/encoded to help with the encoding of data types. However in the SOAP 1.2 specification this encoding has become optional and tool builders are no longer required to implement it, and preference is given to the document/literal encoding.

Even though we like to look at web services as just XML document processors, this doesnt help the developers that need to build web services and web service clients. Tool vendors will do their best to provide infrastructure that allow traditional procedure calls to be applied to simple web services. For example Microsofts Web Service Enhancements 2.0 toolkit provides a set of object types that can be used to implement a request/response style interaction, where the programming infrastructure tries to interpret the document for the programmer. The toolkit also provides the programmer with a similar set of types that provides the programmer with simple but powerful support to receive the raw XML documents.

Internet-wide RPC has failed to succeed in the past, and web services are not going to be of much help in solving the issues surrounding wide-area RPC. There is no magic in the web services infrastructure that can suddenly overcome what excellent protocol architects were not able to achieve with DCE/RPC or GIOP. Even though web services may solve some of the interoperability issues, it does not solve for example the issue that synchronous interaction over wide-area is not scalable or that versioning procedure interface at large scale is extremely difficult.

Misconception #3: Web Services need HTTP

Web services are transport-agnostic, meaning that they can be accessed over any type of transport or application protocol. The SOAP protocol, which describes the web service message format, can be used such that messages are transported over HTTP, but can also be used such that messages go over plain TCP and UDP. There are bindings where the messages flow over SMTP by encapsulating SOAP message in an e-mail message, or over a traditional messaging infrastructure such as MQ-Series or JMS. A core scenario of the web services architecture is the case where a message flows over different transport types before it reaches its destination.

For example a SOAP request is delivered to an enterprise gateway using HTTP. The gateway then uses a load balancing mechanism to pick one of nodes of a server farm to process this request and uses a persistent TCP connection to forward the incoming document. In another case a purchase order encapsulated in a SOAP message is delivered using an e-mail message addressed to order-processing@cheapcomputers.com over an SMTP transport. The receiving server will take the soap content and encapsulate it in a JMS message and insert it into the order processing workflow system, which might be based on traditional message queuing. The service that actually consumes the SOAP requests may not be determined until the message has visited a few intermediate processors that determine whether this is a request that is entitled to gold priority treatment and some auditing has taken place. Eventually the requesting process (remember web services are intended for computer-to-computer conversations, no humans involved), will receive an email message with a confirmation or rejection of the order.

Even though the web service architecture has been developed with this transport independence in mind, it is true that the majority of the web services that are in use at this moment run over HTTP. One of the reasons for this is that most of the early web services toolkits made use of the existing infrastructure that the major web servers Apache, IBM WebSphere and Microsoft IIS offered. Leaving the parsing of requests and dispatching of messages to the web server, it was possible to abstract all of the grind of web services away using web-server add-ons such as Axis or ASP.NET. These extensions will automatically generate the WSDL for the web service and provide an simple service exercise tools, making it a great environment for prototyping and learning web services.

A second reason for the popularity of implementing web services using HTTP is more strategic. In contrast to the period of the dot.com boom, most enterprise software projects currently require a short-term return on investment. This forces most of the production web service projects to focus on improving the access to the corporate data and services for partners and customers, without requiring too much new infrastructure. The first place this is possible is by using the web servers that are already functioning as front ends to J2EE infrastructure. This approach has become rather successful and should be seen as the first step in the path to a deeper integration of web services in the enterprise.

There are people suggesting that the main reason for tunneling web service messages through HTTP is to bypass firewalls. If this would indeed be the reason than it would be a dangerous approach that would seriously weaken a sites security, and one should only do this in combination with extensive content-based filtering techniques of the HTTP flows.

Misconception #4: Web services need web servers

There has been some discussion that maybe we should actually drop the web from web services, as it leads to more confusion and does not contribute to clear view of the world. This is already becoming obvious in such terms as service-oriented architectures, service-oriented integration, or services bus. None of these enterprise concepts use the term web, as they are not relying on any web technologies such as HTTP, or web servers.

There are quite a few toolkits that allow you to develop and integrate web services without the need for a web server infrastructure. Examples are Simon Fells PocketSoap, Systinets WASP, IBMs Emerging Technologies Toolkit and Microsofts WSE. Enterprise integration systems such as Artix and DocSOAP, also provide web-server independent web service development.

As explained in the previous section, there has been an initial set of web services that have exploited the application-server functionality of web servers. But now that the initial business case has been made, and wider choice of transports is required, most systems will move away from implementation inside web servers.

In the past months a high-profile debate has taken place about applying the principles of REST to web services architectures. REST encompasses some of the techniques that make web infrastructures scalable. There is a lot of value in this debate about the web principles, and particularly with respect to resource identification and operation visibility, but it is becoming quickly irrelevant for the bigger picture of web services, given that transport independence is surpasing the importance of the web part of web services. The REST principles are relevant for the HTTP binding, and for the web server parsing of resource names, but are useless in the context of TCP or message queue bindings where the HTTP verbs do not apply.

Misconception #5: Web services are reliable because they use TCP

TCP is a protocol that guarantees reliable, in-order delivery of messages, so it would appear that web services, if they make use of TCP, can achieve the same guarantees. First of all the guarantee of reliability is only partially true for TCP programming, as there a few scenarios under which a message cannot be completely delivered to the remote peer, and the local participant has already closed the connection and will not be notified of this error.

What is more important to realize is that document and message routing for web services provides for the use of intermediaries. In the presence of network, node, and component failures there are quite a few scenarios possible under which the initial delivery of the document to the first station was successful, but where the document will never reach its final destination and thus never gets processed by the service.

The type of reliability that is important for web services and distributed systems in general is that of end-to-end reliability. There are a lot of established techniques in achieving this type of reliability and we will see in the coming year whether they can also be simply applied to web services or whether new technology is needed. In general reliability is achieved through the retransmission of messages, but these retransmissions also require you to weed out duplicate messages in case the message was not really lost. Estimating timeouts, etc. in a heterogeneous network such as the internet is not trivial.

Frequently when you build reliable distributed systems you would like to let some information flow back about the state of the service request processing, such that the producer of the document can take local actions. Giving feedback about the arrival of the document, about the consumption of the document by the service, and the completion of the processing of the request makes building these systems easier.

In addition to reliability we would also like to make sure that if the producers care about it, their messages will be consumed by the service in the order they were sent. This put more stress on the reliability system, because if messages get lost other messages may need to be delayed until the lost message is retransmitted.

None of these guarantees are new; they have been around for years and have been made to work in all sorts of distributed systems, such as distributed objects systems and multi-party fault-tolerant systems. Web services will need these technologies also, but until theyre added web services should be considered unreliable, whether they use TCP or not.

Misconceptions #6: Web services debugging is impossible

As web services enable the internet-scale type of distributed computing, where frequently the parties in the conversation will belong to different organizations, web service developers and those who have to deploy them are confronted with a whole new set of problems that cannot be handled with traditional debugging and monitoring tools. The federated nature of web services means that most of these new challenges are introduced by not 'owning' both ends of the wire. Two of the most prominent challenges facing users are cross-vendor interoperability and WSDL versioning.

Even though traditional tools are of little help with these problems, new web services diagnostic tools such as SOAPscope [4] are emerging to address the development and deployment challenges of web services. SOAPscope is unique in that it focuses on 'watching' the wire, logging the traffic and providing a suite of functionality to detect and resolve these federation-related and other potential problems.

The wide variety of web services toolkits being used to develop both web service clients and servers means that it is becoming more common that different toolkits operate at each end of a SOAP interaction. Each of these toolkits may have interpreted the specification somewhat differently leading to potential interoperability problems. When a client encounters an obscure error from a server, how does the developer diagnose the problem when they have no access to the code running at the server? The solution available to the developer is to focus the SOAP traffic on the wire and the WSDL contract between services.

Tools such as SOAPscope offer several capabilities to help understand and fix interoperability problems. SOAPscope has for example 'resend' and 'invoke' features allow testing 'what-if' scenarios against a server to isolate problem requests. The 'viewing' capabilities allow better understanding of the SOAP messages by visualizing the request at higher-levels of abstract than raw XML. And, to maximize interoperability, the WSDL Analysis detects and helps resolve potential interoperability problems prior to deploying a service.

Another challenge of Web services, which will become increasingly common, is caused by change and versioning of Web services. A small change to the XML Document specification in the WSDL contract at the server can easily break existing clients. Clients may not even be aware the document specification has changed or how to fix their client to accommodate the change. A Web service client may start to receive 'faults' from the server which indicate a problem but are seldom useful to resolving the issue. Tools such as SOAPscope can inspect the XML document specification in the current WSDL and compare those with the specification used to create the client.

These new debugging and deployment tools that use historical data next to a real-time view of the web service interaction provide extremely powerful tools for the web service developers.

Summary

There are many misconceptions about web services technology. This is mainly caused by the fact that web service technology is still evolving, even at the most basic level. Many vendors, trade magazines and venture capitalists have already tagged web services as a technology that will trigger a new wave of applications, enabled by federated interoperability. This early exposure has resulted in many incomplete and incorrect publications, frequent releases of toolkits with little or no architectural vision, and different standardization bodies fighting for the right to control the standards under pinning web services. Add to this that many of the vendors who jumped on board to promote web services, have a vested stake in web and applications servers and/or distributed object technologies, and promote web services only in the context of their flagship technologies.

This has become a fertile ground for many misconceptions. In this article I hope to have clarified a few of those common misconceptions that are important for those who have to reasons about web services at architectural level. It is important that we invest significant effort in education about the unique nature of web services to undo the damage that some of the hype reporting has created.

References

  1. Felipe Cabrera, et al., Web Services Coordination (WS-Coordination), Joint Specification by BEA, IBM and Microsoft, August 2002, http://www-106.ibm.com/developerworks/library/ws-coor/
  2. Colleen Evans, et al., Web Services Reliability (WS-Reliability) Ver 1.0, Joint Specification by Fujitsu, NEC, Oracle, Sonic Software, and Sun Microsystems, January 2003, http://developers.sun.com/sw/platform/technologies/ws-reliability.html
  3. Christopher Ferris and David Langworthy, editors, Web Services Reliable Messaging Protocol (WS-ReliableMessaging), Joint Specification by BEA, IBM, Microsoft and Tibco March 2003, http://www-106.ibm.com/developerworks/webservices/library/ws-rm/
  4. Mindreef Web Services Diagnostics, http://www.mindreef.com
  5. Steve Vinoski, Web Services Interaction Models, Part 1: Current Practice, IEEE Internet Computing, Vol. 6 No 3, pp 89-91, May/June 2002
  6. World Wide Web Consortium, SOAP Version 1.2 Part 0: Primer, June 2003 http://www.w3.org/TR/soap12-part0/
Posted by Werner Vogels at August 26, 2003 02:26 PM
TrackBacks

All Things Distributed: Web Services
Excerpt: All Things Distributed: Web Services are NOT Distributed Objects Even though traditional tools are of little help with these problems, new web services diagnostic tools such as SOAPscope are emerging to address the development and deployment challenges...
Weblog: Dave Seidel :: Wavicle
Tracked: August 26, 2003 03:21 PM
Real World Web Services
Excerpt:
Weblog: Tom Richards .NET Weblog
Tracked: August 26, 2003 06:25 PM
Werner Vogel
Excerpt:
Weblog: Julia Lerman Blog
Tracked: August 26, 2003 08:10 PM
Werner Vogels
Excerpt:
Weblog: Julia Lerman Blog
Tracked: August 26, 2003 09:39 PM
Werner Vogels nails it: Web Services are NOT Distributed Objects.
Excerpt: Werner does a fine job of killing some myths about web services. He's looking for feedback - a must read.
Weblog: Bill de hÓra
Tracked: August 27, 2003 09:24 AM
Werner Vogels on Web Services
Excerpt: Werner Vogels has posted a draft for an article called Web Services are NOT Distributed Objects.
Weblog: Random Stuff
Tracked: August 27, 2003 10:19 AM
More real world web services ...
Excerpt:
Weblog: Tom Richards .NET Weblog
Tracked: August 27, 2003 03:10 PM
These links we make
Excerpt: These links we make, they don't lead us anywhere but where we are already.
Weblog: dive into mark
Tracked: August 28, 2003 03:15 AM
Web Services are not Distributed Objects: Common Misconceptions about Service Oriented Architectures
Excerpt: Werner Vogels from the Dept. of Computer Science, Cornell University has published an useful introduction to web services, trying to clear up some common misconceptions - well worth a read at http://www.allthingsdistributed.com/historical/archives...
Weblog: mikewarriner.com
Tracked: August 28, 2003 08:52 AM
Web Services and Distributed Objects
Excerpt: Via Mark Pilgrim an excellent article on myths about Web Services."In this article I revisit the differences be...
Weblog: Never Give Up
Tracked: August 28, 2003 09:35 AM
Web Services vs. Distributed Objects? Go for REST.
Excerpt: Mark made very true comment on Werners "Web Services are NOT Distributed Objects" post. I liked description of all misconceptions. I would just add some remarks to web services and distributed objects relationship. Werner says: "How is it possible tha...
Weblog: Radovan Janecek: Nothing Impersonal
Tracked: September 2, 2003 03:47 AM
Web Services are not Distributed Objects II
Excerpt: Mark made other good points about the Werner's article. Especially the point about incorrect HTTP limitation of REST is nice. It is interesting to see that for example Doug has just emphasized the part about REST. I see there is...
Weblog: Radovan Janecek: Nothing Impersonal
Tracked: September 2, 2003 05:32 AM
Introduction to Object Oriented Distributed Systems and Web Services
Excerpt: Here are the slides to discussed in the class on 9/1, 9/3 & 9/5 Introduction to Object Oriented Distributed Systems and Web Services Reading: Chapters 3 & 10 Additional Reading: All Things Distributed: Web Services are NOT Distributed Objects Article...
Weblog: COM S 514 Intermediate Computer Systems
Tracked: September 4, 2003 09:07 PM
Web Services are NOT Distributed Objects
Excerpt: Werner Vogels' Weblog ÷ Web Services are NOT Distributed Objects Article. ⼭ ڰ ϴ ص鿡 ѹ غ մϴ. Not a misconception: web services are really simple. Misconception #1: Web services are ju...
Weblog: HOLLOBLOG (ֺε)
Tracked: September 13, 2003 10:44 AM
Comments

I was very glad to find your article. I am a .NET developer and have created a number of VS.NET wizard generated web services. From that point of view web services are just objects that a client can obtain a reference to (VS.NET generated proxy). From that point of view web services are just distributed objects. I haven't cared about SOAP (rpc or doc), or whether I am using xml, just that I can call a method on a remote object.
This has always been more than a little bit unsatisfactory. I have asked "is that all it is?" Firewall friendly remoting?
I have been moving beyond that vision to what web services are really about, though a "learning" project. Kinda of described in my blog with little detail so far (http://weblogs.asp.net/trichards) Your article is very timely and I appreciated it.
Not sure that the general IT audience (at least those here) cares about more than sending messages, receiving responses and http - and security of course.
I assume that my company is somewhat typical - out of >20 coder/developers I think that I'm the only one belonging to IEEE. We have developed a fairly large .net insurance application that is in it's second beta and is being used. The MS hype about .net and web services are being use to sell it.
Anyway, not a coherent review but some thoughts.

Posted by: Tom Richards on August 27, 2003 10:37 AM

I have followed the emergence of SOAP 1.2 since the w3c discussion lists regarding it began. Your take on what web services are, the noise injected by the distributed object vendors, the politics, the REST subset, the its-only-RPC tactic of detractors, and other points in your analysis are on the money and very well stated.

When is publication? Must I refrain from commenting in my blog until then?

Posted by: Margaret Green on August 27, 2003 07:53 PM

Why does this article appear to be revising history?

The term "Web Services" is a term defined by the vendors who all orginal thought it to be based on remote object invocation using XML over HTTP. It's only recently that they've come to terms with reality to realize that to achieve interoperability you have to do asynchronous message passing.

In short, these aren't misconceptions, these are the
information provided by the vendors who believed them to be true.

Today, we know better.

Carlos

Posted by: Carlos E. Perez on August 27, 2003 08:34 PM

I found your article interesting, but it doesn't go far enough.

1. Merely *saying* that Web services are not the same as distributed objects does not prove the case. (I happen to agree with you, but I don't think you have proved your point.)

2. The issue about object references is valid, but, as you yourself point out, getting and using items such as invoice numbers, account numbers, etc. is remarkably analogous to object references. The essential difference may be that object references are an implementation artifact whereas account numbers are a business artifact.

3. When *I* talk about SOA's, I tend to focus on the conversation centric nature of SOA's vs. the object centric nature of OOA's.

4. I also stress (perhaps to the point of overbearance) the issue of *ownership boundaries*. I believe that ownership is of the essence in the World Wide Service Network and that the architecture of Web services must completely respect it if it is to be scalable.

5. Your article focuses on the low-level aspects of the interoperability space. In the WSA, we have currently 5 models: messaging, service, resource, policy and management. I fully expect a 6th model: relationships before we are fully finished in this area.

6. As you noted, the recent debate on resources, representations etc. wrt the WWSN and the Web is very interesting and certainly I learned a great deal from it. Grokking the web at a philosophical level is very enriching.

Anyway, it will take time for the community to fully understand Web services, and I appreciate your article as a contribution.

Frank McCabe

Posted by: Frank McCabe on August 27, 2003 08:56 PM

1. Please use other language than "the process around" and "... computing centers around the design". This is unusual English usage.

2. State-full, statefull, stateful. Only the last of these is correct.

3. I couldn't see a scientific basis for the taxonomy. Imagine that we have black boxes and can observe only state and message behavior. How would one distinguish between the two concepts? Just by watching for XML in messages? It seems the distinction is more about methodology, or some engineering concerns, once we look past business, politics, standards, and the territorial claims of people architecting system layers.

Posted by: Ted Herman on August 28, 2003 04:45 AM

I appreciate these comments very much and will address most of them in a next posting on how I plan to improve the article.

Please keept the comments coming, either here or by email.

Thanks!

Posted by: Werner on August 28, 2003 05:48 AM

Nice article.

I espcially liked this:
"The goal of web services is to enable machine-to-machine communication at the same scale and using the same style of protocols as human interface centered World Wide Web."

You might want to expand on that thought as I think it most clearly explains your point.

Posted by: peter on August 28, 2003 07:26 AM

Nice article...I was wondering if you would touch upon another very common misconception "Web Services will eliminate the need for application integration " in your next posting.

-Sudhir

Posted by: sudhir on September 1, 2003 10:24 PM

Cool! Btw, I would remove "Web Services are not Distributed Objects" from the title of the article because some of the misconceptions you describe have nothing to do with distributed objects. Some more comments on this article are here: http://radovanjanecek.net/blog/archives/000011.html.

One comment on sudhir's comment: web services will not eliminate the need for application integration. They will eliminate proprietary EAI layers though.

Posted by: Radovan Janecek on September 2, 2003 04:52 AM

Nice to read a non political/verdor based artical about web services.

I wish there were more out there.

Posted by: Matt on September 2, 2003 05:18 PM

Web services are services, plain and simple. They can be simple, like getting a state abbreviation from a state FIPS code, or be complex like stateful remote object control.

A mailing list, in a way, is a web service.

Where people fall all over tehmselves is the application of a particular technology and its strengths and shortcomings in particular situations. (My SOAP is better that you XML-RPC is better than your REST is better than your EDI).
The reality is that, just like with programming languages, some situations are more suited to some tools rather than others. All are web services, just like C++, T-SQL, and Ruby are all programming languages.

Posted by: Christopher Mahan on September 3, 2003 03:09 AM

In general, I like the article in that it points out some of the common belief that simply aren't correct -- Web services aren't distributed objects and web services are stateless.

Why are these misconceptions important? It is because in today's IS industry, hype and marketing largely overshadow(in most cases) the technical aspect of technology. And even more sadly, a large portion of IS practioners/programmers/designers/architects couldn't differentiate between hype and marketing versus the technical reality. The result: companies start to look at Web Services as the silver bullet and consider it as the solution for all. I happen to be in consulting business(for large scale commercial applications) and one very sad thing to see is that company spend a lot of money on something that they don't really understand how it should be use(and to be best used). Web Services is one of them. I see company starts projects that specifically ask to use Web Services "as the strategic direction" when they don't even know if Web Services is the right choice for the problem on hand.

There are different types of applications exist in the world. Internet/browser/document based model is only one of them. Web Services does not address the complex nature of many other types of the applications where true distributed object systems and stateful architecture shine.

Therefore, I like to see more articles like this come out and more people read it to understand what the emerging technology is all about, instead of blindly go with the flow. Different applications require different attention and architecture.

Posted by: Mark Wai on September 4, 2003 10:32 AM

A very clear and concise article which helps a great deal. I think the problem is that document oriented web services will not be that useful for developing real applications until higher level standards such as coordination, reliability and security mature. As you point out real progress has been made on security but it will be a while before other standards are accepted. I think it is true that in a loose sense most services are stateful. But can we not make a useful distinction based on the relative location and environment of interface, code and data ?

Posted by: Ben Butchart on September 4, 2003 10:59 AM

I don't think this is that clear on how Web services are different from distributed objects. What are the constraints that Web services and distributed objects must obey? Take a look at the WS-Addressing specification. It defines a model for using ReplyTo with reference properties in endpoint references. It's an obvious step to use EPRs as object references. ReplyTo can be used to support factory patterns. If Web services are defined as NOT using factory patterns and dynamic references, does that mean that a WS using ReplyTo and EPRs is NOT a WS?

Posted by: David Orchard on September 4, 2003 08:00 PM

I agree with most of what you say in the article. Only "Web services is RPC for the Internet" is much less a misconception on the part of unknowledgable developers than it is what most of the big vendors are pushing. It is deeply entrenched in SOAP (as you mentioned yourself), WSDL, JAX-RPC, .Net and lots of tools that exist today.

Posted by: Alexander Jerusalem on September 5, 2003 01:24 PM

I agree with much of what you've said. In regard to the confusion of web services with distributed objects, I think another factor is how WS are currently being used.

If I've been eating my peas with a fork and now you show me a spoon, I'm going to view the spoon as an improved tool for eating peas. Afterall, it has a handle just like a fork and it solves some of the problems I had when using a fork. It will take me (or perhaps someone else) a while to figure out that they are not the same thing and that I can do many other things (having nothing to do with eating) with this spoon due to its nature as a scooping device.

Until we take advantage of the document-centric nature of WS, people will continue to compare and confuse them with distributed objects.

Posted by: Steve Zilora on September 12, 2003 07:58 AM

I agree with your thesis, however it does not help us users in the coporate world who have to develop a case for migrating towards a document oriented, machine to machine, information interchange. The key here is a service which I call it as a verb and not just nouns that must be statically integrated to create a business process environment. Whether it be distributed objects or just the documents that provide interoperability via XML interfaces is really a technical accuracy that does not help the business in orchestrating a virtual application subset which is short lived and dynamically created to solve a business process transaction execution. We have been talking about wrwppers that create objects for flat files so as to facilitate a business transaction. I think the point to focus is not whether SOA via web services is a distributed objects or a XML based document level interchange-but that the platform agonostic nature of interoperability of information interchange. What we need to focus is the service management which allows for a SOA environment where IT can deliver to businesses agile needs and get away from the traditional 6-18 month development tasks.

Posted by: Ajit Kapoor on September 13, 2003 08:58 PM

you have started unravelling a thread that I suspect spawns a few 'versus' arguements...for example;

XML: hierarchical vs relational data

XML: reintroduces the internet way of doing things by using documents, which comes along with URI's....document centric vs datacentric data in xml

OO:inheritance vs composition issue within OO becomes even clearer in the emerging SOA world

XSLT: xslt has reintroduced the declaritive vs procedural issue, with XML trees reminding us of S-boxes...

Even if we do get to a point of simple interactions, complex messages e.g. document centric computing....we still have the following to contend with;

-synchronous vs asynchronous
-stateless vs stateful
-coarse grained web services vs RPC style usage

Seems strange to me that such primary type versus args are emerging across the spectrum of internet computing ...though if the internet is viewed from a framework perspective, many of the 'versus' type args might be cropping up because we are occupying that no mans land between white box reuse and true black box components....which the article is just starting to unravel.

nice article

Posted by: Jim Fuller on October 4, 2003 03:52 PM

Nice article, However, it revolves around semantics...
Is Distributed Objects? is it not Distributed Objects? Really revolves around your definition of what distributed objects are!
So semantically I can say that, since Web Services rely heavily on SOAP, thats:
Simple Object Activation Protocol, right? So Distributed and OO!
Web services are filling the hole left in Internet development, specifically for inter-enterprise communication mechanisms, they where designed using distributed object oriented concepts (& infrastructures).
And as always large evolutionary steps create something new, that stands on the shoulders of its predecessors! In our case Web Services are based on Distributed Objects and add the additional level for standardization and communication!

Posted by: Amihay Zer-Kavod on October 17, 2003 03:43 AM