|
|
This document explains how a request is identified as being a web service request, how the runtime dispatches the request to a service processor that can perform any necessary pre- and post- processing of the request, and finally how this service processor identifies the service handler that will perform the actual business related logic.
This document gives a broad overview of the functionality, not a detailed description of each step. The different steps, and how to perform the setup / develop the necessary functions are described in separate documents.
As such, there are no real differences between web service requests and common web requests.
The real difference is how the requests are handled and what they are used for.
In WebsydianExpress, the common web requests are handled in the following manner:
So a common web request is used in a browser context, where a users interacts with the application (typically pushes buttons/links) - this leads to requests being sent to the application, the application generates HTML, which is used to populate the browser.
A web service request is used in a different context. In many cases, there is no user (or browser) involved in creating the request. In most cases, a web service request contains a file, which is being handled by the application, which then generates another file, which forms the main part of the response returned to the client.
So the steps involved in WebsydianExpress' handling of a web service request is:
The first thing the runtime does when a http request is received is to identify whether it is a web service request or a common web request.
As mentioned, the requests have the same structure and can't be distinguished based on the content alone. On the site settings page in the administration interface, you can specify a URL-extension that will identify that a request is a web service request.
If the site is accessed by this URL:
http://www.websydian.com/site/basicsite
And "service" is specified as the URL-extension, all requests that is targeted to the URL:
http://www.websydian.com/site/basicsite/service
or any extensions of this URL will be handled as web service requests.
The service structure is used to determine how a service request should be handled.
The structure describes which URL extensions of the service URL that targets different service processors, which criteria the service processors use to determine the service handler to call and the valid values of the criteria together with the service handler each value correspond to.
After the request has been identified as being a web service request, the next action the runtime performs is to select a service processor that can perform any pre- and post- processing on the received file and select the custom-developed service handler.
The service processor is identified based on the URL element specified in the service structure.
So for the URL:
http://www.websydian.com/site/basicsite/service/file
"file" is the part of the URL that will be used to identify the service processor to call.
The relation between the URL mask (e.g. "file") and the service processor to call is created on the service structure page in the administration interface.
The runtime identifies the service processor to call using the method described above. But before actually calling the program, a callback point is called. This means that it is possible to create your own functionality for deciding which service processor to call.
All service processors perform three different tasks:
There are three pre-defined service processors. These are delivered as part of the runtime:
The file service processor saves the received data in a file, identifies and calls the handler, retrieves the file containing the response data and returns these data to the client.
The XML service processor receives the data, loads the data using an XML parser, identifies and calls the handler function, extracts the data from the response document and returns these data to the client.
The soap service processor receives the data, loads the data using an XML parser, extracts the body document from the Soap envelope, identifies and calls the handler, wraps the response in a soap envelope, extracts the data containing the soap document and returns it to the client.
For each URL element in the service structure, you must define one or more selection criteria on the service structure page in the administration interface (normally, only one selection criteria will be specified for each URL).
The selection criteria specifies how the service processor can identify the handler to call.
There are three 6 basic selection criteria that can be specified:
For each selection criterion you can specify one or more service handlers together with a value for the selection criterion.
The service processor goes through the criteria that is defined for the URL. For each criterion, the corresponding value is extracted from the request, and it is checked whether a handler is defined for the value.
When the service processor has identified a service handler, the service handler is called.
The handler performs the necessary business logic and returns information about the response to the service processor.
Each service handler is always custom developed for a specific purpose - as they contain the business dependent logic.
After the service handler has finished processing the request, the service processor returns the response data generated by the service handler and returns it to the client.
The following diagram shows the different actions described above:
Background: Service processors
Background: Selection criteria
Background: Understanding the service structure
Online
documentation - WebsydianExpress v3.0