ASA Database Administration Guide
Using the Built-in Web Server
You create web sites by creating services within databases. Services define which URIs are valid and what they do. A single database can define multiple services.
The facilities available through your Adaptive Anywhere web server are defined in databases. Services, created and stored in databases, define which URIs can be used and what they do. A single database can define multiple services. It is possible to define services in different databases so that they appear to be part of a single web site.
Three statements are provided that permit you to create, alter, and delete web services:
CREATE SERVICE
ALTER SERVICE
DELETE SERVICE
The general syntax of the CREATE SERVICE statement is as follows:
CREATE SERVICE service-name TYPE service-type-string [ attributes ] [ AS statement ]
As service names will form part of the URI used to access them, they are flexible in terms of what characters they can contain. In addition to the standard alpha-numeric characters, the following characters are permitted: "-", "_", ".", "!", "*", "'", "(", and ")".
In addition, service names may contain the slash, "/", but some restrictions apply because this character is a standard URI delimiter and affects how Adaptive Server Anywhere interprets your URIs. It cannot be the first character of a service name. In addition, service names cannot contain two consecutive slashes.
The following service types supported:
RAW The result set is sent to the client without any further formatting. You can produce formatted documents, in formats such as HTML or XML, by generating the required tags explicitly within your procedure.
HTML The result set of a statement or procedure are automatically formatted into an HTML document that contains a table.
XML The result set is assumed to be in XML format. If it is not already so, it is automatically converted to XML RAW format.
SOAP The request must be a valid Simple Object Access Protocol, or SOAP, request. The result set is automatically formatted as a SOAP response. For more information about the SOAP standards, see 
www.w3.org/TR/SOAP.
DISH A Deduce Ideal SOAP Handler, or DISH, service acts as a proxy for one or more SOAP services. In use, it acts as a container that holds and provides access to a number of soap services. A Web Services Description Language (WSDL) file is automatically generated for each of the included SOAP services. The included SOAP services are identified by a common prefix, which must be specified in the USING clause.
Of the types HTML, XML, and RAW, RAW gives you the most control over the output. However, it does require that you do more work as you must explicitly output all the necessary tags. XML format can be tuned to some extent using an assortment of built-in procedures.
For more information, see CREATE SERVICE statement.
The statement is the command, usually a stored procedure, that is called when someone access the service. If you define a statement, this is the only statement that can be run through this service. The statement is mandatory for SOAP services, and ignored for DISH services. The default is NULL, which means no statement.
You can create services that do not include statements. The statement is taken from the URI. Services configured in this way can be useful when you are testing a service, or want a general way of accessing information. To do so, either omit the statement entirely or use the phrase AS NULL in place of the statement.
Services without statements are a serious security risk, as they permit web clients to execute arbitrary commands. When creating such services, you must enable authorization, which forces all clients to provide a valid username and password. Even so, only services that define statements should be run in a production system.
The following attributes are available. In general, all are optional. However, some are interdependent.
AUTHORIZATION Authorization controls which users can use the service. The default setting is ON. Authorization must be ON if no statement is provided. In addition, the authorization setting affects how user names are interpreted.
SECURE When set to ON, only secure connections are permitted. All connections received on the HTTP port are automatically redirected to the HTTPS port. The default is OFF, which enables both HTTP and HTTPS requests, provided these ports are enabled using the appropriate switches when the database server is started.
USER The USER clause controls which database user accounts can be used to process service requests. However, the interpretation of this setting depends on whether authorization is ON or OFF:
When authorization is set to ON, all clients must provide a valid user name and password when they connect. When authorization is ON, the USER option may either be NULL, or can be a list of user names. If it is NULL, any database user can connect make requests. Requests are run using the account and permissions of that user. If a list of users is specified, only those users can run requests. Any other database users are denied permission to use the service.
If authorization is OFF, a statement must be provided. In addition, a user name must be provided. All requests are run using that user's account and permissions. Thus, unless the server is physically isolated, the permissions of the named user account should be minimal.
URL The URL clause controls the interpretation of URLs. In particular, it determines whether URI paths are accepted and, if so, how they are processed. If the service name ends with the character "/", the URL must be set to OFF.
For more information, see CREATE SERVICE statement.