Welcome!

Industrial IoT Authors: Pat Romanski, William Schmarzo, Elizabeth White, Stackify Blog, Yeshim Deniz

Related Topics: Industrial IoT

Industrial IoT: Article

Using XML Schemas Effectively in WSDL Design

Using XML Schemas Effectively in WSDL Design

Developers are beginning to develop more sophisticated Web services, exchanging complex XML documents rather than simple parameter types. As this shift takes place, development teams begin to grapple with different approaches to designing these Web services interfaces through the use of WSDL. As we've worked with a number of these teams, we've begun to discover some important best practices that can be applied, particularly in the use of XML Schemas in a Web services design.

In this article, we will focus on four specific areas: XML Schema style, namespaces, XML and WSDL import for modularity, and use of schema types for platform interoperability. Through the use of these techniques, you will be able to achieve a higher degree of portability of your WSDL and XML Schemas and will realize improved reusability and interoperability between a broader collection of Web services platforms.

Design Style for Reusability and Portability
There are many ways to define an XML Schema that could be used to validate the same XML document instance. As you'll see, the design style used can impact the WSDL design and the resulting implementation classes. To better illustrate this point, consider the simple XML document in Listing 1. This might represent the kind of document submitted to a Web service for the purpose of obtaining a price quote on a list of computer parts.

As Listing 2 illustrates, a schema could be defined as one monolithic structure that closely resembles the actual XML document instance itself. While this schema will validate the document as desired, there are several potential issues in taking this approach. First, there are ambiguities in this schema that may impact the generation of helper classes on some platforms. For example, due to the fact that the complex types are unnamed, some platforms will generate the implementation helper class names as anonymous types. This can make it difficult for developers to make use of these helper classes during development.

Second, the elements of this schema are not very reusable. For example, what would happen if you wanted to define a similar schema to reflect the resulting quote response from the supplier? In this case, the "PartList" in the return document may be exactly the same. You could simply define a second document structure with "PartList" structures. However, due to the way most platforms generate helper classes, it's highly likely that unless you name these elements differently, there will be a clash between the two. One way to resolve this is to use two different namespaces, which we'll talk about shortly. Another way to resolve this is to refactor the schema structure so that the "PartList" and "PartItem" elements can be used by both the request and the response documents. This is done by defining a separate complexType with a name such as "PartListType". In the definition for the document, you can then define an element of type "PartListType" with a name of "PartList".

In this example, we might also choose to refactor the CustomerDetails structure so that its components can be leveraged. A response document might have a corresponding element called "SupplierDetails". In this case, the common type could be called "OwnerDetailsType". The schema definition in Listing 3 shows our elements refactored for reuse and the types clearly named so that the resulting helper classes more closely reflect the element types they represent. This design style has the benefit of maximizing the potential for reuse by using type definitions. Another benefit of this technique is that you can selectively choose to expose the namespace of the elements in the resulting XML document. You'll see the value of this in the next section.

Using Namespaces Effectively
Notice in Listing 3 that we've also added the use of a namespace qualifier to the schema definition. XML Namespaces provide a scoping mechanism for a collection of elements or type definitions much like the package keyword works with Java. We've discussed the potential problem of defining two distinct document structures that each contained a PartList structure. If namespaces weren't used, attempting to reference either document's PartList would result in some confusion about which definition you meant. One strategy for resolving this is to define each document in a different schema, using a different namespace for each. The targetNamespace attribute of the opening schema definition allows us to specify what namespace the elements and types defined in the current schema will be bound to. We also defined a short reference name for this targetNamespace called supReq. Now, when we want to talk about the PartList representing the request, we can reference it with this prefix.

Another use for namespaces is to enable application of version control. This can be particularly important if you want to maintain multiple versions of the documents being exchanged by your Web service. While there are many different ways to manage versioning in schemas and WSDL documents, one advantage of using the namespace is that the XML Schema itself is enforcing the version control because a different version appears as a completely different namespace. Here are a few of examples of how this could be done:

<schema targetNamespace="http://acme.com/supplier/
requestTypes_v1" ...
<schema targetNamespace="http://acme.com/supplier/
versions/1.0/requestTypes"

