Cloud Computing depict a broad movement towards internet and the use of WAN and enable smooth

interaction between IT service providers of many types and consumers. Cloud technology brings with it a large
number of key benefits and risks. These includes:

 Outsourcing to cloud-providers
 Dependence on network
 Dependence on Cloud Providers
 Information Assurance

DoD has some Cloud computing considerations that includes:

 Economies of Sale
 Key Obstacles
 Enabling Service Focus

Defining SOA
SOA (Service Oriented Architecture) is built on computer engineering approaches that offer an architectural
advancement towards enterprise system. It describes a standard method for requesting services from
distributed components and after that the results or outcome is managed. The primary focus of this service
oriented approach is on the characteristics of service interface and predictable service behavior. Web Services
means a set or combination of industry standards collectively labeled as one. SOA provides a translation and
management layer within the cloud architecture that removes the barrier for cloud clients obtaining desired
services. Multiple networking and messaging protocols can be written using SOA's client and components and
can be used to communicate with each other. SOA provides access to reusable Web services over a TCP/IP
network, which makes this an important topic to cloud computing going forward.

Service Oriented Architecture

Service-Oriented Architecture (SOA) is a stage in the evolution of application development and/or
integration. It defines a way to make software components reusable using the interfaces.
Formally, SOA is an architectural approach in which applications make use of services available in
the network. In this architecture, services are provided to form applications, through a network call
over the internet. It uses common communication standards to speed up and streamline the service
integrations in applications. Each service in SOA is a complete business function in itself. The
services are published in such a way that it makes it easy for the developers to assemble their apps
using those services. Note that SOA is different from microservice architecture.
 SOA allows users to combine a large number of facilities from existing services to form
applications.
 SOA encompasses a set of design principles that structure system development and provide
means for integrating components into a coherent and decentralized system.
 SOA-based computing packages functionalities into a set of interoperable services, which can
be integrated into different software systems belonging to separate business domains.
There are two major roles within Service-oriented Architecture:
1. Service provider: The service provider is the maintainer of the service and the organization
that makes available one or more services for others to use. To advertise services, the provider
can publish them in a registry, together with a service contract that specifies the nature of the
service, how to use it, the requirements for the service, and the fees charged.
2. Service consumer: The service consumer can locate the service metadata in the registry and
develop the required client components to bind and use the service.

Services might aggregate information and data retrieved from other services or create workflows of
services to satisfy the request of a given service consumer. This practice is known as service
orchestration Another important interaction pattern is service choreography, which is the
coordinated interaction of services without a single point of control.
Components of SOA:

Guiding Principles of SOA:

1. Standardized service contract: Specified through one or more service description documents.
2. Loose coupling: Services are designed as self-contained components, maintain relationships
that minimize dependencies on other services.
3. Abstraction: A service is completely defined by service contracts and description documents.
They hide their logic, which is encapsulated within their implementation.
4. Reusability: Designed as components, services can be reused more effectively, thus reducing
development time and the associated costs.
5. Autonomy: Services have control over the logic they encapsulate and, from a service consumer
point of view, there is no need to know about their implementation.
6. Discoverability: Services are defined by description documents that constitute supplemental
metadata through which they can be effectively discovered. Service discovery provides an
effective means for utilizing third-party resources.
7. Composability: Using services as building blocks, sophisticated and complex operations can
be implemented. Service orchestration and choreography provide a solid support for composing
services and achieving business goals.
Advantages of SOA:
 Service reusability: In SOA, applications are made from existing services. Thus, services can
be reused to make many applications.
 Easy maintenance: As services are independent of each other they can be updated and
modified easily without affecting other services.
 Platform independent: SOA allows making a complex application by combining services
picked from different sources, independent of the platform.
 Availability: SOA facilities are easily available to anyone on request.
 Reliability: SOA applications are more reliable because it is easy to debug small services
rather than huge codes
 Scalability: Services can run on different servers within an environment, this increases
scalability
Disadvantages of SOA:
 High overhead: A validation of input parameters of services is done whenever services interact
