Model-driven engineering of middleware-based ubiquitous services

Abstract

Supporting the execution of service-oriented applications over ubiquitous networks specifically calls for a service-oriented middleware (SOM), which effectively enables ubiquitous networking while benefiting from the diversity and richness of the networking infrastructure. However, developing ubiquitous applications that exploit the specific features offered by a SOM might be a time-consuming task, which demands a deep knowledge spanning from the application domain concepts down to the underlying middleware technicalities. In this paper, first we present the model-driven development process underpinning ubiSOAP, a SOM for the ubiquitous networking domain. Then, based on the domain concepts defined by the conceptual model of ubiSOAP, its architecture and its technicalities, we propose a domain-specific environment, called ubiDSE, that aids the development of applications that exploits the ubiSOAP features, from design to implementation. ubiDSE allows developers to focus on the main behavior of the modeled systems, rather than on complex details inherent to ubiquitous environments. As part of ubiDSE, specific tools are provided to automatically generate skeleton code for service-oriented applications to be executed on ubiSOAP-enabled devices, hence facilitating the exploitation of ubiSOAP by developers.

Appendices

Appendix A: ubiDSE profile

The ubiDSE profile extends the existing profile devised for the PLASTIC project [40] to explicitly account for the peculiarities of ubiquitous networking environments. The profile structure (shown in Fig. 24) consists of five packages:

• 1. Specification contains the stereotypes used for representing the domain elements from the conceptual model. Stereotypes are used for modeling (1) use cases and (nomadic) actors, (2) services and their component-based software architecture and (3) the hardware platform where such components are deployed.

• 2. Physical Mobility contains the stereotypes for modeling the user physical mobility [35].

• 3. Resources is a model library that contains a set of already stereotyped modeling elements representing Available Resources specifications such as Memory (e.g., 1 GB, 512 KB), Screen (e.g., 1,024 $\times$ 768 color), CPU (e.g., 1.8 GHz).

• 4. Middleware is a model library containing the MRN-API component described in Sect. 8.1.

• 5. Customization contains the Customization Classes extending the MagicDraw UML tool interface with the ubiDSE stereotypes. Such a customization process has been described in Sect. 8.1.

  Fig. 24

  

  ubiDSE profile structure

Next sections further detail the stereotypes included in the Specifications (§9) and Physical Mobility (§9) packages, respectively. The stereotypes have been organized in different subsections according to the supported modeling activities as identified in Sect. 8.2.

1.1 A.1 Specifications package

1.1.1 A.1.1 Stereotypes for use case and service modeling

$\langle \langle Capability\,Specification \rangle \rangle$

• Extends: Use Case;

• Semantics: It is a declaration of an offered behavior of the system to the involved parties like Service Consumers or Service Providers. Its behavior is specified by Conversation Specifications;

• Properties (Attributes & Associations):

  • ConversationSpecifications : Conversation Specifications [0..*]: set of behavior specifications

• Notation: as for Use Case;

• Constraints: None.

$\langle \langle ComponentDeveloper \rangle \rangle$

• Extends: Actor;

• Semantics: The role played by the person that implements or integrates components;

• Properties: None;

• Notation: as for Actor;

• Constraints: None.

$\langle \langle ConversationSpecification \rangle \rangle$

• Extends: Activity

• Semantics: It represents the behavior of each CapabilitySpecification. It is described as a collaboration among ServiceDescriptions invoking Operation Specifications of a set of collaborating services, as indicated by the Service Usage and the Service Composition relationships;

• Properties: None;

• Notation: as for Activity;

• Constraints: None.

$\langle \langle OperationSpecification \rangle \rangle$

• Extends: Operation;

• Semantics: Operation exposed by ServiceDescriptions. A set of Operation Specifications defines the service signature;

• Properties: None;

• Notation: as for Operation;

• Constraints:

  • The ownerClassifier must be a ServiceDescription.

$\langle \langle ServiceAdaptation \rangle \rangle$

• Extends: Dependency

• Semantics: It is an explicit binary relationship between ServiceDescriptions and Context Specifications to which the software service must adapt; A ServiceAdaptation dependency implies the semantics of the client (the ServiceDescription) is not complete without the supplier (the Context Specification); It explicitly relates ServiceDescription with DeviceQoSSpecification making the software services aware about which resources are available;

• Properties: None;

• Notation: see Fig. 25;

