![[Note]](images/note.gif) | Note |
|---|---|
| Place-holder for future content. |
To write a expose OGSA-DAI functionality to clients a presentation layer needs to:
-
Map operations to OGSA-DAI core functionality.
- If developing a presentation layer to expose all the functionality of OGSA-DAI then requests from client should specify a resource ID, an operation name and arguments to the operation and these should map directly onto operations on DRERs and other OGSA-DAI resources.
- If developing a presentation layer that hides OGSA-DAI behind application-specific components and operations then this may be more complex. Use may be made of DRERs which are identified by IDs provided as part of the server configuration (rather than selected by the client) and pre-built workflows may be stored and populated using information provided by clients (rather than clients providing the workflows themselves).
-
Translate:
- Presentation layer-specific resource IDs, operation names and arguments to OGSA-DAI core objects and method calls.
- OGSA-DAI core objects to presentation layer specific return types.
- OGSA-DAI core exceptions to presentation layer specific exceptions/faults.
-
Initialize the OGSA-DAI context, if the presentation layer does
not extend an existing one that already does this.
- Section G.2, “OGSA-DAI context” outlines the components that the OGSA-DAI context must contain and which the presentation layer may be responsible for creating.
-
One of these must be a request factory which implements the interface
uk.org.ogsadai.activity.request.RequestFactoryand converts requests in a presentation layer-specific format into requests in the format expected by the OGSA-DAI activity framework and engine.
- Specify a base 64 provider if Apache Axis is not being used. See Section G.7, “Base 64 encoding”.
-
If developing Web services presentation layers then all WSDL
declarations are recommended to be
document/literalencoding.