SERVICE-ORIENTED

SOFTWARE ENGINEERING
Presenters:
Lyn Ciara Cabrera
John Paul Valdez
Steven Edward Montalvo
Drexel Santos
Mark Andrew Tomenio
John Nische Campang
OBJECTIVES
THE OBJECTIVE OF THIS CHAPTER IS TO INTRODUCE SERVICE-
ORIENTED SOFTWARE ENGINEERING AS A WAY OF BUILDING
DISTRIBUTED APPLICATIONS USING WEB SERVICES. WHEN YOU
HAVE READ THIS CHAPTER, YOU WILL:
■ understand the basic notions of a web service, web service standards,
and service-oriented architecture;
■ understand the idea of RESTful services and the important
differences between RESTful and SOAP-based services;
■ understand the service engineering process that is intended to produce
reusable web services;
■ understand how workflow-based service composition can be used to
create service-oriented software that supports business processes.
Contents
18.1 Service-oriented architecture
18.2 RESTful services
18.3 Service engineering
18.4 Service composition
 The development of the Web in the 1990s
revolutionized organizational information exchange.
• However, access was solely through a web browser, and direct
access to the information by other programs was not practical. This
meant that opportunistic connections between servers, where, for
example, a program could query a number of catalogs from different
suppliers, were not possible.
• To get around this problem, web services were developed that
allowed programs to access and update resources available on the
web. Using a web service, organizations that wish to make their
information accessible to other programs can do so by defining and
publishing a programmatic web service interface. This interface
defines the data available and how it can be accessed and used.
 The development of the Web in the 1990s
revolutionized organizational information exchange.
• More generally, a web service is a standard representation
for some computational or information resource that can be
used by other programs. These may be information
resources, such as a parts catalog, computer resources, such
as a specialized processor, or storage resources. For
example, an archive service could be implemented that
permanently and reliably stores organizational data that, by
law, has to be maintained for many years.
• A critical distinction between a service and a
software component, as defined in component-based
software engineering, is that services should be
independent and loosely coupled.

• Therefore, web services do not have a “requires”

