Overview of Web Services and Service Oriented Architecture SOA

1
Overview of Web Services and Service Oriented
Architecture (SOA)

• Vijayan Sugumaran
• School of Business Administration
• Oakland University
• Rochester, MI 48309

2
Background

• Build a distributed computing platform for the
  Web
• Applications are encapsulated, loosely coupled
  Web components that can bind dynamically to
  each other
• Easily find these components and integrate them
  to meet specific requirements
• Plug-and-Play
• Buy and integrate code into your system
• Subscribe to necessary services

3
What are Web Services?

• New breed of Web application
• Self-contained, self-describing, modular
  applications that can be published, located, and
  invoked across the Web
• Perform functions, which can be anything from
  simple requests to complicated business processes
• Once a Web service is deployed, other
  applications (and other Web services) can
  discover and invoke the deployed service

4
Web Services Promise

• Web Services connect computers and devices with
  each other using the Internet to exchange data
  and combine data in new ways.
• The key to Web Services is on-the-fly software
  creation through the use of loosely coupled,
  reusable software components.
• Software can be delivered and paid for as streams
  of services as opposed to packaged products.
• Business services can be completely decentralized
  and distributed over the Internet.
• The dynamic enterprise and dynamic value chains
  become achievable and may be even mandatory.

5
Attributes of Web-Services

• Web-based Protocols Web-services based on HTTP
  are designed to work over the public internet.
  The use of HTTP for transport means these
  protocols can traverse firewalls, and can work in
  a heterogeneous environment.
• Interoperability SOAP defines a common standard
  that allows differing systems to interoperate.
  E.g., the tooling allows Visual Basic clients to
  access Java server components and vice versa.
• XML-based The Extensible Markup Language is a
  standard framework for creating machine-readable
  documents.

Fremantle et al. 2002, Enterprise Services, CACM.
Oct
6
Web Services Technologies

• Web Services technology and underlying standards
  are being rapidly developed
• Introduction of ebXML for Web Service has
  generated lot of interest in the B2B market.
• To provide services, the interface of the service
  should be described with a standard language.
• The contents of services should be registered
  with a registry, shared on the Web.
• A service repository is a distributed directory
  of services and has functions for searching and
  registering.

7
Web Services Technologies (continued)

• In the service registry, information about
  services location and usage are included.
• A particular user could use one or more of the
  services at run time to accomplish a particular
  task.
• Standards are needed to perform the integration
  function

8
Designing Web Services

• Enable universal interoperability
• Enable (Internet scale) dynamic binding
• Support service oriented architecture (SOA)
• Efficiently support both open (Web) and more
  constrained environments
• Based on standards. Pervasive support is critical
  
• Minimal amount of required infrastructure should
  be assumed
• Very low level application integration expected

9
Web Services Standards

• UDDI provides a mechanism for clients to find web
  services. A UDDI registry is similar to a CORBA
  trader, or it can be thought of as a DNS service
  for business applications.
• WSDL defines services as collections of network
  endpoints or ports. A port is defined by
  associating a network address with a binding a
  collection of ports define a service.
• SOAP is a message layout specification that
  defines a uniform way of passing XML-encoded
  data. In also defines a way to bind to HTTP as
  the underlying communication protocol. SOAP is
  basically a technology to allow for RPC over the
  web.

10
Web services technology stack

• Collection of Web Services standards has been put
  together and categorized into different levels
  depending upon their function
• Divided into four levels protocol, description,
  interaction and security
• Helps us to understand the purpose of the
  standards and their underlying assumptions that
  might be required
• Example interaction level (CS-WS) presupposes
  process description level (BPEL4WS), and focuses
  on exchange of messages based on the order of
  sequence described in the process description
  level

11
Web Services Stack (Turner et al., 2003)
12
Web Services How They Work?
SOAP Messages
Requestor
(http transport)
SOAP Client
Web Service Provider

• Components required
• Software which needs to be exposed as a Web
  service
• A SOAP Server (Apache Axis, SOAPLite, etc.)
• HTTP Server (if HTTP is used as the transport
  level protocol)
