Web Services: Implications

for Software Engineering

Kostas Kontogiannis

University of Waterloo

Department of Electrical and

Computer Engineering
 Overview
Distributed Object and Service Technologies

Web Services

Web Services and the application development

lifecycle

Emerging areas
 Network-Centric Computing

Utilize a LAN or WAN as the communication

vehicle between components of the
applications

Leverage the computing power of more than

one system
Enterprise Architecture Evolution

Monolithic Applications (1-tier)

– Mainframe module
– Business logic and
Representational logic
Program
in the same machine Data

– Data can’t be shared

Enterprise Architecture Evolution
Client/Server Applications (2-tier)
– Server implements File Server Database Server

some business logic

Servers
– Client implements the
presentation
Communication Network
logic and some Protocols

business logic
Client
Workstations
 The Problem
Integration of heterogeneous sources:
– operating systems
– programming language
– network protocol
– data representation

Internet Accessibility of
Services
– requires web sites to provide transactional
services, security, messaging, naming services
 Enterprise Architecture Evolution

Distributed Application
– Client implements Tier 1
Clients
the represent logic
Tier 2
– Middle tier provides the Business
business services: Services

Naming service, Tier 3

Software
Transaction service Services

– Backend software processes Application Relational

software or object “Seas of Objects”
the middle tier request databases
 Distributed Computing

Distributed Objects
– The basic idea is that a binary object standard
allows various objects from various vendors,
running on various platforms, to work together to
create an N-Tier client/server application.

Web Services
– The basic idea is to use Web enabled protocols
and standards to access and integrate remote
applications in a transparent way.
 Distributed Objects
Remote components on different computers or
address spaces

Encapsulate the implementation through the

interface

Distributed objects can work independently and

inter-operate via the communication system

Location, language/compiler are transparent to

the end-user
 Web Services
Many definitions available:

– A network-based repository of processes or tasks that can

be used by applications to access data or execute
operations across disparate platforms (NCipher).

– An application capable of being defined [WSD], located via

the Internet protocol, and interacting with other software
applications, identified by a Uniform Resource Identity
(Apple).

– A Web service is a software application identified by a URI,

whose interfaces and bindings are capable of being defined,
described, and discovered as XML artifacts. A Web service
supports direct interactions with other software agents using
XML based messages exchanged via internet-based
protocols (W3C)
 Web Services
A means of integrating applications
regardless of the computing platforms
and programming languages involved

Provide easier and more cost effective

transactions by reducing the complexities
for connecting disparate applications
 Time Line
Web Services

RMI

DCOM
C
O MOM
V
E CORBA
R
A RPC
G
E
Subroutine

1970’s 1980’s 1990’s 2000

 Web Services Stack

Layer Technology O
P
Business Objectives Management, Intents, Goals E
N
Service Negotiation Trading Partner Agreement
Q S
Workflow, Discovery, UDDI, ebXML registries, IBM WSFL, MS o T
Registries XLANG S A
Service Description N
WSDL/WSCL D
Language
A
Messaging SOAP/XML Protocol R
D
Transport Protocols HTTP, HTTPS, FTP, SMTP S
Web Services and the Software
Life Cycle
Using Web Services as a large scale system application
development workbench there are interesting issues to be
considered from the Software Engineering perspective. In
particular issues related to:

– Development Process

– Business Modeling and Economics

– Non Functional Requirements (quality)

– Software Architecture and Design

– Implementation and Testing, and finally,

– Maintenance and Evolution

 Development Process
We experience a trend that shifts away from the
classic Waterfall and Spiral Models towards
Iterative and Incremental models that are also
suited for Object Oriented and Component
Based systems.

A good example of such a suitable process

model that has gained significant attention is the
Unified Model.
Unified Models
Web Services and Unified Processes
Developing Enterprise Applications using the Web
Services paradigm includes the following steps:

– Identify and analyze business models (Inception)

– Integrate business functions into the Web Services paradigm

