Recursive Application of the Service Model

 

Many of the value added services that are now being offered by providers are composed of services that are supplied by various sub-providers. These sub-providers in turn can apply the same principle and can contract other sub-providers. As stated in section , the service model must be capable of modeling the resulting service chains and service hierarchies.

A provider contracting services of another provider acts as a customer to the latter. This means that the provider domain embeds the tasks of the user/customer role and the provider role simultaneously. As such, we can reuse the already modeled associations between the customer and the provider domain in order to model the associations regarding the relation of provider and sub-provider. By expanding the provider domain with the entities of the customer domain, we are able to create an enhanced model of the provider domain containing the classes service implementation and service management, the roles provider, user and customer, and the two client classes.
[Chaining of services]Chaining of services   [r]As figure shows there is no provider-internal connection to the newly added classes of the provider domain. Further classes have to be added to the service model to close the gap between the elements of the two stand-alone models of provider and customer side.

Figure shows how this gap can be closed. As already explained, all roles of the customer and the provider side of a service can reside within the provider domain. Thus, both, the customer role and the user role are part of the provider role. The clients used to access the subsidiary interfaces must be part of the service implementation and the service management respectively to permit an interaction with a sub-provider. As a consequence, the question for further elements within the service implementation and the service management raises.

The service implementation is composed of resources made available by the provider himself and services that are accessible through sub-service clients. Hence, we introduce a service logic to control both, the usage of services as well as the usage of the provider's resources. Thus, our class diagram shows the class service implementation consisting of the classes sub-service client, service logic, and resources. The sub-service client is actually just a refinement of the generic user client added to the provider domain.

The service management will use functionality of the traditional network, system and application management, i.e. the so called basic management functionality (BMF), along with the management functionality provided by subsidiary services. In consequence, there has to be a management logic controlling the BMF as well as the sub-service management clients for the subsidiary service management. The management logic treats the service logic as a managed object which leads to an association between the two classes service logic and service management logic. Corresponding to the service implementation we model the class service management as an aggregation of the three classes BMF, service management logic, and sub-service management client.

As both logics use corresponding clients to access the sub-service and/or their management respectively, they act in the role user (service logic) and customer (management logic). We model this correlation with two associations, one connecting the service logic and the user role, the other one connecting the service management and the customer role.

 

Abbildung:   Model of a provider domain in a service hierarchy