Service-oriented Computing

1
Service-oriented Computing

• Prof. Dr. Schahram Dustdar
• Distributed Systems Group
• Institute of Information Systems
• http//www.infosys.tuwien.ac.at/Staff/sd

2
Some Service-oriented Approaches
3
Jini

• Jini is a technology for building service
  oriented architectures
• Apache River
• Key features
• Written in Java
• Uses RMI and Java Object Serialization
• Offers network plug and play of services (java
  objects)
• Differences with respect to RMI
• Provides Discovery of Jini Services
• A federating technology for services

4
OSGi

• A Java framework for developing (remotely)
  deployed service applications
• Portable byte code (independent of OS or CPU
  architecture)
• Security integrated in the language
• Created through a collaboration of industry
  leaders
• IBM, Ericsson, Nokia, Sony, Samsung, Oracle, and
  many more
• Excellent model for the myriad of customizations
  and variations that are required for todays
  devices

5
UPNP

• UPNP supports Devices and Control Points
• A device may have multiple Services
• Sample Device
• A TV registers itself as a Device
• The TV exports a ControlService for volume,
  power, channel
• It exports a Picture service for color, contrast
  and brightness

6
Web services vs. CORBA I
7
Web services vs. CORBA II
8
Enterprise Application Integration (EAI)
The beginning of SOA
9
Enterprise Application Integration

• One of the main challenges in IT
• Applications shall be integrated to work together
• First step application bridge
• Hooks into source application
• Transforms data
• Invokes target application
• Problems
• Heterogeneity
• Distributed systems
• Quality of service

Source Application
Bridge
Target Application
10
Asynchronous request/reply messaging

• Most asynchronous messaging mechanisms follow the
  fire-and-forget messaging principle where the
  sending application can conduct its work as usual
  once a message was asynchronously sent.
• The sending application assumes that the message
  will arrive safely at its destination at some
  point in time.
• This mode of messaging does not preclude the
  necessity to perform request/reply operations.

11
Adapters/Message Queuing

• Solution split bridge into two adapters
• Source adapter
• Hooks into source application
• Puts data in message queue of target adapter
• Target adapter
• Transforms message into data for target
  application
• Invokes target application
• Message queuing middleware
• QoS
• Scaling

Source Environment
Source Application
Source Adapter
Message Queuing
Target Environment
Target Adapter
Target Application
12
Neutral Message Format

• Each target application needs separate target
  adapters to process the different source message
  formats
• Adapters for each application pair
• Complexity nn
• First improvement neutral message format
• Adapters transform data to/from neutral format
• Complexity nn

13
Message Broker

• Further improvement message broker middleware
• On top of message queuing
• Identifies and transforms messages
• Routes to target
• Simplifies adapter creation
• Provides additional benefits
• Transformations can reflect corporate policies
• Publish/subscribe ? dynamic environments
• However
• Complex to implement and maintain
• Expensive software licenses

14
Message-oriented Middleware

• MOM is an infrastructure that involves the
  passing of data between applications using a
  common communication channel that carries
  self-contained messages.
• Messages are sent and received asynchronously.
• The messaging system (integration broker) is
  responsible for managing the connection points
  between clients for managing multiple channels
  of communication between the connection points.

15
Message-oriented Middleware (cntd)

• MOM provides the following functions
• event-driven processing, i.e., the
  publish/subscribe model.
• reliability and serialization of messages.
• subject-based (textual) names and attributes to
  abstract from physical names and addresses.
• multiple communications protocols, e.g., store
  forward, request/reply, publish/subscribe.
• An integration broker is an application-to-applica
  tion middleware service capable of one-to-many,
  many-to-one many-to-many message distribution.
• It records manages the contracts between
  publishers subscribers of messages.
• An integration brokers provides the following
  functions
• message transformation, business rules
  processing, routing services, naming services,
  adapter services, repository services, events
  alerts.

16
EAI and MoM (cntd)

• EAI uses a fast, robust communications backbone
  with integration broker technology, business
  process workflow, facilities tools.
