Service Oriented Architecture

1. 1
SERVICE
ORIENTED
ARCHITECTURE
SOA
Presented by:
G Emmanuel sandeep
MBA(SEM)

2. AGENDA
What is SOA?
Elements of SOA
Why SOA?
Objectives of SOA
SOA principles
Technologies Used
Service­oriented analysis and development
Service contract
challenges faced in SOA adoption
2

3. 3
WHAT IS SOA?
There is no widely-agreed upon definition of Service-oriented
architecture other than its literal translation that it is an
architecture that relies on service-orientation as its fundamental
design principle. Service-orientation describes an architecture that
uses loosely coupled services to support the requirements of
business processes and users. Resources on a network

in an SOA
environment are made available as independent services that can be
accessed without knowledge of their underlying platform
implementation. These concepts can be applied to business,
software and other types of producer/consumer systems.

4. 4
WHAT IS SOA? [CONTD..]
SOA should be business oriented
SOA is a way of thinking
SOA is not Web Services
Loosely coupled architecture that uses messaging
Enriched by creating composite apps
Move from batch to real-time

5. 5
Elements of SOA

6. 6
WHY SOA?
The main drivers for SOA adoption are that it links
computational resources and promotes their reuse.
Enterprise architects believe that SOA can help
businesses respond more quickly and cost-effectively to
changing market conditions. This style of architecture
promotes reuse at the macro (service) level rather than
micro level (objects).
To gain some type of ROI
Internal (for the organization)
External (for customers or partners)
To be competitive
Time to market
More robust applications

7. 7
OBJECTIVES OF SOA
Technology Independence
The Consumer of a Service component is completely 
independent of the technology of the Provider 
component and vice­versa.
Life­cycle Independence
Each of the Provider and Consumer Service 
components should be able to operate in a separate 
life­ cycle.
Loose Coupling
The Service Consumer Component must define its 
specification independent of the Service Provider 
Component

8. OBJECTIVES OF SOA[CONTD..]
Invokable interfaces
The Service interfaces must be invokable either 
locally or remotely.
Communication Protocol
A Service must be invokable by variety of protocol.
Binding to a specific protocol must take place at run­
time/deployment­time, and not at the design or 
development time.
The choice of protocol must not restrict the behavior 
of the Service.
8

9. 9
SOA PRINCIPLES
   The following guiding principles define the ground
rules for development, maintenance, and usage of the
SOA
Reuse, granularity, modularity, composability,
componentization, and interoperability
Compliance to standards (both common and industry-
specific)
Services identification and categorization, provisioning and
delivery, and monitoring and tracking

10. 10
SOA PRINCIPLES:
SPECIFIC ARCHITECTURAL
PRINCIPLES
Service Encapsulation
Service Loose coupling
Service contract 
Service abstraction
Service documentation
Service reusability
Service composability
Service autonomy
Service optimization

11. TECHNOLOGIES USED
Architecture is not tied to a specific technology. It may 
be implemented using a wide range of technologies, 
including:
REST­Representational state transfer
RPC­Remote Procedure Call
DCOM­Distributed Component Object Model
CORBA­Common Object Request Broker Architecture 
Web Services
SOA can be implemented using one of these protocols 
and, for example, might use a file system mechanism to 
communicate data conforming to a defined interface 
specification between processes conforming to the SOA 
concept. The key is independent services with defined 
interfaces that can be called to perform their tasks in a 
standard way, without the service having foreknowledge 
of the calling application, and without the application 
having or needing knowledge of how the service actually 
performs its tasks.
11

12. 12
SERVICE­ORIENTED ANALYSIS 
AND DEVELOPMENT
The modeling and design methodology for SOA
applications has become known by the terms service-
oriented analysis and design and SOAD. SOAD is a
design methodology for developing highly-agile systems
in a consumer/producer model that abstracts
implementation from process, such that a service-
provider can be modified or changed without affecting
the consumer.

13. SOAD AND ITS INGREDIENTS: 
OOAD, BPM, AND EA
13

14. 14
SERVICE CONTRACT
A service contract needs to have the following components
Header
Name - Name of the service. Should indicate in
general terms what it does, but not be the only
definition
Version - The version of this service contract
Owner - The person/team in charge of the service

