Web service contract design and versioning for soa download
This chapter introduces the basics of how policies can be defined and expressed and then associated attached to different parts of a WSDL document. Topics include policy subjects, policy alternatives, composite policies, and embedded and external attachment options. The examples again lead to a revised WSDL definition that includes a simple, attached policy expression.
We now turn our attention to the SOAP technology language that is used to express the structure of messages as they exist on the wire, when they are transmitted to and from Web services. Although this book is dedicated to the Web service contract only, it is important to understand how messages will be processed in order for us to design them effectively.
Note that this chapter does not explain the SOAP communications framework or any other topics that do not pertain directly to Web service contract design.
There are a variety of messages that a Web service will need to exchange, each with its own unique requirements. This, the first of two chapters dedicated to advanced XML Schema topics, explores the usage of wildcards, extension buckets, and content model groups and documents a variety of techniques that use these XML Schema features to accommodate different types of Web service message designs. Specifically, this part of the chapter provides examples that detail how abstract schemas can be created and how schemas in general can be extended.
Individual Add, Get, Delete, and Update message designs are described, along with common granularity levels. The ability to share schemas across Web services is fundamental to establishing separate schema and contract architecture layers. This chapter delves into the various options by which schemas can be partitioned into reusable modules and then included or imported by different schemas and, ultimately, different WSDL definitions. The creation of a common schema library is furthermore discussed and demonstrated.
Next are sections dedicated to explaining how relational data structures can be simulated using XML Schema features and also how narrative content can be added to supplement base schema content. Finally, the usage and incorporation of pre-defined industry schemas is explored along with several examples and techniques. Both WSDL 1. Subsequent sections discuss special message exchange patterns including WSDL 1. A section dedicated to message dispatch design issues is also provided, along with guidelines as to how to leverage the SOAP Action value to support interpretation of WSDL definitions for dispatch purposes.
Additional topics include different approaches for Web service instance identification and creating header blocks, including the use of the header fault extension. Continuing the coverage of the WS-Policy framework that began in Chapter 10, we now delve into various architectural issues, including the application of the Policy Centralization design pattern and different potential approaches for associating separate policy definition documents with WSDL definitions.
Subsequent parts of this chapter demonstrate the use of nested and parameterized policy expressions and then provide detailed coverage of ignorable policy assertions, including a comparison with optional policy assertions. The chapter concludes with an overview of concurrent policy-enabled Web service contracts. This chapter describes the design process and implications behind creating custom policy assertions. Various examples demonstrate different types of assertions and the pros and cons of customizing policies are further explained.
A separate section is provided, dedicated to issues pertaining to the maintenance of custom policy assertion vocabularies. Later in the chapter, the runtime representation or policy syntax is explored to provide insight as to how policy expressions and alternatives are streamlined into normalized representations.
Finally, an intersection algorithm is explained to identify compatibility between service provider and consumer policies.
WS-Addressing provides an industry-standard means of extending the base SOAP message design to accommodate a wide range of complex message exchange requirements. The chapter provides numerous code samples and concludes with a case study example comprised of a complete set of WS-Addressing headers. The chapter concludes with descriptions of policy assertions provided and standardized by the WSAddressing specification. Basic concepts and terminology associated with Web service contract versioning are established in this chapter, together with a detailed explanation of forward and backward compatibility from both technical and governance perspectives.
Version identification is then described and demonstrated through the use of annotated version numbers and namespace values. The chapter ends with sections that describe three primary versioning strategies Strict, Flexible, Loose that each support forward and backward compatibility to different extents.
These strategies will be used for reference purposes throughout subsequent chapters. Separate sections provide versioning guidance and examples for adding, renaming, and removing operations as well as modifying operation message exchange patterns and associated fault messages. Also provided are techniques for versioning port type definitions and various parts of the concrete description.
The last section describes what parts of the WSDL language can be used to potentially support forward compatibility. I originally announced the conference , in another blog. The focus was purposely not about a single vendors stack of technologies, but rather known techniques, issues in building systems, solutions and new trends, such as Mashups and REST and how they benefit service oriented thinking and design.
Of course, there were large vendors that talked about the benefits of their own product roadmap, but the intention of the organizers in the conference was to promote service oriented design which could be applied to generating solutions using the technology, not specifically about a single vendors bag of goodies.
As a matter of fact, an interesting talk was given by Anne Thomas Manes who talked about whether SOA has been oversold. In the end, it is the principles people should be focusing on for design and people should not overlook to practice these principles, rather than focusing on a specific technology stack.
In the conference, a book that I have colloborated in writing with other colleagues in the field was also launched. At the end of the conference, several of the authors who were gathered in front of the audience was asked why we wrote such a book, that focused on the Web service technology in the SOA practice.
You can find the pictures of the ceremony in the SOA symposium website where we discuss the content of the book and why we wrote it. I will repeat some of this below. When the idea of writing a colloborative book which would be led by Thomas Erl came about, I was attracted to the idea along with my other colleagues.
Kevin Liu from SAP is also an author of the book. Many to us who authored the book worked in the standards and colloborated in many standards bodies. Those web services standards are now the backbone of services that people use today. They are implemented by several vendors that target interoperability so that one can use their toolset to consume services that are built by other vendors easily and also expose their services to others. Andre Tost. More exactly, chapters 20, 21, and 22 of the book addressing the issues related to service contract versioning.
Web services in a SOA-based solution need detailed, technical contracts which clearly specify what each service is meant to do and how is to be used. Since services are subject to change over time, the contract designers need to make sure service consumers use the appropriate variant of the contract, problem solved through versioning.
Design, automate and improve processes to provide better customer experiences, deliver projects faster and increase business agility. Try now! In this chapter, the authors present the basic concepts and terminology used in versioning, compatibility issues to be addressed, how to use version identifiers, and several versioning strategies one could choose from. Since a web service contract can be made up of multiple documents - WSDL definitions, XML Schema definitions, WS-Policy definitions — versioning should apply to all documents that change when the contract changes.
There are 4 fundamental types of changes that need to be considered: backward compatible, forward compatible, compatible and incompatible. This section explains each type of change accompanied by examples. The next sections present the most common versions identifiers used and versioning strategies. Three strategies are detailed:. Beside versioning the entire document, the book contains examples of versioning the operations definitions, the port type definitions, and the concrete descriptions.
The XML Schema definitions contained by a service contract represent the basis for input, output and fault messages exchanged during service use. As a consequence, the authors consider that XML Schema definitions are most often subject to change and in need of versioning. The authors also explain how changes of the XML Schema target namespaces affect the WSDL target namespaces and how to apply strict, flexible and loose versioning in such cases. For more info, please visit informit.
Join a community of over , senior developers. View an example. You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.
Your message is awaiting moderation. Thank you for participating in the discussion. This book is great and has everything in it for everybody who is planning to create XML-based services of whatever flavour. I thank the authors for nailing down all aspects of this terrible subject. Priscilla Walmsley. Hugo Haas. L Umit Yalcinalp. Kevin Liu. David Orchard.
Andre Tost International Business Machines. James Pasley. Export Citations. Download citation Copy citation.
0コメント