SOA - (Service Oriented Architecture)

What is SOA?
Why SOA?

Advantages of SOA

1. Re-usability – can be used in multiple processes

2. Loosely Coupled – No need for modifying the services when
the under laying technology changes or under laying system
changes
3. Inter-Operability – Across Platforms, Operating Systems and
Languages.
4. Defining Business Processes
5. Adapt Applications to Changing technologies
6. Easily Integrate with other systems
7. Leverage existing investments in legacy applications
8. Quick and easily create a business processes from existing
services
9. coarse-grained functionality
10. Hides complexity

SOA Governance
SOA Management
SOA Orchestration
SOA Choreography

 SOA – Service Oriented Architecture

 History of SOA

 What is SOA?

 Why SOA?

 Advantages of SOA

 SOA Governance

 SOA Management

 SOA Implementation

 SOA Orchestration

 SOA Choreography
  Case Studies

 Conclusion

 History of SOA…

As it is already known to everyone how software revluation started

1. To overcome/reduce huge paper work that are involved in the

Businesses, Organizations or across the departments

2. To compansate the work done manully and replace the processes with
softwares.

3. To maintain huge amount of data

4. To carry out the businesses at fast pace

5. To avoid err involved in manul processes

Then came the softwares which addresses these issues.

When the businesses are growing more and more. It has to addresses
the following issues

1. Doing the work in fast pace rether then treditional manner

 WHAT is SOA?

SOA is not an Tool, Softeware or a technology. SOA is holestic approch

toward the Software development.

Service Oriented Archetectur is all about services

"Artificial dependencies should be reduced to the minimum but real dependencies

should not be altered."

Now we are able to define a Service Oriented Architecture (SOA). SOA is an

architectural style whose goal is to achieve loose coupling among interacting
software agents. A service is a unit of work done by a service provider to
achieve desired end results for a service consumer. Both provider and
consumer are roles played by software agents on behalf of their owners.

This sounds a bit too abstract, but SOA is actually everywhere. Let's look at
an example of SOA which is likely to be found in your living room. Take a CD
for instance. If you want to play it, you put your CD into a CD player and the
player plays it for you. The CD player offers a CD playing service. This is nice
because you can replace one CD player with another. You can play the same
CD on a portable player or on your expensive stereo. They both offer the
same CD playing service, but the quality of service is different.

Every CD would come with its own player and they are not supposed to be
separated. This sounds odd, but it's the way we have built many software
systems.

 Service Encapsulation

 Service Loose Coupling

 Service Contracts

 Service Abstraction

 Service Reusability

 Service Compos-ability

 Service Autonomy

 Service Optimization

 Service Discoverability

Deriving Web Services from SOA

Despite the difficulty of defining web services, it is generally accepted that a
web service is a SOA with at least the following additional constraints:

1. Interfaces must be based on Internet protocols such as HTTP, FTP, and

SMTP.
2. Except for binary data attachment, messages must be in XML.

There are two main styles of Web services: SOAP web services and REST
web services.

 Why SOA?

 Advantages Of SOA

 Re-Usability

 Loosely Coupled

 Inter – Operability

o Across Platforms, Operating Systems and Languages

 Adapt applications to changing technologies

 easily integrate applications with other systems.

  Leverage existing investments in legacy applications.

 quickly and easily create a business process from existing services.

 SOA Implementation

 SOA Governance

• IT Governance

• Corporate Governance

It covers all aspects of the SOA life cycle. This model includes things like the
SOA vision, a starting point for SOA, the SOA processes that need to be
governed; the governance mechanisms that will be used to manage the SOA
environment — the policies, the principle, the standards, the procedures needed
to guide decision-making, the dashboards and metrics to monitor progress; the
skills needed to implement SOA; the organizational structure and change
management, including the governance charter, the center of excellence for
SOA, the roles and responsibilities, etc.; and the SOA infrastructure and the
supporting tools, especially those that are different from the non-SOA
implementations we have running in our environment.

a) Policies

b) Principle

c) Standards

d) Procedures

Governance is different from management. Governance plans for what decisions

will need to be made, whereas management is the process of making and
implementing the decisions. Governance sets policies, whereas management
follows them.

Governance becomes more important in SOA than in general IT. In SOA, service
consumers and service providers run in different processes, are developed and
managed by different departments, and require a lot of coordination to work
together successfully. For SOA to succeed, multiple applications need to share
common services, which means they need to coordinate on making those
services common and reusable. These are governance issues, and they're much
more complex than in the days of monolithic applications or even in the days of
reusable code and components.

In practice, SOA governance guides the development of reusable services,

establishing how services will be designed and developed and how those
services will change over time. It establishes agreements between the providers
of services and the consumers of those services, telling the consumers what they
can expect and the providers what they're obligated to provide.

SOA governance doesn't design the services, but guides how the services will be
designed. It helps answer many thorny questions related to SOA: What services
are available? Who can use them? How reliable are they? How long will they be
supported? Can you depend on them to not change? What if you want them to
change, for example, to fix a bug? Or to add a new feature? What if two
consumers want the same service to work differently? Just because you decide
to expose a service, does that mean you're obligated to support it forever? If you
decide to consume a service, can you be confident that it won't be shut down
tomorrow?

Governance is more of a political problem than a technological or business one.

Technology focuses on matching interfaces and invocation protocols. Business
focuses on functionality for serving customers. Technology and business are
focused on requirements. While governance gets involved in those aspects, it
focuses more on ensuring that everyone is working together and that separate
efforts are not contradicting each other. Governance does not determine what
the results of decisions are, but what decisions must be made and who will make
them.

Service Level Agreement

• Service definition
o Services must be identified, their functionality described,
their behavior scoped, and their interfaces designed.
• Service deployment life cycle
o Planned
o Test
o Active - Maintenance
o Deprecated
o Sunsetted
• Service versioning
o No sooner than a service is made available, the users of
those services start needing changes. Bugs need to be fixed,
new functionality added, interfaces redesigned, and
unneeded functionality removed.
o Service versioning meets these contradictory goals. It
enables users satisfied with an existing service to continue
using it unchanged, yet allows the service to evolve to meet
the needs of users with new requirements.
• Service migration
o When a consumer starts using a service, it is creating a
dependency on that service, a dependency that has to be
managed. A management technique is for planned, periodic
migration to newer versions of the service.
• Service registries
 o When a consumer starts using a service, a dependency on
that service is created. While each consumer clearly knows
which services it depends on, globally throughout an
enterprise these dependencies can be difficult to detect,
much less manage. Not only can a registry list services and
providers, but it can also track dependencies between
consumers and services. This tracking can help answer the
age-old question: Who's using this service? A registry aware
of dependencies can then notify consumers of changes in
providers, such as when a service becoming deprecated
• Service message model
• Service monitoring
• Service ownership
• Service testing
• Service security

• SOA Management

• SOA Orchestration

• SOA Choreography

 Case Studies

 Conclusion

 References

SOA Governance

o http://www.ibm.com/developerworks/library/ar-servgov/