There are several answers to the question.
- We really mean it this time -- No Kidding. Can't you take a joke?
- There are some technical differences:
- Web services are more language independent than previous approaches. For example, CORBA was very C-like and was awkward in Smalltalk. EJBs and Java are, by definition, focused on the Java type space. XML renders more naturally into multiple languages like C, Java, COBOL, etc.
- XML and Web services are less fragile and better accommodate change. For example, it is possible to add or reorder elements in an XML business object without necessarily breaking code using older versions. The same applies to WSDL. Most previous approaches like RPC or CORBA were often a distributed version of a runtime model with offsets into data structures or function tables. So, additions and reordering broke code.
- Previous approaches really had three data models and type spaces. For example, a CORBA application had: 1) IDL, 2) IIOP for inflight messages, 3) SQL if the application was accessing a database. Distributed Java has a similar approach with serialized objects, the Java language and JDBC/SQL. Web services have one type space (XML) for interfaces, data applications are manipulating, XML databases and in-flight messages. It may not be obvious why one type space is better than three. The primary reasons are simplicity and flexibility. In Web services, there could be one basic approach for converting a data structure/business object from one format to another, instead of potentially three different type models and tools. This could enable a simpler development tool suite and API set. Moreover, having a consistent model enables flexible and more dynamic placement of business logic. The transformation code could run in an application, in an active database or in network intermediaries (proxies).
- We designed Web services to support both asynchronous messaging and remote procedure call. Previous approaches started with one or the other, and then grafted the other model later on. For example, implementing a layer on top of MQ for simple RPC is common. CORBA was originally RPC centric, but then added support for asynchronous messages. In most cases, the after the fact grafting of one technique on another was awkward and error-prone.
- There is also a different process for evolving the standards. In the past, we sometimes authored the services and then implemented them. This led to interoperability problems. With the advent of open source, the community provides reference implementations during the specification development. This improves interoperability and eliminates ambiguity.
Are Web services "it." Probably not. We will see new technology come. I use the analogy of the tide. The tide comes in one wave at a time, and not all at once. Web services are the current wave, and it offers value.