Summary: ln this article, learn about a method to design service-oriented applications based on software product lines principles. Explore a Service-Oriented Software product lines (SoSPL) methodology that applies SPL variability analysis techniques to Web services to design customized service-based applications. Find out how software product lines (SPL) promote agile and flexible application development for evolving system families. And discover how the adoption of SPL principles can provide a systematic way to analyze and design service-oriented applications.
Date: 31 Jul 2007
Level: Introductory
Activity: 1352 views
Comments: 0 (Add comments)
Average rating (based on 7 votes)
Service-Oriented Architecture (SOA) has emerged as a standard-based computing model for designing, building, and deploying flexible distributed software applications. SOA emphasizes extremely loosely coupled design approaches where disparate systems with different computing platforms can collaborate and evolve without major changes to their core architectures. Services are designed as self-contained modules that can be advertised, discovered, composed, and negotiated on demand.
Software product lines (SPL) are families of software systems that share common functionality, but each member has variable functionality. The main goal of SPL is the agile and speedy development of member systems by taking advantage of reusable assets from all phases of the development life cycle. This goal is similar to SOA's goals.
Despite the wide academic and industrial activities related to SOA, no systematic end-to-end methodology exists to analyze and design service-oriented applications. On the other hand, SPL is an established field with considerable methodological support. When I began working with SPL, it became clear that combining SOA and SPL would be a powerful way to build complex evolving systems. However, only a few organizations, such as the CBDI Service Oriented Architecture Practice Portal (see Resources) touch on the similarities between SOA and SPL. A combined methodology can help elevate service-oriented computing to the mainstream.
This article explores the activities needed in a service-oriented SPL methodology that spans all phases of the development life cycle—a Service-Oriented Software Product Lines (SoSPL) methodology. Such a methodology could raise SOA's state of the art by incorporating SPL principles.
The article briefly presents a methodology for service-oriented single (non-family) systems followed by a methodology for SoSPL that extends the methodology to SPLs.
Service Oriented Analysis and Design for single systems
At the heart of the SoSPL methodology are Service Oriented Analysis and Design (SOAD) activities. SOAD is an emerging field concerned with identifying and building services based on business requirements. SOAD treats services as first-class entities, much like Object Oriented Analysis and Design (OOAD) treats classes and objects.
The typical starting point in OOAD is use-case models, but the starting point in SOAD is business-process modeling.
Business process modeling (BPM) is normally used to illustrate service requirements. A business process is a set of related business tasks that are performed to achieve a certain goal. The focus is on business processes rather than use cases. No actors are modeled, and the emphasis is on the business process's behavior from the business point of view.
You can model business processes using Unified Modeling Language (UML) activity diagrams. Activity diagrams are particularly useful in detailing the workflow of business processes during domain business modeling. Figure 1 shows a hotel reservation process. Each activity in the diagram represents a high-level activity that contains subactivities.
Figure 1. UML activity diagram for a hotel reservation process
See a larger version of this image.
The outcome of this phase is a set of BPM models represented in UML activity diagrams that describe the business process behavior.
Candidate services are identified based on the requirement model. Identifying reusable services is a major goal, because reusability is one of the most important service orientation benefits. A business process model can be implemented by a single service or by multiple services.
You can analyze business process models to identify reusable autonomous operations. The goal is to specify the most essential operations that satisfy the desired business process so you can logically group them into candidate services. You must decide whether to group all operations in one service or group related operations into different services.
Candidate services are categorized based on the roles they play in the target application. You can develop a UML metaclass model to describe the categories, like the model presented in the developerWorks article "UML 2.0 Profile for Software Services" (see Resources). In addition to the stereotypes described in that article, you can identify the stereotypes listed in Table 1.
Table 1. Service structuring criteria
| Stereotype | Role |
|---|---|
abstract service |
Non-concrete; not bound to an actual service implementation |
application service |
Concrete |
standalone service |
Not allowed to be part of a composition |
composable service |
Allowed to be part of a composition |
composite service |
Made of two or more services |
entity centric service |
Data intensive |
task centric service |
Business logic |
controller service |
Controls and coordinates other services |
monitor service |
Monitors other services |
The outcome of the analysis phase is a metaclass model that describes candidate services, their role stereotypes, and their operations.
In this phase, you design candidate services that you identified in the analysis phase.
A service interface is a description of the operations provided by the service. It details operations, input/output parameters, and message types. You can also specify other services required by candidate services. Service interface design requires you to specify both provided and required interfaces. (To learn more about detailed operation- and message-design steps based on Web services, refer to the book Service-Oriented Architecture Concepts, Technology, and Design; see Resources.)
You can analyze choreography models produced in the analysis phase to determine which services need to be built from scratch and the existing services you can use. In addition, you should examine legacy systems to determine whether some of their functionality can be exposed as services and included in the composition.
Verifying composition ensures the compatibility of services that participate in the composition. You can use one of the formal or informal verification techniques described in "Automatic Composition of E-Services that Export Their Behavior" (see the Resources section).
The outcome of this phase is a multiview model that shows all participant services, their required and provided interfaces, and their sequence of invocation.
SOAD for software product lines
To build SoSPLs, you must extend the activities described for single systems, as explained in the following sections.
Requirements activities must be augmented with commonality and variability analysis. You need to transition from business process models to feature models. Feature models are widely used in the SPL requirements commonality and variability analysis phase to model all possible configurations of SPL member applications. Related features are grouped into feature groups. Product line members select their desired features from feature groups.
Services can be used in several systems through customization. A basic, or generic, service can be invoked by several systems with varying functionalities. To be used in software product lines, services need to be analyzed with variability in mind.
You can model requirements variability by introducing variation points in your UML activity diagrams. To do so, use the branches and guards constructs along with UML stereotypes that indicate the location of variability (variation points) and the variant behavior to be inserted at those variation points.
Figure 2 shows some variation points in the hotel reservation activity diagram. The variation points differentiate between convention, residential, and conference reservations.
Figure 2. Variations in the UML activity diagram for hotel reservation process
See a larger version of this image.
Following the classification presented in the book Designing Software Product Lines with UML (see the Resources section), you need to identify common, optional, and alternative features. Common features are requirements that are present in all members of the product line. Optional features are requirements that are present in some members of the product line, and alternative features are requirements that some members of the product line choose from.
You can identify features based on the variation points in your business process activity diagrams. Each variation point can map to an individual feature, or several variation points can map to one feature. In addition, an entire business process can be mapped to one feature, or a feature can encompass several business processes.
Finally, you develop a feature model (expressed in UML metaclass diagrams) for the entire product line, as shown in Figure 3.
Figure 3. UML metaclass feature model for a hotel reservation process
See a larger version of this image.
First, you identify candidate services that are common to all members of the product line, using the method described in the analysis section for single systems. Then, consider optional and alternative services by using the same techniques for single systems discussed earlier.
Next, you analyze variation points identified in the business process models. You must determine whether to model these variation points as part of one service or as part of several services. If the variation points are small, model one service candidate by applying the variation points on the service's operations and parameters. However, if the variation points are rampant in the business process model, a more manageable approach is to logically group related features into separate services.
When you're grouping all variation points in one service, consider a parameterized service approach. Parameterization can be applied to the service's operations, parameters, and messages. (See the Resources section for a Web service parameterization example.)
When you're grouping related features into separate services, you can achieve variability by discovering and binding to different services based on the features they provide. Feature modeling can give you an early indication of the compositional nature of the software product line members' services. Services need to be composed in a specific sequence to deliver the required features. So, variability can affect the participant services and their order of execution in a composition.
You can develop a feature/service dependency model similar to the feature/class dependency model described in the book Designing Software Product Lines with UML (see Resources). In this model, services must be stereotyped to indicate whether they're already available (static selection) or they need to be discovered (dynamic selection), in addition to their role and reusability stereotypes.
First, you design services that are common to all members of the product line, using the method described in the design section for single systems. Then, consider optional and alternative services by using the same techniques for single systems.
Next, you need to design variation points identified during feature analysis. Variation points can be implemented by parameterized services or by multiple services participating in a composition.
You can apply parameterization to several aspects of services to achieve variability:
- Operations and parameters variability—You can parameterize operations and parameters at the interface definition level. Web Service Definition Language (WSDL) documents can be used to implement variability. Each element in a WSDL document can be considered a candidate for a variation point. Adding elements and reordering operations doesn't break backward compatibility in WSDL. So, you can evolve services based on product-line features without introducing separate WSDL documents.
- Transport variability—Variation points can be implemented in a service's transport protocol. For example, one SPL member may select SOAP as a transport protocol, whereas another member selects FTP. This transport choice can be parameterized in the WSDL documents.
- Endpoint variability—Variation points can be implemented in the location choice for a service. For example, some product line members may specify multiple Uniform Resource Identifiers (URI), whereas others specify only one location. You may need multiple endpoints for fault tolerance or data replication. Endpoint specification can be parameterized in WSDL as well.
- Discoverability and binding variability—Variation points can be implemented in the way the product line members are discovered and bound to. You advertise services in public registries by exposing certain characteristics. SPL members can parameterize these advertised characteristics to control how clients discover and bind to them. You can use Universal Description, Discovery, and Integration (UDDI) discovery technology for this purpose.
- Error-handling variability—Variation points can be implemented in the way product line members process their error handling. Error handling can be parameterized based on feature conditions that dictate the actions taken in certain situations. For example, some product line members may log error messages, and others may try a predetermined corrective action.
You can use several design patterns (such as Strategy and Decorator) to implement the identified variation points in services. The Strategy pattern can be used to implement operations' variability, and the Decorator pattern can be used to implement parameters' variability.
When you group related features into several services, variations can be implemented by building feature-based services using the Business Process Execution Language for Web Services (BPEL4WS). BPEL4WS is an XML-based process-composition language used to define the composition of several services, called partners, to achieve specific business needs. Using BPEL4WS's conditional and invocation constructs, you can select feature-based services dynamically or statically. In dynamic selection, the process encompasses a discovery mechanism like UDDI. UDDI's programmatic interfaces can be exploited to search for specific services that provide the required features for a product line member.
Feature group names, identified in the analysis section, can map to conditions in BPEL4WS. By using the switch and invoke constructs, you can select services based on their feature group names. Then, when a specific service is selected based on its feature group, you can achieve finer feature selection by using the switch and invoke constructs again to select individual features inside the service.
You can use several design patterns, such as Composite, Iterator, and Chain of Responsibility, to implement composition variation between services. The Composite pattern can be used to implement the composite service that encompasses other subservices, whereas the Iterator pattern can be used to implement the traversal of subservices. In addition, you can use the Broker architectural pattern to design the architecture for such a composition.
In this article you learned about a method to design service-oriented applications based on software product lines principles. You can apply SPL variability analysis techniques to Web services to design customized service-based applications. The adoption of SPL principles helps designers by providing a systematic way to create customized service-oriented applications.