The document discusses Service Oriented Architecture (SOA), defining it as an architectural style for building systems based on interacting coarse-grained autonomous components called services. It outlines the basic SOA components - services, contracts, endpoints, messages, and policies. Services expose behavior through contracts composed of messages sent to discoverable endpoints. Behavior is governed by externally defined policies. The document also discusses best practices, the past and future of SOA, and introduces the concept of Cloud Service Oriented Architecture (C-SOA).

1. SOA
Harmeet S Sehra
+91-9810475080, sehraharmeet@gmail.com

4.  In order to be able to converge between the
technical and business viewpoints we first need to
differentiate between an architectural style and its
application – once we define what SOA is we can
apply it at an organization level to get an SOA
initiative where services will encapsulate business
function.
 However we can also apply SOA on a single project
and get services whose content revolves around
technical issues like security or management.

5.  We also need to differentiate between design goals
such as loose coupling or business alignment and
architectural building blocks and constraints like
coarse grained services or policy based interactions

6.  Based on that we can define Service Oriented
Architecture as an architectural style for building systems
based on interacting coarse grained autonomous
components called services.
 Each service expose processes and behavior through
contracts, which are composed of messages at
discoverable addresses called endpoints.
 Services’ behavior is governed by policies which are set
externally to the service itself.
 Now lets figure out basic SOA components and their
relations:

8. Service
 The central pillar of SOA is the service.
 A Service should provide a high cohesion and distinct function.
 Services should be coarse grained pieces of logic.
 A Service should implement at least all the functionality
promised by the contracts it exposes.
 One of the characteristics of services is service autonomy.
Autonomy means the services should be self-sufficient, at
least to some extent, and manifest self healing properties.

9. Contract
 The collection of all the messages supported by the
Service is collectively known as the service's contract.
 The contract can be unilateral, meaning a closed set of
messages the service chooses to provide.
 A contract might also be multilateral or bilateral, that is,
between a predefined group of parties.
 The contract can be considered the interface of the
Service akin to interfaces of object in object oriented
languages.

10. End Point
 The Endpoint is an address, a URI, a specific place
where the service can be found and consumed.
 A specific contract can be exposed at a specific
endpoint.

11. Message
 The unit of communication in SOA is the message.
 Messages can come in different forms and shapes,
for instance, http GET messages (part of the REST
style) ,SOAP messages, JMS messages and even
SMTP messages are all valid message forms.

12. Policy
 One important differentiator between Object Orientation or
Component Orientation and SOA is the existence of policy.
 If an interface or contract in SOA lingo, separates specification from
implementation.
 Policy separates dynamic specification from static/semantic
specification.
 Policy represents the conditions for the semantic specification
availability for service consumers.
 The unique aspects of policy are that it can be updated in run-time
and that it is externalized from the business logic. The Policy specify
dynamic properties like security (encryption, authentication, Id etc.) ,
auditing, SLA etc.

13. Service Consumer
 A service doesn’t mean much if there isn’t
someone/something in the world that uses it.
 So to complete the SOA picture we need Service
Consumers.
 A service consumer is any software that interacts with a
service by exchanging messages with the service.
 Consumers can be either client applications or other
"neighboring” services their only requirement is that they
bind to an SOA contract.

14. Best Practices

15.  A recent white paper from IBM Global Services describes the lessons
applied by IBM’s Academy of Technology to achieve success in their
SOA implementations. They did that by focusing on five priorities:
 Develop architecture with a vision for the future - looking beyond
simple connectivity and focusing more on architecture is the most
common recurring need for SOA implementations.
 Foresee linkages from IT to your business processes -
implementation of an architecture that transitions IT into the role of a
service provider for business functionality.
 Create an organizational structure to support SOA including
culture, skills, training, teaming, organization structure, decision
making, reward systems, collaboration and governance.
 Build a scalable infrastructure - create a baseline for your services
performance and scalability using appropriate instruments and
measurements.
 Enable operational visibility - focus on governance and service
management.

16. SOA: Past n Future

17. SOA: The Past
 Businesses have spent the last fifteen years trying to come up with a
set standard. While CORBA and DCOM have been in existence for a
while, they never became worldwide standards.
 Internet has set up standards in more than one way viz., HTTP and
HTML, which link together people all over the globe. Businesses
witnessing the growth and the development of the Internet decided to
use similar strategies to link their own computer systems together.
 Such Businesses first came up with Web services standards which
were based on technologies that originated on the Internet and made
use of technologies such as XML and HTTP as a means for
representing software parts and linking together a number of different
computer systems.
 There has been an adoption of web services as the standards to
base Service Oriented Architecture. Software vendors such as
webMethods have brought out a variety of products onto the market
that have made Service Oriented Architecture quite useful.

18. SOA: The Future
 In recent years there have been meaningful debate
on what standards Service Oriented Architecture
should be based upon in order to optimize
functionality in future scenarios
 The services themselves have to be oriented
towards Business if you expect Business people to
orchestrate them.

19. Cloud Service Oriented Architecture (C-
SOA) is an architectural approach to
leverage cloud computing resources
while utilizing Service Oriented
Architecture (SOA) disciplines to drive
substantial business value.
In this convergence, SOA provides the
underlying enterprise platform to
consume cloud services. Historically, as
business requirements evolved,
enterprises continued to deploy new
systems for almost every new
application suite.
The benefits of C-SOA include:
Increased collaboration and federation
Improved interoperability and agility
Aligned business and IT goals and efforts
Diversified choice of service providers
Increased ROI while reducing IT operating
cost and overhead