• Constraints:

  • The supplier must be a Context Specification (i.e., a DeviceQoSSpecification or a NetworkQoSpecification);

  • The client must be a ServiceDescription.

Fig. 25

ServiceAdaptation notation

$\langle \langle ServiceComposition \rangle \rangle$

• Extends: Dependency

• Semantics: Relationship between a composite Service Description (the client) and one of its elementary (simple) ServiceDescription.

• Properties: None;

• Notation: as for Dependency;

• Constraints:

  • The supplier must be a Context Specification

  • The client must be a ServiceDescription

$\langle \langle ServiceConsumer \rangle \rangle$

• Extends: Actor;

• Semantics: The role played by the person that exploit the software service;

• Properties: None;

• Notation: as for Actor;

• Constraints: None.

$\langle \langle ServiceDeveloper \rangle \rangle$

• Extends: Actor;

• Semantics: The role played by the person that develop the software services as stated by the ServiceDescription interfaces;

• Properties: None;

• Notation: as for Actor;

• Constraints: None.

$\langle \langle ServiceDescription \rangle \rangle$

• Extends: Interface

• Semantics: The context-aware adaptable software service. It declares a set of (Service Signature) of public functionalities (Operation Specifications) and obligations. A ServiceDescription specifies a sort of contract; The set of realizing ComponentSpecifications (defined by Service Realization dependencies) must fulfill that contract. They are context-aware, that is they know which Context Specifications they must adapt to (by means of ServiceAdaptation dependency). Since ServiceDescriptions are declarations, they cannot be instantiated: They have not a runtime counterpart (as Object for Classes). Instead, a ServiceDescription is mapped onto a set of ComponentSpecifications;

• Properties: None;

• Notation: see Fig. 26;

• Constraints: It participates only in ServiceUsage, ServiceComposition and ServiceAdaptation relationships.

$\langle \langle ServiceIntegrator \rangle \rangle$

• Extends: Actor;

• Semantics: The role played by the person that integrate the software services as stated by the dependencies among the ServiceDescription interfaces;

• Properties: None;

• Notation: as for Actor;

• Constraints: None.

$\langle \langle ServiceProvider \rangle \rangle$

• Extends: Actor;

• Semantics: The role played by the party that provide software service;

• Properties: None;

• Notation: as for Actor;

• Constraints: None.

Fig. 26

ServiceDescription notation

$\langle \langle ServiceUsage \rangle \rangle$

• Extends: Usage;

• Semantics: It is a binary relationship between a client ServiceDescription that needs a supplier ServiceDescription for its fully implementation. The client ServiceDescription delegates (part of) the execution of one or more of its OperationSpecifications to the supplier ServiceDescription;

• Properties: None;

• Notation: as for Usage;

• Constraints:

  • The supplier must be a ServiceDescription;

  • The client must be a ServiceDescription.

1.1.2 A.1.2 Stereotypes for software architecture modeling

$\langle \langle AvailableResourceSpecification \rangle \rangle$

• Extends: Property;

• Semantics: The execution context of any software service is composed by the available resources. The resource concept is informally reported. Its concrete subclasses (BatterySpecification, MemorySpecification, ProcessorSpecification, ScreenSpecification) are used to add information about the resources required for the execution of a software service according to a certain QOS profile.

• Properties: None;

• Notation: as for Property;

• Constraints: The ownerClassifier has to be a ContextSpecification.

$\langle \langle ComponentOperationSpecification \rangle \rangle$

• Extends: Operation;

• Semantics: It is a Operation that implements (part of) a OperationSpecification declared by a ServiceDescription;

• Properties: None;

• Notation: as for Operation;

• Constraints:

  • Its owner component must be a ComponentSpecification.

$\langle \langle ComponentSpecification \rangle \rangle$

• Extends: Component;

• Semantics: It represents a software component that implements (part of) the ServiceDescription;

• Properties: None;

• Notation: see Fig. 27;

• Constraints: None.

Fig. 27

ComponentSpecification notation

$\langle \langle ServiceRealization \rangle \rangle$

• Extends: Realization;

• Semantics: A ServiceRealization is a special kind of realization. It is a specialized abstraction relationship between two elements, the former representing a specification (ServiceDescription, the supplier) and the latter representing a possible implementation (ComponentSpecification, the client).

• Properties: None;

• Notation: as for Realization;

• Constraints:

  • The supplier must be a ServiceDescription;

  • The client must be a ComponentSpecification.

1.1.3 A.1.3 Stereotypes for hardware platform modeling