interface that, in CBSE, defines the other system
components that must be present. A web service
interface is simply a “provides” interface that defines
the service functionality and parameters.
Service-oriented systems
• are a way of developing distributed systems where
the system components are stand-alone services,
executing on geographically distributed computers.
Services are platform and implementation-language
independent. Software systems can be constructed
by composing local services and external services
from different providers, with seamless interaction
between the services in the system.
• Software as a service means offering software
functionality to users remotely over the web,
rather than through applications installed on a
user’s computer. Service-oriented systems are
systems that are implemented using reusable
service components and that are accessed by
other programs, rather than directly by users.
Software that is offered as a service may be
implemented using a service-oriented system.
Adopting a service-oriented approach to software
engineering has a number of important benefits:
1. Services can be offered by any service provider inside or
outside of an organization. Assuming these services
conform to certain standards, organizations can create
applications by integrating services from a range of
providers.
2. The service provider makes information about the
service public so that any authorized user can use the
service. The service provider and the service user do not
need to negotiate about what the service does before it
can be incorporated in an application program.
Adopting a service-oriented approach to software
engineering has a number of important benefits:
3. Applications can delay the binding of services
until they are deployed or until execution. Therefore, an
application using a stock price service (say) could,
in principle, dynamically change service providers
while the system was executing. This means that
applications can be reactive and adapt their operation
to cope with changes to their execution environment.
4. Opportunistic construction of new services is
possible. A service provider may recognize new services
that can be created by linking existing services in
innovative ways.
Adopting a service-oriented approach to software
engineering has a number of important benefits:
5. Service users can pay for services according to
their use rather than their provision. Therefore, instead of
buying an expensive component that is rarely used,
the application writer can use an external service that
will be paid for only when required.
6. Applications can be made smaller, which is
particularly important for mobile devices with limited
processing and memory capabilities. Some
computationally intensive processing and exception
handling can be offloaded to external services.
SERVICE-ORIENTED
ARCHITECTURE
• Service-oriented architecture (SOA) is an architectural
style based on the idea that executable services can be
included in applications. Services have well-defined,
published interfaces, and applications can choose
whether or not these are appropriate. An important
idea underlying SOA is that the same service may be
available from different providers and that applications
could make a runtime decision of which service
provider to use.
• Web service protocols cover all aspects of service-
oriented architectures, from the basic mechanisms for
service information exchange (SOAP) to programming
language standards (WS-BPEL). These standards are
all based on XML, a human and machine readable
notation that allows the definition of structured data
where text is tagged with a meaningful identifier.
XML has a range of supporting technologies, such as
XSD for schema definition, which are used to extend
and manipulate XML descriptions. Erl (Erl 2004)
provides a good summary of XML technologies and
their role in web services
Briefly, the fundamental standards for service-
oriented architectures are:
1. SOAP This is a message interchange standard that supports
communication between services. It defines the essential and optional
components of messages passed between services. Services in a
service-oriented architecture are sometimes called SOAP-based
services.
2. WSDL The Web Service Description Language (WSDL) is a standard
for service interface definition. It sets out how the service operations
(operation names, parameters, and their types) and service bindings
should be defined.
3. WS-BPEL This is a standard for a workflow language that is used
to define process programs involving several different services. I
• The UDDI (Universal Description, Discovery, and
Integration) discovery standard defines the
components of a service specification intended to help
potential users discover the existence of a service.
This standard was meant to allow companies to set up
registries, with UDDI descriptions defining the
services they offered. Some companies set up UDDI
registries in the early years of the 21st century, but
users preferred standard search engines to find
services. All public UDDI registries have now closed.
There are many supporting standards because they are
intended to support SOA in different types of enterprise
application. Some examples of these standards include:
1. WS-Reliable Messaging, a standard for message exchange that
ensures messages will be delivered once and once only.
2. WS-Security, a set of standards supporting web service security,
including standards that specify the definition of security policies
and standards that cover the use of digital signatures.
3. WS-Addressing, which defines how address information should be
represented in a SOAP message.
4. WS-Transactions, which defines how transactions across distributed
services should be coordinated
SERVICE COMPONENTS IN AN SOA
• Message exchange, as I explained in Section 17.1, is an important
mechanism for coordinating actions in a distributed computing
system. Services in a SOA communicate by exchanging messages,
expressed in XML, and these messages are distributed using
standard Internet transport protocols such as HTTP and TCP/IP
The WSDL specification defines three aspects of a Web
service: what the service does, how it communicates, and
where to find it:
1. The “what” part of a WSDL document, called an interface,
specifies what operations the service supports and defines the
format of the messages sent and received by the service.
2. The “how” part of a WSDL document, called a binding, maps
the abstract interface to a concrete set of protocols. The binding
specifies the technical details of how to communicate with a Web
service.
3. The “where” part of a WSDL document describes the location
of a specific Web service implementation (its endpoint).
The WSDL conceptual model (Figure 18.4) shows the
elements of a service description. Each element is
expressed in XML and may be provided in separate files.
These elements are:
1. An introductory part that usually defines the XML
namespaces used and that may include a documentation
section providing additional information about the service.
2. An optional description of the types used in the messages
exchanged by the service.
3. A description of the service interface, that is, the operations
that the service provides for other services or users.
The WSDL conceptual model (Figure 18.4) shows the
elements of a service description. Each element is
expressed in XML and may be provided in separate files.
These elements are:
4. A description of the input and output messages processed
by the service.
5. A description of the binding used by the service, that is, the
messaging protocol that will be used to send and receive messages. The
default is SOAP, but other bindings may also be specified. The binding
sets out how the input and output messages associated with the service
should be packaged into a message, and specifies the communication
protocols used.
The WSDL conceptual model (Figure 18.4) shows the
elements of a service description. Each element is
expressed in XML and may be provided in separate files.
These elements are:
6. An endpoint specification that is the physical location of
the service, expressed as a URI—the address of a resource that can be
accessed over the Internet.
18.2 RESTful services
 Evolution of Web Services: From
