OPEN FACULTY OF ENGINEERING TECHNOLOGY

UNIVERSITY BACHELOR OF SOFTWARE ENGINEERING HOUNOURS: LEVEL 4

OF SRI LANKA WEB TECHNOLOGY
EEI4346

WEB TECHNOLOGY
 COURSE MATERIAL

Web Technology

PART 2

The Open University of Sri Lanka

Department of Electrical and Computer Engineering
Copyright
Two units in the Part II of this course has been developed by the Department of Electrical and
Computer Engineering, Faculty of Engineering Technology, The Open University of Sri Lanka .

The Open University of Sri Lanka (OUSL) is the premier Open and Distance learning institution in the
country where students can pursue their studies through Open and Distance Learning (ODL)
methodologies. Degrees awarded by OUSL are treated as equivalent to the degrees awarded by other
national universities in Sri Lanka by the University Grants Commission of Sri Lanka.

© 2019 by the Commonwealth of Learning and The Open University of Sri Lanka. Except where
otherwise noted, Web Technology is made available under Creative Commons Attribution-
ShareAlike 4.0 International (CC BY-SA 4.0) License: https://creativecommons.org/licenses/by-
sa/4.0/legalcode.

The Open University of Sri Lanka

P. O. Box 10250,
Nawala,
Nugegoda,
Sri Lanka
Phone: +94 112881481
Fax: +94 112821285
Email: [email protected]
Website: www.ou.ac.lk
 Web Technology

Acknowledgements
Department of Electrical and Computer Engineering (ECE), The Open University of Sri Lanka
(OUSL) wishes to thank those below for their contribution to Part II of this course material:

Chairperson of the Course team:

HUW Ratnayake

Author:

S. Rajasingham Unit 11

Dilan Perera Unit 12

Content Editors:
Dilan Perera

HUW Ratnayake

GSN Meedin

Desktop Publishing:

S. Rajasingham
Contents
About this course material 153
How this course material is structured ....................................................................... 153

Course overview 155

Welcome to Web Technology ................................................................................... 155
Web Technology —is this course for you? ............................................................... 155
Course Learning Outcomes ....................................................................................... 155
Timeframe ................................................................................................................ 156
Study skills ............................................................................................................... 156
Need help? ................................................................................................................ 157
Assignments.............................................................................................................. 157
Assessments .............................................................................................................. 158

Getting around this course 159

Margin icons ............................................................................................................. 159

Unit 11 161
Web Services ............................................................................................................ 161
Introduction ..................................................................................................... 161
11.1 Webservice .............................................................................................. 161
Activity ..................................................................................................................... 162
11.2 SOAP ....................................................................................................... 162
Activity ..................................................................................................................... 164
11.3 RESTful ................................................................................................... 164
11.4 Creating Web services .................................. Error! Bookmark not defined.
Activity ..................................................................................................................... 166
........................................................................................................................ 166
Unit summary ........................................................................................................... 166
References and Further Reading ................................................................................ 167
Acknowledgement .................................................................................................... 167

Unit 12 168
Enterprise Integration ................................................................................................ 168
Introduction ..................................................................................................... 168
12.1 The Enterprise .......................................................................................... 169
12.2 Integration ................................................................................................ 169
12.3 Approaches to Integration ........................................................................ 170
12.4 Integration Styles ..................................................................................... 171
Activity ..................................................................................................................... 174
12.5 Enterprise Integration Patterns.................................................................. 174
Activity ..................................................................................................................... 177
12.6 Messaging Concerns ................................................................................ 177
Activity ..................................................................................................................... 178
Unit summary ........................................................................................................... 178
References and Further Reading ................................................................................ 179
Acknowledgement .................................................................................................... 179
 Web Technology

About this course material

Part 1 of this book containing 10 Units has been produced by The Open
University of Tanzania. Part 2 of this book „Web Application
DevelopmentWeb Technology‟ containing 2 Units has been produced by
The Open University of Sri Lanka.

How this course material is

structured
The course overview
The course overview gives you a general introduction to the course.
Information contained in the course overview will help you determine:

 if the course is suitable for you

 what you will already need to know

 what you can expect from the course

 how much time you will need to invest to complete the course

The overview also provides guidance on:

 study skills

 where to get help

 course assignments and assessments

 activity icons

 units