(Elaboration-1)
– Architect the system (Elaboration-2)

– Create individual new services or wrap existing ones

(Construction-1)
– Identify middleware frameworks to support distribution
(Construction-2)

– Deploy the created services and place them in an executable,

manageable environment (Transition-1)
– Use and manage the new system (Transition-2)
 Web Services, Processes, and
Roles

The RUP roles include the Project Manager, the

Analyst, the Architect, the Modeler, the
Developer, the Tester, and the Deployment and
operational staff.

SOA maps almost identically to this with the

addition of an SOA Modeler role whose job is to
take the conceptual software model and test it
against the SOA model and resources of the IT
infrastructure.
 Checkpoint
Software Life-Cycle Process
The implications of Web Services to Software
Development Process can be summarized as putting
emphasis on:

– project management,
– model driven development,
– risk assessment and mediation,
– change control,
– quality engineering, and
– post-project and peer reviews

Emphasis is also placed on global issues related to

enterprise planning, strategic reuse, operations
support.
 Business Models
A series of business functions within defined
boundaries (e.g. sales, invoicing, marketing,
etc.). Business processes are denoted by
business models.

In an environment where organizations

constantly exchange information and rely on
each-other services it is important to focus on
models that denote and specify collaborative
models or Business Process Networks.
 Web Services and Business
Models

Web services implement activities within a

business process, and business processes in
turn can be externalized as Web services

Web Services flow languages have matured to

a point where a few de-facto standards have
emerged
 Business Models
Depict workflows at a conceptual level
Contain tasks, data, decisions
Objective is to annotate, denote, and represent workflows in a form
that can be read and processed by a software program
 Need for Web Service Flow
Languages
Handling asynchronous Web service invocations and call backs

Handling requests across many in-flight business processes

Parallel invocation of Web services

Roll-backs for long-running transactions

Composing larger business processes out of smaller business

processes

Reliable message delivery

……..
 Private and Public Flows
The activities specified in the public flow are only those
needed to provide users with information on the
execution state.

Private flows specify the full flow of the implementation

of a service and are usually not suitable as a public
description of service behavior.

Public flows have simpler flow of data and control, but

provide full information about the sequencing of service
operations the client process needs to know.
Web Services Flow Languages
Earlier efforts
– XLang,
– BizTalk
– WSFL
– WSCI
– ECA
Emerging Standards
– BPEL4WS
– WS-Transaction
 Customization of Business
Models
Simplification: Removing one or more steps from
an unnecessarily complicated process, or reducing
unnecessary variety in the process by replacing
components to produce stepwise improvements.

Integration: Joining two or more previously

unconnected or uncoordinated processes into a
larger coordinated process by inserting additional
components to create new links.

Transformation: Creating a radically new process

by disassembling the components, and putting
them back together in a new way.
 Checkpoint
Web Services and Business Models
Clear shift towards executable specifications of business
models

Business models can be services themselves

Several XML-based languages to denote and enact

Business Models (BPEL4WS, WSCI, BPML, ebXML,
XPDL.....)

Currently there are no clear standards for flow languages

Enterprise System Architecture in
the Large
Enterprise Systems relate to a multi-tier
heterogeneous architectural style.
– Multi tier (at the highest level),
– distributed (including broker pattern),
– transactional databases,
– event-based communication,
– implicit invocation,
– object-oriented,
– MVC (e.g., for presentation in the client),
– dataflow for workflow, etc.
Heterogeneous Architectures
– (‘Hierarchical heterogeneous’) A Component in one style
may have an internal style developed in a completely
different style (e.g, pipe component developed in OO style,
implicit invocation module with a layered internal structure,
etc.)

– (‘Locational heterogeneous’) Overall architecture at same

level is a combination of different styles (e.g., repository
(database) and mainprogram-subroutine, etc.). Here
individual components may connect using a mixture of
architectural connectors - message invocation and implicit
invocation.

– (‘Perspective heterogeneous’) Different architecture in