• SOAP Client (Apache Axis, SOAPLite etc.)

From S. Chandrasekarans Talk
13
Simple Web Service Invocation
Service Requestor
Remote Web Service Repository (Web Sites)
2
Manual Web Service Lookup
HTTP GET
3
WSDL File
Write Client Code
1
Remote Web service
4
SOAP Request
Invoke Web Service
Publish Web Service
5
SOAP Response
WSDL - Web Service Description SOAP - Web
Service Message Protocol
From S. Chandrasekarans Talk
14
Web Service Description

• Why describe Web services?
• A service requestor needs to analyze a service
  for his requirements
• A Web service needs to provide the following
  information
• the operations it supports
• the transport and messaging protocols on which it
  supports those operations
• the network endpoint of the Web service
• Languages such as WSDL, DAML-S, RDF can be used
  for describing Web services
• WSDL describes the syntactic information of a
  service
• DAML-S and RDF describe the syntactic as well
  as the semantic information

From S. Chandrasekarans Talk
15
SOAP-Simple Object Access Protocol

• Simple lightweight protocol for exchanging XML
  data over the Web
• Envelop for transmitting messages, guidelines for
  encoding data, rules for representing remote
  procedure calls (RPCs)
• SOAP message structure an XML element with two
  child elements
• Header security, routing, proper handling of
  message
• Body actual message to be transmitted
• Also defines a model that dictates how recipients
  should process SOAP messages
• The message model also includes actors, which
  indicates who should process the message

16
Web Service Message Protocol - SOAP

• SOAP is an XML Messaging Protocol
• that allows software running on disparate
  operating systems, running in different
  environments to
• make Remote Procedure Calls (RPC).

Header
Body
17
WSDL Web Services Description Language

• Describes the programmatic interface of a web
  service similar to IDL
• Two parts of WSDL description
• Application-level (abstract interface)
• Vocabulary, Message, and Interaction
• data type definitions, operations supported by
  the service, input/output message formats
• Specific protocol-dependent details
• network address, protocol bindings, etc.
• what communication protocol to use
• how to accomplish individual service interactions
• where to terminate communication
• A port element describes a single end point as a
  combination of a binding and a network address
• A service element groups a set of related ports

18
Web Service Description (WSDL)
Abstract Description
Concrete Description
From S. Chandrasekarans Talk
19
UDDI Universal Description, Discovery, and
Integration

• Mechanism to register and locate web services
• Interaction with UDDI accomplished via a set of
  pre-defined SOAP interfaces
• Web services register two types of information
  within UDDI
• tModel (technical model)
• Abstract service protocols that describe a
  particular web services behavior
• businessEntity
• Describes the service implementation
• Refers to multiple tModels and provides
  descriptions about the behavior of the collection
  of tModels

20
UDDI (Universal Description, Discovery and
Integration)

• UDDI serves as a Business and services registry
  and are essential for dynamic usage of Web
  services
• UDDI APIs
• Publication API - Authenticated set of operations
  that allow organizations to publish businesses,
  services, service type specifications
• Inquiry API - Non authenticated public set of
  operations that allows users to extract
  information out of the UDDI registry.

From S. Chandrasekarans Talk
21
UDDI

• UDDI classifies businesses and services according
  to standard taxonomies
• Why Classification ?
• Searches based on keywords alone, could return a
  large set of hits for a particular search
• Classification of services and businesses allows
  to perform better searches
• Registry Data
• White Pages
• Yellow Pages
• Green Pages
• ServiceType Registrations

From S. Chandrasekarans Talk
22
UDDI

• White Pages
• contains business name, text description, contact
  info and other related info.
• Yellow Pages
• contains classification information about the
  business entity and types of the services the
  entity offers.
• e.g. a business entity could have itself
  classified as a sports equipment manufacturer and
  also as a skateboard manufacturer.
• Green Pages
• contains information about how to invoke the
  offered services.
• If a business entity were to offer its catalog
  online, its Green
• pages entry would have a reference to its
  catalog URL

From S. Chandrasekarans Talk
23
UDDI