Standards-Based to Lightweight REST
Architecture
REST Architecture Basics
• REST (Representational State Transfer)
is an architectural style based on
transferring representations of
resources.
• Resources, represented as data
elements, have unique identifiers
(URLs).-
• Fundamental operations include Create,
RESTful Operations
• POST: Create a resource with
associated data.
• GET: Read the value of a resource and
return it in a specified representation.
• PUT: Update the value of a resource.
• DELETE: Delete the resource.
Web as an Example
• The web follows a RESTful architecture
where web pages are treated as
resources.
• HTTP and HTTPS protocols use actions
like POST, GET, PUT, and DELETE.
Use of URLs in RESTful
Architecture
• Resources are accessed using URLs,
making data exposure transparent.
• Examples of accessing weather data for
different locations using URLs.
Representation Formats

• RESTful services are not exclusively

XML-based.
• JSON (Javascript Object Notation) and
XML can be used, offering more
efficient processing.
Stateless Design Principle

• RESTful services are designed to be

stateless.
• State information is returned to the
requestor, enhancing system
performance.
Advantages and Challenges
• Advantages: Lower overhead, better
performance for mobile devices, easy
integration with existing websites.
• Challenges: Complex interfaces, lack
of standard interface description, and
the need for self-implemented
infrastructure.
Dual Approach
• Both SOAP-based and RESTful
interfaces can coexist for the same
service or resource.
• Common for cloud services from
providers like Microsoft, Google, and
Amazon.
18.3 Service Engineering
RESTful Services Design Principle:
Stateless
• Resource in interaction session should be
stateless.
• No inherent state information in the resource.

• Necessary state info returned to the requestor.

• If needed later, returned to server by

Advantages of RESTful Services
• Widely used due to mobile device
prevalence.
• Lower overhead for better system
performance.
• Easy integration with existing websites.
• Straightforward implementation of
RESTful API.
Challenges with RESTful Approach
• Complex interfaces pose design
challenges.
• Lack of standards for interface
description.
• Reliance on informal documentation by
users.
• Need to implement own infrastructure for
monitoring and quality management.
Comparison with SOAP-based
Services
• RESTful vs. SOAP: Infrastructure and
Standards.
• SOAP offers additional standards like
WS-Reliability.
• RESTful requires self-implemented
infrastructure.
Pautasso et al.'s Insights (2008)
• Discussion on when to use RESTful vs.
SOAP-based.
• Possibility of providing both interfaces.
• Common dual approach in cloud services
(Microsoft, Google, Amazon).
Service Access Flexibility
• Users can choose access method based on
application needs.
• Dual SOAP and RESTful interfaces for
adaptability.
• Illustration in Figure 18.7 for clarity.
Introduction to Service Engineering
• Definition: Process of developing services
for reuse in service-oriented applications.
• Similarities with Component Engineering.
Service Engineers' Responsibilities
• Ensure service represents a reusable
abstraction.
• Design and develop generally useful
functionality.
• Ensure robustness and reliability.
• Document services for discoverability and
understanding by users.
Logical Stages in Service Engineering
Process
1. Service Candidate Identification
- Identify potential services.
- Define service requirements.
2. Service Design
- Design logical service interface.
- Implement interfaces (SOAP-based
and/or RESTful).
Logical Stages in Service Engineering
Process
3. Service Implementation and Deployment
- Implement and test the service.
- Make service available for use.
Implementation of Reusable Services

• Start with existing service or component.

• Generalize by removing application-specific

features.

• Implementation involves adapting and adding

service interfaces.
Include Figure 18.8 to visually represent the three logical stages
in the service engineering process.
SERVICE INTERFACE DESIGN
OVERVIEW
• Service engineering progression:
Identify candidates ➔ Design
interfaces.
• Focus on designing service
interfaces for SOAP-based and
RESTful services.
ABSTRACT INTERFACE
DESIGN

• Starting point: Abstract interface

design.
• Identify entities, operations, inputs,
outputs, and exceptions.- Transition
to SOAP or RESTful realization.
SOAP-BASED APPROACH

• If SOAP-based: Design XML

message structure.
• Define operations and messages in
WSDL.
RESTFUL APPROACH

• If RESTful: Design mapping of

