Normas de campo 1 Aislación

For every application, there are requirements and expectations that the client must meet, constrained by the environment in which the client needs to operate. Some of the considerations guiding our choice of client are: Is the client intended to be used over the Internet, or within a company intranet? Will it present its user interface through a Web browser or a stand-alone application? What host platforms must the client work on? This section identifies the constraints to consider when choosing a client. For each specific enterprise application, some constraints are more important than others. There are also a number of choices rather than constraints the developer needs to keep in mind. This section considers the effect of various operating envi- ronment, deployment, and implementation constraints.

3.1.1

Operating Environment

Whether the client will be deployed inside a company intranet or in the Internet determines many aspects of the client.

Intranets are usually managed environments, with higher quality network service and less variance than the Internet. Virtual private networks (VPNs) and extranets have characteristics that are a hybrid of Internet and intranet characteris- tics. A VPN is comparable to an intranet in terms of confidentiality and firewall concerns, but it is like the Internet when it comes to quality of network service.

Applications designed for the Internet typically take a lowest-common- denominator approach to the client. In other words, the client must work accept- ably over the slowest link and assume only a minimal set of platform capabilities. Clients intended to be deployed on a company intranet may differ significantly from those destined for the Internet. Within an intranet, it is possible to force stan- dardization to some extent. This means less variance and possibly a higher common denominator.

This section considers the effect of operating environment on the level of network service, and security requirements and constraints.

3.1.1.1 Network Service

Clients working across local area networks in a company’s intranet typically enjoy a high level of network service. Bandwidths of the order of multiple megabits/sec. are available, and latency is negligible, often less than 25 milliseconds. On the other hand, clients on the Internet can expect lower levels of service. Moreover, there is a wide variance in network quality of service across Internet clients. While some

REQUIREMENTS AND CONSTRAINTS 51

clients are connected across dialup telephone lines, others could be connected over cable modems, DSL, or better services.

Network service plays an important role in the design of any distributed appli- cation. Let’s look at two key network characteristics—bandwidth and latency— and see how they affect the choice of what type of client to use.

Highly interactive applications place greater demands on network bandwidth and well as latency. Low bandwidth requires settling for a less interactive inter- face. Or, it may be necessary to move portions of the presentation responsibilities to the client; this, coupled with some form of caching of the data, could yield acceptable response times. Clients such as applets and application clients that can take over presentation responsibilities, may be better adapted to work in low band- width situations.

Consider a browser-based client that displays a hierarchy of information as a tree, for example, a navigational menu or a list of mail folders. If the network is fast, it may be acceptable to make a request to the server every time the user selects a node to see a list of the node’s children. The server then dynamically generates a new screen reflecting the expanded node. However, if the network is slow, a better approach might be to have the client cache the node hierarchy. 3.1.1.2 Security and Firewalls

The Internet and intranets have different security constraints.

Clients that work within the intranet usually do not have to worry about fire- walls between the client and the server. However, clients that need to connect over the Internet must be designed to be able to talk to servers that are often behind firewalls. The presence of a firewall limits the possible choices for protocols that the client can use. With the prevalence of the World Wide Web, most firewalls are configured to allow HTTP and HTTPS protocols to pass across. Firewalls config- ured to allow IIOP communications are not widespread. And even when a corpo- ration allows IIOP to pass through, the details of configuring firewalls for this purpose may not be widely understood.1

Within an intranet, the client and server may be in the same security domain, and can integrate with the environment better in terms of security. For instance, it may be possible to have single signon clients within an enterprise. Over the Inter- net, clients and the server are typically in different security domains. Another aspect of security is confidentiality. While confidentiality is not a concern for a

1

It is possible to configure most firewalls to pass IIOP. However, because this is an excep- tion rather than the rule, most firewall administrators may be wary of doing so.

large category of enterprise information within the corporate intranet, confidenti- ality must be ensured if the communication occurs over the Internet. In this case, its necessary to use a protocol that can ensure confidentiality, such as HTTPS.2

3.1.2

Deployment

The deployment mechanisms available affect the choice of client type. A developer needs to consider:

• The delivery vehicle for the client software • The roll-out and upgrade strategy

• How often the client needs to be upgraded

The bandwidth available to the client plays a role in deciding the client deployment model. For example, some clients such as applets must be down- loaded every time the user establishes a session with the server. In this case, the download must complete in an acceptable amount of time. Thus, when applets are used as part of the client framework, keeping the size of the client small is impor- tant unless the network can be expected to support a large bandwidth.

Web-based clients usually have very little that requires explicit deployment. They therefore work well when the client is changed or upgraded often. By keeping most of the functionality on the server, an application can also use older versions of supporting software on the client.

3.1.3

Implementation

This section considers constraints on the client based on the platform and program- ming language.

3.1.3.1 Platform

The first constraint to consider is whether the client presents its interface in a spe- cific platform, a browser or as a stand-alone Java application, or does the client need to run on multiple hardware and/or software platforms. In the latter case, an enter- prise application developer could take one of two approaches: choose a browser- based client, where the browser software handles platform differences,3 _{or a Java}

2

IIOP can be made to work over SSL connections, although such configurations are not in widespread use.

OVERVIEW OF CLIENT OPTIONS 53

technology-based solution, where the Java runtime environment insulates the client software from the platform.

The computation that can be done on the clients limits some client options. For example, if the client executes in a cell-phone or pager, the server should perform as much computation and data processing as possible and the client should only display the results. Conversely, powerful client platforms may be leveraged for distributed problem-solving. For example, when a financial analysis system runs on a powerful desktop platform, it might make sense to off-load complex financial-projection computation to the client.

3.1.3.2 Programming Language

The choice of implementation language is usually governed by non-technical factors such as the availability of expertise and the desire to integrate with other legacy application clients. If you already have a client that integrates services from several enterprise applications that you are extending to add this new service you might use a language, such as Visual Basic, C++, or another language, that does not integrate with the J2EE platform as seamlessly as Java.