News perspective: In 2002, web services advanced on two major fronts: development of tools to extend web services functionality and standardisation of the back-end plumbing required to make web services work.
Yet deployment of web services is viewed as being in its infancy.
Google and Macromedia released technologies intended to make web services more Web-friendly. Google in April released Google Web APIs service, which uses SOAP and WSDL to enable developers to query more than 2 billion web documents accessible from the Google search engine via their own computer programs, according to the company.
Macromedia's ColdFusion MX moved ColdFusion from a proprietary application server to one that works with J2EE application servers and makes it easier to develop web applications and services.
Web services made inroads with standards, but work remains to be done in areas such as choreography, the interaction between web services for applications such as e-business, and in security. Competing proposals on choreography were offered in 2002 from IBM, Microsoft, and BEA Systems, which partnered on BPEL4WS (Business Process Execution Language for Web Services), as well from Sun Microsystems, with its WSCI (Web Services Choreography Interface), which curiously also is supported by BEA.
For enterprise application vendors, 2002 was a year of warding off web services' threatening potential; with web services, enterprises could build composite applications by cherry-picking vendors' offerings while tightening internal suite integration.
SAP launched a new generation of cross functional applications (xApps) designed to run across multiple existing applications and information sources, driving end-to-end processes across heterogeneous systems. PeopleSoft fired back with AppConnect, a suite of pre-integrated portal, integration, and warehouse solutions leveraging web services to reduce integration costs.
Meanwhile, EAI tools, business process management platforms, and messaging middleware took the stage, while newer technologies including web services, JMS (Java Message Service), and proposed standards such as BPEL4Ws got breakthrough roles as facilitators of simpler integration.
Test Centre perspective: In November the W3C posted a first working draft of a document titled "Web Services Architecture." It candidly admits what has become impossible to ignore: The web services movement is cooking up a stone soup made of all sorts of ingredients. Distributed objects, remote procedure calls, electronic data interchange, message routing, and application integration are being tossed into a cauldron that was already bubbling with the protocols, formats, and addressing schemes of the World Wide Web.
The World Wide Web itself, as it turns out, does exhibit a consistent architecture and vision. By mid-2002, the benefits of Web-style resource description, service invocation, and document exchange were widely hailed. One key metric: the term "Web-friendly," which appeared nowhere in the SOAP 1.1 specification, shows up nine times in the SOAP 1.2 primer. All's well that ends well.
Putting the web back into web services wasn't the year's only accomplishment. There was also excellent progress on an issue that's been called the Achilles' heel of web services: security. In July, at the Burton Group Catalyst Conference in San Francisco, a flock of vendors demonstrated the exchange of authentication and authorization data using SAML (Security Assertion Markup Language), a standard that the Organization for the Advancement of Structured Information Standards (OASIS) ratified in November. Early concerns that SAML might compete with the IBM/Microsoft WS-Security specification dissolved as it became clear that the two specs are, in fact, nicely complementary.
SAML and WS-Security are modules that interconnect with each other and with related modules, such as XML Signature and XML Encryption, in a loosely coupled manner that has come to define the emerging web services architecture. Another nice example of modular reuse is XML Schema. It is used in WSDL to describe the types of data exchanged in SOAP transactions. In the forthcoming Office 11, XML Schema can define and control the data that users manage in ordinary business documents.
Will SOAP transactions rattling among web services endpoints and XML business documents handed around by users turn out to be the same? Yes and no. It's true that a document-oriented and web-friendly style will help us build distributed business systems more easily, and expose them to people more effectively. But the original web architecture doesn't meet all the requirements of a process-oriented and transacted business web. Routing, reliable asynchronous messaging, process workflow, compensating transactions, and granular end-to-end security remain key challenges.