4.4 Client-Server Style
4.4.1 Overview
In the client-server style of the C&C viewtype, components interact by requesting services of other components. The essence of this style is that communication is typically paired and initiated by the client. A request for service from a client is normally paired with the provision of that service. Servers in this style provide a set of services through one or more interfaces, and clients use zero or more services provided by other servers in the system. There may be one central server or several distributed ones. Examples of the client-server style are (1) window systems that partition the system according to client application and screen server; (2) name directory services that partition according to name resolver and name server; (3) two-tier database systems that partition the system according to clients and data; and (4) distributed Web-based information systems that partition the system according to such concerns as client applications, business logic, and data management services.
4.4.2 Elements, Relations, and Properties
In the client-server style, summarized in Table 4.4, component types are clients and servers. The principal connector type for the client-server style is the request-reply connector used for invoking services. When more than one service is indicated on a connector, a protocol is often used to document ordering relationships among the invocable services. Servers have interfaces that describe the services they provide. Servers may in turn act as clients by requesting services from other servers, forming a hierarchy of service invocation.
Table 4.4. Summary of the client-server style
Elements |
Component types:
client, which requests services of another component, and server, which provides services to other components.
Connector types:
request/reply, the asymmetric invocation of server's services by a client.
|
Relations |
Attachment relation associates clients with the request role of the connector and servers with the reply role of the connector and determines which services can be requested by which clients. |
Computational model |
Clients initiate activities, requesting services as needed from servers and waiting for the results of those requests. |
Properties |
Same as defined by the C&C viewtype but refined by the server: the numbers and types of clients that can be attached and performance properties, such as transactions per second. |
Topology |
In general, unrestricted. Specializations may impose restrictions:
|
The computational flow of pure client-server systems is asymmetric: Clients initiate actions by requesting services of servers. Thus, the client must know the identity of a service to invoke it, and clients initiate all interactions. In contrast, servers do not know the identity of clients in advance of a service request and must respond to the initiated client requests.
One form of service invocation is synchronous: The re-quester of a service waits, or is blocked, until a requested service completes its actions, possibly providing a return result. Variants of the client-server style may introduce other connector types. For example, in some client-server forms, servers are permitted to initiate certain actions on their clients. This might be done by announcing events or by allowing a client to register notification procedures, or callbacks, that the server calls at specific times.
Constraints on the use of the client-server style might limit the number of clients that can be connected to a server or impose a restriction that servers cannot interact with other servers. A specialization case in client-server style is an n-tiered client-server model. In this case, clients and servers form an n-level hierarchy, upper tiers consisting of clients that invoke servers in tiers below. N-tiered systems are typically found in business processing applications, and n is usually 3: The first tier consists of client applications; the second tier, business logic services; the third tier, data management services, such as data persistence, concurrency control, and query support. Enterprise JavaBeans is a good example of this kind of architectural style.
Section 6.3 discusses the n-tier client-server style as a hybrid between the client-server and the deployment styles.
|
Useful properties to document about components include whether new clients and servers can be introduced dynamically, as well as any limitations on the number of clients that can interact with a given server. Connector properties deal with the reply-respond protocol: How are errors handled? How are client-server interactions set up and taken down? Are there sessions? How are servers located? What kinds of middleware, if any, are relied upon?
|
4.4.3 What the Client-Server Style Is For and What It's Not For
The client-server style presents a system view that decouples clients applications from the services they use. This style supports system understanding by separating out common services. The grouping of functionality in this style provides a useful basis for deploying the system to the hardware platform or for interoperating with services on legacy systems. The partitioning of functionality into clients and servers allows them to be independently assigned to tiers, thereby supporting performance scalability and reliability.
Client-server system analyses include determining whether the system's server provides the client-required services and whether clients use the services appropriately, such as respecting ordering constraints on service invocations. Other analyses include those for dependability�for example, to understand whether a system can recover from a service failure; security�for example, to determine whether information provided by servers is limited to clients with the appropriate privileges; and performance�for example, to determine whether a system's servers can keep up with the volume and rates of anticipated service requests.
4.4.4 Relation to Other Styles
Like many C&C styles, the client-server style decouples producers of services and data from consumers. The client-server style is a generalization of procedure/function/method call found in programming languages. Another style that involves a round-trip form of communication is the peer-to-peer style, but it does not have the asymmetry found in the client-server style.
Section 6.3.5 treats the classic n-tier client-server architecture as an example of a combined style because it usually carries information about deploying the tiers on different processors.
|
Clients and servers are often grouped and deployed to different machines in a distributed environment to form an n-tier hierarchy.
As discussed in Section 2.4.5, layers and tiers in an n-tiered client-server architecture are not the same. Layering is a particular style of the module viewtype; n-tiered client-server is a constrained form of the client-server style of the C&C viewtype. The main difference is that the relation in the former case is allowed-to-use; in the latter case, the interactions are expressed as request-reply connectors. A tiered diagram can be easily confused for a layered diagram when each layer is realized as a tier.
4.4.5 Examples of the Client-Server Style
The World Wide Web is a hypertext-based system that allows clients to access information from servers distributed across the Internet. Clients access the information, written in Hypertext Markup Language (HTML), provided by a Web server using Hypertext Transfer Protocol (HTTP). HTTP is a form of request-reply invocation. HTTP is a stateless protocol; the connection between the client and the server is terminated after each response from the server.
For example, a client making a simple request will ask for an HTML page. The client knows the identity of the server, and uses a uniform resource location (URL) to locate and access the server. The client sends a server a request in the form of a header that specifies the method used for the request and the properties of the client. Client properties include user name, browser, and supported document types. Some of these are communicated in the request so that the server can send the data in a document format that the client understands. The server sends the client a response in the form of a header that specifies the status of the transaction and the type of data to be sent followed by the data.
|
No comments:
Post a Comment