Cloud Service Oriented Architecture

1. Cloud Applications
Design Considerations of Cloud Applications
1)Scalability
2) Reliability and Availability
3) Security
4) Maintenance and Up gradation
5) Performance
1. Scalability
Scalability is an important factor that drives the application designers to move to cloud computing environments. Building applications that can serve millions of users without taking a hit
on their performance has always been challenging. With the growth of cloud computing application designers can provision adequate resources to meet their workload levels. However,
simply provisioning more and more resources may not bring performance gains if the applications are not designed to scale well. There are several design considerations that the developers
need to keep in mind. Traditional approaches were based on either over provisioning of resources to handle the peak workload levels expected or provisioning based on average workload
levels. Both approaches have their disadvantages. While the over provisioning approach leads to underutilization of resources and increased costs, the approach based on average workload
levels can lead to traffic overloads, slow response times, low throughputs and hence loss of opportunity to serve the customers. In order to leverage the benefits of cloud computing such as
dynamic scaling, the following design considerations must be kept in mind:
Loose coupling of components : Traditional application design methodologies with tightly coupled application components, limit the scalability. Tightly coupled components use
procedure based tight coupling and hard-wired links which make it difficult to scale application components independently. By designing loosely coupled compo nents, it is possible to scale
each component independently.
Stateless Design : Stateless designs that store state outside of the components in a separate database allow scaling the application components independently,
Asynchronous communication: In traditional application designs, it is a common practice to process a request and return immediately. This limits the scalability of the application. By
allowing asynchronous communication between components, it is possible to add capacity by adding additional servers when the application load increases.
Database choice and design: Choice of the database and the design of data storage schemes affect the application scalability. Decisions such as whether to choose a traditional relational
database (SQL approach) with strict schemas or a schema-less database (No-SQL approach) should be made after careful analysis of the application's data storage and analysis
requirements.

2. 2. Reliability & Availability
Reliability of a system is defined as the probability that a system will perform the intended functions under stated conditions for a specified amount of time.
Availability is the probability that a system will perform a specified function under given conditions at a prescribed time. The important considerations to be kept in
mind while developing highly reliable and available applications are:
No single point of failure: Traditional application design approaches which have single points of failure such as a single database server or a single application server
have the risk of complete breakdowns in case the of failure of the critical resource. To high achieve reliability and availability, having a redundant resource or an
automated fallback resource is important.
Trigger automated actions on failures: Traditional application design approaches handled failures by giving exceptions. By using failures and triggers for automated
actions it is possible to improve the application reliability and availability. For example, if an application server experiences high CPU usage and is a unable to server
new requests, a new application server is automatically launched.
Graceful degradation: Applications should be designed to gracefully degrade in the event of outages of some parts or components of the application. Graceful
degradation means that if some component of the application becomes unavailable the application as a whole would still be available and continue to serve the users,
though, with limited functionality. For example, in an e-Commerce application, if a component that manages a certain category of products becomes unavailable, the
users should still be able to view products from other categories.
Logging: Logging all events in all the application components can help in detecting bottlenecks and failures so that necessary design/deployment changes can be
made to improve application reliability and availability.
Replication: All application data should be replicated. Replication is used to create and maintain multiple copies of the data in the cloud. In the event of data loss
at the primary location, organizations can continue to operate their applications from secondary data sources.

3. 3. Security
Security is an important design consideration for cloud applications given the out sourced nature of cloud computing environments. In domains such as healthcare
there are several government laws that require the applications to ensure security of health information of patients. Key security considerations for cloud computing
environments are:
•Securing data at rest
•Securing data in motion
•Authentication
•Authorization
•Identity and access management
•Key management
•Data integrity
•Auditing
4. Maintenance & Upgradation
To achieve a rapid time-to-market, businesses typically launch their application a core set of features ready and then incrementally add new features as and when they
are complete. Businesses may need to adapt their applications based on the feedback from the users. In such scenarios, it is important to design applications with low
maintenance and upgradation costs. Design decisions such as loosely coupled components help in reducing the application maintenance and upgradation time. In
applications with loosely coupled components, changes can be made to a component. without affecting other components. Moreover, components can be tested
individually Other decisions such as logging and triggering automated actions also help in lowering the maintenance costs.

4. 5. Performance
Applications should be designed while keeping the performance requirements in mind. Performance requirements depend on the
type of the application. For example applications which experience high database read-intensive workloads, can benefit from read-
replication or caching approaches. There are various metrics that are use to evaluate the application performance, such as response
time, throughput, etc. For a good user experience a response time less than 4 seconds is generally acceptable However certain
applications may have even more strict requirements.

5. Service Oriented Architecture
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.
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.
Concepts of WSDL
A WSDL 2.0 description contains:
•Service- describes discrete system function exposed as a web service
•End Point - It is the address of the web service
•Binding - It specifies interface and transport protocol
•Interface- It defines web service and operations that can be performed by the service and the input and outputs
•Operations- It defines how the message is decoded and the actions that can be performed
•Types - It describes the data

7. Components of Service Oriented Architecture