service operations to RESTful
operations.
• Consider required resources and
standard operations.
ABSTRACT INTERFACE DESIGN
PROCESS

• Originates from service

requirements.
• Define operation names, parameters,
and exceptions.
BALANCING DETAIL IN INTERFACE
DESIGN
• Textual descriptions may suffice in
some cases.
• For detailed designs, use graphical
notations like UML or readable
formats like JSON.
Erl (Erl 2005) suggests that there are three fundamental types of
service
1. Utility services.
• These services implement some general functionality that may be used by different
business processes.
2. Business services.
• These services are associated with a specific business function.
3. Coordination or process services.
• These services support a more general business process that usually involves different
actors and activities.
Exception Handling
"Exception Handling in Service Design"
• Mention the need to map exceptions to
standard HTTP response codes.
• Note the challenge of dealing with a 404 code
for unretrievable URLs.
Task-oriented vs. Entity-oriented Services

• Erl's classification: Task-oriented or entity-

oriented services.
• Task-oriented associated with activities, entity-
oriented with system resources.
• Coordination services are always task-oriented.
Service Candidate Identification Goals

• Identify logically coherent, independent, and

reusable services.
• Utilize Erl's classification to guide the
discovery process.
Service Design Considerations

• Briefly introduce UML diagram annotations

and constraints.
• Mention the challenge of choosing between
RESTful and SOAP-based approaches.
• Emphasize the impact of local circumstances
on the decision-making process.
RESTful Service Design Decisions
• Point 1: "Resource for Company-Specific Catalog"
URL format: `<base catalog>/<company name>`
Creation using POST operation.
• Point 2: "Catalog Item URL"
URL format: `<base catalog>/<company name>/<item
identifier>`
• Point 3: "GET Operations for Retrieval and Search" -
Retrieval using item URL.
Search using GET with company catalog as URL and search
string as query parameter.
Complex Operations in RESTful Service
• Title: "Complex Operations in RESTful Service“
• Point 1: "Compare Operation" -
Sequence of GET operations for items.
POST operation for comparison table creation.
Final GET operation for user retrieval.
• Point 2: "CheckDelivery and MakeVirtualOrder"
Additional resource for virtual order.
POST operation for creation, using company ID for form.
GET operation for retrieval.
Exception Handling
• Title: "Exception Handling in Service Design“
Mention the need to map exceptions to standard HTTP
response codes.
• Note the challenge of dealing with a 404 code for
unretrievable URLs.
• Acknowledge that further details on this issue are
essential but not covered in the presentation.
Exception Handling
• Title: "Exception Handling in Service Design“
Mention the need to map exceptions to standard HTTP
response codes.
• Note the challenge of dealing with a 404 code for
unretrievable URLs.
• Acknowledge that further details on this issue are
essential but not covered in the presentation.
COMPOSITION
INTRODUCTION

• - Service-oriented software engineering revolves

around composing and configuring services to
create composite services.
• - These composite services can integrate with user
interfaces or other service compositions.
COMPOSITE SERVICES

• - Composite services may consist of both RESTful

and SOAP-based services, extending functionality.
• - Companies transition to service-oriented systems
for widespread reuse and integration with external
providers.
INTERORGANIZATIONAL APPLICATIONS

• - The vision of service-oriented systems includes

interorganizational applications among trusted
suppliers.
• - A "services market" may emerge where services
are procured from external suppliers.
SERVICE COMPOSITION FOR ENHANCED
FUNCTIONALITY

• - Service composition integrates separate business

processes for extended functionality.
• - Example: An airline integrates services from
various providers to offer travelers complete
vacation packages.
WORKFLOW AND BUSINESS PROCESSES

•- Workflow represents a sequence of

activities ordered in time.
•- It models business processes, such as
vacation booking services.
COMPLEXITY IN SERVICE COMPOSITION

• - Service composition involves handling service failures and exceptions.

• - Considerations include accommodating nonstandard demands and handling
incompatibilities between services.
HANDLING INCOMPATIBILITIES:
COMPENSATION ACTIONS

•- Incompatibilities may require undoing

actions and informing the user.
•- Compensation actions are used to undo
completed actions affected by later workflow
activities.
DESIGNING SERVICES WITH REUSE

