Introduction to Service-Orientation

Xiaoying Bai

Department of Computer Science and TechnologyTsinghua University

March 2007

23/4/8 2

Outline

• SOA definition and its business and technology values

• Service-orientation vs. object-orientation

• Service-oriented architecture vs. distributed object architecture

23/4/8 3

What is SOA?

• Just like object a generation ago, services is now the killer buzzword. However, SOA is a often misunderstood topic in IT today.

“My architect thinks it’s service-oriented, my developers insist it’s object-oriented, and my analysts wish it would be more business-oriented. All I can tell you is that it isn’t what it was before we started building Web services.”

23/4/8 4

What are Services?

• Services may mean different things to different people:– Loosely coupled software components that interact with

one another dynamically via standard Internet technologies (Gartner).

– A software application identified by a URI, whose interfaces and binding are capable of being defined, described, and discovered by XML artifacts and supports direct interactions with other software applications using XML-based messages via Internet-based protocols (W3C).

23/4/8 5

What are Services?

– A piece of business logic accessible via the Internet using open standards (Microsoft).

– Encapsulated, loosely coupled, contracted software functions, offered via standard protocols over the Web (DestiCorp).

– Services are self-contained, reusable software modules that are independent of applications and the computing platforms on which they run. Services have with well-defined interfaces and allow a 1:1 mapping between business tasks and the exact IT components needed to execute the task. (IBM)

23/4/8 6

What is SOA?

• SOA definition is still evolving. – A set of components which can be invoked, and whose

interface description can be published and discovered (W3C).

– Service-oriented architecture is a client/server design approach in which an application consists of software services and software service consumers (also known as clients or service requesters). SOA differs from the more general client/server model in its definitive emphasis on loose coupling between software components, and in its use of separately standing interfaces (Gartner).

23/4/8 7

What is SOA?

– Service-Oriented Architecture is a business-driven IT architecture approach that supports integrating your business as linked, repeatable business tasks, or services. SOA helps today’s business innovate by ensuring that IT systems can adapt quickly, easily and economically to support rapidly changing business needs. SOA helps customers increase the flexibility of their business processes, strengthen their underlying IT infrastructure and reuse their existing IT investments by creating connections among disparate applications and information sources. (IBM)

A New Way of Thinking

23/4/8 8

A CD Player Example

• 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. Which 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.

23/4/8 9

Service broker

Registration

Organization X Organization ZOrganization Y

ComponentLibrary

Services

FoundAuto-searchable

Application 1 Application 2

BusinessProcess

The SOA Story

Registration Registration

23/4/8 10

Why Service-Orientation?

Marketing

Manufacturing

Accounting

Research &Development

Customer Service

Sales

Distributed Business

RequiresDistributed Computing

Distributed DataDistributed ComputationDistributed users…..

Distributed DataDistributed ComputationDistributed users…..Market i ng

Manuf actur i ng

Account i ng

Research &Devel opment

Cust omer Servi ce

Sal es

23/4/8 11

Why Service-Orientation?

• Interoperation issues– Heterogeneous network protocols– Heterogeneous hardware platforms– Heterogeneous operating systems– Heterogeneous application formats– ……

There must be consensus On Interoperability !

There must be consensus On Interoperability !

23/4/8 12

Changing Market Dynamics

Collaborative, integrated value netsDynamic, adaptive, learningUnpredictable fluctuationsShortening product lifecycleProactive risk managementIncreased focus on privacy and security

Fixed CostsProprietary systemsLabor-intensiveUsers adapt to technology

Variable costsOpen, integrated systemsSelf-healing, self-managing systemsTechnology adapts to users

Business TechnologyBusiness process decision-makingRigid organizational structureSlow and steady economic growthLong-term product lifecyclePassive operational risk management

Sta

tic

On

D

eman

dWhy Service-Orientation?

23/4/8 13

Why Service-Orientation?

23/4/8 14

Business Drivers

• New opportunities– Innovative products and services from the key differentiator to gain

