Level: Introductory Mohammad Abu-Matar (abumatar@hotmail.com), Senior software engineer, LexisNexis
31 Jul 2007 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.
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.
Requirements activities
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.
Analysis activities
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.
Design activities
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
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.
Analysis activities
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.
Design activities
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.
Summary
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.
Resources Learn
- Visit the
CBDI Service Oriented Architecture Practice Portal.
- Read
"Elements of Service-Oriented Analysis and Design"
(developerWorks, June 2004).
- Read
"What Is
Business Process Modeling."
- Read
"Methodological support for service-oriented design with ISDL."
- Examine a Web service parameterization example,
where Web services are modeled using the UML class diagrams, in
"Modeling the
Variability of Web Services from a Pattern Point of View."
- Learn more about SPL in
Designing
Software Product Lines with UML, by Hassan Goma.
- Read
"UML 2.0 Profile for Software Services" (developerWorks, April 2005).
- Read
"Toward a Programming Model for Service-Oriented Computing."
- Learn the basics of UML diagramming in
UML
Distilled, by Martin Fowler.
- Visit UDDI.org.
- Read
"Speaking
a Common Language: A Conceptual Model for Describing Service-Oriented Systems."
- Learn more about SOA in
Service-Oriented
Architecture (SOA): Concepts, Technology, and Design, by Thomas Erl.
- Read
"Systematic
Development and Exploration of Service-Oriented Software Architectures."
- Read
"Product
Lines for Supporting the Composition and Evolution of Service Oriented Applications."
- Read
"Service-oriented modeling and architecture" (developerWorks, November 2004).
- Read
"Automatic
Composition of E-Services that Export Their Behavior (PDF)."
- Browse the
technology bookstore
for books on these and other technical topics.
-
IBM on demand demos to learn about various software products and technologies from IBM.
- Stay current with
developerWorks technical events and webcasts.
Get products and technologies
Discuss
About the author  | | | Mohammad Abu-Matar is a senior software engineer with more than 13 years of
technical experience in research, architecture, systems engineering, software
design, and development. He has a BS in Electrical Engineering and an MS in
Information Technology (Object Technologies), and is also a Ph.D. candidate in
Information Technology (Software Engineering). Mohammad works for LexisNexis, a
major research and data provider for the legal, business, and government sectors. |
Rate this page
| 
