Difference between revisions of "Service Model"
From GCube System
(New page: [coming soon]) |
|||
| Line 1: | Line 1: | ||
| − | + | 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 will describe the model incrementally throughout the Guide, but we start here to fix some basic concepts and terminology. | ||
| + | |||
| + | At the outset, a gCube service is characterised by one or more '''port-types''', where each port-type exposes a number of functionally related operations that may be invoked on RIs of the service (''incoming calls''). In turn, the RIs may invoke operations exposed by the port-types of other services (''outgoing requests''). Requests may trigger a response, or else report a ''fault''. | ||
Revision as of 20:40, 15 December 2008
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 will describe the model incrementally throughout the Guide, but we start here to fix some basic concepts and terminology.
At the outset, a gCube service is characterised by one or more port-types, where each port-type exposes a number of functionally related operations that may be invoked on RIs of the service (incoming calls). In turn, the RIs may invoke operations exposed by the port-types of other services (outgoing requests). Requests may trigger a response, or else report a fault.
