لطفا منتظر باشید ...
Message Orientation
Web services communicate using messages. They place a significant emphasis on how individual messages are formed and processed. Unlike remote procedure call (RPC) systems in which messages are strictly subordinate to the local programming experience, the Web services architecture is built with messages as the atomic unit of communication. This is true not only of the wire format used for message exchanges (SOAP [SOAP]), but also for the descriptions of a given Web service (WSDL [WSDL]). Granted, some developers may choose to view a Web service using the RPC metaphor; however, this decision is local to that developer's code and not visible on the wire.Web services assume SOAP as the lowest layer in the protocol stack and isolates message transfer from transport details. Ideally, transport-specific bindings do not leak into application semantics. This approach provides a sound base for achieving service interoperability among development platforms and provides for the richer communication patterns required. Web services have typically relied on HTTP as the underlying message transport. By leveraging the open extensibility of the HTTP POST operation, many Web services have been bootstrapped using off-the-shelf Web technologies. As more sophisticated applications of Web services emerge, the importance of other transports becomes clear. For example, it is cumbersome, at best, to implement full-duplex message exchanges over HTTP's strict request/reply discipline. In contrast, sending SOAP messages over TCP [TCP] using a lightweight framing protocol allows any two-party message exchange pattern to be implemented trivially. The key difference is that the lightweight framing approach does not need to include all the HTTP messages required to set up a transmission of a request and to tear it down after the response.Web services can distribute the processing of a given message across multiple network nodes, each of which contributes some piece of functionality, such as access checks, content-based routing, specialized communication, or application-specific validation. This distributed processing model implies that a given message might need to traverse two or more message transports prior to arriving at the ultimate receiver. For that reason, much of the early protocol work in Web services was focused on providing end-to-end secure and reliable message delivery over arbitrary transports. For the simplest deployments in a single trust domain where a secure and reliable transport is available (e.g., TLS [TLS] over TCP or HTTP), more robust protocols such as WS-Security [WS-Security] or WS-ReliableMessaging [WS-RM] are optional. For richer deployments, these protocols are essential.
