This feature allows the service provider to expose existing data resources containing existing data to users of the GRIA OGSA-DAI service.

Connecting an existing data resource

1. Click the "Connect existing data resource" button.
2. Enter the JDBC URL of the data resource you wish to connect to. You can also enter a description.
3. Click the "Save changes" button to apply the changes.

Adding Roles

You will now need to add one or more data resource roles to your data resource. Roles allow you to specify which username and password combinations to use on the data resource backend.

Adding a role to a data resource

1. Click the "Add role" button beside the data resource you wish to modify.
2. Enter the username and password details of the user you are adding.
   Entering a Metric URI allows you to create Service Level Agreements (SLAs) that constrain on specific data resource roles. See the Metrics and SLAs section for more details.
   Repeat steps 1 and 2 if you need to add more than one role.
3. Click the "Save changes" button to apply the changes.

The role has now been created.

Setting Permissions on Resources

See the Access Control section to learn how you can control which users have permission to subscribe to your new resources.

Creating New Databases

This feature allows the service provider to create a new data resources that users can subscribe to and fill with data.

Creating a new data resource

1. Click the "Create new data resource" button.
2. Enter a description for the new data resource.
   You can optionally enter a Metric URI, a modified version of which will be assigned to the three automatically generated roles. Doing this allows you to create Service Level Agreements (SLAs) that constrain on specific data resource roles. See the Metrics and SLAs section for more details.
   
3. Click the "Save changes" button to apply the changes.

The new data resource has now been created. You will notice the OGSA-DAI service has automatically generated three data resource roles. These have the following permissions:

• Administrative role: can view data, modifiy data, and create and delete tables.
• Read/write role: can view and modify data in existing tables.
• Read only role: can view data in existing tables.

Setting Permissions on Resources

See the Access Control section to learn how you can control which users have permission to subscribe to your new resources.

Viewing Subscriptions

It is possible to create a subscription from the web interface.

Creating a data resource role subscription

1. Click the subscribe button on a particular role.
2. Enter description of new subscription.
3. Click save changes button.

After carrying out these steps you should see something similar to that below.

Click the icon circled in red to view your newly created subscription.

Setting Permissions on Resources

See the Access Control section to learn how you can control which users have permission to use your new subscription.

The GRIA service provider management package contains an SLA service that can be used to limit the number of resources users can create and charge them for those that they use. The OGSA-DAI service defines a number of metrics that the service provider can use when creating SLAs. The service generates usage reports using these metrics whenever a user creates a new resource. The SLA service collects these usage reports and charges the user accordingly.

The service provider may wish to set up different pricing terms for individual databases or roles. For example he may wish to charge for read/write access to a database while making read only access free. In this situation the service provider can specify a custom metric URI for each role, and then set up the SLA to constrain on those.

It would be helpful to read this section in conjunction with the SLA Management Service manual.

The OGSA-DAI service provides metrics for each of the resource types:

Example

User A has been given permission by the service provider to create databases. He wants to create a new database, create some tables in that database, and then give User B read/write access to those tables.

• User A calls createDatabase.

  Usage report for User A - Database
  http://www.gria.org/sla/metric/activity/ogsadai/db
  Total now: 1
  Usage report for User A - Administrative Role
  http://www.gria.org/sla/metric/activity/ogsadai/role
  Total now: 1
  Usage report for User A - Read/Write Role
  http://www.gria.org/sla/metric/activity/ogsadai/role
  Total now: 2
  Usage report for User A - Read Only Role
  http://www.gria.org/sla/metric/activity/ogsadai/role
  Total now: 3

• User A calls subscribe on his administrative role so he can create a table.

  Usage report for User A - Subscription
  http://www.gria.org/sla/metric/activity/ogsadai/subscription
  Total now: 1
  Usage report for User A - Subscriber
  http://www.gria.org/sla/metric/resource/ogsadai/subscriber
  Total now: 1

• User A calls perform on his subscription, creating a table.