competitive edge.– Ability to leverage technology to adopt newer business models, thus

enabling more channels to earn revenue.• Cost Savings

– Cost reduction through reduced Total Cost of Ownership adds to the bottom-line.

• Business Agility– With cut-throat competition, every missed business opportunity positions

an enterprise below its competitors. The ability of an enterprise to quickly respond to various business stimuli will be key to survival.

– Faster time to market increases customer satisfaction and also customer loyalty. This results in increased business and higher revenues.

– Ability to provide on demand service, in real-time 24/7.– Seamless collaboration with partners and customers helps to improve

service quality and time to market.

23/4/8 15

SOA Business Values to IT Management

• Make interoperability an innate characteristic of IT applications.

• Offer an easy way to speed time-to-market

• Respond quickly to changing business conditions

• Eliminate rework and maximize the value of existing assets.

23/4/8 16

Technology Drivers

• Openness– Dependency on external technology and platform vendors is a risk

to an organization on which it has little control. However, adopting open standards mitigates this risk.

• Cost Saving– Reduction in maintenance cost– Increased reuse of investment in IT leads in to increased

productivity resulting in increased ROI.• Agility

– Loose coupling increased application agility and reduces time to market for a new application.

– Seamless scalability at minimal cost to cater to seasonal increase in load.

23/4/8 17

Technology Drivers

• Software architecture design principles– Abstraction– Separation of concerns– Anticipation of changes– Design with reuse

23/4/8 18

Related Concepts

SOA

ObjectOriented

CBSD

Web Application

DistributedComputing

BPM

EnterpriseIntegration

CBSD: Component-Based Software Development BPM: Business Process Management

23/4/8 19

Program

Paradigm

Distributed

Com

puting

1950 1960 1970 1980 1990 2000

Assembler

COBOL

SIMULA

Pascal

Modular2

Smalltalk

PROLOG

Ada

C++

Java

C#

VT3270

VT100

Client/Server

RPC

Stored Procedure

TCP/IP

CORBA

EAI

WWW

MQ

EJB

NFSWSDL

SOAP

SO

ASOA Evolution

23/4/8 20

SOA Characteristics

• Based on open standards• Foster inherent reusability• Foster intrinsic interoperability• Emphasizes extensibility• Fundamentally autonomous• Promotes dynamic discovery• Promotes architectural composability• Promotes loose coupling throughout the enterprise• Supports incremental implementation

23/4/8 21

SOA Potential Benefits

• Improved Integration, intrinsic interoperability• Inherent reuse• Streamlined architectures and solutions• Leveraging the legacy investment• Establishing standardized XML data representation• Focused investment on communications infrastructure• Best-of-breed alternatives• Organizational agility

23/4/8 22

SOA Principles

• The business drives the services, and the services drive the technology.

• Business agility is a fundamental business requirement.

• A successful SOA is always in flux.

23/4/8 23

W3C OASIS WS-I

Established 1994 1993 as SGML Open, 1994 as OASIS

2002

Approximate membership

400 600 200

SOA goal To further the evolution of the Web, by providing fundamental standards that improve online business and information sharing.

To promote online trade and commerce via specialized Web services standards.

To foster standardized interoperability using Web services standards.

SOA deliverables

XML, XML Schema, XQuery, XML Encryption, XML Signature, XPath, XSLT, WSDL, SOAP, WS-CDL, WS-Addressing, Web Services Architecture

UDDI, ebXML, SAML, XACML, WS-BPEL, WS-Security

Basic Profile, Basic Security Profile

SOA Standards Organizations

Service Orientation vs. Object Orientation

23/4/8 25

Conceptual Relationship

• Several principles of service-orientation are related to and derived from object-orientation principles.– abstraction -- decomposition– Encapsulation -- Reusability– Interface first -- Loose coupling– Composition -- Autonomy– Statelessness -- Discoverability

• Some object-orientation principles, such as inheritance, do not fit into the service-orientation world.