this decreases performance as it increases load and response time.
 High investment: A huge initial investment is required for SOA.
 Complex service management: When services interact they exchange messages to tasks. the
number of messages may go in millions. It becomes a cumbersome task to handle a large
number of messages.
Practical applications of SOA: SOA is used in many ways around us whether it is mentioned or
not.
1. SOA infrastructure is used by many armies and air forces to deploy situational awareness
systems.
2. SOA is used to improve healthcare delivery.
3. Nowadays many apps are games and they use inbuilt functions to run. For example, an app
might need GPS so it uses the inbuilt GPS functions of the device. This is SOA in mobile
solutions.
4. SOA helps maintain museums a virtualized storage pool for their information and content.
Here lies the protocol stack of SOA showing 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.

Security in SOA
With the vast use of cloud technology and its on-demand applications, there is a need for well - defined
security policies and access control. With the betterment of these issues, the success of SOA architecture will
increase. Actions can be taken to ensure security and lessen the risks when dealing with SOE (Service Oriented
Environment). We can make policies that will influence the patterns of development and the way services are
used. Moreover, the system must be set-up in order to exploit the advantages of public cloud with resilience.
Users must include safety practices and carefully evaluate the clauses in these respects.

Elements of SOA
Here's the diagrammatic figure showing the different elements of SOA and its subparts:

Figure - Elements Of SOA:

Though SOA enjoyed lots achieving the success in the past, the introduction to cloud technology with SOA,
renewed the value of SOA.

Event Driven SOA

Event-driven architecture is a methodology used for designing and implementing applications where events
transmit among decoupled software components and services.
In order to make the connections between the different events that do not appear to be clear, the event-driven
SOA allows business users to monitor and analyze the events. SOA is capable of creating high-level business
events from many low-level system events. Events are created by filtering real-time data with the details such
as dependencies or casual relationships found by connecting other events.
An event-driven architecture is composed of Event Producers are the source of the event and it will know that
the event has occurred and Event Consumers are the entity that needs to know the event has occurred.
 Event consumers typically subscribe to an intermediary event manager, whereas event producers
publish to this manager.
 The event manager receives an event form the event producer and forwards that event to all the event
consumers that are registered.
 The manager can also store the event and try to forward that event later, if the event consumer is
unavailable. This event transmission method is known as store and forward in message-based systems.
This event-driven is organized around the concept of decoupled relationships between event producers and
event consumers. An event consumer is only concerned that it will be invoked when the event has occurred,
rather than caring where and why an event occurs. Enabling large number of creators and consumers to
exchange status and response in real time is a good advantage of event-driven architecture.
Enterprise Service Bus

The Enterprise Service Bus (ESB) is a software architecture which connects all the services together over a bus
like infrastructure. It acts as communication center in the SOA by allowing linking multiple systems,
applications and data and connects multiple systems with no disruption.

ESB Basics

The above picture depicts the communication between software applications in a service-oriented architecture via ESB. Bus is a communication
system that transfers data between computers and interconnects the hard disk drives, CD ROM, graphics adapters and other chips.

ESB as Transaction Manager

As shown in the above figure, the ESB can synchronize with transactions to communicate with multiple
services. Instead of notifying the web applications to coordinate with transaction, the ESB can synchronize
with transaction when multiple distributed applications get involved in a transaction.

ESB as Security Manager

The authentication and authorization mechanisms are very important parts of security check which are incorporated under ESB. The ESB
provides these security mechanisms to inter connect between the web applications.

ESB as Service Proxy

The SOA uses proxy which interprets the service calls between two different client service protocols. For instance, consider you need to access a
service which can be accessible only through the Java's RMI (Remote Method Invocation) and this service can be accessed using the web service
interface (SOAP). To resolve this, you can use the service proxy which accepts the SOAP calls and render them according to Java RMI service.

ESB as Gateway to the World

ESB uses the gateway (acts as entrance to another network) through which it can connect to the different
services running in the other networks. The gateway manages the data communication which is routed
internally or externally from the network. If user wants to access service of an outside network, then user
passes data packet to the gateway, which then connect to the requested service destination.

