Difference between revisions of "Contexts"
(New page: [coming soon] == The gHN Context == [coming soon] == Service Contexts == [coming soon] == PortType Contexts == [coming soon]) |
|||
| Line 1: | Line 1: | ||
| + | Within the implementation of gCube services, some functionality needs to be accessed by different components and for different purposes. | ||
| + | The most obvious case is functionality that exposes the configuration of the service, its RI, or the gHN on which the RI is deployed; as shown later in the Guide, | ||
| + | there is also dynamically acquired information related to scope and security that may need to be shared within service implementations. And beyond information access, | ||
| + | there are general-purpose or service-specific utilities and behaviours that may be called upon from multiple and functionally unrelated components. In gCF, the approach to shared functionality is to centralise it in distinguished components, called '''contexts''', which are easily accessible from any other implementation component. | ||
| + | |||
| + | There are different type of contexts in gCF, each of which centralises functionality that is conceptually associated with the service and its RI, the gHN on which the RI is deployed, the port-types of the service, and even the port-types of remote target services. Some of these contexts are fully defined within gCF (e.g. the context of the gHN). Others are only partially implemented and need to be specialised within individual service implementations. Collectively, the context form a inheritance hierarchy contained in the <code>contexts</code> package: | ||
| + | |||
| + | * <code>GCUBEContext</code>: the base implementation for all contexts in gCF. | ||
| + | |||
| + | * <code>GCUBEGHNContext</code>: a concrete specialisation of <code>GCUBEContext</code> for a gCube Hosting Node. | ||
| + | |||
| + | * <code>GCUBEServiceContext</code>: a concrete specialisation of <code>GCUBEContext</code> for a gCube Service. | ||
| + | |||
| + | * <code>GCUBEPortTypeContext</code>: a concrete specialisation of <code>GCUBEContext</code> for a port-type of gCube Service. | ||
| + | |||
| + | * <code>GCUBEStatefulPortTypeContext</code>: a concrete specialisation of <code>GCUBEPortTypeContext</code> for a stateful port-type of a gCube Service. | ||
| + | |||
| + | * <code>GCUBERemotePortTypeContext</code>: a concrete specialisation of <code>GCUBEContext</code> for a port-type of a target gCube Service. | ||
| + | |||
| + | <code>GCUBEContext</code> defines facilities for handling configuration available in the file system or in the classpath: | ||
| + | |||
| + | *<code>getProperty()</code>: | ||
| + | *<code>getResource()</code>: | ||
| + | *<code>getFile()</code>: | ||
| − | |||
== The gHN Context == | == The gHN Context == | ||
Revision as of 11:23, 21 January 2009
Within the implementation of gCube services, some functionality needs to be accessed by different components and for different purposes. The most obvious case is functionality that exposes the configuration of the service, its RI, or the gHN on which the RI is deployed; as shown later in the Guide, there is also dynamically acquired information related to scope and security that may need to be shared within service implementations. And beyond information access, there are general-purpose or service-specific utilities and behaviours that may be called upon from multiple and functionally unrelated components. In gCF, the approach to shared functionality is to centralise it in distinguished components, called contexts, which are easily accessible from any other implementation component.
There are different type of contexts in gCF, each of which centralises functionality that is conceptually associated with the service and its RI, the gHN on which the RI is deployed, the port-types of the service, and even the port-types of remote target services. Some of these contexts are fully defined within gCF (e.g. the context of the gHN). Others are only partially implemented and need to be specialised within individual service implementations. Collectively, the context form a inheritance hierarchy contained in the contexts package:
-
GCUBEContext: the base implementation for all contexts in gCF.
-
GCUBEGHNContext: a concrete specialisation ofGCUBEContextfor a gCube Hosting Node.
-
GCUBEServiceContext: a concrete specialisation ofGCUBEContextfor a gCube Service.
-
GCUBEPortTypeContext: a concrete specialisation ofGCUBEContextfor a port-type of gCube Service.
-
GCUBEStatefulPortTypeContext: a concrete specialisation ofGCUBEPortTypeContextfor a stateful port-type of a gCube Service.
-
GCUBERemotePortTypeContext: a concrete specialisation ofGCUBEContextfor a port-type of a target gCube Service.
GCUBEContext defines facilities for handling configuration available in the file system or in the classpath:
getProperty():getResource():getFile():
The gHN Context
[coming soon]
Service Contexts
[coming soon]
PortType Contexts
[coming soon]
