لطفا منتظر باشید ...
Chapter 18. Concluding Remarks
Part I, "The Web Services Architecture," of this book introduced the functional building blocks of the Web services architecture and its underlying principles. Each building block was defined in terms of a protocol specification. We expect the functional scope and guiding principles described in this book to remain unaltered. However, we also expect the architecture to expand to support additional scenarios. Being able to accommodate innovation is a fundamental strength of the architecture.Great care has been taken to ensure that the various Web service protocols in this book can be cleanly composed with each other; while they have been designed together, they can be used in a wide range of combinations. As functional building blocks, they behave like a traditional development framework. When needed, such as for SOAP attachments, we have developed new solutions that fit cleanly within the architecture. The focus on composition is not a deterrent from rich functionality. It is a guiding design principle to preserve component independence. A good example of this is provided by the Web services management protocols, in that WS-Management builds directly upon the functional building blocks provided by WS-Enumeration and WS-Eventing.The architecture's SOAP messaging foundation assures wide reach. SOAP messaging supports both asynchronous and synchronous message exchange patterns in a transport-independent manner. There is no more flexible messaging infrastructure. To accelerate broad adoption of the Web services architecture, the specifications have been authored with an extensive collection of technical partners. Partnering with these key technology providers accelerates the deployment of devices and of programming environments that support the on-the-wire protocols. Achieving wide reach, widespread adoption, and scale-independent constructs are three of our core goals.We strive to ensure that the architecture can be implemented on any platform and in any programming language. This is facilitated by the message-based and protocol-based nature of the architecture. At timessuch as when using only WS-Security for message integrity, confidentiality, and authentication, and when expressing metadata using only WS-Policywe have restricted the universe of technical approaches to increase the level of interoperability. Ideally, as long as implementations faithfully follow the protocol specifications of the architecture, they will be able to communicate with any other Web service. The truth is on the wire.Part II, "Example Scenarios," of this book contains a running example of that illustrates the use of the Web services architecture. All the elements were introduced and used as part of the example. We chose to focus on the interoperability characteristics of the architecture. To do so, we described the interactions as seen on the wire, in their SOAP representation.