We strongly recommend that you read the overview carefully before

starting your study.

153
About this course material

The course content

The course consists of many units. Each unit comprises:

 an introduction to the unit content.

 unit outcomes.

 new terminology.

 core content of the unit with a variety of learning activities.

 a unit summary.

Resources
For those interested in learning more on this subject, we provide you with
a list of additional resources at the end of each unit; these may be books,
articles or web sites.

Your comments
After completing Web Application Development we would appreciate if
you would take a few moments to give us your feedback on any aspect of
this course. Your feedback might include comments on:
 course content and structure.
 course reading materials and resources.
 course assignments.
 course assessments.
 course duration.
 course support (assigned tutors, technical help, etc.)

Your constructive feedback will help us to improve and enhance this

course.

154
 Web Technology

Course overview

Welcome to Web Technology

This course will enable you to understand basics concepts of Web
Technology. You may study the theory and practical aspect of client side,
server side and the trends in the technology. At the end of this course,
you should be able to develop a website using the concepts and the
technology presented in this.

Web Technology —is this

course for you?
You should have basic ICT skills to use a computer.

The course aims are:

• To build dynamic and interactive web applications using evolving

technologies.

• To enable the learners to learn and apply methodologies and designing

and deploying the website.

Course Learning Outcomes

Upon completion of Web Technology you will be able to:

 Apply markup languages for processing, identifying, and presenting of

information in web pages.

 Apply scripting languages and web services to transfer data and add
 Outcomes interactive components to web pages.

 Design websites using appropriate security principles, focusing

specifically on the vulnerabilities inherent in common web
implementations.

155
Course overview

Timeframe
This is one-academic year course of 150 total learning hours

This course has 5 day schools, 4 laboratory sessions, 2 TMAs.

Self study time is 5 hours per week for a 8-month academic year which
How long? include exams as well.

Study skills
As an adult learner your approach to learning will be different to that
from your school days: you will choose what you want to study, you will
have professional and/or personal motivation for doing so and you will
most likely be fitting your study activities around other professional or
domestic responsibilities.

Essentially you will be taking control of your learning environment. As a

consequence, you will need to consider performance issues related to
time management, goal setting, stress management, etc. Perhaps you will
also need to reacquaint yourself in areas such as essay planning, coping
with exams and using the web as a learning resource.

Your most significant considerations will be time and space i.e. the time
you dedicate to your learning and the environment in which you engage
in that learning.

We recommend that you take time now—before starting your self-

study—to familiarize yourself with these issues. There are a number of
excellent resources on the web. A few suggested links are:

 http://www.how-to-study.com/
The “How to study” web site is dedicated to study skills resources.

 http://www.howtostudy.org/resources.php
Another “How to study” web site with useful links to time
management, efficient reading, questioning/listening/observing skills,
getting the most out of doing (“hands-on” learning), memory building,
tips for staying motivated, developing a learning plan.

156
 Web Technology

The above links are our suggestions to start you on your way. At the time
of writing these web links were active. If you want to look for more go to
www.google.com and type “self-study basics”, “self-study tips”, “self-
study skills” or similar.

Need help?
This course is offered by the Department of Electrical and Computer
Engineering of The Open University of Sri Lanka for registered students.
If you need help regarding this course and if you are a registered student
Help at OUSL, please contact:

Academic Coordinator/ Web Application Development,

Department of Electrical and Computer Engineering,
Faculty of Engineering Technology,
The Open University of Sri Lanka

The Programme Coordinator can be contacted by email [email protected]

More details will be given with the activity schedule for the particular
year.

Assignments
There will be two assignments for this course which will be changed
every year and will be given in the Learning Management System ( LMS)

Assignments should be submitted as hard and to the LMS as well.

Assignments Assignment submission deadline will be given together with the

Assignments. Depending on the start and end of the academic year, dates
will vary.

157
Assessments
There will be:

4 laboratory sessions,
Assessment
2 TMAs

All continous assesment components will take place before the Final
Exam. You have to obtain more than 40% for Overall CA Mark to sit for
the final exam.

158
 Web Technology

Getting around this course

Margin icons
While working through this course you will notice the frequent use of
margin icons. These icons serve to “signpost” a particular piece of text, a
new task or change in activity; they have been included to help you to
find your way around this course. We suggest that you familiarize
yourself with the icons and their meaning before starting your study.

