# Designing and Implementing Weather Generators as Web Services
## 3 Design and Implementation
### Web Service Server
#### 3.3.3 Weather Realization Sharing Service  
The core weather generation service described in the previous section responds to user's individual requests. The weather realizations generated differ each time even the requesting parameters are the same as it uses a stochastic method. When several applications are serving to multiple users in common regions, they need to use same weather realizations. Thus we implemented a novel mechanism which multiple users can share the same set of weather realizations. The mechanism provides weather realizations under normal forecast condition as the seasonal forecast scenarios vary according to individual user's needs. In order to give maximum interoperability, the weather realizations are encoded to O & M documents. Weather realization scenarios by SOS (WSc SOS) and Intermediate Weather Generator (IWG) are stacked to serve sharing of weather realizations. WSc SOS is for caching weather realizations and providing them through SOS. Based on specific location of user request, IWG searches for weather realizations that has been archived in WSc SOS Server. If none of weather realization in WSc SOS matches the request, weather generation service will be called for \begin{table}
\begin{tabular}{c c c} \hline \hline \multirow{2}{*}{**Service Endpoint**} & [[http://ec2-52-69-188-223.ap-northeast-1.compute.amazonaws.com](http://ec2-52-69-188-223.ap-northeast-1.compute.amazonaws.com)]([http://ec2-52-69-188-223.ap-northeast-1.compute.amazonaws.com](http://ec2-52-69-188-223.ap-northeast-1.compute.amazonaws.com)): \\  & 8080/PDISAGWS/rest/generate? \\ \hline
**HTTP GET Parameter** & **Description** & **Example** \\ \hline \multirow{2}{*}{num} & Number of weather realization & If 100 then 100 scenarios of \\  & scenario that client wants to generate & weather realization are generated. \\ \hline \multirow{2}{*}{climateforecast} & Climate forecast scenario in the format & BN33, NN34, AN3 \\  & of BN, NN, AN & BN33, NN34, AN33 \\ \hline \multirow{2}{*}{from} & Starting year and month for & 2016, 1 then weather realization \\  & generating weather realization & will start from the 1 January 2016 \\ \hline \multirow{2}{*}{to} & Ending year and month for generating & 2017, 1 then weather realization \\  & weather realization & will end at 31 January 2017 \\ \hline \multirow{2}{*}{weatherhistory} & Long-term climatological data in & \multirow{2}{*}{Link to the data} \\  & WTD format giving in the URI form & \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Request parameter of the predictWTD service. generating the weather realizations. The generated weather realization will be stored into WSc SOS and returned to the user in in O & M documents. The detail of two services are described as following. * WSc SOS server for caching  
WSc SOS Server archives weather realizations and publish them as SOS. WSc The weather realizations generated by IWG are encoded in O & M document are stored in WSc SOS server. WSc SOS itself is an independent service, thus it is possible for clients to call WSc SOS service as well. The challenge of sharing weather realization on SOS is a unique characteristic of weather realization. Weather realizations have multiple values at a same location, same phenomena and same time, i.e., maximum temperature on 2016, DOY = 1 may have different values in a different realization. Due to this uniqueness, we cannot simply transform them to comply with SOS standard. In order to standardize weather realizations under SOS and make them available online, we introduced a naming rule for describing each scenario of weather realization in order that we can refer to it. * Uniform Resource Name (URN) rule for weather realization scenario  
We utilize URN concept for referring to each weather realization. Furthermore, we use this URN as a filter parameter for offering tag in the getObservation request. The URN of weather realizations needs the format as follows.