What is Service Catalog

Service Catalog is a tool for service portfolio management decisions. It identifies the linkage
between service assets, services, and business outcomes It also identifies the demand for a
service and shows how the service provider will fulfill the demand.

Now, we will learn the purpose of the service catalog management process.

Purpose and Objectives of Service Catalog Management

The purpose of the service catalog management process is to provide and maintain a single
source of consistent information on all operational services and those being prepared to be run
operationally and to ensure that it is widely available to those who are authorized to access it.
The objective of the service catalog management process are to:
 Manage the information contained in the service catalog

 Ensure that the service catalog is accurate and reflects the current details, status, interfaces, and
dependencies of all services that are being run, or being prepared to run, in the live environment,
according to the defined policies

 Ensure that the service catalog is made available to those approved to access it in a manner that
supports their effective and efficient use of service catalog information

 Ensure that the service catalog supports the evolving needs of all other service management processes
for service catalog information, including all interface and dependency information.

Scope of Service Catalog Management

The scope of the service catalog management process is to provide and maintain accurate
information on all services that are being transitioned or have been transitioned to the live
environment. The services presented in the service catalog may be listed individually or, more
typically, some or all of the services may be presented in the form of service packages. The
service catalog management process covers:

 Contribution to the definition of services and service packages

 Development and maintenance of service and service package descriptions appropriate for the service
catalog

 Production and maintenance of an accurate service catalog Interfaces, dependencies, and consistency
between the service catalog and the overall service portfolio

 Interfaces and dependencies between all services and supporting services within the service catalog
and the CMS

 Interfaces and dependencies between all services, and supporting components and configuration items
(CIs) within the service catalog and the CMS.

The service catalog management process does not include:

 Detailed attention to the capturing, maintenance and use of service asset and configuration data as
performed through the service asset and configuration management process.

 Detailed attention to the capturing, maintenance and fulfillment of service requests as performed
through request fulfillment.

Value to the Business

 The service catalog provides a central source of information on the IT services delivered by the
service provider organization. This ensures that all areas of the business can view an accurate,
consistent picture of the IT services, their details and their status. It includes a customer-facing
view (or views) of the IT services in use, how they are intended to be used, the business
processes they enable, and the levels and quality of service the customer can expect for each
service. Through the work of service catalog management, organizations can:

 Ensure a common understanding of IT services and improved relationships between the customer and
service provider by utilizing the service catalog as a marketing and communication tool

 Improve service provider focus on customer outcomes by correlating internal service provider
activities and service assets to business processes and outcomes

 Improve efficiency and effectiveness of other service management processes by leveraging the
information contained in or connected to the service catalog Improve knowledge, alignment and focus
on the ‘business value’ of each service throughout the service provider organization and its activities.

Let us know more about the Service catalog in the next section and find what the aspects of the
Service catalog are.

Types of Service Catalog

The structure and presentation of the service catalog should support the uses, to which it will be
put, taking into consideration the different, sometimes conflicting needs of different audiences.
Not every service is of interest to every person or group. Not every piece of information about a
service is of interest to every person or group.

When service providers have many customers or serve many businesses, there may be multiple
service catalog views projected from the service portfolio. When initially completed, the service
catalog may consist of a matrix, table or spreadsheet. Many organizations integrate and maintain
their service portfolio and service catalog as part of their CMS.

By defining each service as a CI and, where appropriate, relating these to form a service
hierarchy, the organization is able to relate such things as incidents and requests for change to
the services affected, thus providing the basis for service monitoring and reporting using an
integrated tool (e.g. ‘list or give the number of incidents affecting this particular service’).

It is therefore essential that changes within the service portfolio and its constituent service
catalog are subject to the change management process. It is advisable to present more than one
view of the information in the service catalog to accommodate the different needs of those who
will use it.

In order to ensure that both the customer and IT have a clear understanding of the relationship
between the outcome-based, customer-facing services and the business processes they support, it
 is recommended that a service provider, at the minimum, defines two different views, each one