Activity Assessment Assignment Case study

Discussion Group Help Objectives

activity

Outcomes Reading Answers Guide Study skills

Summary Terminology Time Tip

Computer-Based
Learning Audio Video Feedback
159
 Web Technology

Unit 11

Web Services
Introduction
Now that you have an understanding of what Web Application Security
is. Let‟s look into the web service. This unit describes the importance of
the web services and the common standards it follows. It also goes into
the details of SOAP and gives a brief demonstration of how a simple web
service is created.

Upon completion of this unit you will be able to:

 describe the use of web service.

 describe the commonly used standards in web services.

Outcomes  explain the role of soap in messaging.

 demonstrate how you would create a webservice.

11.1 Web service

The introduction of World Wide Web (WWW) has provided a
platform to augment the communications between applications.
The platform or the interface that has been used to provide this
communication portal and made available over the web is often
referred to as Web services. There are many technologies that
implement this service but the most commonly used technologies
that allow enhanced interoperability between applications are
HTTP and XML.

In general, web services are independent, distributed, dynamic

versatile applications that can be manipulated in such a way to
create products, processes and supply chains. Also these
applications can be supported via local, distributed or web based
platforms as well. The web services follow standard protocol that
confine to TCP/IP, HTTP, Java, HTML and XML which are used

161
Unit 11

as a foundation to build these applications. In other words, web

services are a collection of protocols and stipulated standards that is
used for exchanging data between systems or applications. As
mentioned before the XML and HTTP are the basic web services
platform but there are other standards that are commonly used such
as the following.

 Simple Object Access Protocol (SOAP): A protocol

for exchanging information in the implementation of
the web services.
 Web Services Description Language (WSDL):
Model for describing SOAP based web services.
 WS-Policy: Framework that aid in crafting the
requirements, capabilities and characteristics of the
web services using policies.

The following sections will describe the main functions of the

commonly used standards such as XML, HTTP, SOAP, WSDL and
WS-Policy in detail. Also SOAP will be used to demonstrate the
practical aspect of the web service.

Activity
Activity 11.1
Web service

Explain the purpose of webservices and state the standards that are used
in developing it.

11.2 SOAP
You have already studied XML and the use of HTTP. Now that we
will discuss the rest of the commonly used standards, let‟s look into
the details of SOAP.
SOAP is a lightweight protocol that was created for transferring
information in a decentralized, distributed environment. The XML
technologies are used to define the extensible messaging

162
 Web Technology

framework. It is self-contained and can be implemented with

respect to any programming model.
SOAP was intended to serve two major purposes, first one is the
simplicity and the other is extensibility. In order to meet these goals
its goes to the extent of omitting features from the messaging
framework that does not cater to the goals of reliability, security,
etc. SOAP describes a network protocol to exchange data within
the Internet and between different computer systems. It supports all
existing W3C standards such as WS-Addressing, WS-Policy and
WS-Security. SOAP provides for Remote Procedure Call-style
(RPC) interactions, similar to remote function calls, and Document-
style communication, with message contents based exclusively on
XML Schema definitions in the Web Service's WSDL SOAP
services comprise of the following WSDL components:
 Types
A container for abstract type definitions defined using XML
Schema.
 Messages
A definition of an abstract message that may consist of multiple
parts, with each part being of a different type. You will see more on
this later.
 Port Types
An abstract set of operations supported by one or more endpoints
(commonly known as an interface); operations are defined by an
exchange of messages.
 Binding
The WSDL binding element describes details of using a particular
portType with a given protocol. The binding element contains
several extensibility elements as well as a WSDL operation element
for each operation in the portType. It also indicates the default style
of service, document in this case, along with the required transport
protocol, HTTP.
 Service
The WSDL service element defines a collection of ports, or
endpoints, that expose a particular binding. For further details on
SOAP, follow: https://www.w3.org/TR/soap12-part1/#soapnodes.

163
Unit 11

Activity
Activity 11.2

SOAP

Describe the major functionalities of SOAP

