Unit 3: Service Oriented Architecture and the Cloud

3.1 Introduction to Service oriented Architecture

In this type of architecture, services are communicating to each other to carry out
certain activity. A service-oriented architecture is a collection of services. These
services communicate with each other. The communication can involve either
simple data passing or it could involve two or more services coordinating some
activity. Some means of connecting services to each other is needed.
Before Service-oriented architectures, people was using DCOM or Object Request
Brokers (ORBs) based on the CORBA specification. CORBA and DCOM are two
middleware solutions for handling distributed objects. These solutions provide
better commanding over distributed computing objects.
The Common Object Request Broker Architecture (CORBA) is a detailed
specification for the distributed objects. It was introduced by the OMG (Object
Management Group). The architecture describes a language with a platform-
independent object bus named as ORB (Object Request Broker).
The distributed component object model (DCOM) was introduced by Microsoft
with its Window NT as a bundle package. DCOM was used with Internet Explorer
present inside Windows and it was expected to attract the developers for using
what they have rather than buying. DCOM is also an object bus that helps the
specification of object interfaces and invoking dynamic object exports that
supports distributed environment. This supports sharing if code and requires the
shared code to be declared using an object interface.
SOA, or service-oriented architecture, defines a way to make software components
reusable via service interfaces. These interfaces utilize common communication
standards in such a way that they can be rapidly incorporated into new applications
without having to perform deep integration each time. In this way, SOA represents
an important stage in the evolution of application development and integration over
the last few decades.
Following diagram 3.1 shows the difference between before and after SOA

Diagram 3.1: Before and After SOA

Source: https://medium.com/@SoftwareDevelopmentCommunity/what-is-service-oriented-
architecture-fa894d11a7ec

3.2 Service Oriented Architecture

SOA can be stated as “Services that communicate with each other and this
communication can involve either simple data passing or it could involve two or
more services coordinating some activity. Some means of connecting services to
each other is needed.”
Here service can be well defined function which does not depend on the context or
state of the services. Service is also self-contained. These services are connected to
gather by using web services. A service is the endpoint of a connection. Also, a
service has some type of underlying computer system that supports the connection
offered.
A service has four properties:
 It logically represents a business activity with a specified outcome.
 It is self-contained.
 It is a black box for its consumers.
 It may consist of other underlying services.
SOA is an architecture that allows developers to combine multiple application
services into a larger, composite service. SOA can be implemented using SOAP-
(simple object access protocol) based web services or REST APIs, or sometimes a
combination of both. It's important to understand that in SOA, a service is any
remotely available resource that can respond to requests. A web service is
implemented using specific protocols.
Web Services connection technology is the base of service-oriented architectures.
The following diagram 3.1 illustrates a basic service request and response in
service-oriented architecture. It shows a service consumer at the right sending a
service request message to a service provider at the left. The service provider
returns a response message to the service consumer. The request and subsequent
response connections are defined in some way that is understandable to both the
service consumer and service provider. A service provider can also be a service
consumer.

Diagram 3.2 – Service request and response in Service Oriented Architecture

Source: https://www.service-architecture.com/articles/web-services/service-
oriented_architecture_soa_definition.html

Each service in an SOA includes the code and data integrations required to execute
a complete, discrete business function (e.g., checking a customer’s credit,
calculating a monthly loan payment, or processing a mortgage application). The
service interfaces provide loose coupling, meaning they can be called with little or
no knowledge of how the integration is implemented underneath. The services are
exposed using standard network protocols—such as SOAP (simple object access
protocol)/HTTP or JSON/HTTP—to send requests to read or change data. The
services are published in a way that enables developers to quickly find them and
reuse them to assemble new applications.

3.2.1 There are five horizontal layers in SOA architecture.

1. Consumer Interface Layer: End users are able to access through application.
These are GUI based applications.
2. Business Process Layer: These are business-use cases in terms of
application.
3. Services Layer: These are whole-enterprise, in service inventory.
4. Service Component Layer: are used to build the services, such as functional
and technical libraries.
5. Operational Systems Layer: It contains the data model.

3.2.2 SOA Architecture and Protocols

