Sei sulla pagina 1di 33

Introduction

to
Web Services

Raju. A
Web services
A web service is a collection of protocols and
standards used for exchanging data between
applications or systems.

“Web services” is an effort to build a


distributed computing platform for the Web.
Characteristics
1. A Web Service is accessible over the Web.
2. Web Services communicate using platform-
independent and language-neutral Web
protocols.
3. A Web Service shares schemas and
contracts/interface that can be called from
another program.
4. A Web Service is registered and can be located
through a Web Service Registry.
5. Web Services support loosely coupled
connections between systems.
Web services
• A collection of XML-based technologies developed by
the e-business community to address issues of:
– service discovery
– interoperable data exchange and/or application invocation
– service compositions (workflow, business processes)
• Major developers include:
– Apache, IBM, HP, SUN & Microsoft (.NET)
• http://www.webservices.org/
Technologies
• XML (eXtensible Markup Language)
– markup language that underlies most of the specifications used for Web
services.  
• SOAP (Simple Object Access Protocol)
– (Simple Object Access Protocol), is a network, transport, and
programming language and platform neutral protocol that allows a client
to call a remote service. The message format is XML.
• WSDL (Web services description language)
– An XML-based interface and implementation description language. The
service provider uses a WSDL document in order to specify the
operations a Web service provides. 
• UDDI (universal description, discovery, and integration)
– Both a client-side API and a SOAP-based server implementation that
can be used to store and retrieve information on service providers and
Web services.
Current distributed infrastructure
• Microsoft:
– DCOM/COM+
• SUN:
– Java RMI
• CORBA:
– Try to be a standard specification ( but complex to use)

Disadvantages
• Vendor Specific
• Platform Specific
• No interoperability
• Configuring Firewalls
CORBA-based approach
Waiting
Waitingfor
for Sending
Sending
requests
requests Data in binary format requests,
requests,
(known location,
(known location,
known
getting
getting
knownport)
port)
results
results

• CORBA:
– Data transmitted as objects (at least it looks like that)
– Transport (usually) over well standardised IIOP protocol
– user sessions (state-fullness) very inter-operable
– server side: an RPC call is made
Distributed architecture
• gives
– access to distributed resources
– development encapsulation
• maintainability, re-usability, legacy-awareness
– implementation independence
• requires
– adding a communication layer between parts
– synchronization of efforts.
Distributed architecture
Waiting
Waitingfor
for Sending
Sending
requests
requests Communication protocol, Data format requests,
requests,
(known location,
(known location,
known
getting
getting
knownport)
port)
results
results
Traditional CGI-based approach
Waiting
Waitingfor
for Sending
Sending
requests
requests Data as name/value pairs requests,
requests,
(known location,
(known location,
known
getting
getting
knownport)
port)
results
results

• cgi-bin scripts:
– Data transmitted as name-value pairs (HTML forms)
– Transport over (state-less) HTTP protocol
– no standards for keeping user sessions (state-fullness)
– server side: a script is called
SOAP-based communication
Waiting
Waitingfor
for Sending
Sending
requests
requests Data in XML format requests,
requests,
(known location,
(known location,
known
getting
getting
knownport)
port)
results
results

• SOAP:
– Data in a well-defined XML format
– Transport over various protocols
• HTTP, SMTP are the most used, perhaps because they are
firewall-friendly
– server side: either an RPC call or a message delivered
Service Oriented Architecture
• Service
– Small program interacted by well defines message
exchanges
– Agile, Reliable, Stable, Interoperable, Secure
• Four Tenets
– Boundaries are Explicit
– Services are Autonomous
– Services share schema and contract, not class
– Service compatibility is based upon policy
Service Oriented Architecture

L
Service

SD
Registry
W
ve
ie
tr

Pu
Re

bl
is h
&
er
ov
sc
Di

Service Service
Requestor Provider

Bind
According to the SOA
A Web service is:
 An interface that describes a collection of network
accessible operations
 Described using a service description language
 Published by making this service description available to
users
 Found by sending queries to a registry matching service
descriptions
 Bound-Invoked by using the information contained in the
service description
 Composed with other services to create new services
(service orchestration)
eXtensible Markup Language

• All the technologies in Web Services are XML based


– Messaging
– Description Are all in XML
– Registry