11.3 RESTful
Now you understand SOAP, another important concept to
understand with respect to web services is RESTful.
The Representational State Transfer (REST) style is an abstraction
of the architectural elements within a distributed hypermedia
system. RESTful ignores the details of component implementation
and protocol syntax in order to focus on the roles of components,
the constraints upon their interaction with other components, and
their interpretation of significant data elements. It encompasses the
fundamental constraints upon components, connectors, and data
that define the basis of the Web architecture, and thus the essence
of its behavior as a network-based application. RESTful Web
services allow the requesting systems to access and manipulate
textual representations of Web resources by using a uniform and
predefined set of stateless operations. In a RESTful Web service,
requests made to a resource's URI will elicit a response with a
payload formatted in HTML, XML, JSON, or some other format.
The response can confirm that some alteration has been made to the
stored resource, and the response can provide hypertext links to
other related resources or collections of resources.
The most important concept in RESTful is resources, which are
identified by global IDs typically using URIs. Client applications
use HTTP methods (GET/ POST/ PUT/ DELETE) to manipulate
the resource or collection of resources. A RESTful Web service
implements using HTTP and the principles of RESTful. Typically,
a RESTful Web service should define the following aspects:
 The base/root URI for the Web service such as
http://host/<appcontext>/resources.

164
 Web Technology

 The MIME type of the response data supported, which are

JSON/XML/ATOM and so on.
 The set of operations supported by the service. (for
example, POST, GET, PUT or DELETE).

Now that you have a theoretical understanding of what RESTful is,

for further details you can follow:
https://www.ibm.com/developerworks/web/library/wa-aj-tomcat/

11.4 Creating a Simple Web service

Let‟s learn to start a simple web service using Apache Tomcat. For
this you must download and install Apache Tomcat in your
machine. The IDE used in this section is Eclipse and in order to
install and configure Apache Server in Eclipse, you have to follow
these steps:

Tomcat Installation
1. Open Window -> Preferences -> Server -> Runtime
Environments to create a Tomcat installed runtime.
2. Click on Add to open the New Server Runtime dialog, then
select your runtime under Apache (Apache 7.0 from the list).
“Create a new local server” must be checked when adding
the Apache Tomcat runtime environment. (This is useful so
not to mess up your actual web services with your web
services that you are developing and testing).
3. Put your Tomcat installation dir e.g. C:\Program
Files\Apache Software Foundation\Tomcat 7.0 and finish.
4. In the Servers view panel, you will see the Tomcat server
Stopped. In the Project Explorer view, a Server
configuration will appear.
5. If you run the Server you might encounter an error if your
Tomcat is already running. So you must configure different
ports for your installation, otherwise you must stop your
Tomcat server while you are developing and testing your
web services. If you double click the server, the local
configuration will appear. Change the ports as you wish and
the Right Click the server Icon and select Start to start the
server.
Now that you have installed and configured Tomcat in your
machine. You can follow the step by step tutorial in the following

165
Unit 11

link to create a simple web service:

http://www.softwareagility.gr/index.php?q=node/29.

Activity
Activity 11.3

Creating a web service

Create a simple web service.

Unit summary
In this unit, we discussed the use of web service and it also
describes the protocols a web service should follow. It gives a brief
description of the SOAP and details of RESTful services. It also
gives an overview to create a simple web service.
Summary

166
 Web Technology

References and Further

Reading

1. https://tomcat.apache.org/tomcat-3.2-doc/tomcat-apache-
howto.html#intro (Apache License:
http://www.apache.org/licenses/LICENSE-2.0)
2. https://www.w3.org/TR/soap12-part1/#soapnodes.
3. http://www.softwareagility.gr/index.php?q=node/29.

Acknowledgement
Some contents for this Unit was taken from the following links:
 https://tomcat.apache.org/tomcat-3.2-doc/tomcat-apache-
howto.html#intro (Apache License:
 http://www.apache.org/licenses/LICENSE-2.0)
 https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_a
rch_style.htm
 https://www.restapitutorial.com/lessons/restfulresourcena
ming.html
 https://www.w3.org/TR/wsdl/
 https://www.crummy.com/writing/RESTful-Web-
Services/ CC BY 4.0))
 https://www.hindawi.com/journals/am/2011/238683/

167
Unit 12

Unit 12

Enterprise Integration

Introduction
Software systems range from simple console or desktop
applications which doesn‟t even use file storage or a database to
large scale solutions which deliver content in multiple formats, uses
several means of storing data and can be decomposed into sub-
systems. Such systems are typically not built as a unit, but evolve
over time, typically in response to business needs. Sometimes,
systems evolve separately and are connected at a later point in time,
to provide business functionality that neither could provide in
isolation.