• Some service-orientation principles, such as loose coupling and autonomy, are not directly promoted by object-orientation.

23/4/8 26

Conceptual Differences

Loose coupling between units of processing logic.

Based on predefined class dependencies, resulting in more tightly bound objects.

Coarse-grained interfaces (service description)Message-based communication

Fine-grained interfaces (APIs), Communication based on RPC or local API calls.

Large unit of processing logic (service),May vary significantly in scope.

Unit of logic (object) tend to be smaller and More specific in scope.

Promotes the creation of activity-agnostic units of processing logic (services) that are driven into action by intelligent units of communication (message).

Encourages the binding of processing logic with data, resulting in highly intelligent

units (object).

Prefers that units of processing logic (services) be designed to remain as stateless as possible.

Promotes binding of data and logic, resultingIn the creation of more stateful units (objects).

Service-Orientation Object-Orientation

23/4/8 27

The Paradigm Shift

SimulaSmalltalk

Objective C C++Java

ProgrammingLanguage

XMLUDDI ebXMLWSDLSOAPOWL

StandardSpecification

UML

Modeling

BPELWSFL

XLANG

Modeling

OOADOO Framework

OODBOO Process model

Technology &Methodology

MDASO Framework

Ontology / Service DBSO lifecycle process

Technology &Methodology

Object-OrientedConcept &

Architecture

Service-OrientedConcept &

Architecture

Service Oriented Architecture vs. Distributed Object Architecture

23/4/8 29

Conceptual Relationship

• SOA is a radical departure from client-server architecture. Current SOAs still employ some of the technologies originally used to build client-server applications. Though more sophisticated, SOAs introduce complexity that sharply contrasts the simplicity of a two-tier client-server architecture.

• Distributed Internet architecture has much in common with SOA, including a significant amount of its technology. However, SOA has distinct characteristics relating to both technology and its underlying design principles.

23/4/8 30

Distributed System Architecture

Client

Server

Data ManagementApplication Processing

Presentation

Client

Server

Data Management

PresentationApplication Processing

Two Tier with Thin Client

Two Tier with Fat Client

Server

Application Processing

Server

DataManagement

Client

Presentation

Three Tier

23/4/8 31

Multi-Tier System Architecture

• RPC-based– Client and middleware server is tightly coupled

• Remote Object based– Remote objects communicates through standard interfa

ce languages– Object models: OMG CORBA, SUN Java RMI, MS D

COM

• Web based– Browser + “Dynamic content generation”– Enabling techniques: CGI, Java Servlet/JSP, MS ASP

23/4/8 32

Distributed Object Computing

• Coupled with a powerful communications infrastructure, distributed objects divide monolithic client/server applications into self-managing components, or objects, that can interoperate across disparate networks and operating systems. – SUN J2EE

• JavaTM 2 Platform, Enterprise Edition

– MS DCOM• Distributed Component Object Model

– OMG CORBA• Common Object Request Broker Architecture

23/4/8 33

Middleware

• In a distributed computing system, middleware is defined as the software layer that lies between the operating system and the applications on each site of the system. It serves to "glue together" or mediate between separate components.

• Objectives– Hiding distribution– Hiding the heterogeneity – Providing uniform, standard, high-level interfaces– Supplying a set of common services

• Examples– Transaction processing monitors– Data converters– Communication controllers

23/4/8 34

Middleware

• Design Challenges– Performance– Scalability – Complexity of administration– Mobility and dynamic reconfiguration– Global information network to manage large

applications that are heterogeneous, widely distributed and in permanent evolution

23/4/8 35

CORBA – A bit of history

• OMG Standard, “to allow applications to communicate with one another no matter where they are located or who has designed them”– 1991, CORBA 1.1, IDL & API within an ORB– 1994, CORBA interoperability & IIOP

(Internet Inter-ORB Protocol)– 2002, CORBA Component Model

23/4/8 36

CORBA – Objectives

• Distributed object computing middleware that shields applications from heterogeneous platform dependencies.

