- 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
Ownership of the XML Message Schemas
XML technologies and web services have enabled us to look at ownership aspects of the definition of the interfaces from different perspectives. All the XML technologies are geared toward complete platform and technology independence. Web services allow coarse-grained, loosely coupled, high-level business module interfaces to be exposed as services. These interfaces don't need to be defined as low-level technology data objects, but instead are suited for defining and controlling the business functionality that's exposed to the user community. Consequently, it greatly benefits the process to have this definition of the interfaces done by the business owners of the project, rather than the engineering or IT department that implements the business functionality, based on the requirements document provided to them by the business community.
Once the requirements-gathering phase is complete and the engineering team is handed a requirements document, the first step must be to translate the requirements objectively and define an XML schema for the messages. As business groups get more XML-savvy, these XML schemas could then be part of the requirements document itself—much like how UI screen mockups are determined during the requirements/analysis phase prior to any engineering work.
Here are the benefits of this approach:
Business groups rightly own the message definition that expresses business functionality.
Business has full control of the functionality that it exposes or controls in the current release and subsequent releases of the software.
Business groups objectively define the business functionality specified in the requirements document. This strategy aids the development of the engineering/IT groups.
Business groups don't depend on the IT groups or the implementation of the business module to determine the functionalities to be exposed.
Business analysts choose naming conventions used in the interfaces. These conventions don't have to be based on low-level implementation artifacts or technology-specific terminologies.
Interfaces are defined prior to implementation! This is a good service-oriented architecture practice.
Loosely coupled systems (providers and consumers) can go about building their modules independently and in parallel.