- Introduction
- Using XML Schema To Define Messages
- WSDL Interfaces for RPC-Style Web Services
- XSD Interfaces for Document-Style Web Services
- Ownership of the XML Message Schemas
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
WSDL Interfaces for RPC-Style Web Services
An RPC-style web service mimics the way in which distributed technologies worked prior to web services. It takes the low-level data objects that make up the service API or operation, serializes them, and then transports them over the wire. The operations are performed in the reverse order on the other side to re-create the data objects.
Developers who are used to prior distributed technologies can relate to this style of distributed access and are comfortable using it. It's also the easiest way to build a web service. Hence, it has become the de facto way to start learning more about web services. But there are issues with this approach:
Performance. Our next article in this series will talk about performance issues with web services in greater detail. The relevant observation here is that RPC-style web services perform very poorly when used in production for even a moderately-sized user base. This is true even for very small payloads. Thus, RPC-style services are not really suitable for production usage where scalability is of utmost importance.
Auto-generation of the actual interface (WSDL). In RPC-style Web services, the WSDL is the only interface contract binding all entities. Even though the technology-specific data objects may act as the API to the business module, the XML-serialized form represented in the WSDL is the interface to the web service.
API fidelity. As we mentioned in our previous article, web services are all about interoperability to gain technology and platform independence. RPC-style services attempt to exchange technology-specific data objects and APIs by serializing the data objects into XML and de-serializing again at the other end. Since web services are technology- and platform-neutral, de-serialization on the client side (based on the web services engine) to convert back to the data objects may not re-create the exact signature of the objects as defined by the provider.
NOTE
Exposing legacy systems as web services may be critical for the enterprise to enable remote access and for the extensibility of the system's reach. In such cases, exposing its API as RPC-style makes perfect sense despite the possible poor performance. This fact should eventually lead to document-style services to fine-tune the performance aspect.
For a service-oriented architecture, the interface definition is key to achieving loose coupling between systems. Enterprises must have full control over this definition and the technology to specify it. RPC-style web services offer convenient tools (such as Axis' Java2WSDL) to auto-generate the WSDL along with the server and client stubs. But while this setup may be convenient for prototypes, it could be the downfall of production environments. Auto-generating a key artifact such as the interface should not be an option for systems in production because this technique forces the enterprise to depend on the convenience tools for service interfaces. On the contrary, a process must be put in place by the enterprise to manage interface definitions and their future enhancements. The auto-generated WSDL merely serves as a starting point to build the WSDL manually for production-ready services.
Axis—an open source web service engine—offers the utility tools Java2WSDL and WSDL2Java to convert the data objects to XML and back to data objects for Java consumers and producers. Even with the same technology performing these two operations on your API, however, you'll get an altered version of the API you started with. The problem could be worse if you have to use another web service engine for another technology (for example, Perl's SOAP::Lite) and expect it to convert your serialized XML string into Perl objects.
What problem does this mangled API/object definition cause? From the business module's perspective, the API of the business module should be the contract to the clients and not the intermediate XML message stream defined by the WSDL. Otherwise, the business module owner loses control of the module's interface—a critical artifact for a loosely coupled system.
All these limitations make RPC-style services less desirable for production-quality web services for enterprises (except for legacy systems, in which the opportunity to bring the system online far outweighs these drawbacks).