This chapter describes basic hardware configurations for the SilverStream Server and explains how the server operates in the Web environment. It contains sections on:
HTTP server configurations differ according to the server environment. This section describes the recommended SilverStream configurations for the production and development environments. For simplicity, the descriptions assume a single (standalone) SilverStream Server.
In a production environment, it is best to configure your SilverStream Server and database server(s) on separate machines. (This is called a multiple-host configuration.) The figure that follows shows the preferred SilverStream Server configuration. This example shows two database server connections.
The SilverMaster database (shown with the SilverStream Server in the figure) is a master database catalog for the entire system, and is created when SilverStream is installed. For a description of the SilverMaster, see The SilverMaster database catalog.
NOTE Having another Web server in this configuration would have little impact on the SilverStream Server. SilverStream can coexist with Web servers, as long as you change SilverStream's listening port from the default port 80 to another port. For more information, see Specifying general server properties.
Configuring the SilverStream Server and database servers on separate machines results in the following benefits.
One drawback to configuring SilverStream Servers and database servers on separate machines is that you must maintain extra machines.
For more detailed information about possible configurations for your production SilverStream environment, see
Network configurations.
You can set up your development environment using multiple independent development environments (the preferred configuration) or using a shared development environment.
In a multi-developer environment, it is best for each developer to have a SilverStream Server and Designer client running on his or her own machine (therefore, each development environment is independent). Ideally each developer would also have a standalone database on their machine (such as Sybase Adaptive Server Anywhere, available as an installation option in the Developer Edition) or their own user account in the database, so that each server can store its own version of the design data. In addition, you should install a source control system to ensure that changes made by developers are not overwritten by other developers.
Preferred development environment
The following figure shows the preferred development environment configuration. In this configuration, each designer communicates with the source control system, while user data (that is, the data used by the application) is accessed from a separate machine.
The chief benefit of configuring one SilverStream Server for each Designer is that each developer can have a sandbox environment, that is, a space to develop, test, and build applications independently. A developer is not affected by changes made by other developers on a shared server, until that developer chooses to get those changes from source control.
You would implement such an environment by installing a Developer Edition on each developer's workstation.
A variation of this configuration is to have on each developer's workstation a standalone database containing the user data; this database matches the production database. This configuration gives each developer a completely independent sandbox environment. But this configuration is not always practical. Sometimes it is not possible to maintain a copy of the production database on a developer's workstation.
For a description of a development environment coexisting with a production environment, see
Group development configuration.
In a shared development environment, two or more SilverStream Designers share a single SilverStream Server. The database might exist on the same machine as the server, one of the Designers, or (more commonly) on a separate machine. The single-host configuration is typically used when you are developing an application in a small group, if it is impractical for each developer to have their own database access, or if you do not plan to use source control.
In this configuration, there is no sandbox environment, which means that developers cannot necessarily rely on independent application development. Also, debugging a shared server causes the entire server process to be interrupted for all developers.
To implement this type of environment, you would install a Developer Edition on each developer's workstation (using a Designer-only install) and a Workgroup or Enterprise Edition server on another machine. Each developer would access the Workgroup or Enterprise Edition server.
In a typical large-scale Web environment, a static traffic routing service is placed between the network service provider's router and the internal network. The traffic routing service may be implemented at an IP level using screening rules in a router, or at an application level, using proxy gateways and services.
About proxy servers
A proxy server is an application that mediates traffic between a protected network and the Internet. Proxy servers are used primarily to consolidate Internet connections, provide users a general level of anonymity (by shielding information normally passed from the browser to the Web server), and enforce enhanced security about Web traffic (for example, what sites users can access).
Many proxies contain extra logging or support for user authentication. Since proxies must understand the application protocol being used, they can also implement protocol-specific security. The proxy machine provides a higher level of audit and security, but it also increases configuration costs and reduces the level of service, because a proxy needs to be developed for each desired service.
NOTE The proxy server software you use with the SilverStream Server should support HTTP 1.1, such as the Microsoft Proxy Server or Netscape Proxy Server.
About firewalls
A firewall is a hardware or software facility used to regulate access to a network. Firewalls are traditionally used to protect the company's intranet from the public Internet traffic. Policies are configured on the firewall to allow only certain traffic to pass through. The actual mechanism involved varies, but in principle, the firewall can be thought of as two mechanisms, one that exists to block traffic and another that exists to permit traffic. Administrators can configure a firewall to notify them of security breaches and monitor overall traffic.
The SilverStream Server should run inside any firewalls your site has, with the HTTP requests from extranet customers to the SilverStream Server either allowed through the firewall or proxied. This way, the database connections need not go through the firewall. The next figure shows how a SilverStream Server might be configured with a firewall and proxy server.
This section presents several possible ways to configure your network, based on your application's needs.
Small companies, departments, and small teams of developers can work against a single SilverStream Server. The following figure shows a simple network configuration with the SilverStream Server (agsrv1) hosting a simple Web application serving users on a local area network. The application server leverages an existing Windows NT security domain (on pdc1) and e-mail server (mailsrv1) for user authentication/access control and pushing application data to users via e-mail.
The SilverStream Server maintains its master catalog, SilverMaster, in the database server (dbsrv1) where the line-of-business database resides. The application database also resides on the database server.
When this configuration makes sense
This type of configuration is suitable when:
Benefits of this configuration
This configuration has several benefits:
Limitations of this configuration
While this configuration may be suitable for small companies or departmental applications, there are some limitations to this approach:
In order to provide basic load balancing and failover capabilities, the SilverStream Server provides a Dispatcher, Load Manager, and Cache Manager. The following figure shows a typical network diagram of several SilverStream Servers (agsrv1, agsrv2, and agsrv3) in a cluster with traffic directed by the SilverStream Dispatcher (dispatch1). The Cache Manager and Load Manager can reside on virtually any machine in the network, though it is preferable to have them on the same physical subnet as the cluster of SilverStream servers (agsrv1 and agsrv3, for example).
In this scenario, a browser on one of the corporate workstations would access the application by connecting to the dispatcher (dispatch1) using the Web browser or SilverJRunner. Depending on the load plan, the dispatcher would reply with an HTTP redirection to one of the available servers in the cluster.
In order to establish a connection, the client needs to resolve the TCP/IP host name of the target server using standard means. On Windows workstations, for example, the client would request the TCP/IP address of the target server from the WINS (Windows Internet Naming Service) or DNS (Domain Naming Service) Server, or perform a NBT (NetBIOS over TCP/IP) broadcast to resolve the name and address. Once resolved, the client will then access the server directly. No subsequent trips to the dispatcher would be made.
HTML application example
A corporate user opens a browser to http://dispatch1/Accounting/default.html in order to log into the company's accounting HTML application. The SilverStream Dispatcher (dispatch1) returns an HTTP redirect signal back to the client, which in turn establishes a connection directly to http://agsrv2/Accounting/default.html. Notice that not only was the browser redirected to the SilverStream Server (agsrv2), the full URL address information (database name, Accounting, and page name) was also passed along.
The next user to access the application would be directed in a round-robin fashion to the next available server according to the load plan: http://dispatch1/Accounting/default.html would be redirected to http://agsrv3/Accounting/default.html.
Java client example
A Windows NT workstation launches SilverJRunner with the three parameters dispatch1 Accounting fmMain. Once connected to the dispatcher, SilverJRunner's session is then redirected to agsrv1 Accounting fmMain, according to the load balance plan. Like the previous example, the next user would also be automatically redirected to the next available server, agsrv3 Accounting fmMain.
Benefits of this configuration
This configuration has several benefits:
Also, there's no additional hardware or software (such as a third-party dispatcher or firewall) required to install and maintain this configuration.
Limitations of this configuration
This configuration does have limitations:
To learn more
For more information about clusters and load balancing, see Administering a Cluster.
The following figure shows how a single SilverStream Server can be used to provide Extranet Web application functionality for both internal users (running a Java application using SilverJRunner) and business partners outside a company accessing the HTML application over the Internet.
In this scenario, the SilverStream Server (agsrv1) provides Web application services in conjunction with existing static content served from the corporate Web site servers (www1 and www2). The SilverStream Server (agsrv1) is DNS-registered, so when an Extranet user is linked from the Web site to the application logon page (hosted on the SilverStream Server), the browser knows what route to take in order to connect to the SilverStream Server. In this case, Internet clients must pass through the firewall (gatekeeper1) in order to gain access to the SilverStream Server.
To facilitate this connection, the firewall (gatekeeper1) has been configured so that only HTTP traffic on TCP/IP port 80 can pass through only to the SilverStream Server. This way, system administrators are assured that the application-sensitive data will not be interpreted unknowingly by someone other than the end user, and that incoming traffic cannot access other corporate resources.
The user accesses the application from a link on the corporate Web site (www1 and www2). SilverJunction has been installed and configured on both Web servers and offers redirection capabilities to the logon page on agsrv1. Once redirected, browsers that support HTTP 1.1 will establish a connection to the SilverStream Server.
This process can be summarized as follows:
For user authentication, upon connecting through the firewall to the SilverStream Server (agsrv1), the user is prompted to log on to the application. A listing of Extranet users is maintained in the server's master catalog, the SilverMaster database. This database, like the database serving the e-commerce application, is maintained on dbsrv1. The user enters the logon credentials and is logged onto and can commence using the application.
Internal to the company, corporate users interact with Extranet users using a Java application that runs on Windows NT workstations and SilverJRunner. For administrative and development purposes, corporate IT uses the SilverStream Management Console and SilverStream Designer on HTTP port 80.
Benefits of this configuration
This configuration has several benefits:
Limitations of this configuration
This configuration has the following limitation:
To learn more
For more information about SilverJunction, see Integrating with existing Web servers.
Usually larger-scale e-commerce applications require a very high degree of functionality, throughput, and availability. This requires an underlying system architecture that is more robust and complex than those previously shown.
The following figure shows an example of a large-scale Internet application, served from a cluster of SilverStream Servers. Internet users access the application using links from the two Web servers (www1 and www2) located outside the firewall (gatekeeper1).
In order to implement transparent session-level failover and reduce overall DNS and firewall administration, the systems administrators install a third-party hardware dispatcher that supports DNS masking, as opposed to using SilverStream Dispatchers. This way, traffic to all SilverStream Servers can be localized to a single TCP/IP address and host name on the Intranet (www3). In addition, with this type of device, only one TCP/IP address and host name have to be DNS registered, as opposed to four machines using the SilverStream Dispatcher (dispatch1, agsrv1, agsrv2, and agsrv3).
When any incoming requests are linked to the Web application itself (on www3) the browser establishes a connection through the firewall to the Web dispatcher. Based on its own load plan, the dispatcher connects the browser to an available server in the cluster. Unlike the SilverStream Dispatcher, the hardware dispatcher controls the flow of all HTTP traffic. In the event that the server goes down, the dispatcher can automatically route the browser session to a different server in the cluster.
Since the dispatcher uses DNS masking, the failure was completely transparent to the end user.
To learn more
For more information about clusters and load balancing, see Administering a Cluster.
The complexity of Internet security and network infrastructure is often related to the size of a company. Larger companies with complex e-commerce Internet and Extranet applications, for example, may have a two-tiered approach to firewall security.
The following figure shows such an example. All Internet traffic is routed through an Internet firewall (gatekeeper1). This firewall allows only Web traffic and Internet mail through to the Demilitarized Zone (DMZ). All Web and application servers reside in the DMZ for security purposes.
It would have been possible to add a third network card to the firewall and have it protect Intranet traffic as well. However, for security reasons, this company decided to use separate devices.
DNS masking hardware dispatchers (www and apps) are used to route traffic in a load-balanced fashion. It is also possible to use one device configured for multiple TCP/IP addresses and route traffic to both clusters. However for redundancy purposes, two separate devices are used.
The Intranet firewall (gatekeeper2) allows e-mail traffic and database connections from the SilverStream Servers (agsrv1 and agsrv2) to pass through. This way, the system administrators can be assured that only e-mail traffic and database calls from the secured DMZ (the SilverStream Servers) can access corporate information.
External users can be authenticated by obtaining a browser certificate from the certificate server (cert1). The SilverStream Servers can authenticate these users based on their certificates and encrypt the network traffic from the browser to the application server.
Finally, since there are separate development and deployment environments, business logic has been completely secured in two ways: First, the Java classes that make up the business logic have been published from the development to the deployment environments without source code. This is an option developers can use when moving code from one environment to another. Second, security has been placed on the database itself, such that only authorized Intranet users can overwrite or delete the application objects stored in the database.
Benefits of this configuration
This configuration is beneficial where there are the following requirements:
This architecture is complex and more difficult to maintain than the average Intranet site. However, you might want to set up this type of architecture to ensure the benefits listed above. Downtime often equates to loss of business. Maintaining a well-designed network infrastructure often pays for itself very quickly.
To learn more
For more information about clusters and load balancing, see Administering a Cluster.
The following figure shows two separate SilverStream environments:
Here, each developer (wksta1 and wksta2) uses a SilverStream Developer Edition (SDE), which includes a single-user SilverStream Server, the SilverStream Designer and standalone database. Using the SDE, each developer has a complete development environment to work on. For source management, each SDE user checks changes to the application source code in and out of a common source control server (source1). For pre-deployment functional and stress testing, a group development server (agdev1) has been configured.
All application source code is stored in the database (located on the local database for each SDE or accessed from the agdev1 server). Application code can also be stored and tracked in the source management server (source1). From a developer workstation one can check in changes to code, view history for application objects, and revert to previous versions of application objects.
This section provides an overview of the HTTP communications protocol, describing in some detail how clients communicate with the SilverStream Server. It is provided for background information.
SilverStream clients access server objects through HTTP Uniform Resource Locators (URLs) (except in the case of clients accessing Enterprise JavaBeans or some non-SilverStream clients, which use RMI). The accessed object (resource) can be of any type, from a static HTML page to an executable program. Resources that have URLs can be located and served to browsers regardless of the resource type. URLs are used to obtain information or to place information at a specific location. A URL is composed of four parts:
http:
//silverstream
//Javasoft.com:80
http://silverstream.com/products/updates.html
http://java.sun.com:80/doc/tutorial.html
What is a resource?
A resource is a network data object or service that can be identified by a URL. Resources provide an object-oriented mechanism for extending SilverStream Server behavior. A SilverStream resource consists of the following parts:
Where resource information is stored
Resource information is stored in two SilverStream system tables:
For more information, see
SilverStream System Tables and URLs.
HTTP is a request/response protocol used for communications between clients and servers on the Web. The client sends a request to the server. The target server responds to the client only after it receives a request.
HTTP 1.1 uses persistent connections as the default. This means that the client and server maintain connections and send their responses and requests back and forth until the connection is explicitly closed.
Request components
The client request has five components:
http://localhost/employee/active.html?query=month%30"april"
Response components
The server response has the following components:
SilverStream constructs many of the HTTP components for you automatically. For example, when a SilverStream form requests data from the database, SilverStream constructs the URL for the database resource and submits a GET request to the SilverStream Server. The SilverStream Server then locates the data and returns it to the requesting form.
For more information about the HTTP protocol, see the Programmer's Guide.
The three general types of HTTP request-response communication scenarios are summarized in this section.
This is the simplest and most common scenario in a developer environment.
This scenario is often used with firewalls where the local-area network is isolated from the Internet. A client makes a request to the proxy, then the proxy makes a request to the server on behalf of the client. The server relays to the proxy and the proxy relays to the client.
Another approach is to use an intermediate caching agent instead of a proxy. (Most proxy agents are also caching agents.) The caching agent tries to serve the request through its internal cache of resources before it forwards the request. The cache itself saves any response it receives, if appropriate. This shortens the response chain, improves response time, and reduces network load.
In this scenario, a tunnel blindly funnels requests and responses between two HTTP applications. Unlike a proxy, a tunnel does nothing with the requests and is often used for communications over non-TCP/IP links.
SilverStream stores information about each client connections in a session object. A session is initiated when a client first connects to the server. Information in the session object includes user authentication, SilverStream download information, and database access activity. SilverStream applications can also store application-specific data in the session object.
Sessions are managed by the server and span client connections. Consequently, a browser session can have sequential TCP/IP connections with a single SilverStream session. In addition, if the session requires user authentication for secure data, the authentication can be done once per active session.
Authentication is the process through which the server and client verify one another's identities. Authentication is described in Enabling authentication.
A SilverStream session remains active as long as the page contains a Java form or view. HTML pages that do not contain Java objects are subject to a time-out after five minutes by default.
SilverStream sessions rely on cookies to track sessions. A cookie is a piece of information sent by a Web server to a Web browser. The browser saves this information and sends it back to the server whenever an additional request is made to the server.
SilverStream uses the cookie as a session ID. When the SilverStream Server receives a request from a browser that includes a cookie, the server is able to use the information stored in the cookie to reconnect with the session.
SilverStream Server cookies are kept in memory and are never written to disk. There is no personal user or tracking information in the cookie.
NOTE If you or your users are concerned about the contents of cookies, you can turn on warn on cookies in your browser. See your browser documentation for details.
This section introduces some of the key features of the SilverStream Application Server.
The SilverStream Designer client allows developers to build robust applications for the Web. Once the application has been deployed, you need to monitor the client connections.
Like database connections, the TCP/IP connections between clients and the SilverStream Server are a limited resource. The server tries to keep idle connections open for a while, on the chance that an idle connection will soon be used again. However this activity imposes a limit on the number of simultaneous open connections that can be supported. The server uses a tunable algorithm to decide what to do when a new connection is established or when an active connection goes idle.
Using the SilverStream Management Console, you can modify several client connection parameters to tune server performance. For more information, see Managing client connections.
SilverStream supports the Java Servlet API. Servlets were designed to extend the functionality of a Java Web server. They are equivalent in functionality to CGI, Microsoft's ISAPI, and Netscape's NSAPI, except that servlet programming is done in Java.
A servlet "owns" one or more URLs and is invoked in response to HTTP requests on its URLs. A servlet is passed an HTTP request, and then responds with a complete HTTP reply, which may include data in any appropriate format.
Servlets can extend a Web server's functionality in the same way that CGI scripts do. However servlets are far less resource-intensive than CGI scripts, and since servlets are written entirely in Java, they work across platforms.
NOTE Pages developed in the SilverStream Page Designer are actually servlets.
SilverStream developers can write servlets using the SilverStream API.
For more information about servlets, see the Programmer's Guide.
SilverStream applications can be presented in several ways. The SilverStream Server manages the presentation. Applications can use any of the following presentations:
Your audience or application design might require an extra thin client without the overhead of downloading Java classes. When you use SilverStream dynamic pages, the SilverStream Server retrieves and maintains the data. Multiple users do not share the data, and the server manages any concurrent access.
For more information, see the Programmer's Guide.
A Java presentation page is a page template with presentation references. For example, an HTML page with a SilverStream Java form on it is a Java presentation. The URL of the presentation is actually embedded in the page as a reference. This means that all the containing pages can remain the same even though the presentation may change.
You can also run Java applications standalone, using the SilverJRunner or non-SilverStream clients.
For more information, see the Programmer's Guide.