• Integration brokers are used
• for message process flow
• are responsible for brokering
• messages exchanged
• between two or more
• applications.
• They provide the ability to
• transform,
• store route messages
• apply business rules
• respond to events.

17
Publish/Subscribe Messaging

• The application that produces information
  publishes it and all other applications that need
  this type of information, subscribe to it.
• Messages containing
• the new information are
• placed in a queue for
• each subscriber by the
• publishing application.
• Each application
• may have a dual role
• it may act as a publisher or
• subscriber of
• different types
• of information.

Message server
18
Service-Oriented Computing and Web Services
19
Some good references
20
Service-oriented Computung (SoC)
21
Vision and Principles

• Programmatic interactions between autonomous
  systems (e.g., EAI, B2B Interactions, Access to
  Internet Resources and applications)
• Web services self-contained Software Entities
  which are published, discovered, and invoked on
  the Internet. XML-based languages are used -gt
  loose coupling of systems
• Virtualization of Resources, Utilization and
  consolidation of Internet-based infrastructure
• Agile Development of integrated systems through
  service composition
• Services can be provided and consumed everywhere,
  from servers to mobile devices

22
What is a Service?

• Standardized interface
• Self-contained with no dependencies to other
  services
• available
• Little integration need
• Coarse-grained
• Context-independent
• Services themselves have context
• Allows for Service Composition
• Quality of Service (QoS) Attributes which can be
  measured

23
Service-oriented Systemone example

• Today Amazon or Google Web service
• Future?
• Which credit is the right one for me?
• Credit-Management is part of an overall larger
  system, i.e., what about
• Insurance options protecting me?
• Repayment modalities combined with saving
  modalities?
• The system is open and dynamic
• Interest rate changes
• My status changes (e.g., illness, debt, etc.)
• With each change the process starts all over
  again how often?

24
Software Services

• Equivalent to real-world services
• Software services should align with business
  functions/real-world services
• Service properties apply to software services too
• Implementation of services does not matter
• Complex applications are built by combining
  services (Service Composition)

25
Software Services

• are self-contained, modular applications that
  can be
• Described
• Published
• Found
• Bound
• Invoked
• Composed

26
Context and State

• Services are context independent
• Do not depend on the context in which they are
  used
• E.g. it does not matter to a taxi driver why the
  passenger wants to get to the destination
• Not necessarily stateless
• Loosely coupled
• Services can be reused in new contexts
• Customers are not restricted to one predetermined
  supplier

27
What is SOA?

• Architectural style of software design
• Guides all aspects of creating and using services
• Also a way to design an IT infrastructure
• Main paradigms loose coupling, dynamic binding,
  high interoperability
• Basic Architecture publish/find/bind

28
Roles

• The service model allows for a clear distinction
  to be made between
• service providers (organizations that provide the
  service implementations, supply their service
  descriptions, and provide related technical and
  business support)
• service clients (requestors) (end-user
  organizations that use some service)
• service registry a searchable directory where
  service descriptions can be published and
  searched.
• Service requestors find service descriptions in
  the registry and obtain binding information for
  services.
• This information is sufficient for the service
  requestor to contact, or bind to, the service
  provider and thus make use of the services it
  provides.

29
Service-Oriented Architecture
ServiceSpecification
Service Registry/Broker
ServiceSpecification
ServiceSpecification
ServiceProvider
ServiceRequestor
Service
Request
Response
Requirements
Requirements
30
Application Service Providers

• The concept of software-as-a-service is
  evolutionary appeared first with the ASP
  (Application Service Provider) software model
• an ASP rents applications to subscribers.
• The whole application is developed in terms of
  the user interface, workflow, business and data
  components that are all bound together by the ASP
  provider to provide a working solution.
• An ASP hosts the entire application the
  customer has little opportunity to customize it
  beyond the appearance of the user interface,
  e.g., adding company logos.
• An alternative of this is where the ASP is
  providing a software module that is downloaded to
  the customers site on demand

31
ASP vs. Web Services

• Although the ASP model introduced the concept of
  software as-a-service first, it suffered from
  several inherent limitations such as
• inability to develop highly interactive
  applications,