Until now, we've been talking about a schema that is defined in a single file. However, it may be the case that a schema is built from a set of common types shared among several schemas. For example, if we wanted to leverage the common types defined in the schema in Listing 3 between both the quote request and the response, we might define these common types in a separate schema as shown in Listing 4. The schema for the quote request can then import and reference these elements as shown in Listing 5. Note that in order to tie everything together, we have to define an additional namespace reference, which we called "common". While we refer to the common types with the newly defined name "common", we still refer to the types defined in the current schema using "supReq", which is the name associated with the targetNamespace for this schema.

One final thing to consider is whether you want your common types to have their own namespace or share the namespace of the schema they are imported into. This is controlled with the "elementFormDefault" attribute in the common types schema file. In our example schema in Listing 4, we assigned a value of "qualified", which means that any references to these definitions must be qualified by the namespace. If we assign this a value of "unqualified", the definitions will be imported without any namespace associated with the types. As a result, the types will inherit the namespace defined by the importing schema.

Extending Import to Enhance WSDL Reusability
WSDL also includes a robust import mechanism to enable Web services interfaces to be built in a modular fashion. We recommend defining the XML Schemas independently from the WSDL, using import to connect them together. This approach is usually easier to manage, especially if the schemas and WSDL are created by different development groups. In some cases, the XML Schemas might exist prior to the development of the Web services. Use of import can also increase the reusability of your schemas across various development projects.

First we need to address how to properly import a schema into a WSDL. This can be confusing because WSDL currently supports two mechanisms for doing this: xsd:import and wsdl:import. The WS-I Basic Profile recommends that wsdl:import only be used to import WSDL documents, while xsd:import should be used to import schemas. According to WS-I, here is an incorrect way to import our schema defined in Listing 5:

<definitions targetNameSpace="http://acme.com/supplier/
definitions"...>
<wsdl:import namespace="http://acme.com/supplier/types"
location="http://acme.com/supplier/types.xsd"/>
...
</definitions>

The correct way:

<definitions targetNameSpace="http://acme.com/supplier/definitions"...>
<types>
<xsd:schema targetNamespace="http://acme.com/
supplier/types" ...>
<xsd:import namespace="http://acme.com/supplier/types"

schemaLocation="http://acme.com/supplier/types.xsd"/>
</xsd:schema>
</types>
...
</definitions>

You can use wsdl:import to separate your WSDL into modular components. As Figure 1 illustrates, you could put your XML Schemas in one file, the WSDL message abstractions in a second, and the service bindings in a third. The service bindings would import the message definitions using wsdl:import and the message definitions would import the schemas using xsd:import. This approach can greatly improve reusability of your components. For example, you could provide multiple service bindings for the same message types.

The next important issue to address is how to properly reference the schema types within the WSDL. The most common approach is to reference these types in the WSDL input and output message parts. In our example, the XML Schema might define a request for a quote for a supplier. This definition (identified by types:QuoteRequest) would then be referenced within the WSDL message part as follows:

<definitions targetNameSpace="http://acme.com/supplier/
definitions"
xmlns:types="http://acme.com/supplier/types">
<types>
<!-- import goes here -->
</types>
<message name="GetQuoteRequest">
<part name="QuoteRequest" element="types:QuoteRequest"/>
</message>
</definitions>

Notice in the above code that we specify a namespace of "http://acme.com/supplier/types" for the imported schema. When using the import statement, remember that the namespace of the imported file must be different than the file doing the importing. This is usually a good practice to follow, especially if you have broken your WSDL into multiple components. However, there may be times when you want the imported file to have the same namespace. WSDL 1.2 introduces a wsdl:include tag, which works similar to xsd:include allowing a single namespace to be shared across components.

The final piece of advice we wish to leave you with is about the importance of tools in this design process. A good tool can help in creating both the XML Schema types and the WSDL. We have found that a combination of tools is sometimes necessary to fulfill these requirements. For example, we use XMLSPY to design our schemas and CapeClear's WSDL Editor to import the schema and create the necessary WSDL message and service definitions. These tools can provide great value in the design and development of Web services.