15. 15
SERVICE CONTRACT[CONTD..]
RACI
•Responsible - The role is the person/team responsible for the
deliverables of this contract/service. All versions of the
contract
•Accountable - Ultimate Decision Maker in terms of this
contract/service
•Consulted - Who must be consulted before action is taken on
this contract/service. This is 2-way communication. These
people have an impact on the decision and/or the execution of
that decision.
•Informed ­ Who must be informed that a decision or 
action is being taken. This is a 1­way communication. 
These people are impacted by the decision or 
execution of that decision, but have no control over 
the action.

16. 16
SERVICE CONTRACT[CONTD..]
Type - This is the type of the service to help distinguish
it in the layer in which it resides.
•Data
•Process
•Functionality
•Presentation

17. 17
SERVICE CONTRACT[CONTD..]
Functional
Functional Requirement (From Requirements Document) -
Indicates the functionality in specific bulleted items what
exactly this service accomplishes. The language should be
such that it allows test cases to prove the functionality is
accomplished.
Service Operations - Methods, actions etc. Must be defined in
terms of what part of the Functionality it provides.
Invocation - Indicates the invocation means of the service.
This includes the URL, interface, etc. There may be multiple
Invocation paths for the same service. We may have the same
functionality for internal and external clients each with a
different invocation means and interface. Examples:
SOAP
REST
Events Triggers

18. 18
SERVICE CONTRACT[CONTD..]
Non-Functional
Security Constraints - Defines who can execute this service in
terms of roles or individual partners, etc. and which
invocation mechanism they can invoke.
Quality of Service - Determines the allowable failure rate
Transactional - Is this capable of acting as part of a larger
transaction and if so, how do we control that?
Service Level Agreement - Determines the amount of latency
the service is allowed to have to perform its actions
Semantics - Dictates or defines the meaning of terms used in
the description and interfaces of the service
Process - Describes the process, if any, of the contracted
service

19. CHALLENGES FACED IN SOA 
ADOPTION
One obvious and common challenge faced is 
managing services metadata.
Another challenge is providing appropriate 
levels of security.
Interoperability is another important aspect in 
the SOA implementations.
There is significant vendor hype concerning 
SOA that can create expectations that may not be 
fulfilled.
19

20. REFERENCES
http://en.wikipedia.org/wiki/Service­oriented_architecture
http://www.thbs.com/soa.html
http://javaboutique.internet.com/tutorials/serv_orient/index­4.html
http://msdn2.microsoft.com/en­us/architecture/aa948857.aspx
20

21. 21
THANK YOU

22. EXAMPLE: AUTOMOTIVE WORK 
ORDER
The Automotive Work Order domain describes 
the process by which an automotive maintenance 
company manages its customer operations. We 
will use this domain problem to illustrate the 
issues of SOAD.
A work order represents an agreement between 
the auto service company and a customer to 
perform a set of scheduled or emergency 
maintenance activities such as a scheduled 
50,000­mile service, a brake pad or tire 
replacement, or an oil change.
22

23. MACRO FLOW EXAMPLE OF WORK 
ORDER
23

24. AUTOMOTIVE WORK 
ORDER[CONTD..]
If you constructed Work Order as an OO application, these software objects would 
contain all the necessary business rules and would understand the business 
processes that should be followed.
However, there are some practical disadvantages to this approach:
Many of the steps involve interfacing with existing legacy systems and databases 
such as billing, scheduling, and inventory systems, which were probably not 
designed adhering to the OO paradigm (applying an adapter or mediator pattern 
helps in such situations). 
In order to make the system as flexible as possible, it would be helpful to have some 
of the rules externalized so that the processes or workflow can be modified without 
changes to the code. For example, rules like: 
A standard 24,000­mile service includes four liters of oil. Additional charges for 
oil should only be made if more than four liters are used, or if the customer 
requests a premium grade oil (such as a synthetic oil). 
There are a set of industry­standard labor estimates for common automotive 
maintenance activities available through a legacy application. The customer 
should be billed the standard labor costs unless the mechanic exceeds that 
estimate by more than X% and reports a valid reason for the difference. 
The customer should be contacted for confirmation if the estimate is exceeded by 
more than Y%.
24

25. AUTOMOTIVE WORK 
ORDER[CONTD..]
SOAD provides an excellent solution to these 
issues. Since it groups services on the basis of 
related behavior, rather than encapsulated 
(behavior plus data), the set of services will be 
subtly different from a business object model.
For example, you would probably group Work 
Order and Work Order Item together, into Work 
Order Services, and create Scheduling, Catalog, 
and Inventory services. Also, because there are 
no services instances, there are no equivalents to 
relationships between services.
25

26. SERVICES MODEL EXAMPLE OF A 
WORK ORDER
26