Diagram 3.3: SOA and Protocols

Source: https://www.w3schools.in/service-oriented-architecture/
 As per the diagram 3.3, the protocol stack of SOA shows that each protocol
along with their relationship among each protocol. These components are
often programmed to comply with SCA (Service Component Architecture),
a language that has broader but not universal industry support. These
components are written in BPEL (Business Process Execution Languages),
Java, C#, XML etc and can apply to C++ or FORTRAN or other modern
multi-purpose languages such as Python, PP or Ruby. With this, SOA has
extended the life of many all-time famous applications.

3.2.3 Elements of SOA

Diagram 3.4: Elements of SOA

Source: https://www.w3schools.in/service-oriented-architecture/
3.2.4 SOA Protocols and Communications
In SOA, services are described by the Web Services Description
Language (WSDL). Programmers use the XML extensively to structure data
that is used to wrap in a nearly exhaustive description-container. Now SOAP
describes the communications protocols. Whether these description languages
are the best possible for the job, and whether they will become/remain the
favorites in the future, remain open questions. As of SOA depends on data and
services that are described by metadata that should meet the following two
criteria:

1. The metadata should come in a form that software systems can use to
configure dynamically by discovery and incorporation of defined services,
and also to maintain coherence and integrity. For example, metadata could
be used by other applications, like a catalogue, to perform auto discovery of
services without modifying the functional contract of a service.

2. The metadata should come in a form that system designers can understand
and manage with a reasonable expenditure of cost and effort.

Simple Object Access Protocol (SOAP), originally defined as, is

a protocol specification for exchanging structured information in the
implementation of Web Services in computer networks. It relies
on Extensible Markup Language (XML) for its message format, and usually
relies on other Application Layer protocols, most notably Hypertext Transfer
Protocol (HTTP) and Simple Mail Transfer Protocol (SMTP), for message
negotiation and transmission.

SOAP is the foundation layer of a web services protocol stack, providing a

basic messaging framework upon which web services can be built. This
XML based protocol consists of three parts: an envelope, which defines
what is in the message and how to process it, a set of encoding rules for
expressing instances of application-defined datatypes, and a convention for
representing procedure calls and responses. SOAP has three major
characteristics:

1. Extensibility (security and WS-routing are among the extensions under

development),
2. Neutrality (SOAP can be used over any transport protocol such
as HTTP, SMTP, TCP, or JMS) and
 3. Independence (SOAP allows for any programming model).

SOAP working can be explained as a SOAP message could be sent to a web

site that has web services enabled, such as a real-estate price database, with
the parameters needed for a search. The site would then return an XML-
formatted document with the resulting data, e.g., prices, location, features.
With the data being returned in a standardized machine-parsable format, it
can then be integrated directly into a third-party web site or application.

The SOAP architecture consists of several layers of specifications: for

message format, Message Exchange Patterns (MEP), underlying transport
protocol bindings, message processing models, and protocol extensibility.
SOAP is the successor of XML-RPC, though it borrows its transport and
interaction neutrality and the envelope/header/body from elsewhere
(probably from WDDX).

3.3 Understanding the Coupling, Implementation of Service

Oriented Architecture (SOA)
We know that a service is a independent function that describes a piece of
functionality. A service can swap data and knowledge from different services. It is
not dependent on the nature of another service. It applies a loosely coupled,
message-based information design to interact with applications and additional
services.
In order to understand the implementation of SOA, let us see the principles of
SOA.

3.4 Principles of Service-Oriented Architecture (SOA)

There are total nine design principles to remain in memory while generating an
SOA service:
 Standardized Service Contract: Services stick to a service-description. A
service needs to have some information that defines what the service is about.

 Loose Coupling: Services minimize dependencies on each other. So if the

service functionality breaks at several points in time, this should not crush the
client application or stop it from running.
 Service Abstraction: Services wrap the logic they encapsulate from the
unknown external world. The service shouldn’t show how it performs its
functionality.

 Service Reusability: Logic is divided into services to maximize re-use.

 Service Autonomy: Services must control the logic they encapsulate.

 Service Statelessness: Services should stay stateless. This determines that