• User A gives User B permission to subscribe to his Read/Write role.

• User B calls subscribe on the Read/Write role.

  Usage report for User B - Subscription
  http://www.gria.org/sla/metric/activity/ogsadai/subscription
  Total now: 1
  Usage report for User A - Subscriber
  http://www.gria.org/sla/metric/resource/ogsadai/subscriber
  Total now: 2

• User B executes some queries on his Read/Write subscription.

At the end of this example, the usage for the two users is as follows:

In some situations the service provider may wish to charge or constrain differently for different databases or database roles. For example, he may want to make read-only access to a database free while charging for read/write access.

This can be implemented through the use of custom metric URIs. There are two places where a custom URI can be entered:

• When adding a new role.
• When creating a new database (the automatically generated roles get assigned metric URIs based on the one provided).

When a user subscribes to a database role that uses custom metric URIs he generates one usage report for the standard subscription metric (http://www.gria.org/sla/metric/activity/ogsadai/subscription) and one for the custom metric. This is different from subscribing to a role without a custom metric URI, where the user would only generate a usage report for the standard subscription metric.

Providing a custom metric URI when creating a new database will assign similar metric URIs to the three automatically generated database roles. These URIs are generated using the same rules as username generation - the three postfixes are appended onto the end of the metric URI for each of the three roles.

For example, supposing you keep the default values for the username postfixes (eg, ".a" for the administrative role and ".r" for the read-only role), and specify a metric URI http://www.test.com/metric/test_database, the following metric URIs would be generated for the three roles:

• Administrative role: http://www.test.com/metric/test_database.a
• Read/write role: http://www.test.com/metric/test_database.w
• Read Only role: http://www.test.com/metric/test_database.r

SLA templates can be created to constrain on any of the above metrics. Several example sections of SLA templates are given below. See the GRIA user documentation for information on constructing full SLA template XML documents.

Limiting database creation

When inserted into the <constraints> section of an SLA template, this capacity constaint will limit the user to creating only one database. The user may still subscribe to other databases, and other users may subscribe to his database.

<constraint type='INSTANTANEOUS'>
    <metric type='ACTIVITY'>
        <uri>http://www.gria.org/sla/metric/activity/ogsadai/db</uri>
        <description>
            <description>database</description>

        </description>
        <units type='DECIMAL'>
            <instantaneous>database</instantaneous>
        </units>
    </metric>

    <bound>LE</bound>
    <private>false</private>
    <limit>1.0</limit>
    <contention>1.0</contention>

    <repeating>false</repeating>
</constraint>

Limiting subscriptions

When inserted into the <constraints> section of an SLA template, these capacity constraints will allow the user to subscribe to three database roles, and have one person subscribe to any roles he creates. The user can create an unlimited number of databases.

<constraint type='INSTANTANEOUS'>
    <metric type='ACTIVITY'>
        <uri>http://www.gria.org/sla/metric/activity/ogsadai/subscription</uri>
        <description>
            <description>subscription</description>

        </description>
        <units type='DECIMAL'>
        <instantaneous>subscription</instantaneous>
    </units>
    </metric>

    <bound>LE</bound>
    <private>false</private>
    <limit>3.0</limit>
    <contention>1.0</contention>

    <repeating>false</repeating>
</constraint>

<constraint type='INSTANTANEOUS'>
    <metric type='RESOURCE'>
        <uri>http://www.gria.org/sla/metric/resource/ogsadai/subscriber</uri>

        <description>
            <description>subscriber</description>
        </description>
        <units type='DECIMAL'>
            <instantaneous>subscriber</instantaneous>

        </units>
    </metric>
    <bound>LE</bound>
    <private>false</private>
    <limit>1.0</limit>

    <contention>1.0</contention>
    <repeating>false</repeating>
</constraint>

Visit the URL of the GRIA OGSA-DAI Service you wish to access and drag the wsdl link from the webpage in to the service view of the client.

Connecting to an OGSA-DAI Service from Client

If you are running the GRIA OGSA-DAI 1.0 client drag the OGSA-DAI Service legacy link, otherwise use the OGSA-DAI Service link. It is most likely that you are using a 5.2 client.

This feature allows you to expose existing databases containing existing data to users of the GRIA OGSA-DAI service. To use this feature you need to have been given access to the connect-database PBAC role on the OGSA-DAI service. See the Access Control section for more information.

Before starting you should ensure that the OGSA-DAI service is listed in your client. If it does not exist you can add it by either left clicking on the "Services" menu item and selecting "Add a service", or dragging the service's WSDL link onto the "Services" entry.

Right click on the OGSA-DAI service and select "Connect existing resource".

This will open a dialog box where you can enter the details of the database you wish to connect. You are able to enter the JDBC URL of any type of database here, and also a short description of the database.  No checks as to the validity of the JDBC URL are made.

Once you have connected you data resource you are able to add roles.  Right click on the connected data resource and select "Connect role".

Enter a description plus the username and password of the role on your database.

After clicking "OK", the role you have created is added to the list.

Setting Permissions on Roles

See the Access Control section to learn how you can control which users have permission to subscribe to your new data resource role.

Creating New Data Resources

This feature allows you to create new data resources which you can either subscribe to and use yourself, or give permission for others to use. To create new data resource you need to have been given access to the create-dataresource PBAC role on the OGSA-DAI service. See the Access Control section for more information.

Before starting you should ensure that the OGSA-DAI service is listed in your client. If it does not exist you can add it by either left clicking on the "Services" entry and selecting "Add a service", or dragging the service's WSDL link into the client.

Right click on the OGSA-DAI service and select "Create new dataresource".

Enter a description and press ok.

The database and its three roles have now been created.

Setting Permissions on Data Resources

See the Access Control section to learn how you can control which users have permission to subscribe to your new data resources.

Getting a subscription to a database role allows you to execute queries (perform documents) on it. By default you are allowed to subscribe to roles created by yourself. To be able to subscribe to roles created by other people, they need to have given you the client PBAC role on their resource. See the Access Control section for more information.

If you have been given access to a role and it does not appear in your client, try right clicking on the OGSA-DAI service and selecting "Discover existing resources".

Before starting you should ensure that the OGSA-DAI service is listed in your client. If it does not exist you can add it by either left clicking on the "Services" menu item and selecting "Add a service", or dragging the service's WSDL link into the client.

Right click on the role you wish to subscribe to and select "Subscribe". You will be asked to enter a short description for the subscription.

The subscription is now listed in your client. You can execute SQL queries on it directly from the client by right clicking on it and selecting one of "Execute query" or "Execute update" entries.  Note this only works on SQL Database types of data resources.

Usage

Delegating access to a Subscription

This feature allows you to permit another user to execute database queries using your subscription. Note that the delegate only gets access to a subset of methods on your subscription:

Left click on the database subscription that you wish to delegate access to, and select "Access control list".

Now add a new access control rule for the "delegate" role. In the screenshot below we are adding a rule such that everyone is considered a delegate to this subscription, and will be able to run perform documents on it.

The GRIA client allows you to destroy any of the resources for which you have the owner PBAC role. To do this simply right click on the resource and select "Destroy".

Destroying Data Resources

When destroying a data resource that was created by the OGSA-DAI service (ie. by using the create new data resource feature), all tables and data in that database will be removed from the RDBMS.

Destroying a data resource that already existed (and was configured using the connect existing database feature) will only remove the link between the OGSA-DAI service and the back-end, and will leave the data intact.

Destroying a database will cause all roles and subscriptions on the database to be destroyed in addition to the database resource itself.

Destroying Role Resources

Destroying a role resource will also destroy any subscriptions that use that role.

Note you cannot destroy roles that were automatically created by the OGSA-DAI service. These roles exist until the database that they belong to is destroyed.

Destroying Subscription Resources

Removing a subscription resource will prevent any further queries from being run using that subscription.