Resources

• Products & Solutions
• System Requirements
• Samples
• Install Center
• Third-Party Software Reference
• Documentation
  • What's New in SAS
  • Product Index A-Z
  • SAS Viya
  • SAS 9.4
  • SAS 9.3 and Earlier
• Papers
• Focus Areas

SAS^® AppDev Studio 3.0 Developer's Site

Middleware Server: Learning About MWS

• Middleware Server Overview
• Using Middleware Server
• Working with User Profiles
• Client Deployment Issues
• Debugging Middleware Server

Middleware Server Features

Understanding the Middleware Server (MWS) features can help you determine if and when you need to use MWS. Some features are enabled automatically, while others require that you provide information through a properties file or user profile. For information on properties files, see Using Middleware Server.

Load Balancing

the process of assigning clients to SAS sessions as clients connect to MWS. In most cases, these SAS sessions will be funneled. Load balancing behavior is modified by the rollover policy that is selected.

Rollover

the act of starting a new SAS session or using an existing SAS session. Rollovers occur to satisfy load balancing. You can customize when rollovers occur in order to balance the loads that any one SAS session (server) handles.

Connection Caching

the process of caching a SAS session that currently has no client connections. The cached session can then be used again when a new SAS session is required without incurring the startup time associated with a new SAS session. You can specify the amount of time that a session remains cached before it is terminated.

User Profile Values

the process of creating profiles that define unique MWS settings for specific MWS users. Once a user profile is created, it can be specified when using MWS to simplify configuration.

Preloading

the process of starting a SAS session (or SAS sessions) before the session is actually needed. This feature saves time when your application, applet, JavaServer Page, or servlet needs to connect to data using MWS. Preloading configuration is specified through User Profiles.

Gateway Access

the process by which MWS overcomes applet security restrictions when your Web server and SAS server reside on two separate machines. The traditional Java security model, known as the Sandbox model, only allows unsigned code (such as applets downloaded from a Web server) to access the machine from which the applet was downloaded (such as the Web server). Gateway Access alleviates this problem by placing MWS on the Web server. Any applet request is forwarded to MWS, which, in turn, communicates with the SAS server as needed. Because the applet does not directly communicate with the SAS server, the applet host security restriction is avoided.

Determining When to Use MWS

It is a good idea to use MWS if you want to

• reduce server resources
• reduce client start-up time
• bypass applet security restrictions that can occur when your Web server and SAS server reside on different machines.

Before you use MWS, you might want to consider the following potential disadvantages:

Time Versus Space

With MWS, the amount of space that is gained on the server is offset by a potential decrease in performance because each SAS session can handle only one client request at a time. Simultaneous requests from multiple clients are queued. If multiple threads of a single-client process send overlapping requests (for example, when a second request is sent before the first request finishes), the second request is ignored.

If you have too many SAS sessions available (that is, one or only a few clients per session before a new session is started), then there is no transaction waiting time. However,

• each SAS session requires about 10MB of space to load
• it takes time to start new SAS sessions, so clients may experience a delay (once a session has started, there is little delay for transactions).

If you have too few SAS sessions available (that is, many clients on a session before another session starts), then there are fewer resources required. However,

• each client must wait for the previous transaction to end before it can proceed
• scalability becomes an issue if many clients are making calls to the MWS.

There is no right or wrong solution. You must determine if processing time is more important than space efficiency in order to select the number of SAS sessions that you would like to make available.

Memory

MWS uses memory commensurate with the number of concurrent sessions that it is managing. The amount of memory used increases as the number of MWS clients increases.

By default, the Java Virtual Machine only provides 32MB of memory. If the MWS requires additional memory to support the number of clients, start the MWS using the -Xmx option to resize the Java heap. For example, if you use -Xmx128M, then the Java Virtual Machine uses a maximum heap size of 128MB. This larger heap size enables MWS to support more concurrent clients.

For more information on sizing MWS, see MWS and Memory Usage: an Example.

Performance Degradation Due to Client Synchronization

As the number of clients increases for each SAS session, the probability of a given client waiting for other clients to finish work increases. SAS is a single-threaded server. Because of this, MWS maintains a single connection to the SAS session. MWS gives the connection object to the first client that requests SAS processing. That client holds the connection until SAS finishes processing the request. When the client request is complete (SAS finishes processing and returns the results), the connection is returned to MWS.

If MWS receives request from other clients while a particular client is using the connection, MWS queues the request (or requests) until the first client's request is complete. However, if the client holding the connection makes another request before its first request is complete, MWS does not queue this request and it is passed through the connection to SAS. Since SAS is single threaded, the best outcome of such and "overlapping" request is that it is ignored. It is strongly recommended that you write clients in such a way as to not allow overlapping requests from a single client.

Long-running SAS requests will block all other client requests until they are complete. The best client performance will be realized by applications that do not make unnecessary remote requests. Keeping remote requests short will improve responsiveness for all clients currently connected and making requests.

Understanding How MWS is Launched

When you start MWS using a menu path (such as Start Programs SAS AppDev Studio Services SAS AppDev Studio Middleware Server), a launcher program (launcher.exe) is actually being called. Launcher programs use a configuration file to pass parameters to the Java Virtual Machine. Launcher program configuration files include one parameter per line. If the line begins with a hyphen, then the parameter is an argument.

In the case of MWS, the launcher program uses a configuration file named MiddleWare.cfg. This file is typically available in \install-directory\Java\SAS (where install-directory is the directory in which AppDev Studio was installed).

The first argument in the MiddleWare.cfg file specifies the command that invokes MWS.

The MiddleWare.cfg file also includes an argument that specifies the location of the RocfORB.properties file. The RocfORB.properties file specifies the parameters that MWS should use when it is started. For more information on the RocfORB.properties file, see Using Middleware Server.

Finally, the MiddleWare.cfg file includes an argument that specifies the directory that the MWS Class Loader should scan for JAR or class files. For more information about the MWS Class Loader, see Client Deployment Issues.