services should not keep data from one state to the other. This would be
required to be done from each client application.

 Service Discoverability: Services can be discovered (usually in a service

registry). We have previously viewed this in the theory of the UDDI, which
performs a registry which can contain information about the web service.

 Service Composability: It breaks large problems into tiny problems.

 Service Interoperability: Services should use standards that provide different

supporters to use the service. This is examined so obviously these days that it is
frequently dropped as a principle.
 Diagram 3.5: Service Oriented Architecture
Source: https://www.xenonstack.com/insights/service-oriented-architecture/

3.5 Service-Oriented Architecture (SOA) Terminology

SOA Stands for "Service Oriented Architecture." When businesses grow, they
often add new products and services. While these additions may help make the
business larger, it is often difficult to implement them in an efficient manner. The
goal of SOA is to make it easy for businesses to grow and add new services.

Service Consumer: It finds records in the broker registry using different find
services and then binds to the service provider to invoke one of its web services.
Which service the service-consumers require, they should take it into the Registry,
bind it with several services, and after that work on it. However, they can reach
various services if the service gives various services.

Service registry: It is a service provider that transfer service offers to one or more
further service providers. It is also known as a service broker and also called it a
repository.

Service provider: It generates a web service and produces the information to the
service registry or broker — each provider discusses which service to give more
attention: security or easy availability.
3.6 Characteristics of Service-Oriented Architecture (SOA)
SOA has following characteristics:

o It supports loose coupling everywhere in the project.

o It supports interoperability.
o It increases the quality of service
o It supports vendor diversity.
o It promotes discovery and federation.
o It is location-transparent
o It is still maturing and achievable idea

3.7 Benefits of Service-Oriented Architecture (SOA)

Feature Benefits Supporting Infrastructure
Improved information flow
Ability to expose internal functionality
Service Organizational flexibility
Lower software development and
Service Re-use management costs Service repository

Messaging Configuration flexibility Messaging program

Business intelligence
Performance measurement
Message Monitoring Security attack detection Activity monitor
Application of management policy
Message Control Application of security policy PDPs and PEPs

Message Transformation Data translation Data translator

Message Security Data confidentiality and integrity Encryption engine

Simplification of software structure

Ability to adapt quickly to different external
environments
Complex Event Processing Improved manageability and security Event processor
 Ability to develop new function
Service Composition combinations rapidly Composition engine

Ability to optimize performance,

functionality, and cost
Service Discovery Easier introduction of system upgrades Service registry

Asset Wrapping Ability to integrate existing assets

Improved reliability
Ability to scale operations to meet different
Virtualization demand levels

Model-driven Model-implementation
Implementation Ability to develop new functions rapidly environment

Table 3.1 Feature, benefits and supporting infrastructure of SOA

Source: WWW.opengroup.org/soa/source-book/soa

3.8 Advantages of Service oriented architecture (SOA)

Following are advantages of SOA

 Easy Service Maintenance: In order to edit and update any service is

easily done. Any service is maintained by a 3 rd party and any change in that
service will not affect your system. In most cases old API work as it is
working before.

 Same directory structure: Due to same directory Structure of Services,

consumers can access the service data from the same directory every time. If
any service has changed its location then also directory remains same. This
feature is very helpful for consumers.

 Prevents the reinventing the wheel: The service provider company can use
pre-build service and don’t have to rebuild the same functionality from
scratch. This will also increase the productivity of the service provider
company. Now the service provider company can only focus on its own
website or software without worrying about external component integration.
  Scalable: If any service getting many users then it can be easily scalable by
attaching more servers. This will make service available all time to the users.

 Reliable: Services are usually small size as compared to the full-fledged

application. So it is easier to debug and test the independent services.

 Quality of code improved: Every service is different from other in terms of

code. As services run independent of our system and they have their own
style of code so our code is prevented from redundancy. Also, our code
becomes error free.

 Independent of other services: Services are independent of each other. So

services can be used by multiple applications at the same time.

 Platform independence: Services communicate with other applications

through common language which means it is independent of the platform on
which application is running. Services can provide API in different
languages e.g. PHP, JavaScript etc.

3.9 Disadvantages of Service oriented architecture (SOA)

