Unit I SOA

61
04.05.2011 Unit 1 Service Oriented Architecture UNIT I Based On Service-Oriented Architecture: Concepts, Technology, and Design By Thomas Erl Prepared By S.Usha & J.Jeyalakshmi Lecturer / Department of Information Technology Rajalakshmi Engineering College

Transcript of Unit I SOA

Page 1: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 1/61

04.05.2011 Unit 1

Service Oriented ArchitectureUNIT – I

Based On

Service-Oriented Architecture: Concepts,Technology, and Design

By

Thomas Erl

Prepared By

S.Usha & J.Jeyalakshmi

Lecturer / Department of Information TechnologyRajalakshmi Engineering College

Page 2: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 2/61

04.05.2011 Unit 1

Roots of SOA (comparing SOA to past architectures) 

• What is architecture?

 –  IT departments started to recognize the need for a standardized definition of 

a baseline application that could act as a template for all others.

 –  This definition was abstract in nature, but specifically explained the

technology, boundaries, rules, limitations, and design characteristics that

apply to all solutions based on this template.

 –  This was the birth of the application architecture.

Types Of Architecture:

1. Application architecture

2. Enterprise architecture

3. Service-oriented architecture

Page 3: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 3/61

04.05.2011 Unit 1

Application architecture

Application architecture is to an application development team what a blueprint is to ateam of construction workers.

Different organizations document different levels of application architecture.

Some keep it high-level, providing abstract physical and logical representations of 

the technical blueprint. Others include more detail, such as common data models,

communication flow diagrams, application-wide security requirements, and aspects of 

infrastructure.

It is not uncommon for an organization to have several application architectures.

A single architecture document typically represents a distinct solution environment.For example, an organization that houses both .NET and J2EE solutions would verylikely have separate application architecture specifications for each.

A key part of any application-level architecture is that it reflects immediate solution

requirements, as well as long-term, strategic IT goals.

Page 4: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 4/61

04.05.2011 Unit 1

Enterprise architecture

• In larger IT environments, the need to control and direct IT infrastructure is critical.

• When numerous, disparate application architectures co-exist and sometimes even integrate, thedemands on the underlying hosting platforms can be complex and onerous.

• Therefore, it is common for a master specification to be created, providing a high-level overviewof all forms of heterogeneity that exist within an enterprise, as well as a definition of thesupporting infrastructure.

• Continuing our previous analogy, an enterprise architecture specification is to an organization

what an urban plan is to a city. Therefore, the relationship between an urban plan and the blueprint of a building are comparable to that of enterprise and application architecturespecifications.

• Typically, changes to enterprise architectures directly affect application architectures, which is

why architecture specifications often are maintained by the same group of individuals.

Further ,enterprise architectures often contain a long-term vision of how the organization plans toevolve its technology and environments.

For example, the goal of phasing out an outdated technology platform may be established in thisspecification.

Page 5: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 5/61

04.05.2011 Unit 1

Service-oriented architecture

service-oriented architecture spans both enterprise and application architecturedomains.

The benefit potential offered by SOA can only be truly realized when appliedacross

multiple solution environments.

This is where the investment in building reusable and interoperable services based

on a vendor-neutral communications platform can fully be leveraged. This does notmean that the entire enterprise must become service-oriented.

SOA belongs in those areas that have the most to gain from the features andcharacteristics it introduces.

 Note that the term "SOA" does not necessarily imply a particular architectural

scope. An SOA can refer to an application architecture or the approach used tostandardize technical

architecture across the enterprise.

Because of the composable nature of SOA (meaning that individual application-level architectures can be comprised of different extensions and technologies), it isabsolutely possible for an organization to have more than one SOA.

Page 6: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 6/61

04.05.2011 Unit 1

Characteristics of SOA 

The following primary characteristics:

1. Contemporary SOA is at the core of the service-oriented computing platform.

2. Contemporary SOA increases quality of service.

3. Contemporary SOA is fundamentally autonomous.

4. Contemporary SOA is based on open standards.

5. Contemporary SOA supports vendor diversity.

6. Contemporary SOA fosters intrinsic interoperability.

7. Contemporary SOA promotes discovery.

8. Contemporary SOA promotes federation.

9. Contemporary SOA promotes architecturalcomposability.

Page 7: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 7/61

04.05.2011 Unit 1

Characteristics of SOA cont… 

10.Contemporary SOA fosters inherent reusability.

11.Contemporary SOA emphasizes extensibility.

12.Contemporary SOA supports a service-oriented

