لطفا منتظر باشید ...
Autonomous Services
Web services are autonomous software entities whose development, deployment, operation, management, and security all vary independently from those of the service's consumer. This "forced independence" has several important ramifications that permeate the architecture.Service autonomy has deep implications on how versioning is implemented. As a service's implementation evolves, the universe of compatible consuming applications changes. Appropriate management of these changes is critical to the correct operation of Web servicebased systems. At the most basic level, SOAP provides a protocol evolution model based on SOAP headers. SOAP headers are expected to be added or removed to a given message format over the lifetime of a given protocol. As new headers are introduced, the upgrade policy is carried in the header itself. Headers that can be safely ignored are simply inserted into the message. Headers that cannot be safely ignored are annotated with a mustUnderstand attribute, indicating that their insertion is an important change and that only recipients that recognize the header can process the message. This basic model for extensibility is most visible in SOAP itself; however, it is mirrored in various other Web service protocols, including WSDL. More importantly, this principle is used by Web services to add new protocol functionality (e.g., security) to a single messaging format (SOAP). Ultimately, the primary feature of SOAP is extensibilitynew versions of SOAP are not needed for each new protocol requirement.The autonomous nature of Web services also requires a greater emphasis on security, including the explicit management of trust between applications, request authentication and authorization, and input validation. Because services can be arbitrarily combined into systems, a greater degree of care is needed to ensure that malicious agents cannot compromise the integrity of a service. Particular care is needed for those services that are accessible from the public Internet. Part of this care takes the form of stronger input validation, which often can be automated using various schema languages. A more interesting aspect of this increased focus on system integrity is the use of explicit trust models. WS-Security can be used to secure messages with multiple security tokens. Some of these tokens may correspond to user identities or principals, while other tokens may correspond to rights that are granted to a particular user or application and can be cryptographically validated as part of a broader authorization scheme.Systems composed of long-lived, autonomous services need mechanisms to allow them to return to a steady state. In particular, services need to recycle resources created by requests of services that will not communicate again. In fact, resource reclamation policies are needed for all kinds of resources. A popular scheme is the use of leases as exemplified by subscriptions for event notification latter in this book. As asynchronous messaging allows services to have complete local control over the scheduling of message processing, resource reclamation policies can be triggered at any time. Services also have flexibility regarding maximum allowed message size, message transmissions, and connectivity management. Last but not least, services have independent failure modes. Systems should be able to recover from the failure of an underlying service.Finally, the autonomous nature of Web services invariably requires processes or systems that were at one time centralized to move to a federated model. This is true not only of security identities, but also of service directories and systems management. These new systems have to operate in the presence of unbounded message latencies, independent failure modes, and when services are intermittently connected to the network. Later in this book, examples showing the use of brokered trust and dynamic service discovery are presented to demonstrate federated identity and system management capabilities, respectively.