focusing on one type of service:

 a view for customers that shows the customer-facing services,

 a second view for the IT service provider showing all the supporting services.

The data stored in the service catalog regarding relationships and dependencies between items
would allow information in one view to be accessed from another when deemed appropriate.
Service catalog has two views.

 Business/ Customer Service catalog view and

 Technical Service catalog view.

The Business/Customer Service Catalog View:

This contains details of all the IT services delivered to the customers (customer-facing services),
together with relationships to the business units and the business processes that rely on the IT
services. This is the customer view of the service catalog. In other words, this is the service
catalog for the business to see and use.

The Technical/Supporting Service Catalog View

This contains details of all the supporting IT services, together with relationships to the
customer-facing services they underpin and the components, CIs and other supporting services
necessary to support the provision of the service to the customers.
Some organizations only maintain either a Business Service catalog or a Technical Service
catalog. The preferred situation adopted by the more mature organizations maintains both aspects
within a single Service catalog, which is part of a totally integrated Service Management activity
and Service Portfolio.

The Business Service catalog facilitates the development of a much more proactive or even pre-
emptive SLM process, allowing it to develop more into the field of Business Service
Management.

The Technical Service catalog is extremely beneficial when constructing the relationship
between services, SLAs, OLAs and other underpinning agreements and components, as it will
identify the technology required to support service and the support group(s) that support the
components.

The combination of a Business Service catalog and a Technical Service catalog is invaluable for
quickly assessing the impact of incidents and changes in the business.

In the next section, we will understand the key activities within the Service Catalog Management
process.

Service level agreements in Cloud computing

A Service Level Agreement (SLA) is the bond for performance negotiated between the cloud
services provider and the client. Earlier, in cloud computing all Service Level Agreements were
negotiated between a client and the service consumer. Nowadays, with the initiation of large utility-
like cloud computing providers, most Service Level Agreements are standardized until a client
becomes a large consumer of cloud services. Service level agreements are also defined at different
levels which are mentioned below:
 Customer-based SLA
 Service-based SLA
 Multilevel SLA