Platform Compatibility of Schema Types and Structures
If you're leveraging a Web services tool or platform in your development, you'll need to pay special attention to potential interoperability issues in the use of certain schema types and structures. What if a language doesn't support a specific data type or if multiple platforms have different meanings for the same data type? We will now turn our attention to how these differences can present challenges to Web services developers.

One of the first recommendations is to stick with simple types in your WSDL. However, even these types can pose potential interoperability problems. For example, while Java defines a char type, there is no mechanism to map a char to XML. Another example is the use of unsigned numerical types (e.g., xs:unsignedInteger). Languages such as C++ are able to handle these types, but Java does not currently include support for them. You should also avoid the use of data type restrictions in your schemas, because most languages do not support this capability. Finally, if you are working with decimal or float values, be sure to test for loss of precision across implementations.

Obviously, complexity increases as you move from simple to complex types. Use of arrays can pose a challenge, especially if you're using nested or multidimensional arrays. We also discovered interoperability issues in using a Java ArrayList or Vector to represent data collections. Instead, you should use literal arrays (e.g., String[]) to avoid any potential portability problems. Another example is the use of hashtables, which is supported by both .NET and Java. However, there is no guarantee that a java.util.HashMap will be properly unmarshalled to a Systems.Collections.Hashtable in the .NET platform.

Dates can also present some interoperability challenges, even between J2EE-based platforms. When designing an XML Schema, you would most likely use xsd:datetime to represent a date. In Java, you might be using either java.util.Date or java.util.Calendar for dates. Both of these Java types will map to xsd:datetime, but JAX-RPC maps xsd:datetime to java.util.Calendar. If you develop a Web service that uses java.util.Date, a JAX-RPC-based client would automatically map to java.util.Calendar, causing a potential compatibility problem with your Web service. The general guideline is to use java.util.Calendar when possible.

You may also encounter problems mapping certain XML Schema constructs to the language. For example, the CHOICE keyword is not directly supported in JAX-RPC. There are also no Java constructs to represent schema annotations, default values, or optional attributes. If these are used in a WSDL, they will not be represented in the server-side bindings that are generated by the platform. These constructs will then be lost if your platform dynamically generates the WSDL from the bindings. You may want to force the platform to use the static WSDL file so that clients can see these additional annotations in the WSDL.

So, what more can you do to improve Web services interoperability? First, don't abandon the use of XML Schemas. While there are clearly pitfalls to avoid, there is also much to be gained in reusability and portability. Second, pay close attention to WS-I, which has come out with a number of recommendations to encourage the use of XML Schemas. Finally, if you really want to know how your Web service will work with other platforms, design a comprehensive suite of tests to minimize potential interoperability issues across platforms.

Conclusion
In this article, we covered a number of important best practices for leveraging XML Schemas in a Web services design. Using a more modular schema design can maximize the potential for reuse in your organization. The proper refactoring and naming techniques can also simplify the generation of implementation classes for your platform.

A modular design approach will also require an effective use of namespaces in your XML Schemas. Namespaces provide a mechanism to scope different elements or type definitions in your design. They can simplify how you reference or import types that might exist in external schema files. They can also be used to enforce versioning of your Web services.

The techniques that were discussed to modularize XML Schemas can also apply to the design of the WSDL interfaces. If used properly, the import mechanism can provide a great amount of reusability of both the XML Schema types and the WSDL message types. This design can be further enhanced through the use of development and design tools. It's important to remember that each Web services platform might manage XML differently. Use of certain XML data types or schema structures may not be supported on certain platforms. In the design, you should pay close attention to these interoperability issues, adding testing where appropriate.

Proper use of XML Schemas can improve the reusability, flexibility, and maintainability of your Web services components.

