Sticky Web Services

With a Web Service, successive requests can be handled by any member of the Services Pool, that is any fglrun process that has been started to service those web service requests.  Web Service code should therefore be stateless so that each request is independent of other requests.  This means you should not have any modular or global variable influencing the result, and you should have no sequential or scrollable cursors left open after each request.

What if you wanted a web service to return one row of the database cursor to a calling program, the user in the calling program then clicks something like Next , and to then call the same web service returning the next row from the database cursor?  If its a scrollable cursor you might want to allow the user to click something like Previous and fetch the previous row from the database cursor.  This means you need the same fglrun process to be called by consecutive requests.

By adding an attribute (mode=”sticky”) to a web service .xcf, we can signify that the web service is a Sticky Web Service.  This means that successive requests from the same user agent will be handled by the same fglrun process, and no other user agent will be serviced by that fglrun process.  The fglrun process will be reserved for the exclusive use of that User Agent.

Some things to be aware of when configuring  a sticky web service.

• The POOL element is ignored.  There is no maximum number of requests that will be opened.
• You are responsible for closing the session.  You might have a lower than normal KEEP_ALIVE so that the fglrun process does not hang around for a long time.
• When the fglrun process is waiting to receive the next response it will be consuming a user license.  If you have a Genero front-end it will also be consuming a user license.

When returning multiple rows of data via a web service and then having the user view these rows, there are three broad techniques you can use.  Two techniques do not involve a sticky web service, whilst the third does.

• The most simplest, you can return all rows in a single request and populate an array.  The user can then view the array as they choose without having to wait for data to be fetched.
• You can use one request to return all the primary keys.  Then as the user navigates the array you can use a different request that has an OPEN and a FETCH to fetch the data for each row passing the primary key to indicate what row of data to fetch.  Compared to the previous technique, this is faster to retrieve the first row but is slower as the user navigates the array.  Both this technique and the one above do not require a sticky web service.
• The technique involving a sticky web service, the first request has a DECLARE and OPEN to create and populate the database cursor.  Subsequent requests FETCH the appropriate row of data using the same database cursor.  There should be a last request to CLOSE the cursor and shut down the web service.

Which technique you choose is upto you.  How many rows of data are being returned versus how many are being viewed.  You will be balancing speed to return first row, speed to return each row.  What if values change on the database as you go.  License Count.

It is rare to use a Sticky Web Service but the functionality does exist.  It can allow you to write two tightly coupled programs that operate on two seperate servers that communicate with each other using web service technologies.