In this session, you will be learning about the context in which such
software is created, the approaches that can be used to connect
systems and recurring techniques for connecting systems which can
be used to good effect when designing software - with the intent
that you make an informed decision about their use for projects.
Upon completion of this unit you will be able to:

 identify why enterprise integration is important .

Outcomes  explain what messaging is.

 understand how information technology combined with

business processes can bring an organization competitive
advantage.

168
 Web Technology

12.1 The Enterprise

What is an „enterprise‟? The term is often loosely used to describe
an organization or possibly to distinguish a large organization.
However, when discussing software, an enterprise is best defined
formally, to gain a better understanding of what it is.

The Open Group Architecture Framework (better known as

TOGAF) Standard defines an enterprise as „the highest level
description of an organization and typically covers all missions and
functions‟. It also doesn‟t limit the enterprise to a single
organization, but specifies that it will often span multiple
organizations. Surprisingly, this could extend to related
organizations that have business links and have a bearing on
business operations that may (or may not) require software to be
developed for it. Based on the above definition, examples of an
enterprise could be:

1. A whole corporation or a division of a corporation

2. A government agency or a single government department
3. A chain of geographically distant organizations linked
together by common ownership
4. Groups of countries or governments working together to
create common or shareable deliverables or infrastructures
5. Partnerships and alliances of businesses working together,
such as a consortium or supply chain

Enterprise Architecture would then be the practice related to the

preparation of the software architecture within the context of
enterprises. As explained previously, such software may have to
span multiple organizations and systems, which means that
enterprise architecture often deals with having to integrate such
software systems..

12.2 Integration
As noted by Woolf and Hohpe [www2] and attested to above,
today‟s applications rarely live in isolation. Integration is the
process by which two (or more) systems are brought out of

169
 isolation to interoperate with each other - with the intention of
deriving some synergistic benefit.

While users of software today expect instant access to

functionality, the process of integration is usually not an easy one,
as the systems being integrated could be based on different
technology platforms, procedures, data models and protocols.
While overcoming these differences can prove challenging, some
well-known approaches have been used widely, over the years.

12.3 Approaches to Integration

Broadly speaking, two approaches to integration exist, based on
execution models - synchronous and asynchronous.
Synchronous
The synchronous (or „sync‟) approach to integration is based
primarily on the Remote Procedure Call (RPC) model, where when
(e.g.) System A connects to System B with the intent of performing
some task, it completes that task prior to returning control to the
initiating system. This is often considered „real-time‟, as all actions
are performed in a sequence and the results are returned once all
actions are completed.
This approach is analogous to a person (System A) making a
telephone call to another person (System B), requesting that the
callee should retrieve some information for the caller. While the
callee performs this task, the caller waits on the phone.
This approach has the drawback that until the initiating system
receives the results of the invoked operation, it cannot perform any
other operations (on that thread/path of execution) and consumes
resources until the result of the operation is returned.
Since System A is blocked from performing any other operations,
this is also known as a „blocking‟ approach.
Asynchronous
The asynchronous (or „async‟) approach to integration operates on
a „callback‟ model, where when (e.g.) System A connects to
System B with the intent of performing some task, System B
returns immediately with acknowledgment of having received the

170
 Web Technology

request to perform the task; System B then performs the task and
connects back to System A, to return the result of the operation.
Using the previous analogy, this approach is analogous to a person
(System A) making a telephone call to another person (System B),
requesting that B should retrieve some information for A. While B
performs this task, A hangs up the phone and performs some other
tasks. Once B has the necessary information, B calls A back (from
which stems the term „callback‟) and provides the information.
This has the advantage of being better from a resource utilization
perspective (i.e. System A can perform other tasks), but it can be
more complex to implement as System B needs to know how to
connect to System A (which does not occur in the synchronous
model).
Since System A is not blocked from performing any other
operations, this is also known as a „non-blocking‟ approach.

12.4 Integration Styles

Hohpe and Woolf [www2] identify several integration styles, each
with its own advantages and disadvantages.
File Transfer
In this integration style, an application would share data by placing
it in a file and providing it to the counterpart application as shown
in Figure 12.1.

Figure 12.1: File Transfer