• Service Types
• Reusable, abstract definitions of services (
  abstract part of WSDL)
• that are defined by industry groups and
  standard bodies.
• These reusable abstractions are referred to as
  Technology Models
• The UDDI data structure corresponding to this is
  called TModels
• TModels
• Any abstract concept can be registered within
  UDDI as a TModel.
• e.g. If you define a new WSDL port type, you can
  define a TModel that represents the port type
  within the UDDI

From S. Chandrasekarans Talk
24
How UDDI Works ?
1.
SW companies, standards bodies, and programmers
populate the registry with descriptions of
different types of services
UDDI Business Registry
Service Type Registrations
Source http//www.uddi.org/pubs/UDDI_Overview_Pr
esentation.ppt
25
Service Oriented Architecture and Related
Challenges
26
Current Business Trends

• How can, new value be created by leveraging
  existing technology investments?
• How can technology help reconfigure operational
  processes and improve flexibility through
  business process outsourcing?
• How can companies move from one-channel, single
  business unit solutions to cross-enterprise,
  multi-channel solutions?
• How can the inside-out process perspective
  (customer management, supply chain) be balanced
  with an outside-in services view

27
Service Oriented Architecture (SOA)

• SOA - structure of the system
• Includes software components, externally visible
  properties of those components, relationships
  among them, and constraints on their use
• The underlying foundation for designing and
  developing SOA is the emerging field of Web
  Services
• Enables different software components to be
  integrated without having to develop these
  components from scratch - no hassle of custom
  coding

28
Services Aspect of Web-Services

• Modular Service Components are useful in
  themselves, reusable, and it is possible to
  compose them into larger components.
• Available Services are available to systems
  that wish to use them. Services must be exposed
  outside of the particular paradigm or system they
  are available in.
• Described Services have a machine-readable
  description that can be used to identify the
  interface of the service, and its location and
  access information.
• Implementation-independent The service
  interface must be available in a way that is
  independent of the ultimate implementation.
• Published Service descriptions are made
  available in a repository where users can find
  the service and use the description to access the
  service.

Fremantle et al. 2002, Enterprise Services ,
CACM. Oct
29
Putting it Together

• Web Services (SOAP, UDDI, WSDL)
• Data exchange between two programs in XML format
• Operate on syntactic level Web services
  infrastructure do not access data content.

30
Web Services Invocation

• Invocation Model
• One way invocation
• Request/Reply invocation
• Solicit/Response invocation
• Invoked Entity (Service Provider)
• Publishes WSDL operation with input and output
  message
• Invoker (Service Requester) No concept
• Especially not a subroutine call a la RPC with
  appropriate stack operations or stub generation

31
WS-Based Development

• Standards organizations
• Wide Web Consortium (W3C)
• Organization for the Advancement of Structured
  Information Systems (OASIS)
• Web Services Industry body (WS-I)
• Microsoft, IBM, BEA, Sun Micro Systems, SAP,
  Oracle and Hewlett-Packard
• Three stakeholders
• service provider
• service consumer
• Web Services Standards Organizations
• Several challenges exist in integrating Web
  Services into E-commerce applications

32
WS Based Application Development Issues

• Identifying and analyzing the challenges that
  exist for each of these stakeholders
• Presents a framework that organizes and
  inter-relates the challenges in an easily
  understandable manner
• The framework is intended to help both the
  service consumers and providers in improving
  their expectations and quality regarding Web
  Services

33
Concerns with SOA-based Application Development

• Automate individual applications based on
  cross-organizational, heterogeneous software
  components
• Coordination of a set of Web Services working
  toward a common goal
• Web services performance needs to be optimized
• Quality of service parameters as well as service
  level agreements
• Monitoring and controlling of Web Services

34
Stakeholders
WS Providers
WS Consumers
WS Integrators Publishers
Web Service Vendors
Application Assemblers
End Users
Standards Organizations
W3C
OASIS
WS-I
Others
35
Challenges in WS Integration

