Key Moments
Web Services Middleware: All Grown Up!
Google TalksWant to know something specific about what's covered?
We've already dissected every moment. Ask and we will deliver (with timestamps).
Key Moments
Web services have evolved from RPC-over-SOAP to a pure message-passing architecture, essential for enterprise middleware but often overkill for simpler web interactions.
Key Insights
SOAP's evolution from an RPC-tied protocol (SOAP 0.9) to a transport-agnostic messaging format (SOAP 1.2) marked a significant shift away from distributed objects.
WSDL 1.1's message concept, inspired by email attachments, was a key design point allowing data to be sent in various ways, but WSDL 2.0 simplifies this to an XML element, with XOP and MTOM handling non-XML data.
The initial Apache SOAP stack's mistake was modeling web services after synchronous Java class invocations, a disconnect from the asynchronous, message-centric nature of web services.
Axis2's core design principle is XML-centric processing, treating all messages as XML (even if fictitious for non-XML inputs) and supporting both SOAP and POX (Plain Old XML) equally by focusing on the payload.
WS-Security, WS-ReliableMessaging, and WS-Transactions are essential additions built on top of the core SOAP/WSDL infrastructure, providing enterprise-grade qualities of service that RESTful approaches often lack.
The battle between REST and Web Services is framed as a misunderstanding of their purpose: REST for resource-oriented architectures (like the web) vs. Web Services for service-oriented architectures (enterprise integration).
The foundational shift from RPC to messaging in SOAP
The early days of web services were heavily influenced by Remote Procedure Calls (RPC), with Microsoft's initial SOAP project in the mid-90s aiming to integrate XML into communication protocols as an alternative to DCE. XML-RPC emerged as a simple RPC protocol using XML messages. SOAP version 0.9, released in 1999, was also RPC-centric and tightly coupled to HTTP. A pivotal change occurred with SOAP 1.1, which IBM helped drive, making the protocol transport-agnostic. Critically, the SOAP encoding data model, designed for serializing graph data, proved inconsistent with XML messages. This led to the development of SOAP 1.2, which fundamentally reoriented the standard as a purely messaging format. The acronym 'SOAP' was dropped, reflecting the shift from 'Simple Object Access Protocol' to just 'SOAP,' emphasizing its role as a message format rather than a protocol for distributed objects. This transition underscores a long-standing debate in distributed systems, ultimately settling in favor of message-based communication for web services.
WSDL's evolution from protocol description to abstract interface definition
Web Service Description Language (WSDL) also underwent significant evolution. Initially, Microsoft's SDL (Service Description Language) focused on describing how messages were sent over specific protocols like HTTP. IBM proposed NASA's NASSL (Network Application Service Specification Language), which was more akin to WSDL's current abstract/concrete structure but focused on RPC. The merger of these ideas led to WSDL 1.0, which adopted the abstract and binding nature of NASSL while incorporating the message-oriented structure from SDL. WSDL introduced the concept of 'message' as a collection of data parts, similar to an email with a body and attachments. WSDL 1.1, the widely adopted industrial standard, retained this structure. A key design principle behind WSDL was IBM's desire to remain transport-agnostic, allowing abstract service descriptions to be bound to various protocols like JMS or RMI, not just SOAP/HTTP. This was facilitated by the Web Service Invocation Framework (WSIF), an Apache open-source project that provided a unified programming model over different bindings.
The limitations of early web services for advanced qualities of service
While the abstract-concrete design of WSDL aimed for flexibility, its practical implementation faced challenges, particularly concerning advanced qualities of service like security and reliability. IBM's vision of abstract descriptions binding to diverse transports clashed with Microsoft's XML- and HTTP-centric approach. As a result, specifications like WS-Security, WS-ReliableMessaging, and WS-Addressing became tightly coupled to SOAP. This meant that WSIF could function for lightweight service invocation without these extra features, but deeper integration with message-level security or guaranteed delivery required adherence to the SOAP stack. The speaker concludes that achieving true transparency across all protocols with advanced features is not feasible, and embracing WS-* specifications necessitates commitment to the SOAP infrastructure.
WSDL 2.0: Simplifying messages and handling non-XML data
WSDL 2.0 marked another significant shift, fundamentally differing from its predecessor. It eliminated the abstract 'message' concept from WSDL 1.1 and replaced it with an XML element as the abstract description of an entire message. This simplification makes describing common XML exchanges straightforward: an XML element going in, an XML element coming out. For HTTP, this translates to simply placing the XML as the body of a POST request. For SOAP, it means placing the XML element within the SOAP body. A challenge arose with non-XML content (like images) that couldn't be directly embedded within an XML document without inefficient Base64 encoding. W3C standards XOP (XML-Out-of-Band Protocol) and MTOM (Message Transmission Optimization Mechanism) addressed this. XOP leverages the XML Infoset's abstract data model to allow non-XML characters, while MTOM uses MIME attachments when serializing to a transport like HTTP, replacing the embedded binary data with a reference to the MIME part. This integration means attachments are now logically part of the message's data model, simplifying security implementations like digital signatures that can cover both the message and its attachments consistently.
The diverse ecosystem of WS-* specifications
Beyond the core WSDL and SOAP, a rich set of WS-* specifications provides enterprise-grade capabilities on top of the messaging infrastructure. WS-Addressing defines message headers similar to email headers, specifying source, destination, and reply addresses. Security is handled by WS-Security (encrypting and signing XML/SOAP messages using XML Signature and Encryption), WS-Secure Conversation (establishing contexts for more efficient encryption), and WS-Trust (enabling trust through a trusted server, akin to Kerberos). Reliability is addressed by WS-Reliable Messaging, which guarantees message delivery, including ensuring exactly-once and in-order delivery through protocol exchanges. Transactional capabilities are provided by Atomic Transactions (two-phase commit, primarily for within-platform transactions) and Business Activity (a looser, coordination-based transaction model for wide-area interactions). WS-Policy offers a framework for defining business protocols and requirements for message interactions, such as reliability or transaction needs, while BPEL (Business Process Execution Language) enables service composition and workflow creation, allowing new services to be built by orchestrating existing ones. Metadata Exchange allows querying endpoints for their descriptions and policies.
Axis2: An XML-centric, payload-focused processing engine
Apache's web services stack evolved significantly, moving from Apache SOAP to Apache Axis, and then to Axis2. Apache SOAP's initial mistake was modeling web services after synchronous Java class invocations, a disconnect from the asynchronous, message-centric nature of actual web services. Axis addressed some shortcomings, notably adding support for headers and handlers, and improving performance by switching from DOM to SAX. However, Axis still largely assumed a synchronous request-response model and performed data binding (XML to Java types) within its core. Axis2, developed around 2004, fundamentally broke these models. Its core principle became purely XML-centric processing, treating all messages as XML (even creating a fictitious SOAP Infoset for non-XML inputs to ensure handlers operate on a consistent model). The focus shifted to a one-way message processing pipeline, with no inherent concept of data binding within the engine itself. This payload-centric approach naturally supports both SOAP and POX (Plain Old XML) by design, as it simply delivers the payload to the application. Axis2 uses a deferred build model with its Axium (Axis Object Model) to achieve high performance, only building the XML information model as needed. Data binding, while supported, is performed outside the core engine, often generated at development time for maximum efficiency.
The ongoing REST vs. Web Services debate and their distinct roles
The speaker addresses the common 'REST vs. Web Services' battle, arguing it's a misframed debate because they solve different problems. REST is fundamentally a resource-oriented architecture, well-suited for the web's information distribution. Web Services, particularly with the WS-* stack, are designed for service-oriented architectures (SOA), enabling complex enterprise integration with qualities like reliability and security that REST often lacks. While REST can be used for programmatic integration, when advanced features like message-level security or guaranteed delivery are required, the overhead and structure of SOAP become necessary. The speaker notes that within enterprise environments, the need for these qualities of service makes the choice for Web Services clear, whereas pure REST is generally sufficient for simpler web interactions. The preference for one architecture over the other depends on the specific system being built.
Axis2's extensibility and future performance goals
Axis2's architecture is designed for flexibility and performance. It operates on a message context that always represents the message as a SOAP Infoset, regardless of the actual input format (SOAP, POX, JSON, etc.), allowing handlers to work uniformly. Applied policies (security, reliability) are processed before the message is delivered to the application via a message receiver. While direct XML manipulation is preferred for efficiency, Axis2 supports data binding by mapping XML to Java classes outside the core engine, often using pre-generated code. The core engine can be implemented as POJOs, Spring beans, or directly using XML. Axis2 also supports modular extensions, including implementations of WS-* specifications and various language bindings (PHP, JavaScript, Python, Ruby) through projects like WSO2. Looking ahead, Axis2 aims to achieve performance levels comparable to or exceeding native Java RMI, thereby removing performance as a differentiator between using Web Services and other invocation mechanisms. The C implementation is expected to further boost performance capabilities by leveraging the efficiency of the C language for message processing.
Mentioned in This Episode
●Products
●Software & Apps
●Companies
●Organizations
●Concepts
Common Questions
SOAP was initially developed at Microsoft in the mid-90s to integrate XML into communication mediums, aiming to evolve beyond protocols like DCE and XML RPC.
Topics
Mentioned in this video
A network authentication protocol that WS-Trust is compared to for its trust server mechanism.
A protocol for querying an endpoint to obtain its service description and policies.
A language for defining business process interactions and composing services to create new services.
A specification that defines how to address web services, enabling them to process messages with routing information.
A transactional protocol implementing a two-phase commit, primarily for cross-platform transactions.
A security specification related to WS-Security that handles the issuance and validation of security tokens.
A programming language or system for which a binding was created to invoke mainframe activities via web services.
A revision of SOAP that purely focuses on messaging format, dropping the RPC and graph encoding aspects.
A protocol that guarantees the reliable, in-order delivery of messages, even in the event of failures.
A version of SOAP designed to be transport-agnostic and support messaging structures.
An architectural style that promotes the use of services and their integration, with web services as a common realization.
Asynchronous JavaScript and XML, for which XPI provides web service capabilities.
A specification for enhancing communication security with XML-based message integrity and confidentiality.
A specification for the digital signature and encryption of XML data.
A WS-Security extension that establishes security contexts for more efficient communication.
A framework for asserting the requirements and capabilities of web services, related to business protocols and policies.
Remote Method Invocation, a Java technology for inter-process communication, used as a performance benchmark for web services.
Web Service Invocation Framework, an Apache open-source project that provided a programming model for WSDL.
A Java API for reading XML, used as a basis for Axis2's message processing.
Simplified Wrapper and Interface Generator, used for creating bindings for C implementations of Axis2.
A project formed from Xfire and Celtycs, offering a more flexible data model than Axis2.
ECMAScript for XML, a language extension that provides a more user-friendly way to work with XML in JavaScript.
Java 2 Platform, Enterprise Edition, a platform for enterprise Java applications, compared with web services capabilities.
Microsoft's framework for building various types of applications, compared with web services capabilities.
Axis Object Model, the underlying model used in Axis2 for representing messages.
A module for Apache Axis2 that implements WS-Security.
The first SOAP implementation from Apache, initially based on RPC and Java classes.
Java Message Service, an IBM messaging technology that WSDL was designed to interoperate with.
A successor to Apache SOAP, featuring handlers for better protocol support and switching from DOM to SAX.
A popular Java framework, integration with which is supported by Axis2 for service implementations.
A server-side scripting language for which Axis2 implementations and bindings are developed, noted for its XML handling.
A popular SOAP engine, known for being Javacentric but less effective with other web service protocols.
A major rewrite of Axis, focusing on an XML-centric processing architecture, supporting POX and SOAP, and using an XML pipeline model.
Original developer of SOAP, also contributed to SDL (Service Description Language).
An Enterprise Service Bus (ESB) from WSO2 that routes, transforms, and manages messages.
A project that merged with Xfire to form CXF.
Became part of the SOAP community and proposed an alternative to SDL called NASA (NASSL).
The company founded by the speaker, driving the development of Apache web services components and products.
More from GoogleTalksArchive
View all 51 summaries
58 minEverything is Miscellaneous
54 minStatistical Aspects of Data Mining (Stats 202) Day 7
45 minKey Phrase Indexing With Controlled Vocabularies
63 minMysteries of the Human Genome
Ask anything from this episode.
Save it, chat with it, and connect it to Claude or ChatGPT. Get cited answers from the actual content — and build your own knowledge base of every podcast and video you care about.
Get Started Free