Both parties will have to understand the format of the file (the
sender to generate the file and the recipient to understand or „parse‟
it).
If the intention of sharing data is to keep the recipient application
updated with data from the sender, the sending process can be
repeated on a scheduled basis.
Today, the most popular format is JSON (JavaScript Object
Notation), although XML (eXtensible Markup Language) is also
still widely used.

171
 This style allows each application to function synchronously, but is
best suited for publishing data.
Shared Database
This integration style shares data by all integrating applications (of
varying technologies and platforms) using a common database.

Figure 12.2: Shared Database

All parties need to be aware of the persistence schema and

coordinate changes to shared schemata. Operations can benefit
from transaction management, hence the level of data consistency
is high.

This style allows each application to function synchronously and

supports both publishing and retrieval of data.
Remote Procedure Invocation
This integration style connects applications by the „client‟
application (the consumer) invoking a function/passing a message
to a „server‟ application (the provider) and waiting for a result
message.

172
 Web Technology

Figure 12.3: Remote Procedure Invocation

Typically such integrations benefit from using standard
communication protocols (e.g. HTTP) to connect with each other
and standard data formats (e.g. XML, JSON) to help represent the
content being communicated. Combinations of the above protocols
and formats can be seen in SOAP Web Services and RESTful Web
Services. The current trend towards microservice architectures are
largely based on RESTful Web Services, communicating over
HTTP (or more typically HTTPS/TLS for greater security) and
using JSON to represent data payloads. You will be learning more
about SOAP, RESTful Web services and microservice architectures
in a higher level course. For now, you are expected to get familiar
with the terms of the technology used in this course.
The level of encapsulation of data is higher in this approach, with
clear lines of ownership of functionality and data. The
maintainability of such integrations are higher, with each
application able to make modifications to its internal
implementation, without affecting consumers.
This style is inherently synchronous and supports both publishing
and retrieval of data.
Messaging
This integration style integrates applications through passing of
messages via a „message bus‟ - a common message transportation
mechanism.

Figure 12.4: Messaging

Messaging results in systems that are „loosely coupled‟ (which is a
very desirable design trait), allowing each application to be
modified in isolation. It also provides the benefit that the receiving
application does not have to be executing at the time of the
initiating application sending the message. These differences call
for a significant change in the thinking pattern of developers who
are more familiar with synchronous execution and typically yields
more complex codebases.

173
 Message payloads are typically represented using standard data
formats, such as XML or JSON.
This style is inherently asynchronous and supports both publishing
and retrieval of data, although the manner of retrieval is via
callback.

Activity
Activity 12.1

What does the word „synergistic‟ mean? It might not be a technical

term, but therein lies the answer to why integrations take place.

12.5 Enterprise Integration Patterns

A pattern is the re-usable form of a solution to a problem. A pattern
language therefore, is an organized collection of patterns within a
given field of study. Originally conceived by a (building!) architect
named Christopher Alexander, he defined patterns thus:

“The elements of this language are entities called patterns. Each

pattern describes a problem that occurs over and over again in our
environment, and then describes the core of the solution to that
problem, in such a way that you can use this solution a million
times over, without ever doing it the same way twice.”

Within software, various disciplines within the software industry

has seen the emergence of patterns; to wit - Architectural Patterns,
Design Patterns and of particular interest to this session, Integration
Patterns. Given the breadth of the topic (Hohpe and Woolf
identified a pattern language of 65 Integration Patterns in their
book „Enterprise Integration Patterns‟!), a few Integration Patterns
relating to Messaging Channels (a channel being the mechanism by
which applications exchange data) are discussed below.

174
 Web Technology

Point-to-Point Channel
Point-to-Point Channels are a mechanism of ensuring that exactly
one receiver will receive a specific message.

Figure 12.5: Point-to-Point Channel

In the event of multiple receivers (i.e. Competing Consumers, a

related Messaging Endpoint pattern) existing on a channel, the
channel itself ensures that only one receiver will receive a message.
Upon delivery, the message is removed from the channel.
Point-to-Point channels are typically realized in Message Queuing
systems, where a channel would be a queue, possibly with FIFO
(First In, First Out) message delivery.
Publish-Subscribe Channel
This pattern (fondly known as Pub-Sub) describes how multiple
receivers will receive a specific message. Here, the sender is known
as the publisher and the recipients (who subscribe to receive
publications) are known as subscribers.