• To simplify development of distributed applications by automating/encapsulating– Object location – Connection & memory mgmt.– Parameter (de)marshaling– Event & request demultiplexing– Error handling & fault tolerance– Object/server activation– Concurrency– Security

• CORBA defines interfaces, not implementations

23/4/8 37

CORBA Application Structure

• Object Request Broker: enables objects to transparently make and receive requests and responses in a distributed environment. – The core of the reference model, “telephone exchange”

• Object Services: a collection of services (interfaces and objects) that support basic functions for using and implementing objects.– e.g. Naming, Trading, and Life Cycle Service

• Common Facilities: a collection of services that many applications may share, but which are not as fundamental as the Object Services– e.g. e-mail facility

• Application Objects: products of a single vendor on in-house development group that controls their interfaces.

23/4/8 38

Object Request Broker

ApplicationObjects

DomainFacilities

Horizontal CORBAFacilities

Domain Facilities

CORBA Application Structure

23/4/8 39

Interface Repository

Implementation Repository

IDLCompiler

ClientClient ObjectObject

DynamicInvocation

IDLStub

ORBInterface

IDLSkeleton

DynamicSkeleton Object

Adapter

ORB Core GIOP/IIOP/ESIOPS

CORBA Middleware Architecture

23/4/8 40

Object Request Broker (ORB)

• A logical set of services– Locates the remote object, communicates the request,

waits for the results and when available communicates the results back to the client

– Location transparency

– Programming language independent: interface translation and language binding

Client Object

Object Request Broker (ORB)

23/4/8 41

Interface Definition Language (IDL)

• Language neutral, Language mapping– Modularized object interface

– Operations and attributes that an object supports

– Exceptions raised by an operation

– Data types of an operation return value, its parameters, and an object’s attributes

Client

Object Request Broker (ORB)

IDLStub

IDLSkeleton

Object

23/4/8 42

Two-way Processing

ORB COREORB CORE

In args

ObjectClient Obj. ref.Operation ()

Out args + return value

IDLStub

1C

Locate target object

3C 2CSend request to serverWait for

request to complete

ImplementationRepository

ImplementationRepository

1S

Activate server

IDLSkeleton

2SActivate Object’s Servant

3SProcess Request

4S

Return Request

4CReturn Control to

Client

23/4/8 43

CORBA Interoperability

• Motivation – ORB implementation diversity– ORB boundaries:

• Partition the environment into different ORBs• Simplified test, management, and maintenance• Decentralized control• e.g. internet ORB, company ORB

– ORB vary in scope, distance and lifetime• e.g. archives ORB, game ORB

• Elements – Inter-ORB Bridge: transactions between ORB domains – General Inter-ORB Protocol (GIOP): ORB-ORB interactions over

connection-oriented transport protocol– Internet Inter-ORB Protocol (IIOP): ORB-ORB communication ac

ross the Internet (TCP/IP)

23/4/8 44

Client

ORB 1

IDLStub

IDLSkeleton

Object Client

IDLSkeleton

Object

ORB 2

IDLStub

IIOP

Interoperability uses ORB-to-ORB communication

CORBA Interoperability

23/4/8 45

CORBA Services

Services Description

Object Life Cycle Define how CORBA objects are created, removed, moved and copied

Naming Define how CORBA objects can have friendly symbolic names

Events Decouple the communication between distributed objects

Relationships Provides arbitrary typed n-ray relationships between CORBA objects

Externalization Coordinates the transformation of CORBA objects to and from external media

Transactions Coordinates atomic access to CORBA objects

Concurrency Control Provides a locking service for CORBA objects in order to ensure serialized access

Property Supports the association of name-value pairs with CORBA objects

Trading Supports the finding of CORBA objects based on properties describing the services offered by the object

Query Support queries on objects

23/4/8 46

J2EE

• A platform for developing applications– Oct. 1994, Public introduction of Java

– Jan. 1996, JDK 1.0 released

– Apr. 1997, EJB specification announced