different perspectives (e.g., structure of the logical view,
structure of the physical view, etc.)
Enterprise Services
 Web Services Architecture
A Service Provider provides a service interface to a
software component that manages a set of tasks.
A Service Broker acts as a repository for software
interfaces published by service provider.
A Service Requester discovers and invokes software
services.
Web Services Technologies
SOAP
Simple Object Access Protocol
(remote invocation)

WSDL
Web Service Definition
Language (service
characteristics)

UDDI
Universal Description,
Discovery, and Integration
(directory)
 Business Service Networks
BSNs are Internet business communities where
companies collaborate through loosely coupled
business services [Tenenbaum]

Service providers publish details about services

they offer, and corporations in the community
can discover and incorporate these services into
their business flows.
 Reference Deployment
ASP Domain

Client
: Rule
Engin
e
: Internet

: UDDI :
Registr Service
y Provide
r

: UDDI :
Registr Service
Business Service Networks.
y Provide
r
 Service Localization (UDDI)
The Universal Description, Discovery and Integration
(UDDI) is a specification to publish and discover
information about remote services.

Three major parts:

– The business registration module “white pages” denoting the

address, contact, and known identifiers for the service offering;

– “yellow pages” for providing a categorization of the offered

service according to standard taxonomies and;

– “green pages” for denoting technical information about the

offered services.
 Service Interface Description
Example
<?xml version="1.0" encoding="UTF-8"?>
<message name="IngetQuoteRequest">
</message>
<message name="OutgetQuoteResponse">
</message>
<portType name="NasdaqQuotes">
<operation name="getQuote">
</operation>
</portType>
<binding name="NasdaqQuotesBinding" type="NasdaqQuotes">
<soap:bindingstyle="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="getQuote">
<soap:operation soapAction="urn:NasdaqQuotes"/>
<input>
<soap:bodyencodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:NasdaqQuotes" use="encoded"/>
</input>
<output>
<soap:bodyencodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:NasdaqQuotes" use="encoded"/>
</output>
Service Implementation Description
Example
<?xml version="1.0" encoding="UTF-8"?>
<definitions name="NasdaqQuotes"
targetNamespace="http://urn:NasdaqQuotes_WSDL"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://urn:NasdaqQuotes_WSDL"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<service name="NasdaqQuotes">
<documentation>IBM-WSTK 2.0 generated service definition file
</documentation>
<port binding="NasdaqQuotesBinding" name="NasdaqQuotesPort">
<soap:address location=
"http://localhost:8080/soap/servlet/rpcrouter/"/>
</port>
</service>
<import location="IBM_NasdaqQuotesClient-interface.wsdl"
namespace="http://urn:NasdaqQuotes_WSDL-interface" />
</definitions>
 Service Invocation (SOAP)
Simple Object Access Protocol is an XML-based
lightweight protocol for the exchange of information in a
decentralized, distributed environment.

SOAP defines a messaging protocol between requestor

and provider objects.

SOAP forms the basis for distributed object

communication in most vendor implementations of SOA.

Central idea is based on the delivery of SOAP Envelopes.

 SOAP Request Example
POST /InStock HTTP/1.1
Host: www.stock.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body
xmlns:m="http://www.stock.org/stock">
<m:GetStockPrice>
<m:StockName>IBM
</m:StockName>
</m:GetStockPrice>
</soap:Body>
</soap:Envelope>
 Transactional Issues
SOAP Messages
Security
Reliable Messaging
Business Orchestration
Eventing
Transactions

Legacy Systems Enterprise Data

Partner Systems
 Checkpoint
Web Services and System Architecture

A clear emphasis towards Heterogeneous, multi-

tier architectures

Major Architectural requirements for Web

Services include [W3C]:
– Interoperability
– Reliability
– Web-friendliness, usability
– Security
– Scalability and Extensibility
Design and Implementation Issues
Transition from a reference architecture to a concrete
architecture and to a specific implementation
technology

Implementing transaction management techniques

Messaging and invocation protocols