Figure 12.6: Publish-Subscribe Channel

175
 The messaging system will maintain an output channel per
subscription, linked to an input channel. When the input channel
receives a message, it will internally deliver a copy of the message
to the related output channels, thus ensuring that each subscriber
receives the message once. Upon delivery, the message is removed
from the output channel.
Publish-Subscribe channels are typically realized in messaging
systems as topics, where a topic is bound to by subscribers and
written to by publishers. Internally, Message Queues might be used
to handle internal message delivery (between input and output
channels).
Message Bus
This pattern is more advanced and used in response to an enterprise
scenario where several systems need to be able to fulfil business
requests, operating in a unified manner, with the facility to easily
add or remove applications without affecting other applications.

Figure 12.7: Message Bus

A bus, in computing terms, is a common communication
mechanism between components of a system. An analogy from the
hardware world would be the bus that connects the processor,
memory and devices (i.e. the components) of a computer system.

A message bus combines a standardized payload format, a common

set of operations and message delivery mechanisms to enable
integration.

176
 Web Technology

Activity
Activity 12.2

Look up the following Integration Patterns [www2] and describe

them in your own words:

1. Message pattern (a Message Routing pattern)

2. Message Broker pattern (a Message Routing pattern)

3. Event-Driven Consumer pattern (a Message Endpoint

pattern)

4. Durable Subscriber pattern (a Message Endpoint pattern)

12.6 Messaging Concerns

This section discusses design concerns such as message delivery
semantics and ordering, which need to be factored into software
design. An architect‟s life would be much easier if all messages
would be delivered exactly once and in the order it was sent in.
However, architects need to be aware of these concepts - in the
event that the messaging system at hand does not provide such
capabilities, even though these design concerns would ideally be
addressed by the messaging systems.

Message Delivery Semantics

Message Delivery Semantics outline the different approaches to
message delivery in distributed systems, such as:

1. At most once (each message is delivered once OR never

delivered at all)
2. At least once (each message can be delivered multiple
times, but will definitely be delivered once)
3. Exactly once (each message will be delivered once and only
once)

177
 These delivery semantics influence how applications are designed
to process messages, especially in the face of message delivery
failure. While exactly once is the ideal situation, it is a hard
problem to solve and architects are advised to design systems
taking the above into consideration. Underlying any conversation
on delivery semantics is the need for reliable messaging. This
means messaging systems are typically built atop reliable transport
layer protocols such as TCP/IP.
Message Ordering
In an ideal world, all messages would arrive in the order that they
were dispatched. However, this too is a hard problem to solve and
architects need to take out-of-order delivery into consideration,
when designing applications.

Activity
Activity 12.3
Design an integration solution for the following scenarios, using
Integration Patterns:
1. You are developing a weather forecasting mobile app and a
weather Web Service has been identified.
2. An e-Learning Tool has sent assessment grades to your
RESTful Web Service; there are multiple systems in your
domain that wish to be notified of these grades.
3. Your system posts Customer Profile changes to a
downstream partner system; you know that some messages
may fail (i.e. cannot be delivered).

Unit summary
This unit dealt with approaches taken to connecting systems in the
software industry, with the content describing integration
approaches, styles and patterns that are commonly used. The
session also looked at fundamentals like „what is an enterprise‟ and

178
 Web Technology

Summary „what is a pattern‟ where relevant, as these general concepts are

critical to understanding the more advanced session content.
The material also discussed where different integration approaches,
styles and patterns could be best used and readers are encouraged to
couple this knowledge with further reading on each area, prior to
use.

References and Further

Reading

https://pubs.opengroup.org/architecture/togaf9-
doc/arch/chap03.html#tag_03_38
https://www.enterpriseintegrationpatterns.com/
https://www.confluent.io/blog/exactly-once-semantics-are-
possible-heres-how-apache-kafka-does-it/
https://developer.lightbend.com/blog/2017-11-01-atotm-akka-
messaging-part-2/index.html

Acknowledgement
Some contents for this Unit was taken by:
Images from [www2] used under the Creative Commons Attribution
license. As specified at the end of each pattern page (e.g. File Transfer),
the “pattern icon, the pattern name, the problem and solution statements
(in bold), and the sketch under this license” [www2] are candidates for
re-use, under this license.

179