– Dec. 1998, Java 2, SDK 1.2 released

– Jun. 1999, J2EE announced

– Dec. 1999, J2EE platform released – Sep. 2001, J2EE 1.3 released

– Nov. 2003, J2EE 1.4 released

23/4/8 47

PureHTML

JavaApplet

Browser

JavaApplication

Desktop

J2EEClient

Other Device

Client SidePresentation

Server SidePresentation

JSP

JavaServlet

WebServer

JSP

J2EE platform

Server SideBusiness Logic

EJB

EJB

EJB Container

EJB

J2EE platform

EnterpriseInformation

System

J2EE Application Architecture

23/4/8 48

J2EE Middleware Architecture

23/4/8 49

J2EE Interoperability

23/4/8 50

J2EE Services

• HTTP/HTTPS• JAAS – Java Authorization and Authentication Service• JTA – Java Transaction API• JNDI – Java Naming and Directory Service• RMI-IIOP• JDBC – Java DataBase Connectivity• JMS – Java Message Service• JavaMail• JAXP – Java API for XML Parsing• Java IDL• ……

23/4/8 51

Advantages of Distributed Object Architecture

• It allows the system designer to delay decisions on where and how services should be provided

• It is a very open system architecture that allows new resources to be added to it as required

• The system is flexible and scaleable• It is possible to reconfigure the system

dynamically with objects migrating across the network as required

23/4/8 52

Weakness of Distributed Object Architecture

• Tightly coupled– Both ends of each distributed computing link had to

agree on the details of the API. A code change to a COM object, for example, required corresponding changes to the code accessing that object.

• Proprietary– Microsoft controlled DCOM– Implementing a CORBA architecture typically

necessitated the decision to work with a single vendor's implementation of the specification.

23/4/8 53

SOA -- Evolution vs. Revolution

• SOA is developed upon the weaknesses of distribute object computing technique.– Standard-based

• Reliance upon universally accepted standards provides broad interoperability among different vendors’ solutions

– loosely couples • Separates the participants in distributed computing interactions

so that modifying the interface of one participant in the exchange does not break the other.

23/4/8 54

Summary

• SOA enables dynamic collaboration among loosely coupled, reusable software components through standard Internet protocols.

• SOA is driven by both business and technology needs for open collaboration, cost saving and flexibility to dynamic changes.

• SOA is developed from other software techniques including distributed object computing, component-based software engineering, and enterprise application integration.

23/4/8 55

References

• M. P. Singh and M. N. Huhns, “Service-Oriented Computing”, John Wiley & Sons, 2005.

• Thomas Erl, “Service-Oriented Architecture: Concepts, Technology, and Design”, Prentice Hall, 2005.

• Eric Newcomer and Greg Lomow, “Understanding SOA with Web Services”, Addison Wesley, 2005.

• D. Krafzig, K. Banke and D. Slama, “Enterprise SOA: Service-Oriented Architecture Best Practice”, Prentice Hall, 2005.

• Wei-Tek Tsai, “What is SOA? Why should you care?”, Tsinghua University Short Course on Service-Oriented Computing and Architecture, 2006.

• Jen-Yao Chung, “Service-Oriented Architecture and Web Services”, keynote speaking, SOSE 2005.

23/4/8 56

References

• Jason Bloomberg, “Principles of SOA”, Feb. 2003. • “A Practical Guide to SOA for IT Management”, Systinet

Corp. 2005.• Shireesh Jayashetty, Pradeep Kumar M, “Adopting Service

Oriented Architecture increases the flexibility of your enterprise”, Infosys, 2006.

• Ian Summerville, “Software Engineering” (6th Edition), Addison-Wesley, 2000.

• ObjectWeb, http://middleware.objectweb.org/• OMG, http://www.omg.org/• Doug Schmidt’s CORBA page, http://

www.cs.wustl.edu/~schmidt/corba.html• IBM SOA glossary, http://www-306.ibm.com/software/sol

utions/soa/glossary/index.html