$\langle \langle BatterySpecification \rangle \rangle$

• Extends: Property;

• Generalization: AvailableResourceSpecification;

• Semantics: It models the battery of a battery-powered device used to access the software services. It extends the abstract AvailableResourceSpecification stereotype;

• Properties:

  • Unit : Battery Unit. It represents the unit of value used to measure the amount of power stored within the battery;

• Notation: as for Property;

• Constraints: None.

$\langle \langle DeviceQoSSpecification \rangle \rangle$

• Extends: Artifact;

• Semantics: It defines a quality profile of devices exploited by service consumer(s). The ubiSOAP middleware is in charge of adapting the service according to the resources available on users’ devices.

• Properties:

  • Battery : BatterySpecification [1];

  • Memory : MemorySpecification [1];

  • Network : Network[*];

  • Processor : ProcessorSpecification [1];

  • Screen : ScreenSpecification [1];

• Notation: see Fig. 28;

• Constraints: None.

Fig. 28

DeviceQosSpecification notation

$\langle \langle MemorySpecification \rangle \rangle$

• Extends: Property;

• Generalization: AvailableResourceSpecification;

• Semantics: It is used to model information about memory of device. They can be wireless resource-constrained handheld devices with limited memory. Software services need to cope with the optimization of memory footprint on these kind of devices. It extends the abstract AvailableResourceSpecification stereotype and its is used to define the DeviceQoSSpecification.

• Properties:

  • Unit : Memory Unit. It represents the unit of value used to measure the amount of memory available on device;

• Notation: as for Property;

• Constraints: None.

$\langle \langle NetworkQoSSpecification \rangle \rangle$

• Extends: Artifact;

• Semantics: It defines a quality profile of a point-to-point communication established among service consumer(s) and service provider(s). The ubiSOAP middleware is in charge of selecting the best Network available according to such a QoS profile.

• Properties:

  • Bitrate : String;

  • PacketLoss : String;

  • PowerConsumption : String;

  • TransferDelay : String;

• Notation: see Fig. 29

• Constraints: It can only participate as a target association end of ServiceAdaptation relationships.

  Fig. 29

  

  NetworkQoSpecification notation

$\langle \langle Network \rangle \rangle$

• Extends: Node,Port;

• Semantics: It represents a possible physical communication channel among services and, then, a possible hop in a network infrastructural path;

• Properties: None;

• Notation: as for Node and Port;

• Constraints: It is used in Service Deployment Diagrams. It has to be modeled as Node at the Hosts Level and as Port of Places at the Physical Locations Level.

$\langle \langle ProcessorSpecification \rangle \rangle$

• Extends: Property;

• Generalization: AvailableResourceSpecification;

• Semantics: It is used to model information about the CPU of a device. It can be wireless, resource-constrained handheld device with a limited CPU. Then, software services need to cope with the optimization of CPU utilization of this kind of devices. It extends the abstract AvailableResourceSpecification stereotype and it is used to define the DeviceQoSSpecification.

• Properties:

  • Unit : Processor Unit. It represents the unit of value used to measure the processing power of CPU;

• Notation: as for Property;

• Constraints: None.

$\langle \langle ScreenSpecification \rangle \rangle$

• Extends: Property;

• Generalization: AvailableResourceSpecification;

• Semantics: It is used to model information about the screen of a device. It can be a wireless, resource-constrained handheld device with limited screen dimensions and resolutions. Then, software services need to cope with different capabilities to display information. It extends the abstract AvailableResourceSpecification stereotype, and it is used to define the DeviceQoSSpecification.

• Properties:

  • Width : Integer [1]: screen width (in pixel);

  • Height : Integer [1]: screen height (in pixel);

  • Color : Boolean [1]: determines if the screen support colors or not.

• Notation: as for Property;

• Constraints: None.

1.2 A.2 Physical mobility package

These packages include the stereotypes for representing the physical mobility of nomadic users exploiting ubiquitous services based on ubiSOM. Its stereotypes allow the representation of physical mobility patterns as introduced in [35].

$\langle \langle AllowedNodeLocation \rangle \rangle$

• Extends: Relationship;

• Semantics: It is used to model the possible physical location of the hosts where the artifacts (e.g., executables) of ubiquitous software services are deployed.

• Properties: None;

• Notation: as for Relationship;

• Constraints: The target must be a Place.

$\langle \langle PHMobContext \rangle \rangle$