• - Designing new services involves reusing existing

ones.
• - Requirements must be modified to align with
available services, budget constraints, and
acceptable quality of service.
CONCLUSION

• - Service-oriented software engineering facilitates

composite services for enhanced functionality.
• - It involves managing complexity, handling
incompatibilities, and designing with reuse in mind.
Q&A

•- Invite questions and discussions

from the audience.
WORKFLOW
DESIGN
INTRODUCTION

•- Workflow design involves analyzing

business processes to understand tasks and
information exchange.
•- BPMN (Business Process Modeling
Notation) is commonly used for graphical
modeling.
UNDERSTANDING EXISTING PROCESSES

• - Existing processes may be informal, relying on

individual skills and abilities.
• - Designing workflows requires aligning with
current practices or defining new processes.
BUSINESS PROCESS MODELING NOTATION
(BPMN)

• - BPMN is used to create graphical models of

business processes.
• - Activities, events, gateways, and message flows
are key elements in BPMN.
CONVERTING BPMN TO WS-BPEL

• - With SOAP-based services, BPMN workflows

can be automatically converted into WS-BPEL, an
XML-based workflow language.
• - This facilitates conformity with web service
standards like SOAP and WSDL.
COMPOSING RESTFUL SERVICES

•- RESTful services can be composed within

standard programming languages like Java or
using composition languages for service
mashups.
EXAMPLE BPMN MODEL

• - Display a simplified BPMN model depicting part

of the vacation package scenario, focusing on hotel
booking.
• - Activities like GetRequirements,
CheckAvailability, ReserveRooms, etc., are
represented.
CORE CONCEPTS IN BPMN

• - Rectangles with rounded corners represent activities, which can

be human-executed or automated.
• - Circles represent events, including start, end, and intermediate
events.- Diamonds represent gateways where choices are made.
• - Solid and dashed arrows indicate sequence and message flow
between activities.
CONCLUSION

•- Workflow design involves understanding

business processes and modeling them using
BPMN.
•- BPMN provides a standardized notation for
representing business processes graphically.
Q&A
•- Open the floor for questions and
discussions.
THANK YOU

•- Conclude the presentation and thank the

audience for their attention.
TESTING SERVICE-ORIENTED
SYSTEMS
IMPORTANCE OF TESTING

• - Testing ensures systems meet functional and non-

functional requirements and detects defects.
• - Many techniques rely on analyzing source code,
but this is challenging with external service
providers.
LIMITATIONS OF WHITE BOX TESTING

• - Access to source code is unavailable for external

service implementations.
• - White box testing techniques relying on source
code analysis cannot be used.
CHALLENGES IN TESTING SERVICE
COMPOSITIONS

• 1. Lack of Control Over External Services:- Service providers can

withdraw or modify services, impacting application testing.
• 2. Dynamic Binding:- Applications may not always use the same
service, leading to uncertain test outcomes.
• 3. Non-Functional Behavior Variability:- Service performance
may differ under actual usage conditions compared to testing
scenarios.
CHALLENGES IN TESTING SERVICE
COMPOSITIONS

• 4. Costly Payment Models:- Testing services can be

expensive, especially with subscription or pay-per-use
models.
• 5. Testing Compensation Actions:- Simulating service
failures for testing compensation actions is difficult.
ACUTE CHALLENGES WITH
EXTERNAL SERVICES
• - Testing complexities are heightened with external
services due to limited control and payment
models.
• - Source code availability and trust between
cooperating companies can alleviate some
challenges.
RESEARCH NEEDS AND FUTURE
DIRECTIONS
• - Resolving testing challenges for service-oriented
applications remains a critical research area.
• - Guidelines, tools, and techniques are needed to
address the unique testing requirements of service-
oriented systems.
CONCLUSION

• - Testing service-oriented systems presents unique

challenges due to external service dependencies.
• - Future research efforts aim to develop effective
testing strategies and tools for service-oriented
applications.
Q&A
•- Invite questions and discussions
from the audience.
THANK YOU
•- Conclude the presentation and express
gratitude to the audience.