لطفا منتظر باشید ...
Managed Transparency
Web services autonomously determine what implementation information is exposed through its interfaces and contracts. This managed transparency is a cornerstone of loosely coupled systems. The message-oriented façade that every service exposes provides ample insulation from the implementation choices made by a particular service developer. This opacity is critical to service autonomy and allows the largest amount of programming model, operating system, and deployment flexibility. Further, it allows the independent maintenance and evolution of service implementations, including the wholesale substitution of one service implementation for another. However, providing visibility to the service operations in terms of the messages sent and received, as well as the format of each message, has proven useful for automating the construction of services. Ideally, as long as both services respond to the same set of request messages with comparable results, the requestor is none the wiser that a different service implementation has been used.Given the emphasis on autonomous services, it may seem somewhat ironic that Web services place a great deal of emphasis on the transparency of implementation-specific information. However, this is needed to foster interactions and joint work among services. For example, if a service were completely opaque, one could not tell whether the set of input messages accepted by Service A were similar to or different from those accepted by Service B. For this reason, services are expected to make the publicly visible aspects of them that have to be transparent to the outside world. Contracts are the central concept to express the capabilities and deployment constraints of services. They enable the programmable discovery of service functionality and deployment constraints and also enable potential automation of interservice interaction. The transparency in Web services is achieved through the use of contracts. Contracts are machine-readable descriptions of the messages a service sends or receives, as well as the abstract capabilities and requirements of the service.Public contracts are essential for creating a rich Web services ecosystem for tools and execution environments. They also play an important role in achieving interoperability between heterogeneous systems. Development tools rely on contracts to create programmer-friendly language bindings for the messages a service accepts or sends. Deployment tools rely on contracts to wire up a deployed service to one or more publicly visible endpoint addresses. The runtime binding of a requestor to a given service can take advantage of contracts to ensure that a compatible service is selected during normal execution. Finally, management tools could rely on contracts to audit and signal whether a given service is operating within its expected collection of input and output messages.Managed transparency not only applies to descriptions of services, but also to the messages themselves. Let's consider security in the architecture. Unlike monolithic protocols of the past, SOAP and WS-Security together provide a flexible security layer in which different parts of a message can have distinct security characteristics. This means that the sender can elect to leave some aspects of the message completely transparent and visible to all potential readers, while encrypting other parts of the message intended for only a trusted set of readers. In the general case, each message part may be encrypted for a distinct set of readers. Those message parts that are not encrypted can be signed to protect them against tampering.