8. Layers of Service Oriented Architecture
The layers of SOA are
Business Systems - This layer consists of custom built applications and legacy systems such as Enterprise Resource
Planning(ERP),Customer Relationship Management (CRM),Supply Chain Management (SCM) etc.
Service Components -The service components allows the layers above to interact with the business systems. The service components
are responsible for realizing the functionality of the services provided.
Composite Services - They are coarse-grained services which are composed of two or more service components .It can be used to
create enterprise scale components or business unit specific components.
Orchestrated Business Processes - Composite services can be orchestrated to create higher level business processes. In this layer the
compositions and orchestrations of the composite services are defined to create business processes.
Presentation Services - This is the topmost layer that includes user interfaces that exposes the services and orchestrated business
processes to the users.
Enterprise Service Bus - This layer integrates the services through adapters, routing, tranformation and messaging mechanisms.

10. Guiding Principles of SOA:
Standardized service contract: Specified through one or more service description documents.
Loose coupling: Services are designed as self-contained components, maintain relationships that minimize dependencies on other services.
Abstraction: A service is completely defined by service contracts and description documents. They hide their logic, which is encapsulated within
their implementation.
Reusability: Designed as components, services can be reused more effectively, thus reducing development time and the associated costs.
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.
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.
Composability: Using services as building blocks, sophisticated and complex operations can be implemented. Service orchestration and
choreography

11. Cloud Component Model (CCM)
Cloud Component Model (CCM) is a application design methodology that provides a flexible way of creating an application in
rapid, convenient, platform independent manner unlike the existing approaches that use architecture-specific and domain-specific
templates. It is architectural approach that is not tied to any specific programming language or cloud platform. It can contribute to
innovative hybrid deployments in which components of an application can be deployed in cloud infrastructure and platforms of
different cloud vendors. It has better portability and interoperability. CCM based applications have better scalability because of
asynchronous communication and decoupling of application components. CCM makes maintainability of cloud application easier
as each component of the application can be improved or upgraded independent of other components. CCM provides cost benefits
to the cloud application as components can be carefully mapped to cloud resources and by scaling the resources up only for
components which require additional computing capacity.
The steps in CCM approach are as follows:
1.Component Design
2.Architecture Design
3.Deployment Design

13. 1. Component Design
Cloud Component Model is created for the application based on the comprehensive analysis of the application’s functions and building blocks. Cloud
Component Model allows to identify the building blocks of cloud application which are classified based on the functions performed and the type of cloud
resources required. Each building block performs a set of actions to produce the desired outputs for other components. Each component takes specific
inputs performs pre-defined set of actions and produces the desired outputs. Components offer their services through functional interface which can be
used by other components. Components report their performance to a performance database through performance interface. Components have number of
resources like web pages, images, documents, database tables etc. Auto Scaling performance constraints and conditions can be specified for each
component. Component based approach is applicable to web based applications and mobile applications.

14. 2. Architecture Design
In this step the interactions between the application components are defined. CCM Components have the following characteristics:
Loose Coupling :
Components in the Cloud component model is loosely coupled. Instead of hard-wiring the links the components interface through clearly defined functional and service
boundaries.Link between the components are established and broken as they respond to service requests. Loose coupling of components relies on REST communication
protocol that allows components developed in different programming language to communicate to each other.
Asynchronous Communication :
Loosely coupled components communicate asynchronously through message based communication using message queues. The benefit of messaging queues is that the
overall application can continue to perform even though individual components may go offline temporarily. When the component becomes temporarily unavailable the
messages are buffered and processed when the component becomes available again. Loose coupling isolates the components of the application and each component
communicates in an asynchronous manner treating other components as black boxes. Because of asynchronous communication it is possible to add additional servers when
the application load increases.
Stateless Design :
Components in Cloud component model are stateless. By storing session state outside of the component, stateless component design enables distribution and horizontal
scaling. In distributed computing with horizontal scaling of components successive requests to a component may be serviced by different servers.
3. Deployment Design
In this step the application components are mapped to specific cloud resources such as web servers, database servers , application servers etc. As the application components
are loosely coupled and stateless with asynchronous communication the components can be deployed independently. Moreover multiple clouds can be used for application
deployment. This approach makes it easy to migrate application components from one cloud to another easily. With this flexibility in application design and deployment the
application developers can ensure that the applications meet the performance and cost requirements with changing contexts.

15. Model View Controller
Model :Model manages the data and the behavior of the applications. Model processes
event sent by controller. Model responds to the requests for information about its
state (from the view) and responds to the instructions to change state (from controller).
View: View prepares the interface which is shown to the user. User.; interact with the
application through views. Views present the information that the model or controller tell the
view to present to the user and also handle user requests and sends them to the controller.
Controller: Controller glues the model to the view. Controller processes user
requests and updates the model when the user man ipulates the view.
Controller also updates the view when the model changes.

17. MVC separates the application logic, the data, and the user interface. The benefit of using MVC is that improves
the maintainability lity of the application and allows reuse of code. The applications built with MVC architecture
can be updated easily due to the separation of the model from the view. In MVC, both the view and controller
depend on the model, however, the model does not depend on either. This allows the model to be developed
and tested independently. Similarly the separation between the view and the controller is also well defined for web
applications.
ln traditional applications the view is generally tightly coupled with the model. Since views are likely to change
more frequently than the model, this tight coupling requires re-wiring the l inks. With MVC, the views can be
changed without affecting t he model.