Complete and reusable description of message structural constraints in web service interfaces

Abstract

Existing specifications for describing message structure as a part of web service description do not support use case-specific definition of structural constraints. We propose a solution to describe a complete set of structural constraints for a particular business object in all its use cases. To implement our solution we use XML Schema (XSD), de facto standard for description of web service message structure. We propose XSD extensions that realize two distinct and complementary approaches. Measurements have shown that by using our extensions the average complexity of real world schemas (XSD documents) comparing to expressional equivalent alternatives is smaller by ~ 29%.

Introduction

Web service description (i.e. interface) should include constraints on message structure [1] using XSD (XML Schema [2]) [3]. XSD is used for description and validation of structure of XML (Extensible Markup Language [4]) messages being exchanged between web services, WS-BPEL (Web Services Business Process Execution Language [5]) business processes and other service consumers. It is widely observed [6], [7], [8], [9] that XSD fails to achieve the objective to provide useful level of structural constraint definition. Useful level is described as the ability to describe all structural constraints while maximizing reuse of the description parts. This is due to a lack of capabilities for use case-specific definition of elements and types that need to be used in different use cases [10], [11], especially regarding the definition of obligatory elements. Solution proposed by the problem observers is (A) to specify elements with specific constraints regarding optionality in different use cases as optional. Such best practice is recommended by standardization organizations, such as NIST [6] and TM Forum [8], advisory organizations, such as Fiatech [7], and industry content providers, such as IBM [9]. In this best practice approach (A), presence of obligatory elements in messages is not validated by the XSD, as these constraints vary for different use cases [6]. This approach has several negative consequences on development and maintenance of final software solution (described in detail in Section 3). However, it is argued by [6], [7], [8], [9] that all these drawbacks weigh out the ones of the obvious alternative solution that proposes (B) usage of a different XSD element/type for each specific use case containing exact structural constraints for that use case. This is mainly due to a significantly poorer reuse [7] (discussed in detail in Section 3).

We believe that all the described disadvantages of the approach (A) by comparison with the approach (B) can be eliminated by enabling use case-specific definitions of structural constraints on XSD types and elements for different use cases. This way all described disadvantages of the approach (B) can be avoided and all described disadvantages of the approach (A) eliminated.

The main objective of this article is therefore to propose a solution to enable use case-specific definitions in XSD. Using our solution obligatory elements are defined in a single element/type for all its use cases, thus number of XSD types in a domain is reduced to a minimum. Consequentially service reuse is the same as in the approach (A). As argued by proponents of the approach (A) it is better than in the approach (B). XSD definitions are used for complete structure validation in all use cases, including checking obligatory elements. There is no additional effort needed for development and maintenance of business logic for this kind of checking. Service descriptions using our solution are self-documented because all structural constraints are defined in XSD. Service consumers can determine the set of obligatory data for each particular use case from the service description alone. Thus, service discovery process is neither aggravated nor prolonged.

We achieve our main objective by proposing XSD extensions for use case-specific definition of XSD types and elements that are used in different use cases, in each with its own set of specific constraints. Proposed extensions provide capabilities for use case-specific definitions of structural constraints, most notably to specify specific elements of a complex type to be used only in some use cases. Proposed extensions realize two distinct approaches. Element centric approach enables definition of specific constraints directly on the relevant elements. Use case centric approach enables definition of constraints overrides from the default use case in separate sections.

This article is organized in eight sections. We present related work in Section 2. In Section 3, we present problems our solution solves from a broad perspective and explain why existing solutions are not satisfactory. We describe the problems in detail in Section 4 and the proposed solution in Section 5. In Section 6, we present proof of concept. We discuss the results in Section 7 and give conclusions in Section 8.