- 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
XSD Interfaces for Document-Style Web Services
In document-style web services, the business module interface is always XML. If the business module interface is already defined via a schema, it's undesirable to redefine it through WSDL for a couple of reasons: First, this is a redundant step; more importantly, we'd have to change the WSDL with every change in the schema. The real solution is to use the XSD Schemas for the business module as the API signature in the web services. Web services can continue to use WSDL to specify SOAP envelope-specific details such as transport protocol and endpoint identification. But the SOAP message merely wraps the XML business message and transmits it—without any knowledge of the schema used to format that message.
This fact brings up a critical architectural decision: Who owns the validation of incoming messages? The web services layer handles decryption, verification of the digital certificates, and authentication of the client. For RPC-style web services, it also performs validation of the input message to the WSDL, because otherwise it would be impossible for the web services layer to map the message to the business data objects and its API. But in document-style web services—where the SOAP envelope has no knowledge of the message schema—how could the web services layer validate the message before handing it off to the business module? Validation of the incoming messages now resides in the purview of the business module. The business module need not know how the message got to it, but it needs to validate all incoming messages before processing them. This design is perfectly fine because this layer really needs to attach meaning to the schema of the incoming message. If the responsibility of validating the message lies with the business module, one central component in the architecture will have both responsibility and authority to handle messages. From an architectural perspective, this is a characteristic of a good design.
It's important to realize that only the ownership of the validation step has shifted hands from the web services infrastructure layer to the business module—this plan has no performance impact on the overall processing time of the message. Business API validation is part of the business module and its ownership, and thus validation should reside there. The high-level architectural diagram in Figure 1 highlights the responsibilities handled by the web service layer and the business module layer.
)
Figure
1 Functionality and ownership of the web services infrastructure and business
module layers.