Few Service Level Agreements are enforceable as contracts, but mostly are agreements or contracts
which are more along the lines of an Operating Level Agreement (OLA) and may not have the
restriction of law. It is fine to have an attorney review the documents before making a major
agreement to the cloud service provider. Service Level Agreements usually specify some
parameters which are mentioned below:
1. Availability of the Service (uptime)
2. Latency or the response time
3. Service components reliability
4. Each party accountability
5. Warranties
In any case, if a cloud service provider fails to meet the stated targets of minimums then the provider
has to pay the penalty to the cloud service consumer as per the agreement. So, Service Level
Agreements are like insurance policies in which the corporation has to pay as per the agreements if
any casualty occurs.
Microsoft publishes the Service Level Agreements linked with the Windows Azure Platform
components, which is demonstrative of industry practice for cloud service vendors. Each individual
component has its own Service Level Agreements. Below are two major Service Level Agreements
(SLA) described:
1. Windows Azure SLA –
Window Azure has different SLA’s for compute and storage. For compute, there is a guarantee
that when a client deploys two or more role instances in separate fault and upgrade domains,
client’s internet facing roles will have external connectivity minimum 99.95% of the time.
Moreover, all of the role instances of the client are monitored and there is guarantee of detection
99.9% of the time when a role instance’s process is not runs and initiates properly.
2. SQL Azure SLA –
SQL Azure clients will have connectivity between the database and internet gateway of SQL
Azure. SQL Azure will handle a “Monthly Availability” of 99.9% within a month. Monthly
Availability Proportion for a particular tenant database is the ratio of the time the database was
available to customers to the total time in a month. Time is measured in some intervals of minutes
in a 30-day monthly cycle. Availability is always remunerated for a complete month. A portion of
time is marked as unavailable if the customer’s attempts to connect to a database are denied by
the SQL Azure gateway.
Service Level Agreements are based on the usage model. Frequently, cloud providers charge their
pay-as-per-use resources at a premium and deploy standards Service Level Agreements only for that
purpose. Clients can also subscribe at different levels that guarantees access to a particular amount of
purchased resources. The Service Level Agreements (SLAs) attached to a subscription many times
offer various terms and conditions. If client requires access to a particular level of resources, then the
client need to subscribe to a service. A usage model may not deliver that level of access under peak
load condition.
Scalability and Elasticity in Cloud Computing
Cloud Elasticity :
The Elasticity refers to the ability of a cloud to automatically expand or compress the infrastructural
resources on a sudden-up and down in the requirement so that the workload can be managed
efficiently. This elasticity helps to minimize infrastructural cost. This is not applicable for all kind of
environment, it is helpful to address only those scenarios where the resources requirements fluctuate
up and down suddenly for a specific time interval. It is not quite practical to use where persistent
resource infrastructure is required to handle the heavy workload.
It is most commonly used in pay-per-use, public cloud services. Where IT managers are willing to
pay only for the duration to which they consumed the resources.
Example :
Consider an online shopping site whose transaction workload increases during festive season like
Christmas. So for this specific period of time, the resources need a spike up. In order to handle this
kind of situation, we can go for Cloud-Elasticity service rather than Cloud Scalability. As soon as the
season goes out, the deployed resources can then be requested for withdrawal.
Cloud Scalability :
Cloud scalability is used to handle the growing workload where good performance is also needed to
work efficiently with software or applications. Scalability is commonly used where the persistent
deployment of resources is required to handle the workload statically.
Example :
Consider you are the owner of a company whose database size was small in earlier days but as time
passed your business does grow and the size of your database also increases, so in this case you just
need to request your cloud service vendor to scale up your database capacity to handle a heavy
workload.
It is totally different from what you have read above in Cloud Elasticity. Scalability is used to fulfill
the static needs while elasticity is used to fulfill the dynamic need of the organization. Scalability is a
similar kind of service provided by the cloud where the customers have to pay-per-use. So, in
conclusion, we can say that Scalability is useful where the workload remains high and increases
statically.
Types of Scalability :
1. Vertical Scalability (Scale-up) –
In this type of scalability, we increase the power of existing resources in the working environment in
an upward direction.
 2. Horizontal Scalability –
In this kind of scaling, the resources are added in a horizontal row.

3. Diagonal Scalability –
It is a mixture of both Horizontal and Vertical scalability where the resources are added both
vertically and horizontally.

Difference Between Cloud Elasticity and Scalability :

Cloud Elasticity Cloud Scalability

Elasticity is used just to meet the sudden

up and down in the workload for a small Scalability is used to meet the static
period of time. increase in the workload.
1

Elasticity is used to meet dynamic

changes, where the resources need can Scalability is always used to address the
increase or decrease. increase in workload in an organization.
2

Elasticity is commonly used by small Scalability is used by giant companies

companies whose workload and demand whose customer circle persistently grows in
increases only for a specific period of time. order to do the operations efficiently.
3

It is a short term planning and adopted just Scalability is a long term planning and
to deal with an unexpected increase in adopted just to deal with an expected
demand or seasonal demands. increase in demand.
4
Advanced services through large-scale data processing

It is difficult to manage the data generated in the web, IT systems, etc. (e.g., transaction logs, sensor logs, and life logs) and other data that

continues to increase explosively in volume. Analysis of such voluminous data (known as big data) in a conventional manner becomes

exponentially costly even when the data is collected by the system, so the data has been either stored wastefully or discarded. The advent of scale-

out technology, however, has reduced the cost of constructing systems for processing large-scale data, and new advanced services such as

personalization based on analytical results are now possible.

Large-scale data processing enables the use of diverse types of big data in a cloud environment in order to create mash-up*1 services, as shown

in Fig. 1. A large-scale distributed data processing platform collects and stores the big data produced by IT systems or the Internet. By analyzing

such large volumes of data, one can acquire new knowledge and expertise and create new mash-up services. A large-scale distributed data

processing platform is expected to serve as a platform for creating knowledge on which to base advanced services for customers.