• inability to provide complete customisable
  applications
• inability to integrate applications
• Today we are in the midst of another significant
  development in the evolution of
  software-as-a-service. The new architecture
  allows for
• loosely-coupled asynchronous interactions
• on the basis of eXtensible Markup Language (XML)
  standards
• with the intention of making access to, and
  communications between, applications over the
  Internet easier, by means of appropriate standards

32
Are ASP, Software as a Service, Web Service
the same?
View in Browser
Typical ASP
Application runs here
Download on Demand
Software as a Service
Application runs here
Access Service
Web Services
Application runs partly here
Application runs partly here
(composition, repackaging, differentiation,
added value services)
Adapted from CBDi forum
33
What problems do we solve?
Describe Services
Discover Services
IntegrateServicesTogether
34
Types of Web Services

• Informational services are services of relatively
  simple nature. They either provide access to
  content interacting with an end-user by means of
  simple request/response sequences, or expose
  back-end business applications to other
  applications. Examples include
• Content services such as weather report info.,
• simple financial info., stock quote info.,
  news items
• Simple trading services that can provide
• a seamless aggregation of information across
• disparate systems data sources.
• Complex services that involve the assembly
• invocation of many pre-existing services
• possibly found in diverse enterprises to
• complete a multi-step business interaction
• a supply-chain application involving order
  taking,
• stocking orders, sourcing, inventory
  control, financials and logistics.

35
Service Properties State

• Functional non-functional properties
• The functional service description details the
  operational characteristics that define the
  overall behavior of the service,
• The non-functional description targets service
  quality attributes, e.g., service metering and
  cost, performance metrics (response time or
  accuracy), security, authorization,
  authentication, scalability, availability, etc.
• Stateless or stateful services
• Services that can be invoked repeatedly without
  having to maintain context or state are called
  stateless.
• Simple informational services are stateless.
• Services that require their context to be
  preserved from one invocation to the next are
  called stateful.
• Complex services (business processes) typically
  involve stateful interactions.

36
Loose Coupling Granularity

• Loose Coupling
• Coupling indicates the degree of dependency any
  two systems have on each other.
• Web services are loosely coupled they connect
  and interact more freely (across the Internet).
  They need not know how their partner applications
  behave or are implemented.
• Service granularity
• Simple services are discrete in nature, exhibit
  normally a request/reply mode of operation are
  of fine granularity, i.e., they are atomic in
  nature.
• Complex services are coarse-grained, e.g., a
  SubmitPurchaseOrder process. These involve
  interactions with other services and possibly
  end-users in a single or multiple sessions.
• Coarse-grained communication implies larger and
  richer data structures, (viz. those supported by
  XML).

37
Synchronicity Well-definedness

• Sychronicity there are two programming styles
  for services
• synchronous or remote procedure call (RPC)-style
  Clients of synchronous services express their
  request as a method call with a set of arguments,
  which returns a response containing a return
  value.
• Simple informational services, e.g., returning
  the current price for a given stock providing
  the current weather conditions in a particular
  location or checking the credit rating of a
  potential trading partner.
• asynchronous or message (document)-style When a
  client invokes a message-style service, it
  typically sends an entire document, e.g., a
  purchase order, rather than a discrete set of
  parameters.
• Business processes, e.g., a purchase order
  responding to a request for quote order from a
  customer or responding to an order placement by
  a particular customer.
• Well-definedness
• The service interaction must be well-defined. The
  Web Services Description Language allows
  applications to describe to other applications
  the rules for interfacing and interacting.

38
Service Interface Implementation

• The service interface defines service
  functionality visible to the external world and
  provides the means to access this functionality.
• The service describes its own interface
  characteristics, i.e., the operations available,
  the parameters, data-typing and the access
  protocols, in a way that other software modules
  can determine what it does, how to invoke its
  functionality, what result to expect in
  return.
• The service implementation realizes a specific
  service interface whose implementation details
  are hidden from its users.
• Different service providers using any programming
  language of their choice may implement the same
  interface.

