Modeling Non-Functional Properties in Service Oriented Architecture

From Distributed Software Systems Group, University of Massachusetts, Boston

(Redirected from SOA)


Hiroshi Wada and Jun Suzuki.

Executive Summary

This project investigates and empirically evaluates two modeling techniques: Unified Modeling Language (UML) profile. The proposed UML profile is used to explicitly and graphically model and maintain non-functiona properties (e.g., security and fault tolerance) of applications in Service Oriented Architecture (SOA), and allows developers to define the non-functional properties without depending on any particular implementation technologies. A supporting tool, called Ark, which generates application code (program code and deployment descriptors) according to a configuration (or instance) of the proposed feature model and a UML model defined with the proposed UML profile.

Objective

In Service Oriented Architecture, the non-functional properties of services and their connections, such as security and fault tolerance, should be defined separately from their functional properties (i.e., business logic) because different applications use services and connections in different non-functional contexts. For example, an application may unicast messages to a service, and another may manycast messages to multiple replicas of the service to improve fault tolerance. The separation between functional and non-functional properties improves the reusability of services and connections. It also enables the two different properties to evolve independently, and improves the ease of understanding application architectures. This contributes to higher maintainability of applications.

This project proposes a model-driven development (MDD) framework for non-functional properties in SOA, through the notion of UML profile and feature modeling. The framework consists of (1) a Unified Modeling Language (UML) profile to visualize non-functional properties, and (2) an MDD tool, called Ark, which generates application code (program code and deployment descriptors) according to a configuration (or instance) of the proposed feature model and a UML model defined with the proposed UML profile. Using the proposed UML profile, non-functional properties can be modeled without depending on any particular implementation technologies.

Novelty

  • Modeling Support for Non-functional Properties in SOA: This project is the first attempt to investigate a UML profile for various non-functional properties in SOA. The proposed UML profile covers the following four areas of non-functional properties
    • Service Deployment Semantics: service redundancy.
    • Message Transmission Semantics: messaging synchrony, message delivery assurance, message queuing, multicast, manycast (for fault tolerance), anycast (for load balancing), message routing, message prioritization, messaging timeout, message logging, and message retention.
    • Message Processing Semantics: message conversion, message split, message aggregation, and message validation.
    • Security Semantics: transport-level encryption, message-level encryption (entire/partial message encryption), message signature, message access control, and service access control
  • Modeling Support for Regulatory Compliance: As regulatory compliance has been becoming an important factor in software development, regulatory mandates (e.g., the Sarbanes-Oxley Act and HIPPA) dramatically increase the number of non-functional properties that application developers need to implement. This project is the first attempt to investigate a modeling language to specifically describe the non-functional properties derived from regulatory mandates.
  • MDD Support for Service-Oriented Applications: Non-functional requirements change during application lifecycle more often than functional properties. When a non-functional requirement (e.g., security policy) changes in an application, application developers make changes in the corresponding non-functional properties of the application and leave its functional part alone. The proposed MDD tool (Ark) generates non-functional code from the updated UML model and combines the existing functional code. Ark makes the applications's functional properties more reusable and extend their longevity, thereby improving the productivity of application development and maintenance.

Details of the proposed UML Profile

This project provides a set of modeling elements to describe non-functional properties as a UML profile. The following figure shows the definition of five key elements in the proposed UML profile: Service, Message, MessageExchange, Connector and Filter.

The Metamodel Definition of the Key Model Elements in the Proposed UML Profile
The Metamodel Definition of the Key Model Elements in the Proposed UML Profile
  • Service: Represents a network service.
  • MessageExchange: Represents a pair of a request and reply messages. Specifies which services send and receive the messages.
  • Message: Represents a (request or reply) message.
  • Connector: Represents a connection between services (i.e., message source and destination). Defines the semantics of message transmission and processing. Specifies which messages (message exchange) to transmit.
  • Filter: Customizes the semantics of message transmission and message processing in a connector.

The following figure shows an example model defined with the proposed UML profile. It illustrates an astrophysical virtual observatory system in which telescopes store space images in distributed archives. In this example, two services (Telescope and AstronomyRawDataArchive) exchange messages. Each service is defined as a class decorated with the stereotype <<Service>>. Services exchange a message (RawData), which is stereotyped with <<Message>>. The data field steteotyped with <<EncryptedProperty>> (metaData) is encrypted with the algorithms specified as tagged-values (algorithm = ...). The connector (BatchConn) works as a queue that stores and forwards RawData messages in a batch mode between Telescopes and an AstronomyRawDataArchive.

Astrophysical Virtual Observatory System
Astrophysical Virtual Observatory System

Code Generation

A supporting tool, called Ark, takes a UML model designed with the proposed UML profile, and generates running code on Mule ESB and Service MIX.

Extensions

This project is extended to support early aspects in business processes by leveraging the notion of aspect oriented programming and feature modeling. You can find the details here.

Publications