Difference between revisions of "Service Model"

From GCube System
Jump to: navigation, search
Line 2: Line 2:
 
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.
 
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.
 
We describe the model incrementally throughout the Guide, but we start here to fix some basic concepts and terminology.
 +
 +
[[Image:model.pdf]]
  
 
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). A successful deployment yields a Running Instance (RI) of the service, a runtime abstraction in which port-types are bound to addressable locations, or '''endpoints'''.  At any time, zero or more RIs of a service may be available in a gCube infrastructure as a result of deploying the service on zero or more gHNs.   
 
The service acquires run-time existence when it is deployed, statically or dynamically,  on a gCube Hosting Node (gHN). A successful deployment yields a Running Instance (RI) of the service, a runtime abstraction in which port-types are bound to addressable locations, or '''endpoints'''.  At any time, zero or more RIs of a service may be available in a gCube infrastructure as a result of deploying the service on zero or more gHNs.   

Revision as of 18:28, 20 January 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.

File:Model.pdf

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). A successful deployment yields a Running Instance (RI) of the service, a runtime abstraction in which port-types are bound to addressable locations, or endpoints. At any time, zero or more RIs of a service may be available in a gCube infrastructure as a result of deploying the service on 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.