There are some disadvantages of SOA.

 Extra overload: In SOA, all inputs are validated before it is sent to the
service. If you are using multiple services then it will overload your system
with extra computation.

 High cost: SOA is costly in terms of human resource, development, and

technology.

 High bandwidth server: As some web service sends and receives messages
and information frequently so it easily reaches a million requests per day. So
it involves a high-speed server with a lot of data bandwidth to run a web
service.

3.10 Serving the Business with SOA and Cloud Computing

Some examples of SOA are below:-

 A website using payment service like PayPal integration

 An e-commerce website using TCS service (or any other service) for
physical shipment of products
 Any hotel getting food prepared through any outer service provider
 Any big organization get extra services from providers to run their business
is included in SOA

3.11 Summary.
Service Oriented Architecture (SOA) is an architectural approach in which
application components makes use of a collection of services available in a
network, which communicates with each other. In service oriented architecture,
services communicate with each other, either to pass the data or to coordinating an
activity.
SOA is an approach for distributed systems architecture that
employs loosely coupled services, standard interfaces and
protocols, to deliver seamless cross-platform integration. It is
used to integrate widely divergent components, by providing
them with a common interface and a set of protocols for them to
communicate through what is called a service bus. In business
terminology, SOA is a business-centric IT architectural service
that supports integrating your business as linked, repeatable
business tasks, or services. The structural design of SOA makes
sure that there is an alignment with the requirements of the
business as well as the technological solution of the same.

3.12 References.
3.12.1 Books
• Cloud Computing: Principles and Pardigms by Rajkumar Buyya, James
Broberg and Andrzej M.Gos cinski, Wiley, 2011.
•Distributed & Cloud computing, Kai Hwang, Geoffery C.Fox, jack
Elsevierm,2012
 • Cloud Computing implementation, management and security by John W.
Rittenhouse, James E Ransome,CRC Press, Taylor & Francis group,2010
• Cloud computing a practical approach by Anthony T. Velte, Toby J. Velte
Robert Elsenpeter, Tata Mc Graw Hill edition, 2010.
• Cloud Application Architecture by George Reese, Oreilly publishers
• Cloud computing and SOA convergence in your enterprise, by David
S.Linthicum, Addison- Wesley
• Cloud Services For Dummies, by Judith Hurwitz, Marcia Kaufman, and
Dr. Fern Halper, John Wiley & Sons, Inc.

3.12.2 Websites
• https://www.xenonstack.com/insights/service-oriented-architecture/
• https://www.visual-paradigm.com/guide/development/what-is-service-
oriented- architecture/
• https://www.itrelease.com/2018/10/advantages-and-disadvantages-of-
service-oriented-architecture-soa/
• https://www.w3schools.in/service-oriented-architecture/
• https://www.vskills.in/certification/tutorial/soa-communications/
• https://www.javatpoint.com/introduction-to-cloud-computing
• https://www.explainthatstuff.com/cloud-computing-introduction.html
• https://www.zdnet.com/article/what-is-cloud-computing-everything-you-
need-to-know-about-the-cloud/
• https://www.digitalocean.com/community/tutorials/a-general-introduction-
to-cloud-computing
• https://www.salesforcetutorial.com/introduction-to-cloud-computing/
• https://azure.microsoft.com/en-in/overview/what-is-cloud-computing/

3.13 Exercise.
Q.1. What is SOA? What are the main features of SOA?
Q.2. what are the benefits of SOA?
Q.3. what are the principles of SOA?
Q.4. Explain how do you transform an Enterprise business in a SOA?
Q.5. what are the common pitfalls of SOA?
Q.6. How can you achieve loose coupling in a SOA?
Q.7. what is the most important skill needed to adopt SOA? Technical or cultural?
Q.8. Explain SOA architecture
Q.9. what are the advantages of SOA?
Q.10. what is the relationship between SOA and cloud architecture?
Q.11. Explain basic SOA concepts and how they map to implementations?
Q.12. what are the major drawbacks of SOA?
Q.13. what is SOA governance?
Q.14. what are SOA governance functions?
Q.15. what are the components of SOA?