Web Services Overview:

A technical introduction

Originally created by:

Clovis Chapman
Department of Computer Science
University College London
c.chapman@cs.ucl.ac.uk
Modified and presented by:
Gandhi Manalu
A Brief History of Distributed Computing

• Remote Procedure Call (RPC)

• Made popular by Sun Microsystems
• Extended procedure calls to work across a network
• RPC worked well for 2-teir application, but lacked the flexibility
to adapt to N-teir uses.
• Common Object Request Broker Architecture (CORBA)
• CORBA uses an Object broker (ORB)
• The ORB must reside on the client and sever and is responsible
for handling the distributed communication
• Distributed Common Object Model (DCOM)
• A protocol developed by Microsoft
• DCOM extends Common Object Model (COM) to include
references over a network.
• Java Remote Method Invocation (RMI)
• A java package for executing methods that are on a different
JVM
A Brief History of Distributed Computing

• All of these technologies enjoyed success, but all

present shortcomings when used in the Web
environment
• They tend to create tightly coupled systems
• Some where platform and vendor specific
• Some required the distributed system to run on a
closely administered environment
• Proprietary and complex protocols and data
representation
Web Service

• The World-Wide-Web was designed to allow users

access to vast amounts of information
• Now, business would like programmatic access
to that information to automate some business
activities.
• Web Services are functional applications that
reside on the web and can be invoked to
accomplish a specific goal.
• Web Services allows for platform independent
access to this information
• All data and service metadata is transmitted using XML,
so programming language and system dependencies are
removed
Service Oriented Architecture (SOA)

• SOA uses modular services that can be integrated or

reused to create distributed applications
• Scalable – The past solutions were not designed with the
scale of the Web in mind. SOA should work across the world.
• Loosely-coupled – SOA does require that the parties in a
transaction are known well. The system only needs the
information to invoke the service.
• Interoperability – One party should be able to communicate
with another party regardless of the machine they are running
on.
• Discovery – On party should be able to dynamically discover
other partners to invoke.
• Abstraction – A SOA abstracts the underlying technology.
Developers can concentrate on building services for business
users rather than connecting systems and applications.
• Standards – Standards are the basis of interoperable contract
selection and execution.
SOA and Web Service Standards

• Web Services use standards that are based on

XML.
• This allows for the platform flexibility that is required by
the SOA
Web Services

 Essentially a collection of protocols and standards

(XML-based)

 These standards define:

 Which operations/requests a service may support

 How to format requests
 Security…
 Can mix and match according to requirements (in theory)

 Numerous implementations and development Kits

available (Apache Axis, gSOAP, .Net, etc.)
Basic Web Service Standards

• Simple Object Access Protocol (SOAP)

• The standard used to provide communication between systems
on differing platforms developed with differing languages
• Envelope defines the namespace and the encoding style
• Header defines other characteristics of the message
• Body contains the data of the message that is being sent
• Web Service Description Language (WSDL)
• An XML representation of the service
• This file contains all the information needed to describe and
invoke the service
• Universal Description, Discovery, and Integration (UDDI)
• A registry for WSDL files.
• UDDI creates a place where Web Services can be advertised
and discovered.
First things first: XML
 eXtensible Mark-up Language: Text-based data formatting Language

 (similar to HTML but NOT HTML)

 Can define your own elements and document structure
 The key to enabling platform-heterogeneity

1: Start and end TAG <TAG> … </TAG>

<book> The Master and Margarita </book>

--------------------------------------------
2: Nested elements <book>
<title> The Master and Margarita </title>
<author> Bulgakov </author>
</book>
--------------------------------------------
<book author=Bulgakov>
3: Attributes
The Master and Margarita
</book>
First things first: XML - Schemas
 Schemas enable constraints to be defined for the structure of the XML document and content

 Schemas enable you to define your own XML syntax e.g. types or categories of elements
 Facilitates parsing of XML documents

1: Namespaces

<schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<complexType name=“book">
<sequence>
<element ref="author“ type=“string” />
<element ref="title“ type=”string”/>
<element ref=“inStock“ type=“integer”/>
</sequence>
</complexType>
2: Type
</schema>
Web Services Architecture Overview

WSDL
interface –
CondorService

