Difference between revisions of "Service Model"
| Line 7: | Line 7: | ||
A gCube service is a compile-time abstraction for the implementation of functionality that can be consumed over a network in a standard fashion. The implementation is structured in '''components''' and its functionality exposed through an '''interface''' of operations logically grouped in one or more '''port-types'''. | A gCube service is a compile-time abstraction for the implementation of functionality that can be consumed over a network in a standard fashion. The implementation is structured in '''components''' and its functionality exposed through an '''interface''' of operations logically grouped in one or more '''port-types'''. | ||
| − | + | The service acquires run-time existence when it is deployed, statically or dynamically, on a gCube Hosting Node (gHN). The runtime counterpart of a deployed service is a Running Instance (RI), an abstraction in which port-types are bound to addressable locations, or '''endpoints'''. Zero or more RIs of a given service may be available in a gCube infrastructure at any time, as a result of deploying the service in zero or more gHNs. | |
| − | The service acquires run-time existence when it is deployed, statically or dynamically, on a gCube Hosting Node (gHN). | + | |
Using the endpoints of a RI, the operations of the port-types may be invoked by '''service clients''' (''incoming requests''). In turn, the RI may invoke operations exposed by the port-types of other '''target services''' (''outgoing requests''), and thus act as a client for them. Incoming and outgoing requests may trigger a response, or else report a '''fault''' that clients may handle, report, or simply propagate to their own clients, if they have any. | Using the endpoints of a RI, the operations of the port-types may be invoked by '''service clients''' (''incoming requests''). In turn, the RI may invoke operations exposed by the port-types of other '''target services''' (''outgoing requests''), and thus act as a client for them. Incoming and outgoing requests may trigger a response, or else report a '''fault''' that clients may handle, report, or simply propagate to their own clients, if they have any. | ||
Besides interface and implementation, the service includes non-programmatic '''configuration''' components that describe the service, its deployment and interface, and that govern its implementation. | Besides interface and implementation, the service includes non-programmatic '''configuration''' components that describe the service, its deployment and interface, and that govern its implementation. | ||
Latest revision as of 09:16, 24 April 2009
gCube does not make stringent assumptions on the structure of its services. gCore and gCF, on the other hand, define their facilities with respect to a more explicit model of the key components of a gCube service. We describe the model incrementally throughout the Guide, but we start here to fix some basic concepts and terminology.
A gCube service is a compile-time abstraction for the implementation of functionality that can be consumed over a network in a standard fashion. The implementation is structured in components and its functionality exposed through an interface of operations logically grouped in one or more port-types.
The service acquires run-time existence when it is deployed, statically or dynamically, on a gCube Hosting Node (gHN). The runtime counterpart of a deployed service is a Running Instance (RI), an abstraction in which port-types are bound to addressable locations, or endpoints. Zero or more RIs of a given service may be available in a gCube infrastructure at any time, as a result of deploying the service in zero or more gHNs.
Using the endpoints of a RI, the operations of the port-types may be invoked by service clients (incoming requests). In turn, the RI may invoke operations exposed by the port-types of other target services (outgoing requests), and thus act as a client for them. Incoming and outgoing requests may trigger a response, or else report a fault that clients may handle, report, or simply propagate to their own clients, if they have any.
Besides interface and implementation, the service includes non-programmatic configuration components that describe the service, its deployment and interface, and that govern its implementation.
