لطفا منتظر باشید ...
Chapter 9. Introduction to the Example Scenarios
Part II of this book provides example scenarios illustrating the richness and use of the Web services architecture. Care was taken to choose examples that demonstrate each of the most important features of the Web services architecture. The example scenarios begin with the base XML technologies used for SOAP messaging and then proceed to incrementally add each of the features we described in Part I. In particular, the main example scenario, the first presented, shows how the Web services specifications are applied for secure, transacted, and reliable (WS-STAR or WS-*) Web services.
Despite being quite self-contained, this part of the book assumes that the reader has read Part I and understands the relationships between the various Web services specifications.
As the Web services architecture achieves interoperability through specification of wire-level protocols, each example scenario is given in terms of the wire representations. In particular, the example scenarios demonstrate how the various Web services protocols compose together and are manifest on the wire as SOAP messages. For interoperability, the truth is on the wire and nowhere else.
Software platforms built to use the Web services architecture as their underlying messaging infrastructure are expected to provide appropriate programming models for producing the messages from within their corresponding object models. Programmers are not expected to directly encode the SOAP messages produced by their software platforms. It is only because of our focus on interoperability that we choose to present the wire-level view of SOAP communication between services. Information about the XML wire format helps develop an understanding of how the protocols are designed and how the various features are implemented at the lowest level. We note that most of the facilities described in the example scenarios are expected to be provided by the messaging infrastructure in underlying software platforms and not by application logic.
The example scenarios are developed around a Web services solution where a fictional art school, the School of Fine Art, orders customized electronic books and other material from Microsoft Press. The school's (rather simple) procurement system communicates with the (fictional) Microsoft Press order management and book distribution systems using Web services. The scenarios are later expanded to incorporate the Web services architecture features that are well-suited for communication with devices such as printers. This device-focused example scenario describes a solution in which each professor locates appropriate printers and requests bound versions of their textbooks. Finally, the example scenarios are expanded one more time to incorporate the Web services architecture's system management framework. To avoid confusion with the specific real-world management protocols used for devices such as printers or network equipment, the systems management scenario departs from book procurement and printing and instead discusses systems management protocols in the context of smart drinking fountains. While a robust management solution for drinking fountains is not realistic today, the systems management features we discuss can be easily translated to more practical applications.
With that introduction, we now return to the first of the example scenarios. In the first step of the ordering process, the scenario includes the series of message exchanges involved in ordering customized electronic books. A swim-lane diagram of this scenario is shown in Figure 9-1.
Figure 9-1. Example scenario.
The scenario includes three separate message exchanges, in which five messages are exchanged:
A PurchaseOrder message [Message 1] is sent from the School of Fine Art's procurement system to Microsoft Press. An OrderAcknowledgement response [Message 2] is sent synchronouslyChapter 3Metadata."
Once the order is processed, a customized electronic book is generated for the school and an EBookAvailableNotice [Message 3] is sent asynchronously to the School of Fine Art's procurement system.
The information provided in the EBookAvailableNotice message is used by the procurement system to request the book. This is sent in the EBookRequestMessage [Message 4]. The book distribution system then returns the electronic book as an attachment included in the response message [Message 5].
This first, simple scenario is sufficient to explain many core features of the Web services architecture. As we discuss the more complex features provided in the architecture, the scenario will be expanded. The other example scenarios will be documented using the same approach.
Part I. However, in a few cases, the topics have been reordered to simplify our discussion.