startJob(exec)
Site B
stopJob(exec)
Web Server

Site A

Client Condor
Service
CondorService.startJob(job)

SOAP Service 2
HTTP

SOAP Libraries (Stub)

Container
 Web Service Description Language
 Used to describe the functionality provided by a service and how to
communicate with it
<definitions
name=“JobSubmissionService”
targetNamespace=“urn:Condor”>

<types>
Definitions: service name, <complexType name=“Job”>
namespaces, schemas <sequence>
<element name=“input” type=“String”>
..
</sequence>
Types: description of data </complexType>
</types>
structures used
<message name=“StartJobRequest”>
Can be automatically generated!
<part name=“JobRequest” type=“Job” />
</message>
Messages: structure of messages
e.g.… Java2WSDL (Axis)
exchanged <portType name=“SubmissionPortType”>
<operation name=“StartJob”>
<input name=“StartJobRequest” type=“StartJobRequest” />
<output name = … >
PortType: set of operations </operation>
supported </portType>

<binding name =…>

Binding: info on protocol and data
encoding for operation invocations
</binding>
<soap:binding style=“rpc” transport=http://schemas.. />
<operation name=“StartJob”>
<!–- encoding format for each message -->
</operation>

Service port: specifies the <service name=“JobSubmissionServiceImpl”>

endpoint address <port name=“SubmissionPort” binding=“..”>
<soap:address location=“http://hello.ac.uk/services”/>
</port>
</service>
Simple Object Access Protocol
 XML-based protocol for message exchange between client and service
 Does not have to be SOAP
 “Wrapped” in HTTP packet (Hypertext Transfer Protocol – used for browsing
the World Wide Web)
 Better firewall management (in theory)
 Can use other transport protocols
HTTP header (POST)
SOAP Action
<SOAP-ENV:Body>
<m:StartJobRequest xmlns:m="some-URI">
Request <symbol>DEF</Symbol>
</m:StartJobRequest>
</SOAP-ENV:Body>

HTTP header
<SOAP-ENV:Body>
<m:StartJobResponse xmlns:m="some-URI"> Response
<result>22.50</result>
</m:StartJobResponse>
</SOAP-ENV:Body>
SOAP and Firewalls?

 HTTP traffic is usually allowed through firewalls for web

browsing (in theory)
 Bypassing firewalls defeats their purpose
 Some firewalls can filter SOAP headers but not easy

 However Web Services allow session management

through a single port
 Multiple services can be accessed through a single port
 Simplifies firewall administration
SOAP attachments
 SOAP body is restricted to XML character set
 Attachments provide us with means to transfer binary data (i.e.
non text) – e.g. input files for jobs

 Uses MIME (Multi-Purpose Internet Mail Extensions) originally

defined for e-mail attachments
 MIME provides encoding schemes that allow binary content to be
transmitted over transports that are not otherwise able to do so.
 Any type of data can accompany SOAP

 Can still add a considerable overhead (e.g. base64 encoding

can add 33%)
 But probably less overhead than converting your data to XML
Web Service Discovery - UDDI
 Universal Description Discovery and Integration
 Enables Just-in-time integration

Registry

find Publish description

Client Service
use
Developing Web Services

• Create a UML Diagram

• This defines the classes that will be used by the service and the methods that
will be implemented by those classes
• Generate Java Code
• Tools like Poseidon can be used to generate skeleton classes from the UML
• Add Web Service Annotations
• Java 6 annotation that will tell the complier that these classes are part of a web
service
• Generate WSDL
• From the annotations, the WSDL file for this service can be generated
automatically
• Implement Methods
• This step simply implements the business logic of the methods in the classes
• Deploy Service
• The service must be deployed on a application server like Apache Axis.
• This server handles all the SOAP communication.
• Test Service
• Write a simple java program to invoke and test the exposed methods of the
service.
• Publish Service to UDDI Registry
Building your first Web Service Client

 Using Axis API.

 Generate stubs from WSDL file using WSDL2Java

 e.g. Submit a Job to a JobSubmissionService

locator = new ServiceLocator();

service = locator.getJobSubmissionService(new URL(
http://machine:port));

result = service.startJob(myJob);
Thank You!