Web Services

 

Web Services has enabled a new generation of Internet based applications. These services support application to application internet communication. In other words applications at different network locations can be integrated to a function as if they were part of a single large software system via distributing technologies.

The Online Golf Handicapping system is an example of an application made possible by Web services. This Web Services includes an automated data collection system from the USGA (business to business transaction) and vice versa [req-6], as well as allowing for communication with non-browser desktop and handheld device access. This allows a user to calculate their golf handicap as well as retrieve previously stored information.

The basis of our Web Service will be utilizing SOAP requests to retrieve the data from the USGA interface. What is a SOAP message? It is a remote method invocator that allows a distributed application (Online Golf Handicapping server) to invoke a particular function on another distributed application (USGA server) or even remotely [req-1]. In our case we will generate a request to retrieve any changes or new updates from USGA server.

Part of our requirements within our web service is to utilizes the "USGA.WSDL" that will generate stubbed out code when used with a wizard tool (i.e. if we are using java as our programming language of choice then we would use castor). Once the stubbed out code is generated we can then start invoking the USGA web service.

Our Web Service will invoke a request out to the USGA Web Service nightly at a low peak time for the service. Once the data is retrieved we are going to use the Pipe and filter approach via a singleton pattern.

Being that the data from USGA is being streamed in and no user actions are required to complete this task a pipe filter approach would be ideal. A [singleton] [2] design pattern will be used to update course and handicapping algorithm. This will be implemented via a trigger which is a procedure that is executed when a particular data activity occurs. This in turn will fire a stored procedure that kicks off the update.

Within the store procedure there will be some algorithms for handicap differential [req-3]. It is computed from four elements:

  • Adjusted gross score
  • USGA Course Rating
  • USGA Slope Rating
  • 113 (the Slope Rating of a course of standard difficulty).

To determine the handicap differential, subtract the USGA Course Rating from the adjusted gross score; multiply the difference by 113; then divide the resulting number by the USGA Slope Rating. Round the final number to the nearest tenth.

Handicap Differential = (Adjusted Gross Score - USGA Course Rating) x 113 / USGA Slope Rating.

When the adjusted gross score is higher than the USGA Course Rating, the handicap differential is a positive number. Following is an example for determining a differential using an adjusted gross score of 95 made on a course with a USGA Course Rating of 71.5 and a USGA Slope Rating of 125:

Adjusted Gross Score - USGA Course Rating:

 

95 - 71.5 = 23.5

Difference x Standard Slope:

 

23.5 x 113 = 2655.5

Result / USGA Slope Rating:

 

2655.5 / 125 = 21.24

Handicap Differential (rounded):

 

21.2

When the adjusted gross score is lower than the USGA Course Rating, the handicap differential is a negative number. Following is an example for determining a differential using an adjusted gross score of 69 made on a course with a USGA Course Rating of 71.5 and a USGA Slope Rating of 125:

Adjusted Gross Score - USGA Course Rating:

 

69 - 71.5 = -2.5

Difference x Standard Slope:

 

-2.5 x 113 = -282.5

Result / USGA Slope Rating:

 

-282.5 / 125 = -2.26

Handicap Differential (rounded):

 

-2.3

These are a few algorithms you can find off the USGA Handicap rules by the United States Golf Association (USGA).

In the pipe-and-filter solution each component has a set of inputs and outputs. A component, termed filter, reads input streams of data, applies a local transformation and produces the output streams of data incrementally. Each connector, termed pipes, serving as conduits for the streams, transforms outputs of one filter to inputs of another.

      I.      Advantages

  •  Process independence algorithm can be changed individually without affecting others. As well as the data representation can be easily changed individually.
  •   Modification on one module can be done without affecting others.
  •  Any two filters can be hooked together as long as the data that is being transmitted between them had been agreed upon.
  •  High transparency overall input/output behavior of a system as a simple composition of the behavior of the individual filters.

  II.      Disadvantages

  •       Performance hits with data replication and space.
  •       This architecture is suitable for layered system.
  •       It dose not support interactive applications.

Design Rationale

This architecture has quite a few advantages process independence algorithm can be changed individually without affecting others [req-3]. As well as the data representation can be easily changed individually. There is high transparency overall input/output behavior of a system as a simple composition of the behavior of the individual filters. Modification on one module can be done without affecting others. Any two filters can be hooked together as long as the data that is being transmitted between them had been agreed upon.

The pipe-and-filter guarantees the delivery of information by the web service prior to processing any new transactions [req-1 ]. When using a web service infrastructure we not only leverage the WSDL file from the USGA service we can also generate our own WSDL file and schemas to allow affiliated organizations to interact with our API [req-6]. Being able to interact with the USGA services gives us the ability to register new users with them [req-2].

Back to main page