• Extends: State;

• Semantics: It is used to model the configuration (in terms of available software and hardware resources as represented on Service Deployment Diagrams) of current physical location of a nomadic user. It determines the actual AllowedNodeLocation relationship from the Hosts to the Physical Locations Levels on a Service Deployment Diagram.

• Properties: None;

• Notation: as for State;

• Constraints: It must be included as a state within a PHMobPattern. All the ingoing and outgoing transitions have to be PHMobTranstions.

$\langle \langle PHMobPattern \rangle \rangle$

• Extends: StateMachine;

• Semantics: It is used to model the physical mobility pattern of a nomadic user that exploits an ubiquitous service. It includes a set PHMobContexts states and their corresponding PHMobTransitions. It determines the set of the AllowedNodeLocation relationships from the Hosts to the Physical Locations Levels on a Service Deployment Diagram.

• Properties: None;

• Notation: as for StateMachine;

• Constraints: None.

$\langle \langle PHMobTransition \rangle \rangle$

• Extends: Transition;

• Semantics: It represents a physical move from one physical location to another. It causes the change of the actual AllowedNodeLocation relationship from the Hosts to the Physical Locations Levels on a Service Deployment Diagram.

• Properties:

  • Unit : Processor Unit. It represents the unit of value used to measure the processing power of CPU;

• Notation: as for Transition;

• Constraints: Source and target states have to be PHMobContexts.

$\langle \langle Place \rangle \rangle$

• Extends: Node;

• Semantics: It represents a physical location on the Physical Locations Level on Service Deployment Diagrams. The nesting of places can be used to model a physical containment of a (nested) place(s) within a (nesting) place. Ports may be used to model the available communication networks. A place is the target association ends of AllowedNodeLocation relationships.

• Properties:

  • Unit : Processor Unit. It represents the unit of value used to measure the processing power of CPU;

• Notation: as for Property;

• Constraints: None.

Appendix B: comparing ubiDSE with SoaML

In this appendix, we briefly compare ubiDSE with the service-oriented architecture Modeling Language (SoaML) [19] by highlighting the possible similarities and differences between the corresponding profiles.

SoaML aims at supporting the following modeling capabilities in UML:

• Identifying services, the requirements they are intended to fulfill and the anticipated dependencies between them.

• Specifying services, the functional capabilities they provide, what capabilities consumers are expected to provide, the protocols or rules for using them, and the service information exchanged between consumers and providers.

• Defining service consumers and providers, what requisition and services they consume and provide, how they are connected and how the service functional capabilities are used by consumers and implemented by providers in a manner consistent with both the service specification protocols and fulfilled requirements.

• The policies for using and providing services.

• The ability to define classification schemes having aspects to support a broad range of architectural, organizational, and physical partitioning schemes and constraints.

• Defining service and service usage requirements and linking them to related OMG metamodels.

• SoaML focuses on the basic service modeling concepts, and the intention is to use this as a foundation for further extensions both related to integration with other OMG metamodels.

ubiDSE shares with SoaML the first four modeling capabilities. Similarities emerge as overlapping concepts like services architecture, service, consumer, provider as shown in Table 1 where we list possible mappings between the ubiDSE stereotypes and the corresponding SoaML stereotypes (when applicable).

Table 1 Comparison among SoaML and ubiDSE stereotypes

The comparison does not take into account the corresponding base metaclasses from the UML metamodel. Indeed, different choices in stereotypes’ metaclasses affect the usage of stereotypes at the model level. In this respect, SoaML uses Collaboration and CollaborationUse metaclasses from UML to define roles and to bind them to Participants in the service provision. Conversely, ubiDSE adopts Activities and the ad hoc Business Process Description Diagram (see Sect. 8) to model service orchestrations.

It is worth noting that ubiDSE focuses on the modeling of component-based services that are deployed on and communicate over ubiquitous networking environments. Furthermore, services in ubiDSE are context-aware and adaptive to changes of the underlying network resources. Therefore, specific modeling constructs for representing the following elements are out of the scope of SoaML, which does not provide any stereotype (see the “–” entries in Table 1) for dealing with such modeling concerns:

• Heterogeneous communication networks (centered on the concept of network infrastructural path),

• Physical mobility (based on the representation of places and physical mobility patterns),

• Context (as the integration of information about B3G networks and physical locations of users),

• Adaptation (triggered and managed by the ubiSOAP middleware as response to violations of network-related QoS profiles).