How can clients avoid duplicating the code required to use a specific service, and also be insulated from the intricacies of communications logic?
Clients must know a lot about services in order to use them. Resource APIs require clients to use specific media types, set HTTP headers appropriately, and issue specific server methods in order to achieve the desired outcome. RPC APIs and Message APIs often require the request to be formatted as XML and wrapped in a SOAP envelope that uses specific SOAP headers. Some web services require data to be encrypted or demand that clients submit security claims (e.g., username/password tokens, X.509 certificates, SAML tokens, etc.). The client must also know the service's address or how to construct it, how to serialize requests, and how to deserialize responses. Each client application could develop a custom solution to meet the specific requirements of the service. This, however, often results in duplicate code. It would be much better to consolidate this logic so that it can be reused by multiple clients.
Create a library or set of classes that encapsulates the logic a client must implement in order to use a group of related services. Create a high-level interface that abstracts the details of this logic, thereby making the classes easier to use.
Service Connectors make services easier to use by hiding the specifics of communications-related APIs. Connectors encapsulate the generic communications-related logic required to use services, and also include logic that is quite specific to given services. They are typically responsible for service location and connection management, request dispatch, response handling (i.e. receipt), and some error handling. There are two types of Service Connectors. The first is the Service Proxy (a.k.a. Proxy). This type of connector is used with RPC APIs and Message APIs. The second type is the Service Gateway, which is commonly used with Resource APIs. Unlike service proxies, they usually aren't produced by code generation tools.