Modeling and use of data and metadata

Personalization and adaptation

Efficient use of design patterns

 Model Driven Architecture
OMG has proposed a framework for designing,
deploying, and integrating distributed systems and
services.

The basic idea is on the use of a generic reference

architecture and model for distributed services (Platform
Independent Models) that can be transformed to yield
concrete architectures specific to an implementation
platform (Platform Specific Models)
Building an MDA Application

A Detailed Model, Start with a Platform-

Platform- stating Pre- and Post- Independent Model
Independent Conditions in OCL, (PIM) representing
Model and Semantics in
business functionality
Action Language
and behavior,
undistorted by
technology details.
Generating Platform-Specific
Model

Map a PIM to Specific MDA tool applies a

Platform- Middleware standard mapping to
Independent Technologies via OMG generate Platform-
Model Standard Mappings
Specific Model (PSM)
from the PIM. Code is
partially automatic,
CORBA partially hand-written.
Model
Mapping to Multiple Deployment
Technologies

Map a PIM to Many MDA tool applies a

Platform- Middleware standard mapping to
Independent Technologies via OMG generate Platform-
Model Standard Mappings
Specific Model (PSM)
from the PIM. Code is
partially automatic,
CORBA Java/EJB XML/SOAP Other partially hand-written.
Model Model Model Model
Generating Implementations

Map PSM to application MDA Tool generates

Platform- interfaces, code, GUI all or most of the
Independent descriptors, SQL implementation code
Model queries, etc.
for deployment
technology selected
by the developer.
CORBA Java/EJB XML/SOAP Other
Model Model Model Model

CORBA Java/EJB XML/SOAP Other

Integrating Legacy & COTS

Reverse-engineer MDA Tools for reverse

Platform- existing application into engineering automate
Independent a model and redeploy. discovery of models
Model for re-integration on
new platforms.

Legacy COTS Other

App App Model

Other
 EJB Architecture
EJB Server
EJB Server

EJB Container EJB Container

Home Interface &

Locate, Create
Home
and Remove Home
Object
Instance of EJB Interface

Home Object Enterprise

JavaBean
EJB
Remote Interface & Client
EJB
Remote
EJBObject Invoke Business
Interface
Object Database

methods of EJB
Enterprise JavaBean Enterprise Services and API
EJB Clients Naming Service(JNDI)
Transaction Service
Security
Messaging
 Enterprise JavaBean
Two Types of
Enterprise JavaBean EJB Server

– Entity beans, Entity EJB Container

Home
represent persistent EJB
Home
Interface
Object
Entity
data and methods on Client JavaBean

that data in a domain Remote

Interface
EJB
Object

model EJB
Client
– Session beans, more Session EJB Container
Database

general purpose
Home
Interface Home
Object

server-side beans Session

JavaBean

Remote EJB
EJB Interface Object
Client
 Object Wrappers

An Object wrapper is essentially a

software layer between two different
system, for example, between OO and
non-OO, between distributed OO and
non-distributed OO.
 Types of Object Wrapper

Types of Object Wrappers

Object Legacy
– Screen Scraper Wrappers Resources

– Function Wrapper OO Screen

Screens
– Data Wrapper Scrapper

Legacy
OO OO Function Code
Code
Clients Wrapper Access

Flat Files

OO Data
Wrapper

RDBMS
Wrappers and Integration Gateways

Integrate and synthesize Integration Gateway

object wrappers with Object

Wrappers
Access
Legacy
Resources
Technologies
various access OO
Screen
Screens
technologies. Wrapper

Legacy
OO Code
OO Function
Code
Clients Wrapper
Access

Flat Files

OO
Data
Wrapper

RDBMS
 Checkpoint
Web Services and Design
Well established standards and robust technologies for
encapsulating and wrapping services

Follows closely the distributed systems paradigm (mostly

document computing not RPC)

Variations on the transaction model and messaging

(application layer)

Major breakthrough, Model Driven Architecture

Next step includes generative programming and