39
Perspectives
40
Deployment/Realization
Web-service orchestration interface
Imported web-service interfaces
Web-service usage interface
Web-service client
Service-deployment
build/buy
Service-realization
reuse/buy
build
Web-service Implementation (in-house)
Web-service Implementation (outsourced)
Web-service Implementation (outsourced)
41
SOA Framework
Discovery, Negotiation
Composition
Orchestration
Choreography
Transactions
Reliable Messaging
Quality of Service
Security
Interface Bindings
Policy
Description
Messaging Protocol, Addressing
Messaging
Transport Protocols
Transport
42
Service Characteristics (1)

• Loosely coupled
• Interface coupling (implementation details
  hidden)
• Technology coupling (platform independent)
• Process coupling (reusable in different business
  processes)
• Well-defined service contracts
• Meaningful level of abstraction
• Based on standards
• Interface
• Data model
• Process model

43
Service Characteristics (2)

• Predictable service-level agreements (SLAs)
• Dynamic and Discoverable
• Consumable without provider intervention where
  possible
• Minimal intervention when needed (e.g.
  subscription)

44
Service Level Agreements (SLAs)

• An SLA is a formal agreement (contract) between a
  provider and client, formalizing the details of
  use of a Web service (contents, price, delivery
  process, acceptance and quality criteria,
  penalties, etc in measurable terms) in a way that
  meets the mutual understandings and expectations
  of both providers clients.
• An SLA may contain the following parts
• purpose
• parties
• validity period
• scope
• restrictions
• service-level objectives
• penalties
• exclusion terms
• administration authority

45
Quality of Service (QoS)

• QoS refers to the ability of a Web service to
  respond to expected invocations perform them at
  the level commensurate to the mutual expectations
  of both its provider its customers.
• The key QoS attributes in a Web services
  environment are
• availability
• accessibility
• conformance to standards
• integrity
• performance
• reliability
• scalability
• security
• transactionality

46
Components vs. Services

• Components
• Tight coupling
• Client requires library
• Client / Server
• Extendable
• Stateless
• Fast
• Small to medium granularity

• Services
• Loose coupling
• Message exchanges
• Policy
• Peer-to-peer
• Composable
• Context independent
• Some overhead
• Medium to coarse granularity

47
Technical Benefits

• Efficient development
• Promotes modularity (loose coupling)
• Easy to divide and assign to different developers
• Requestor implementation does not need internal
  information
• More reuse
• Loose coupling
• Standards-based
• Simplified maintenance
• Interface is independent of implementation
• Incremental adoption
• Relatively easy to implement incrementally
• Can co-exist with legacy software (and still
  provide benefits)
• Allows step-by-step migration

48
Business Benefits (1)

• Increased business agility
• Finding the right service
• Changing service providers
• Quick assembling of services into application
• Supporting new service requestors and delivery
  channels
• Dynamically adjusting capacity
• Using existing services to support new
  requirements
• Better business alignment
• Service usage and utilization metrics
• Service-level agreements
• Customer satisfaction
• Consistent experience across interfaces

49
Business Benefits (2)

• Reduced integration costs
• Application integration main area of application
• Loose coupling
• Platform independence
• Reduced dependency on technology and vendors
• Application platform (e.g. J2EE, .NET)
• Packaged applications (e.g. SAP)
• Middleware technology (e.g. CORBA)
• Product features (e.g. Stored Procedures)

50
Challenges

• Staff training
• Maintain discipline
• Services must be developed for long-term benefit,
  not only immediate benefit
• Definition of reusable services is non-trivial
• Relatively high short-term costs
• Define business processes
• Create specifications
• Develop code
• Management
• Need to modify some legacy applications
• No callable interfaces
• Only accessible via file transfer

51
Possible Solution

• Step-by-step migration to SOA
• Find and implement specific instances where
  services provide immediate benefits
• Lay foundation for service-oriented architecture
  in department or enterprise
• Add to SOA as expedient
• Caveat maintaining discipline becomes even harder

52
SOA Technologies

• SOA can be built using
• Distributed object middleware (e.g. CORBA, J2EE,
  COM/DCOM)
• Message-oriented middleware (e.g. IBM WebSphere
  MQ)
