DAServer
This is a Tool topic for Data Abstract
Note: See also the new Relativity, which superseded DAServer in the Fall 2009 release.
Contents |
DAServer is a standalone executable server that is provided with Data Abstract. DAServer (DAS for short) can be run as a standalone application or as a Windows Service and it basically provides a fully-fledged middle-tier server for as many Schemas as you like, in other words, in many cases you will no longer need to write a custom middle tier server application (but of course you can still write your own servers, as always, if you need more flexibility than DAS provides).
When you start DAS as a standalone application (DAServer.exe), it looks like this:
To run DAS as an NT Service, simply install it by running "DAServer.exe /install" from the command line. Once that is done, you can start and stop DAS like any other Windows Service, using the Services Management Console, or the "net start/stop" command line tool.
When running as an Windows Service, DAS of course will not display a GUI, but whatever options you configured when running it as a standalone application will take effect.
In the screenshot above, two schemas have already been registered with the server, one for the Microsoft SQL Server Northwind database and one for "ROTFL", our internal Task Management System (which is based on DA and DAS).
You can register new Schemas to be served by DAS in two ways:
- You can use the "Add Schema" button to tell DAS to add any .daSchema file (and its associated .daConnections file) on the local hard disk.
- You can use the Schema Modeler integration to publish Schemas directly to a remote (or local) DAServer.
The second option is preferred, however, and is the one we'll further look into for the remainder of this topic.
Publishing a new Schema
To start creating and publishing a new Schema, simply start up Schema Modeler from the Start Menu (or from the IDE) and create the new Schema as usual. Drag your Tables to create DataSets and Commands. Adjust your fields, specify Business Rules, etc., just like you would do when creating a standard DA Schema.
Once you are finished defining your schema, click the "Publish" button as indicated above, or select Publish Schema to DAServer from the Schema menu. This will pop up the Publish Schema dialog:
This dialog allows you to specify the URL of your DAServer (Schema Modeler will always talk to the DAServer via HTTP and BinMessage), the Admin login that will authorize you to access schema info on that server (the default is "admin/admin", which you should change when deploying DAS on publicly accessible servers), as well as a name to publish the Schema under.
By clicking "Refresh", you can obtain a list of Schemas already registered on the server, which is helpful if you are planning to replace a schema that's already on the server or if you simply want to avoid picking a duplicate name.
Once all is set, click "Ok" to publish your Schema. After the dialog closes, you will notice that the new schema immediately shows up in the DAServer GUI (see the first screenshot above). Your Schema is now ready to be served and accessed by the client (yet to be built).
Editing a Schema
Before you close Schema Modeler, you can save the Schema you designed to a file on your local hard disk, though this is not actually necessary, as your schema is safely stored inside the server. If you later need to change or update your Schema, simply start Schema Modeler and click the Get button or choose Schema/Get Schema from DAServer... from the menu.
A variation of the dialog we saw above appears:
Simply enter the URL and login for your server, pick the right schema name from the Get Schema combo-box and press ok. Schema Modeler will now download the Schema from the server and open it for editing.
Schema Modeler can maintain a list of the servers you use frequently. Once you have filled in the Url and Username/Password, click the "Save" button to add the server info to your list. From now on, this server will show up in the "My Servers" list at the top of the Publish and Get Schema dialogs, and you can recall its settings simply by selecting the appropriate entry from the list.
As you would expect, you can manage the list of servers you have stored by clicking the "Manage" button.
Schema Modeler will also remember that the schema was obtained from the server, so whenever you click Save, your changes will be sent back up to the server instead of to a local file.
Adding Login capabilities to Your Schema
In any serious real-life application, you will want to limit access to your middle-tier server via customized user logins. Do not confuse this with the actual database login (which usually is static for your application) as you will want individual user names and passwords to be required from the client in order to authenticate themselves with the server; this will keep unauthorized users from accessing and compromising your data.
DAServer provides a simple yet effective way for you to add a login requirement to your schema easily:
- When DAServer receives a call to its DASessionManager.Login method, the first thing it does is to inspect the aSchema and aConnection parameters. Based on these, it locates the Schema and will eventually create a database connection.
- DAServer checks if the schema contains a dataset defintion named DAServer_Login. If no such dataset is found, it will ignore the aUsername and aPassword parameters and assume that no user-login is required; the session will now be ready to serve the schema.
- If a dataset named DAServer_Login is found, DAServer will look for :Username and :Password parameters in the dataset, fill those with the aUsername and aPassword parameters it received from the client and then open the dataset. The dataset is expected to return exactly one record if the login information is ok, and zero records if the login is invalid.
- Based on the query result, DAServer will accept the login and start serving the Schema, or will discard the session and fail the call to Login with an exception.
So, to enable login for your own Schema, all you need to do is provide a custom DAServer_Login dataset that implements the logic for your login; which could be a statement as simple as
SELECT TOP 1 * FROM Users WHERE [Name] = :UserName AND [Password] = :Password
but could also contain much more elaborate logic, depending on your specific needs.
See Also
Product: RemObjects Data Abstract
Available Editions: Data Abstract for .NET, Xcode, Delphi, Java and JavaScript
