- 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
Using XML Schema To Define Messages
The intention behind separating the business module implementation from the web services layer is for each of these designs to be independent of the other. The business module implementation is a business problem requiring domain knowledge; the web services layer solves an infrastructure issue to enable remote access. The two design processes requires different specific skill sets.
Our previous article discussed how web services enable us to define a business-type interface for a business module and use XML for that interface. For a standalone business module that has an XML interface and that would be exposed to external clients, you would typically define an XSD schema for the message exchanges and validate incoming messages against that schema before processing any requests. Even if the clients are always trusted or are internal, it helps to define a schema for the message in order to achieve loose coupling between the systems and allow parallel development of all the internal software modules. In essence, the schema becomes the contract among the entities that exchange these messages. A schema for the messages is a reasonable expectation for all software modules with XML interfaces.
If web services is considered purely as a way to expose the business module to remote clients, then it really is just a technology enabler. The schema for the business messages should also be exposed as the schema for the web services messages. A web service does package messages inside its envelope (SOAP). And we would need to use WSDL to define the SOAP message exchange and identify end points of the service. But the actual message should remain unaltered even inside the SOAP envelope and be validated against its schema.