Service Oriented Architecture

1

SERVICE ORIENTED ARCHITECTURESOA

Presented by:

G Emmanuel sandeep

MBA(SEM)

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

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

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

Elements of SOA

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

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

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

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

SOA PRINCIPLES:SPECIFIC ARCHITECTURAL PRINCIPLES

Service Encapsulation Service Loose coupling Service contract Service abstraction Service documentation Service reusability Service composability Service autonomy Service optimization

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

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.

SOAD AND ITS INGREDIENTS: OOAD, BPM, AND EA

13

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

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

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

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

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

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

REFERENCES

http://en.wikipedia.org/wiki/Service-oriented_architecture

http://www.thbs.com/soa.html http://javaboutique.internet.com/tutorials/se

rv_orient/index-4.html http://msdn2.microsoft.com/en-us/architectu

re/aa948857.aspx

20

21

THANK YOU

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

MACRO FLOW EXAMPLE OF WORK ORDER

23

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

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

SERVICES MODEL EXAMPLE OF A WORK ORDER

26