• TP monitors (e.g. CICS)
• Custom middleware
• B2B platforms (e.g. ebXML, RosettaNet)
• Web services
• Most of these are not ideal for SOA
• Only few installations of conventional middleware
  actually implement a service-oriented architecture

53
Web Services

• One possible implementation technology
• for SOA

54
What are Web Services?

• SOA abstract architectural concept (! Web
  services)
• Web services one approach to realizing SOA
• Not a replacement technology (at least today)
• Not a new programming language
• Not a new middleware system
• Not directly executable (needs execution
  environment)
• XML-based interface technology

55
Web Service - Definition

• A Web service is a software system designed to
  support interoperable machine-to-machine
  interaction over a network. It has an interface
  described in a machine-processable format
  (specifically WSDL). Other systems interact
  with the Web service in a manner prescribed by
  its description using SOAP-messages, typically
  conveyed using HTTP with an XML serialization in
  conjunction with other Web-related standards.
• - W3C (http//www.w3.org/TR/ws-gloss/)

56
Well suited for SOA

• Based on Web standards
• XML and XML Schema for data representation
• HTTP as transport protocol
• Relatively simple
• Platform independent
• Pervasive
• Standardized (W3C, OASIS, )
• Embraced by the IT industry

57
SOA Framework
Core Web Service Standards
Web Service Framework
Discovery, Negotiation
Orchestration
Choreography
UDDI
UDDI, WS-Addressing,WS-MetaDataExchange
BPEL4WS
WS-CDL
Composition
Reliable Messaging
WS-Reliable Messaging
Transactions
Security
WS-Transaction WS-Coordination
WS-Security
Quality of Service
Policy
WS-Policy
Interface Bindings
WSDL
Description
Messaging Protocol, Addressing
SOAP
SOAP, WS-Addressing
Messaging
Transport Protocols
TCP/IP, HTTP, SMTP, FTP,
Transport
58
Core Web Service Architecture
WSDLSpecification
UDDI Registry
WSDL Specification
WSDLSpecification
ServiceProvider
ServiceRequestor
Web Service
Request
Response
Requirements
Requirements
59
Standards

• Core standards (SOAP, WSDL, UDDI) describe basic
  parts of Web service platform
• Designed with extensibility in mind
• Extended specifications provide additional
  features, for example
• Flexible addressing
• Non-functional descriptions
• Quality of Service (reliable messaging, security,
  coordination, transactions)
• Choreography
• Orchestration

60
SOAP

• Originally Simple Object Access Protocol
• XML-based messaging protocol
• Defines
• Simple enveloping mechanism
• Processing model for messages
• Extensibility scheme
• Binding mechanism for transport protocols
• Attachment of non-XML encoded information

61
WSDL

• Web Services Description Language
• XML vocabulary to describe Web services
• Highly extensible and adaptable
• Two parts
• Abstract operations behavior (what?)
• Concrete binding, service (how?, where?)

62
UDDI

• Universal Description, Discovery and Integration
• Flexible directory/registry service for Web
  services
• Services described using WSDL and accessed using
  SOAP
• Original vision public directory
• Companies register provided Web services
• Other companies dynamically discover and use
  these
• Not (yet) fully realized
• Meanwhile intra-enterprise directories

63
Web Services

• are self-contained, modular applications that
  can be
• Described WSDL
• Published to UDDI
• Found in UDDI
• Bound using SOAP
• Invoked using SOAP
• Composed Orchestration (e.g. BPEL)

64
Extended Specifications (1)

• WS-Addressing
• Interoperable, transport-independent way of
  identifying message senders and receivers
• WS-Policy
• Define constraints, conditions, service-level
  assurances and requirements
• Attach these policies to Web services
  usingWS-PolicyAttachment
• WS-MetaDataExchange
• Dynamic exchange of WS-Policy and other metadata
• Between endpoints, no registry involved

65
Extended Specifications (2)

• Quality of Service Specifications
• WS-Security
• Security Framework using existing security
  models(e.g. Kerberos, X.509)
• WS-ReliableMessaging
• In-order delivery
• At least once delivery
• At most once delivery
• WS-Coordination
• General mechanism for coordinating multiparty,
  multi-message Web service tasks
• WS-Transaction
• WS-AtomicTransaction short duration (2-phase
  commit)
• WS-BusinessActivity longer duration activities
  (requires compensation techniques)

66
Extended Specifications (3)

• WS-CDL (Web Services Choreography Description
  Language)
• Describes how services work together
• BPEL (Business Process Execution Language for Web
  Services)
• Provides orchestration for Web services
• Definition and execution of business processes
• Allows the recursive creation of larger Web
  services from smaller ones

67
Orchestration
Chebbi, I., Dustdar, S., Tata, S. (2005). The
view-based approach to dynamic inter-organizationa
l workflow cooperation. Data and Knowledge
Engineering, Elsevier, Vol. 56,(2), pp. 139-173,
2006.
68
Choreography
Chebbi, I., Dustdar, S., Tata, S. (2005). The
view-based approach to dynamic inter-organizationa
l workflow cooperation. Data and Knowledge
Engineering, Elsevier, Vol. 56,(2), pp. 139-173,
2006.
69
Adoption

• Designed for step-by-step adoption
• Core standards usable without extended
  specifications
• Extended specifications provide additional
  features
• SOAP, WSDL and (partially) UDDI already in
  widespread use
• State of extended specifications varies
• Broad vendor support, including industry
  heavyweights IBM and Microsoft

70
Example
71
Example Overview

• Example company travel agency Service-Oriented
  Travel (SOT)
• Services provided to customers
• Organization of trips (holiday, business, )
• Handling of all relevant aspects (flight, hotel,
  rented car, )
• Suppliers
• Airlines
• Hotels
• Car rental services
• Objective
• Implement SOA with Web services internally
• Connect to suppliers using Web services

72
Benefits to Customers

• Quicker response time
• Many steps automated
• No waiting for slow employees of SOT itself or
  suppliers to get tasks done
• Greater accuracy
• Employee in the office, at the telephone, and
  online service use same software service to get
  information
• No more cases of uninformed employees

73
Benefits to Travel Agency

• Faster reaction to changes in supply market
• Loose coupling
• Standards-based
• Improved customer satisfaction
• Cost savings
• No employees needed to manage hotel reservations,
  booking of flights, car rental
• Quicker response time (suppliers)
• Greater accuracy (suppliers)
• Benefits to suppliers are much the same

74
Benefits of SOA

• Benefits only fully realized once company itself
  and all suppliers have implemented SOA (or at
  least external Web services)
• However
• Number of short-term benefits
• Step-by-step introduction reduces negative impact
• Longer-term benefits increase with time

75
Summary
76
Summary SOA (1)

• Software services similar to real-world services
• SOA abstract architectural concept
• Architecture publish/find/bind
• Technical benefits
• Efficiency
• Reuse
• Maintenance
• Incremental adoption
• Business benefits
• Agility
• Alignment
• Customer satisfaction
• Integration costs
• Dependence

77
Summary SOA (2)

• Challenges
• Training/Skills
• Discipline
• Short-term costs
• Legacy applications
• Possible solution step-by-step adoption

78
Summary Web Services (1)

• One approach for SOA
• XML-based interface technology
• Properties
• Based on Web standards
• Relatively simple
• Platform independent
• Pervasive
• Standardized (W3C, OASIS, )
• Embraced by the IT industry

79
Summary Web Services (2)

• Core standards
• SOAP
• WSDL
• UDDI
• Extensibility
• Extended specifications
• WS-Adressing
• WS-Policy
• WS-MetaDataExchange
• QoS WS-Security, WS-ReliableMessaging,
  WS-Coordination, WS-Transaction
• WS-CDL
• BPEL4WS
• Adoption step-by-step, core standards widely used

80
Thanks for your attention!

• Prof. Dr. Schahram Dustdar
• Distributed Systems GroupInstitute of
  Information Systems
• Vienna University of Technology
• Austria
• http//www.infosys.tuwien.ac.at/Staff/sd/