Đang chuẩn bị liên kết để tải về tài liệu:
Expert Service-Oriented Architecture in C# 2005 phần 2

Không đóng trình duyệt đến khi xuất hiện nút TẢI XUỐNG Tải xuống

chúng tôi muốn đảm bảo rằng lưu lượng truy cập bình thường vào trang web không thể can thiệp. Đồng thời, nó là bây giờ một SOA, mục đích của dịch vụ Web để trao đổi và xử lý XML tin nhắn, không chỉ đơn giản đóng vai trò là máy chủ cho các cuộc gọi thủ tục từ xa (RPC) phương pháp phong cách. | 4 CHAPTER 1 INTRODUCING SERVICE-ORIENTED ARCHITECTURE Services are analogous to traditional object-oriented OO type-based components in that they provide a defined interface and they execute one or more operations. However a key difference is that service consumers can flexibly bind to a service whereas OO component consumers must set more rigid references. Service consumers can respond flexibly to changes in a service provider interface because it is easy to regenerate the proxy class using the updated WSDL document. However if a traditional component changes its interface the consumer itself must be recompiled in order to avoid type mismatch errors. Components are tightly integrated to their consumers and can break them. Service consumers however do not have to recompile if their service changes. Instead they simply have to rebind to the updated WSDL document. This is what is known as loose coupling or loosely coupled services. Of course if the service drastically changes its method signatures problems may result in the consumer. For example the consumer may not have the ability to supply new and modified input parameters for the updated methods. But as with any kind of interface-based programming it is understood that you cannot make significant changes to an existing method signature especially in terms of dropping existing input parameters or changing the type definitions for existing input or output parameters. In Web services terms this extends to the XML schema-based input and output messages that are exchanged by the service as well as to its supported operations. Just as with traditional components services should ideally remain backward-compatible as their interfaces evolve although this is not a requirement as it is for classic OO programming. Web services technically only need to honor their current contract as documented by their WSDL document which allows potential clients to dynamically bind to the service using the latest contract interface. Still