automatic code generation
 Web Services and Testing
Technology Level Testing
– SOAP messages
– WSDL specifications
– UDDI Specifications

Service Level Testing

– Web Services as components, functional testing

Architecture Level Testing

– Proof-of-concept, transaction management, Quality of Service,
load/stress testing,

Global Level Dynamic Testing

– Composition, orchestration, versioning, monitoring, and
regression testing
 Checkpoint
Web Services and Testing
Need for new testing tools

Transaction management is an issue for long

transactions

New challenges for Integration, System, and Regression

testing due to the loosely coupled components involved
and the nature of the transactions

Acceptance testing more diverse

Possibly need to devise strategies for metadata

evaluation as well
 Security Issues
Three areas of attention:
– Technology related (secure messaging)
– Business related (policy, risk, trust)
– Coordination related (platform vendors, developers,
network providers, customers)

The broad area of securing Web services:

– Securing integrity and confidentiality of messages
– Ensuring a service acts on requests that comply with
claims required by policies
 Maintenance and Evolution
Incremental evolution of components and
services
Design and development collaborative tools
Impact and what-if analysis
Versioning
Enabling reuse
Compliance with emerging standards and
versioning
Maintenance of meta-data
 Financial Issues
There five potential revenue models for Service Providers:

– Transactional: refers to the pay-per-click or fee-for-use model.

– Membership/subscription: established user account with specific

terms for usage.

– Lease/license: require large volumes of usage and expect a more

customized agreement.

– Business partnership: refers to the establishment of terms

through out-of-band or prior usage-based system, on the bartering
of services, equity, or even a percentage of gross revenue of the
requestor.

– Registration: applies more readily to a UDDI provision business.

 Emerging Areas
Emerging areas in the field of Web Services
include:

– Integration of distributed heterogeneous components

into autonomic systems.

– Service discovery frameworks

– Creation, monitoring and management of

agreements, agreement templates

– Metadata exchange
Autonomic and Adaptive Systems
Autonomic systems are interactive collections of
autonomic-elements. Autonomic elements provide a
service only if it is consistent with their goals (intents)
[Kephart, Chess]

The main characteristics of autonomic systems are:

– Self-configuration

– Self-optimization

– Self-healing

– Self-protection
 Coordination and Intents
Basis is the coordination theory by T. Malone (MIT).

Coordination theory is body of principles about how

activities can be coordinated, that is, about how actors
can work together harmoniously [Malone].

Intents are models of the objectives or goals of a service.

The problem is to manage constraints so that intents can

be achieved.
 Web Services and Adaptive
Systems
Adaptation that leads to autonomicity can be
best applied at either:
– Service level
– Middleware level

Adaptation can take the forms of

– Control adaptation (workflow adaptation)
– QoS adaptation
– Data and Metadata filtering
 Checkpoint
Web Services and Autonomic Computing

Extending Web services with programming tools

and techniques for managing relationships between
autonomic elements

Formalisms for modeling intents

Techniques and frameworks for monitoring

autonomic systems

Selecting and applying behaviors

 The Next Steps
Model Driven techniques for system
development
Security protocols (above transport layer)
Testing and evaluation tools
Adding semantic information to services
Metadata and data exchange and mediation
Workflow adaptation and customization
Autonomic systems
 Conclusion - Summary
Web services as large software distributed
systems pose new challenges to the
Software Engineering community

Web Services are not the end, but merely

provide the means to move to new
paradigms and explore new technologies
 References
http://www.w3.org/2002/ws/
http://www-130.ibm.com/developerworks/webservices/
http://msdn.microsoft.com/webservices/
http://conferences.computer.org/icws/2005/
http://www.oasis-open.org/home/index.php
www.omg.org/mda
http://ccs.mit.edu/ccsmain.html
http://www.research.ibm.com/autonomic/
Web Services: Implications
for Software Engineering

Kostas Kontogiannis

University of Waterloo

Department of Electrical and

Computer Engineering