I'll like to answer your real question, instead of what you have asked here.
The WMS standard as such, does not talk about tiling, or the size of the images that should be requested. It says that a WMS service should return whatever image, in
whatsoever size that is requested.
What you have seen in OpenLayers, is that by default, it will call for small 256x256 tiles instead of the whole current extent as a single image (this option can be changed when you initialize the layer, in the JavaScript Code.). To understand why this is a good idea, you should understand that rendering the data and creating these images is a computationally intensive task, and it takes both resources as well as time.
If OpenLayers calls for tiles, that has the following benefits:
- If you pan the map , only requests for the tiles in the new area will be made, and the server will be quicker in responding.
- These tiles can be saved in a cache and reused.
- If the map is panned only a little, then there is a good chance that existing tiles would cover that area, and new request need not be made. The code could also request for new tiles in background. All of this gives a much snappier experience to the user.
Now coming to your actual issue. As far as I understand, you want to reduce the load on your server, give a quicker response and at the same time be WMS compliant.
I'll suggest that you look at GeoWebCache.
The geowebcache documentation states:
As most mapping clients render WMS (Web Map Service) data every time they are queried, this can result in unnecessary processing and increased wait times. GeoWebCache optimizes this experience by saving (caching) map images, or tiles, as they are requested, in effect acting as a proxy between client (such as OpenLayers or Google Maps) and server (such as GeoServer, or any WMS-compliant server)
The section on WMS states:
Web Map Service (WMS) is an OGC standard that supports requests such as getcapabilities, getmap and getfeatureinfo. GeoWebCache supports the former two natively and can proxy other requests to the WMS backend server.
So in conclusion, the GWC will create a cache, which can be sent to the user, while at the same time, proxy the getfeatureinfo and other WMS requests to the real WMS server.
Update
How does your client know what request to make? GWC has the concept of gridsets, and if your map is EPSG:4326 or EPSG:3857, there are standard gridsets, and OpenLayers will make requests in that.
This is something which is client specific. If you use any arbitrary client, there is no guarantee that it will use these tiles. A generic WMS client will only make requests for arbitrary extents, and these can't be tiled and cached. It's only when you control both the client and service, can you fully use the functionality of GWC.
Answering your second question. Tiling and WMS services both have pros and cons, and there are still many advantages to a pure WMS service:
- Tiling is useful if you have static data. if you have data which changes then the tiles will have old data, and be of no use.
- A WMS service has many functionailities which cannot be replicated by tiles. For example, I can request for the layers in the map to use a different symbology, which I can specify in the request itself.
- If you have muliple layers published on your WMS server, I can request one or more or any combination of the Layers in the resulting image. This can't be done with the Cached Tiles.
- Tiles should only be used when you have static data, like satellite imagery, or a custom base map which you have developed.