• Important issues with adoption of web services
• insufficient standardization
• low acceptance of service consumers
• critical mass of available useful services
• Need a framework for studying web services
  adoption
• technical and non-technical issues associated
  with web services deployment
• These two dimensions have to be investigated for
  all the major stakeholders
• web service providers, web service consumers, and
  standards organizations

36
Web Services Providers

• Identifying new web services requirements,
  design, implementation, testing, eliciting
  customer feedback
• Web services development strategy, architecture
  standards, and design requirements
• Service provider specific processes such as
  metering, accounting, and billing
• Service delivery overhead
• Coordination function is critical because
  business transactions usually follow a
  contractually defined, fixed pattern

37
Web Service Providers (contd.)

• Support for versioning management
• Quality of Service (QoS) policy
• Service Level Agreements (SLAs), legally binding
  contracts that establish bounds on various QoS
  metrics
• Unpredictable workloads and high peak-to-average
  ratios in workload intensity
• Implementing priority-based admission control
  mechanisms

38
Web Service Consumers

• Application Assemblers and End Users
• Difficulty in identifying relevant web services
  and integrating them to generate a cohesive
  application
• Manually search for web services, typically by
  completing a web form to search a repository
• Dealing with web services that evolve over time
• For discontinued services application should
  automatically search for the next best fit and
  seamlessly integrate it

39
Web Service Consumers

• Service Integrators face a number of issues
• Efficiency - web services execution must be very
  efficient
• Expressiveness - B2B interactions are complex,
  requires expressive set of supported integration
  concepts
• Security - interactions must be secured to
  prevent attacks of all types, and non-repudiation
  must be provided for reliable record keeping
• Reliability - remote and distributed
  communication must be reliable, and messages must
  be sent exactly once to ensure dependable
  interactions
• Manageability - inter-enterprise communication
  changes frequently, requiring easily manageable
  technology

40
WS Standards Organizations

• Business process dynamics and nonfunctional
  properties of service-enabled processes are
  poorly addressed
• Current standards do not put forth a methodology
  to assist designers in building web services on
  top of legacy assets
• Specifications to support creating robust service
  compositions
• Standards-based definition of an interoperability
  communication protocol

41
WS Standards Organizations

• Mechanisms for service description, discovery,
  and composition and a basic set of quality of
  service protocols
• Design guidelines, including
• large granularity of messages
• asynchronous messaging,
• bi-directionality of services,
• endpoint discovery, service agents,
• request pipeline
• context and content-based routing

42
Overall Challenges Framework
Web Services Suppliers
Web Services Consumers
Web Services Registry
Web Services Standards Organizations
43
Web Services Supplier

• Technical Challenges
• Service description and profile
• WS accessibility, and documentation
• Architecture standards infrastructure
• Design Requirements
• Web services evolution
• Managerial Challenges
• Pricing Quality of Service commitments
• Identifying new services
• Customer feedback and support
• Partnerships with third party providers
• Demand management and Liability

44
Web Services Consumer

• Technical Challenges
• Search and identification of relevant WS
• Customization and integration
• Validation and testing
• Technology, domain task characteristics
• Tools, infrastructure and metrics
• Managerial Challenges
• WS utilization strategy
• Promoting WS, training and education
• Resource allocation and support
• Incentives and rewards
• Partnership management and Security

45
WS Standards Organizations

• Technical Challenges
• Service description, publishing invocation
• WS technology stack components
• Modeling web services
• Architectures for WS applications
• Specifications for all aspects of WS
• Managerial Challenges
• Future directions for WS research practice
• WS implementation guidelines
• Vendor cooperation for common standards
• Open standards and interoperability
• Consistency between standards

46
Summary

• Mass market for web services are slow to
  materialize and businesses are slow to adopt web
  services technology
• Web services based development warrants a shift
  in paradigm, and managers are ill equipped to
  assess the advantages and disadvantages
• Myriad of challenges faced in adopting web
  services havent been thoroughly explored
• Challenges framework for studying the adoption
  and diffusion of web services from the
  stakeholders perspective
• Managerial challenges have to be investigated
  using relationships between web service producers
  and consumers