• Why?
– XML is pure text with no binary data
– Applications read the XML
– Applications share data using XML . Any application can talk to
any other
application using XML (unlike binary) irrespective of the platform
– XML is a method for putting structured data in a text file
XML Rules
• Well formed
– Syntax is correct (all tags opened and closed)
• Valid
– All the elements matches the definitions written in the schema
• XML Documents (.xml) == XML Instances of the Schema (.xsd)
• DTD
– Document Type Definitions – Validates XML data against it
• XML Schema
– Alternative to DTD with added functionality. It supports other data types not
supported by DTD
• Predefined Simple Types (integers,booleans,dateTime…)
• User-defined datatypes ( Complex Types)
• Validations Restrictions to types
– XML schema itself is an XML document !
• XML Processing
– Read the XML documents XML processors (Parsers)
• SAX (based on events)
• DOM ( reads the xml document and loads it in memory)
• Python implements this interfaces in a package PyXML
SOAP
• Simple Object Access
Protocol
• SOAP is an open protocol
specification defining a
uniform way of performing
RPCs using HTTP as the
underlying communications
protocol with XML for the
data serialization.

PORT 80 or HTTP
XML Messaging Using SOAP
SOAP
An internet standard specification, the goal of which is to define
a platform and vendor neutral wire protocol based on internet
standard protocols (HTTP & XML) to access web services.

How do we access a service ?


- With a soap message: Is a XML stream which is used to
transmit messages via HTTP.
SOAP-Packet
HTTP Packet

HTTP Header

HTTP Body

TCP communication channel


WSDL
• Web Services Definition Language
– http://www.w3.org/TR/wsdl/
• An XML-based language for describing Web
Services
– what the service does (description)
– how to use it (method signatures)
– where to find the service
• It does not depend on the underlying protocol
• But it is not much human-readable
WSDL
Web Services Definition Language

• WSDL is an XML-based language used to define Web Services and describe


how to access them.
• It is the external interface for a client (IDL)

• WSDL includes information about


– Data types it uses
– Parameters it requires and returns
– Groupings of functionality
– The protocol to be used to access the service
– The location or address of the service
WSDL Structure
Service

• portType
– Abstract definition of a Port Port
(e.g. http://host/svc)

service (set of operations) Binding


(e.g. SOAP)
Binding
• Multiple bindings per
portType:
portType
– How to access it
– SOAP, direct call
operation(s)
• Ports inMesage outMessage
– Where to access it
Abstract interface

Livermore July 25
2001
Client invocation

• Single stub can invoke services over different bindings


– Depends only on abstract interface.
• Are independent of binding (but pluggable).
– Add new bindings without recompiling/redeploying stub

• Allows optimisations RMI-


IIOP
based on the bindings of service.
• Will support extended Client Proxy SOAP/
object HTTP
services models if described
In WSDL JMS/
MQ
Invoking a web service

A client invoking a Web service


UDDI Overview

• UDDI defines the operation of a service registry:


– Data structures for registering
• Businesses
• Technical specifications: tModel is a keyed reference to a technical
specification.
• Service and service endpoints: referencing the supported tModels
– SOAP Access API
– Rules for the operation of a global registry.
UDDI: Universal Description Discovery and Integration
3.

1. SW companies, standards
bodies, and programmers
Marketplaces, search
populate the registry with
engines, and business
descriptions of different
apps query the
types of services
registry to discover
services at other
companies
2.

• Businesses Business Service 4.


populate Descriptions Types
the registry with
descriptions of
the services they Business uses this
support data to facilitate
easier integration
with each other
over the Web
How it works all together
Why to use Web Services…
(comparing to CORBA)
• WS are easier to deploy because of their firewall-
friendliness
• WS are quite well marketed (both from IT companies
and Open Source projects)
• However:
– user sessions are less standardised
– many parts yet-to-be-done (notification, transactions,
security, etc.)
• The programming effort and maintainability is similar
to other distributed technologies
Conclusion
• Distributed computing is inevitable
• More accesses by programs than by clicking
on hyperlinks
• More technologies of distributed architecture
will collaborate
• The better standards we have the better
results we’ll get
• Web Services is not a new hype but a trend to
follow
For more information
– SOAP
http://www.w3c.org/TR/soap
– WSDL
http://www.w3c.org/TR/wsdl
– UDDI
http://www.uddi.org
THANK YOU

Potrebbero piacerti anche