References

  • Ballinger, K.; Ehnebuske, D.; et al. (2003). Basis Profile Version 1.0. WS-I, March.
  • Mitre Corporation. (2003). "XML Schemas: Best Practices." www.xfront.com/BestPracticesHomepage.html, February.
  • Peeters, Johan. (2003). "WSDL Tales from the Trenches," Part 2. webservices.xml.com, June.
  • Seely, Scott. (2002). "Splitting up WSDL: The Importance of targetNamespace." MSDN, August.
  • Siddiqui, Bilal. (2002). "Developing Web Services, Part 3: SOAP Interoperability." IBM DeveloperWorks, September.
  • More Stories By Mark Secrist

    Mark is a senior constultant for the HP Developer Resource Organization with 10+ years experience involving distributed object technologies and building n-tier, web-based applications. He currently consults with enterprise customers on J2EE & web services development. Mark also has published technical white
    papers on J2EE, mobile and web services development.

    More Stories By Chris Peltz

    Chris Peltz is a senior architect within HP's
    Developer Resources Organization (http://devresource.hp.com), providing technical and architectural consulting to enterprise customers in the areas of J2EE, Web services, and
    application management.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    IoT & Smart Cities Stories
    While the focus and objectives of IoT initiatives are many and diverse, they all share a few common attributes, and one of those is the network. Commonly, that network includes the Internet, over which there isn't any real control for performance and availability. Or is there? The current state of the art for Big Data analytics, as applied to network telemetry, offers new opportunities for improving and assuring operational integrity. In his session at @ThingsExpo, Jim Frey, Vice President of S...
    In his keynote at 18th Cloud Expo, Andrew Keys, Co-Founder of ConsenSys Enterprise, provided an overview of the evolution of the Internet and the Database and the future of their combination – the Blockchain. Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settl...
    @CloudEXPO and @ExpoDX, two of the most influential technology events in the world, have hosted hundreds of sponsors and exhibitors since our launch 10 years ago. @CloudEXPO and @ExpoDX New York and Silicon Valley provide a full year of face-to-face marketing opportunities for your company. Each sponsorship and exhibit package comes with pre and post-show marketing programs. By sponsoring and exhibiting in New York and Silicon Valley, you reach a full complement of decision makers and buyers in ...
    Two weeks ago (November 3-5), I attended the Cloud Expo Silicon Valley as a speaker, where I presented on the security and privacy due diligence requirements for cloud solutions. Cloud security is a topical issue for every CIO, CISO, and technology buyer. Decision-makers are always looking for insights on how to mitigate the security risks of implementing and using cloud solutions. Based on the presentation topics covered at the conference, as well as the general discussions heard between sessio...
    The Internet of Things is clearly many things: data collection and analytics, wearables, Smart Grids and Smart Cities, the Industrial Internet, and more. Cool platforms like Arduino, Raspberry Pi, Intel's Galileo and Edison, and a diverse world of sensors are making the IoT a great toy box for developers in all these areas. In this Power Panel at @ThingsExpo, moderated by Conference Chair Roger Strukhoff, panelists discussed what things are the most important, which will have the most profound e...
    The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it results in an overall increase in consumption. Writing on the increased use of coal as a result of technological improvements, 19th-century economist William Stanley Jevons found that these improvements led to the development of new ways to utilize coal. In his session at 19th Cloud Expo, Mark Thiele, Chief Strategy Officer for Apcera, compared the Jevons Paradox to modern-day enterprise IT, examin...
    Rodrigo Coutinho is part of OutSystems' founders' team and currently the Head of Product Design. He provides a cross-functional role where he supports Product Management in defining the positioning and direction of the Agile Platform, while at the same time promoting model-based development and new techniques to deliver applications in the cloud.
    There are many examples of disruption in consumer space – Uber disrupting the cab industry, Airbnb disrupting the hospitality industry and so on; but have you wondered who is disrupting support and operations? AISERA helps make businesses and customers successful by offering consumer-like user experience for support and operations. We have built the world’s first AI-driven IT / HR / Cloud / Customer Support and Operations solution.
    LogRocket helps product teams develop better experiences for users by recording videos of user sessions with logs and network data. It identifies UX problems and reveals the root cause of every bug. LogRocket presents impactful errors on a website, and how to reproduce it. With LogRocket, users can replay problems.
    Data Theorem is a leading provider of modern application security. Its core mission is to analyze and secure any modern application anytime, anywhere. The Data Theorem Analyzer Engine continuously scans APIs and mobile applications in search of security flaws and data privacy gaps. Data Theorem products help organizations build safer applications that maximize data security and brand protection. The company has detected more than 300 million application eavesdropping incidents and currently secu...