business modeling paradigm.

13.Contemporary SOA implements layers of abstraction.14.Contemporary SOA promotes loose coupling throughout

the enterprise.

15.Contemporary SOA promotes organizational agility.

16.Contemporary SOA is a building block.17.Contemporary SOA is an evolution.

18.Contemporary SOA is still maturing.

19.Contemporary SOA is an achievable ideal

Page 8: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 8/61

04.05.2011 Unit 1

Characteristics of SOA

• Service-oriented software architecture has these characteristics Bieber and

Carpenter 2001, Stevens, Service-Oriented, 2002, Sun Microsystems, Jini

Technology Architectural Overview 2001):

• Services are discoverable and dynamically bound.

• Services are self-contained and modular.

• Services stress interoperability.

• Services are loosely coupled.

• Services have a network-addressable interface.

• Services have coarse-grained interfaces.

• Services are location-transparent

• Services are composable.

• Service-oriented architecture supports self-healing.

Page 9: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 9/61

04.05.2011 Unit 1

SOA vs Traditional Distributed Internet Architecture

• Muliple client-server architectures have appeared

• Client-server DB connections have been replacedwith Remote Procedure Call connections (RPC) using

CORBA or DCOM• Middleware application servers and transaction

monitors require significant attention

• Multi-tiered client-server environments began

incorporating internet technology in 90s.

Page 10: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 10/61

04.05.2011 Unit 1

SOA vs Traditional Distributed Internet Architecture

• The browser shifted 100% of application logic to the

server 

• Distributed Internet architecture introduced the Web

server as a new physical tier • HTTP replaced RPC protocols

Page 11: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 11/61

04.05.2011 Unit 1

SOA vs Traditional Distributed Internet Architecture

• Distributed Internet application put all the applicationlogic on the server side

• Even client-side scripts are downloaded from the

server • Entire solution is centralized

• Emphasis is on:

 –  How application logic is partitioned

 –  Where partitioned units reside

 –  How units of logic should interact

Page 12: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 12/61

04.05.2011 Unit 1

SOA vs Traditional Distributed Internet Architecture

• Difference lies in the principles used to determine the

three primary design considerations

• Traditional systems create components that reside on

one or more application servers• Components have varying degrees of functional

granularity

Components on the same server communicate via proprietary APIs.

• RPC protocols are used across servers via proxy stubs

Page 13: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 13/61

04.05.2011 Unit 1

SOA vs Traditional Distributed Internet Architecture

• Actual references to other physical components can

 be embedded in programming code (tight coupling)

• SOAs also rely on components

• Services encapsulate components

• Services expose specific sets of functionality

• Functionality can originate from legacy systems or 

other sources

Page 14: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 14/61

04.05.2011 Unit 1

SOA vs Traditional Distributed Internet Architecture

• Functionality is wrapped in services

• Functionality is exposed via open, standardized

interface, irrespective of technology providing the

solution• Services exchange information via SOAP messages.

SOAP supports RPC-style and document-style

messages

• Most applications rely on document-style

Page 15: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 15/61

04.05.2011 Unit 1

SOA vs Traditional Distributed Internet Architecture

• Messages are structured to be self-sufficient

• Messages contain meta information, processing

instructions, policy rules

• SOA fosters reuse on a deep level by promotingsolution-agnostic services

Page 16: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 16/61

04.05.2011 Unit 1

Page 17: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 17/61

04.05.2011 Unit 1

Comparing SOA to client-server anddistributed internet architectures 

Page 18: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 18/61

04.05.2011 Unit 1

Client-Server Application Technology

• The technology set for client-server applicationsincluded 4GLs like VB and PowerBuilder, RDBMSs

• The SOA technology set has expanded to include

Web technologies (HTML, CSS, HTTP, etc)• SOA requires the use of XML data representation

architecture along with a SOAP messagingframework 

Page 19: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 19/61

04.05.2011 Unit 1

Page 20: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 20/61

04.05.2011 Unit 1

Client-Server Application Security

• Centralized at the Server level

• Databases manage user accounts and groups

• Also controlled within the client executable

• Security for SOA is much more complex

• Security complexity is directly related to the degree

of security measures required

• Multiple technologies are required, many in WS-Security framework 

Page 21: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 21/61

04.05.2011 Unit 1

Client-Server Application Administration

• Significant maintenance costs associated with client-

server 

• Each client housed application code

• Each update required redistribution

• Client stations were subject to environment-specific

 problems

Increased server-side demands on databases

Page 22: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 22/61

04.05.2011 Unit 1

Client-Server Application Administration

• SOA solutions are not immune to client-sidemaintenance challenges

• Distributed back-end supports scalability, but new

admin demands are introduced• Management of server resources and service

interfaces may require new admin tools and even a private registry

Commitment to services and their maintenance mayrequire cultural change in an organization

Page 23: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 23/61

04.05.2011 Unit 1 23

Logic components of the Web services

framework 

• Web services contain

one or more operations.

• Figure 8.4 as anexample

Page 24: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 24/61

04.05.2011 Unit 1 24

Logic components of the Web services

framework 

• Each operation governs

the process of a specific

function the web service

is capable of  performing.

• Figure 8.5 gives an

example of an operation

sending and receiving

SOAP messages

Page 25: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 25/61

04.05.2011 Unit 1 25

Logic components of the Web

services framework

• Web services form an

activity though which

they can collectively

automate a task.

• Figure 8.6 as an

example

Page 26: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 26/61

04.05.2011 Unit 1 26

Logic components of 

automation logic• Fundamental parts of 

the framework 

 –  SOAP messages

 – Web service operations

 –  Web services

 –  Activities

• Renamed terms

 –  Messages

 – Operations

 –  Services

 –  Processes

• Activity has been changed because it uses a different context

when modeling service-oriented

 business processes.

Page 27: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 27/61

04.05.2011 Unit 1 27

Logic components of 

automation logic• Messages = units of communication

• Operations = units of work

• Services = units of processing logic

• Processes = units of automation logic

Page 28: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 28/61

04.05.2011 Unit 1 28

Logic components of 

automation logic• The purpose of these

views is to express the

process, services and

operations.

• Is also provides a flexible

means of partitioning and

modularizing the logic.

• These are the most basic

concepts that underliesservice-orientation.

Page 29: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 29/61

04.05.2011 Unit 1 29

Components of an SOA

• Message

 –  A message represents the data required to

complete some or all parts of a unit of work.

Page 30: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 30/61

04.05.2011 Unit 1 30

Components of an SOA

• Operation

 –  An operation represents the logic required to process

messages in order to complete a unit of work .

Page 31: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 31/61

04.05.2011 Unit 1 31

Components of an SOA

• Service

 –  A service represents a logically grouped set of 

operations capable of performing related units of 

work.

Page 32: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 32/61

04.05.2011 Unit 1 32

Components of an SOA

• Processes

 –  A process contains the business rules that determine which

service operations are used to complete a unit of 

automation.

 –  A process represents a large piece of work that requires the

completion of smaller units of work .

Page 33: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 33/61

04.05.2011 Unit 1 33

How components in an SOA inter-

relate

• An operation sends and receives messages to

 perform work.

• An operation is therefore mostly defined by

the message it processes.

Page 34: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 34/61

04.05.2011 Unit 1 34

How components in an SOA inter-

relate

• A service groups is a collection of related

operations.

• A service is therefore mostly define by the

operations that comprise it.

i i

Page 35: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 35/61

04.05.2011 Unit 1 35

How components in an SOA inter-

relate• A process instance can compose service.

• A process instance is not necessarily defined by itsservice because it may only require a subset of the

functionality offered by the services.

• A process instance invokes a unique series of operations to complete its automation.

• Every process instance is therefore partially defined bythe service operation it uses.

Page 36: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 36/61

Page 37: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 37/61

04.05.2011 Unit 1 37

Key Points

• The logical parts of an SOA can be mapped tocorresponding components in the basic Web servicesframework.

• By viewing a service-oriented solution as a unit of 

automation logic, we establish that SOA consists of asophisticated environment that supports a highlymodularized separation of logic into differently scopedunits.

• SOA further establishes specific characteristics, behaviors, and relationships among these componentsthat provide a predictable environment in support of service-orientation.

Page 38: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 38/61

04.05.2011 Unit 1

COMMON PRINCIPLES OF

SERVICE- ORIENTATION

38

Page 39: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 39/61

04.05.2011 Unit 1 39

Common principles of service-

orientation• Services are reusable

• Services share a formal contract

• Services are loosely coupled

• Services abstract underlying logic

• Services are composable

Services are autonomous

• Services are stateless

• Services are discoverable

Page 40: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 40/61

04.05.2011 Unit 1 40

Services are reusable

• Regardless of weather immediate reuse

opportunities exist, services are designed to

support potential reuse.

• Service-oriented encourages reuse in all

services.

• By applying design standards that require

reuse accommodate future requirements with

less development effort.

Page 41: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 41/61

04.05.2011 Unit 1 41

Services are reusable

Page 42: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 42/61

04.05.2011 Unit 1 42

Case Study

RailCo created the Invoice Submission Servicewhich contains two operations

 –  SubmitInvoice

 –  GetTLSMetadata

• SubmitInvoice - Allows RailCo send

electronic invoices to TLS Account Payable

Service

• GetTLSMetadata  –  checks periodically for 

changes to TLS Account Payable Service

Page 43: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 43/61

04.05.2011 Unit 1 43

Case Study

• In Plain English

 – Business License Office provides a distinct

service

• Issuing business licenses

• Renewing business licenses

 – Provides service to all customers• Classifies this service as reusable

Page 44: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 44/61

04.05.2011 Unit 1 44

Services share a formal contract

• For services to interact, they need not

share anything but formal contract that

describe each service and define the

terms of information exchange.

Page 45: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 45/61

04.05.2011 Unit 1 45

Services share a formal contract

• Service contracts provide a formal definitionof:

 –  The service endpoint

 –  Each service operation –  Every input and output message supported by each

operation

 –  Rules and characteristics of the service and its

operations

• Service contacts define almost all of the primary parts of an SOA.

Page 46: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 46/61

04.05.2011 Unit 1 46

Services share a formal contract

Page 47: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 47/61

04.05.2011 Unit 1 47

Case Study

• RailCo and TLS agreed to a service contract

that allow the two companies to communicate

• TLS defined the definition of the associated

service description documents

• TLS ensures a standardized level of 

conformance that applies to each of its online

vendors

• TLS can change the service at any time

Page 48: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 48/61

04.05.2011 Unit 1 48

Case Study

• In Plain English

Application form is needed obtain or renew a

 business license

 –  Application formalizes the request in a standard

format for the Business License Office

 –  Application is a contract between the business and

Business License Office

Page 49: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 49/61

04.05.2011 Unit 1 49

Services are loosely coupled

• Services must be designed to interact without

the need for tight, cross-service dependencies.

Page 50: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 50/61

04.05.2011 Unit 1 50

Services are loosely coupled

Page 51: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 51/61

04.05.2011 Unit 1 51

Case Study

• TLS services are designed to communicate

with multiple online vendors make it loosely

coupled

• RailCo service are designed to communicate

only with TLS B2B system so is considered

less loosely coupled

Page 52: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 52/61

04.05.2011 Unit 1 52

Case Study

• In Plain English

 – Once the Application is submitted no further 

action is required on the business

 – Business and Business License Office remain

independent

 – Application is the only requirement tocommunicate with Business License Office

Services abstract underlying

Page 53: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 53/61

04.05.2011 Unit 1 53

Services abstract underlying

logic• The only part of a service that is visible to

the outside world is what is exposed via

the service contract. Underlying logic,

beyond what is expressed in thedescriptions that comprise the contract, is

invisible and irrelevant to service

requestors.

Services abstract underlying

Page 54: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 54/61

04.05.2011 Unit 1 54

Services abstract underlying

logic

Page 55: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 55/61

04.05.2011 Unit 1 55

Case Study

• RailCo Web services hide the underlying

legacy code need to produce the invoices

that are needed to sent to TLS

• TLS Web services hide the underlyingservices that process the invoices from

multiple online vendors

• Neither service requestor require anyknowledge of what processes are working

on the other’s service providor  

Page 56: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 56/61

04.05.2011 Unit 1 56

Case Study

• In Plain English

 – Business License Office tasks are hidden

from the business

 – Business does not care what Business

License Office does, it just wants a license

Page 57: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 57/61

04.05.2011 Unit 1 57

Services are composable

• Services may be compose other services. This

allows logic to be represented at different

levels of granularity and promotes reusability

and the creation of abstraction layers.

Page 58: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 58/61

04.05.2011 Unit 1 58

Services are composable

Page 59: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 59/61

04.05.2011 Unit 1 59

Case Study

• TLS accounts Payable Service is composed on

three services

 –  Accounts Payable Service

 –  Vendor Profile Service

 –  Ledger Service

Page 60: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 60/61

04.05.2011 Unit 1 60

Case Study

• In Plain English

 –  Other government agencies can use the Business

License Office for their license tasks

Page 61: Unit I SOA

7/29/2019 Unit I SOA

http://slidepdf.com/reader/full/unit-i-soa 61/61

THANK YOU