Web Service Workshop - 3 days

Ionut David &
Sorin Nita
December 2013
WebServices
Workshop

•What is XML and XSD
•What is a Web Service
•What is SOAP
•What is WSDL
•What is JSON
•What is REST
•What is WADL
•Tools
Agenda
2

What is XML
3
• XML stands for eXtensible Markup Language.
• XML was designed to transport and store data, as HTML was designed to display data.
• XML tags are not predefined. You must define your own tags.
• XML does not do anything, XML it’s just a framework.
• XML is the most common tool for data transmissions between all sorts of applications.
<?xml version="1.0" encoding="ISO-8859-15"?>
<class_list>
<student>
<name>Robert</name>
<grade>A+</grade>
</student>
<student>
<name>Lenard</name>
<grade>A-</grade>
</student>
</class_list>

XML Tree Structure
4
• The first line is the XML declaration. It defines the XML version (1.0) and the encoding used (ISO-
8859-1 = Latin-1/West European character set).
• The next line describes the root element of the document (like saying: "this document is a note").
• The next 4 lines describe 4 child elements of the root (to, from, heading, and body).
• And finally the last line defines the end of the root element
<?xml version="1.0" encoding="ISO-8859-
1”?>
<note>
<to>Sam</to>
<from>John</from>
<heading>Reminder</heading>
<body>Don't forget the meeting!</body>
</note>

XML Tree Structure
5
• XML documents must contain a root element. This element is "the parent" of all other elements.
• All elements can have sub elements (child elements).
• Children on the same level are called siblings (brothers or sisters).
• All elements can have text content and attributes (just like in HTML).

XML Syntax Rules
6
• The syntax rules of XML are very simple and logical.
• All elements must have a closing tag.
• <p>This is a paragraph</p>
• XML tags are case sensitive, opening and closing tags must be written with the same case
• <Message>This is incorrect</message>
<message>This is correct</message>
• All XML elements must be properly nested within each other.
• <b><i>This text is incorrect</b></i>
<b><i>This text is correct</i></b>
• In XML, the attribute values must always be quoted.
• <note date="12/11/2007">

XML Naming Rules
7
• XML elements must follow these naming rules:
• Names can contain letters, numbers, and other characters
• Names cannot start with a number or punctuation character
• Names cannot start with the letters xml (or XML, or Xml, etc)
• Names cannot contain spaces
• Any name can be used, no words are reserved.
• Avoid using the following characters: - (line) . (dot) or : (colon)

XML Namespaces
8
• In XML, element names are defined by the developer. This often results in a conflict when trying
to mix XML documents from different XML applications.
<table>
<tr>
<td>Apples</td>
<td>Bananas</td>
</tr>
</table>
<table>
<name>African Coffee Table</name>
<width>80</width>
<length>120</length>
</table>
• Name conflicts in XML can easily be avoided using a name prefix.
<h:table>
<h:tr>
<h:td>Apples</h:td>
<h:td>Bananas</h:td>
</h:tr>
</h:table>
<f:table>
<f:name>African Coffee Table</f:name>
<f:width>80</f:width>
<f:length>120</f:length>
</f:table>

XML Namespaces
9
• When using prefixes in XML, a so-called namespace for the prefix must be defined.
• The namespace is defined by the xmlns attribute in the start tag of an element.
• The namespace declaration has the following syntax. xmlns:prefix="URI".
• Namespaces can be declared in the elements where they are used or in the XML root element.
<root xmlns:h="http://www.w3.org/TR/html4/"
xmlns:f="http://www.w3schools.com/furniture">
<h:table>
<h:tr>
<h:td>Apples</h:td>
<h:td>Bananas</h:td>
</h:tr>
</h:table>
<f:table>
<f:name>African Coffee Table</f:name>
<f:width>80</f:width>
<f:length>120</f:length>
</f:table>
</root>

XML Namespaces
10
• A Uniform Resource Identifier (URI) is a string of characters which identifies an Internet Resource.
• Defining a default namespace for an element saves us from using prefixes in all the child
elements.
• It has the following syntax: xmlns=“namespaceURI”
• This XML carries HTML table information:
<table
xmlns="http://www.w3.org/TR/html4/">
<tr>
<td>Apples</td>
<td>Bananas</td>
</tr>
</table>
• This XML carries information about a piece of furniture:
<table xmlns="http://www.w3schools.com/furniture">
<name>African Coffee Table</name>
<width>80</width>
<length>120</length>
</table>

Quiz time
11
• Time to test the XML knowledge

XML Schema
12
• An XML Schema describes the structure of an XML document.
• The XML Schema language is also referred to as XML Schema Definition (XSD).
<?xml version="1.0"?>
<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="note">
<xs:complexType>
<xs:sequence>
<xs:element name="to" type="xs:string"/>
<xs:element name="from" type="xs:string"/>
<xs:element name="heading" type="xs:string"/>
<xs:element name="body" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

XSD features
13
• An XML Schema:
• defines elements and attributes that can appear in a document
• defines which elements are child elements
• defines the order and the number of child elements
• defines whether an element is empty or can include text
• defines data types for elements and attributes
• defines default and fixed values for elements and attributes

XSD Reference
14
• This XML document has a reference to an XML Schema:
<note
xmlns="http://www.w3schools.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3schools.com note.xsd">
<to>Sam</to>
<from>John</from>
<heading>Reminder</heading>
<body>Don't forget the meeting!</body>
</note>
• The following fragment: xmlns=http://www.w3schools.com specifies the default namespace
declaration.
• This fragment: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance indicates the XML Schema
Instance namespace
• Last fragments is the schemaLocation attribute The first value is the namespace to use. The second value
is the location of the XML schema to use for that namespace:
xsi:schemaLocation="http://www.w3schools.com note.xsd

XSD <schema> Element
15
• The <schema> element is the root element of every XML Schema.
• The <schema> element may contain some attributes. A schema declaration often looks something
like this:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.w3schools.com"
elementFormDefault="qualified">
...
</xs:schema>

XSD <schema> Element
16
• The following fragment: xmlns:xs=http://www.w3.org/2001/XMLSchema indicates that the
elements and data types used in the schema come from „http://www.w3.org/2001/XMLSchema“
namespace .
• This fragment: targetNamespace="http://www.w3schools.com” indicates that the elements
defined by this schema come from http://www.w3schools.com
• This fragment: xmlns="http://www.w3schools.com” indicates the default namespace.
• This fragment: elementFormDefault=“qualified” indicates that any elements used by the XML
instance document which were declares in this schema must be namespace qualified
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.w3schools.com"
elementFormDefault="qualified">
...
</xs:schema>

XSD Simple Element
17
• A simple element is an XML element that contains only text. It cannot contain any other elements
or attributes.
• The text can be of many different types. It can be one of the types included in the XML Schema
definition (boolean, string, date, etc.), or it can be a custom type that you can define yourself.
• The syntax for defining a simple element is:
<xs:element name=„xxx“ type=„yyy“/>
• Where xxx is the name of the element and yyy is the data type of the element.
• XML Schema has a lot of built-in data types. The most common types are: (xs:string, xs:decimal,
xs:integer, xs:boolean, xs:date, xs:time)
<xs:element name="lastname" type="xs:string"/>
<xs:element name="age" type="xs:integer"/>
<xs:element name="dateborn" type="xs:date"/>

XSD Simple Element Values
18
• Simple elements may have a default value OR a fixed value specified.
• A default value is automatically assigned to the element when no other value is specified.
• In the following example the default value is "red":
<xs:element name="color" type="xs:string" default="red"/>
• A fixed value is also automatically assigned to the element, and you cannot specify another value.
• In the following example the fixed value is "red":
<xs:element name="color" type="xs:string" fixed="red"/>

XSD Attributes
19
• All attributes are declared as simple types.
• Simple elements cannot have attributes. If an element has attributes, it is considered to be of a
complex type.
• The syntax for defining an attribute is:
<xs:attribute name=“xxx" type=“yyy"/>
<xs:attribute name="lang" type="xs:string"/>
• Where xxx is the name of the attribute and yyy is the data type of the attribute.
• XML Schema has a lot of built-in data types. The most common types are: (xs:string, xs:decimal,
xs:integer, xs:boolean, xs:date, xs:time)
• Here is an example:

XSD Attributes Values
20
• Attributes may have a default value OR a fixed value specified.
• A default value is automatically assigned to the attribute when no other value is specified.
• In the following example the default value is "EN":
<xs:attribute name="lang" type="xs:string" default="EN"/>
• A fixed value is also automatically assigned to the attribute, and you cannot specify another value.
• In the following example the fixed value is "EN":
<xs:attribute name="lang" type="xs:string" fixed="EN"/>
• Attributes are optional by default. To specify that the attribute is required, use the "use" attribute:
<xs:attribute name="lang" type="xs:string" use="required"/>
• When an XML element or attribute has a data type defined, it puts restrictions on the element's
or attribute's content.
• If an XML element is of type "xs:date" and contains a string like "Hello World", the element will
not validate.

XSD Restrictions/Facets
21
• With XML Schemas, you can also add your own restrictions to your XML elements and attributes.
These restrictions are called facet.
• The following example defines an element called "age" with a restriction. The value of age cannot
be lower than 0 or greater than 120:
<xs:element name="age">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="120"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
• A value that is outside of 0-120 will not be validated.

XSD Restrictions/Facets
22
• To limit the content of an XML element to a set of acceptable values, we would use the
enumeration constraint.
<xs:element name="car">
<xs:simpleType>
<xs:restriction
base="xs:string">
<xs:enumeration
value="Audi"/>
<xs:enumeration
value="Golf"/>
<xs:enumeration
value="BMW"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
• In right side case the type "carType" can be used by other elements because it is not a part of the
"car" element, it’s a new custom type that we’ve created.
<xs:element name="car"
type="carType"/>
<xs:simpleType
name="carType">
<xs:restriction
base="xs:string">
<xs:enumeration
value="Audi"/>
<xs:enumeration
value="Golf"/>
<xs:enumeration
value="BMW"/>
</xs:restriction>
</xs:simpleType>

XSD Restrictions on content
23
• The example below defines an element called "letter" with a restriction. The only acceptable value
is ONE of the LOWERCASE letters from a to z:
<xs:restriction base="xs:string">
<xs:pattern value="[a-z]"/>
</xs:restriction>
• The next example defines an element called "initials" with a restriction. The only acceptable value
is THREE of the UPPERCASE letters from a to z:
<xs:pattern value="[A-Z][A-Z][A-Z]"/>
</xs:restriction>
• The next example also defines an element called "initials" with a restriction. The only acceptable
value is THREE of the LOWERCASE OR UPPERCASE letters from a to z:
<xs:pattern value="[a-zA-Z][a-zA-Z][a-zA-Z]"/>
</xs:restriction>

XSD Restrictions on format
24
• The next example defines an element called "choice" with a restriction. The only acceptable value
is ONE of the following letters: x, y, OR z:
<xs:pattern value="[xyz]"/>
</xs:restriction>
• The next example defines an element called “digits" with a restriction. The only acceptable value
is FIVE digits in a sequence, and each digit must be in a range from 0 to 9:
<xs:pattern value="[0-9][0-9][0-9][0-9][0-9]"/>
</xs:restriction>
• The example below defines an element called “word" with a restriction. The acceptable value is
zero or more occurrences of lowercase letters from a to z:
<xs:pattern value="([a-z])*"/>
</xs:restriction>

XSD Restrictions on format
25
• The next example also defines an element called "letter" with a restriction. The acceptable value
is one or more pairs of letters, each pair consisting of a lower case letter followed by an upper
case letter:
<xs:pattern value="([a-z][A-Z])+"/>
</xs:restriction>
• The next example defines an element called "gender" with a restriction. The only acceptable value
is male OR female:
<xs:pattern value="male|female"/>
</xs:restriction>
• The next example defines an element called "password" with a restriction. There must be exactly
eight characters in a row and those characters must be lowercase or uppercase letters from a to z,
or a number from 0 to 9:
<xs:pattern value="[a-zA-Z0-9]{8}"/>
</xs:restriction>

XSD Restrictions on whitespaces
26
• This example defines an element called "address" with a restriction. The whiteSpace constraint is
set to "preserve", which means that the XML processor WILL NOT remove any white space:
<xs:whiteSpace value="preserve"/>
</xs:restriction>
• The whiteSpace constraint is set to "replace", which means that the XML processor WILL REPLACE
all white space characters (line feeds, tabs, spaces, and carriage returns) with spaces:
<xs:whiteSpace value="replace"/>
</xs:restriction>
• The whiteSpace constraint is set to "collapse", which means that the XML processor WILL
REMOVE all white space characters (line feeds, tabs, spaces, carriage returns are replaced with
spaces, leading and trailing spaces are removed, and multiple spaces are reduced to a single
space) <xs:restriction base="xs:string">
<xs:whiteSpace value=“collapse"/>
</xs:restriction>

XSD Restrictions on length
27
• To limit the length of a value in an element, we would use the length, maxLength, and minLength
constraints.
• This example defines an element called "password" with a restriction. The value must be exactly
eight characters:
<xs:length value="8"/>
</xs:restriction>
• This example defines another element called "password" with a restriction. The value must be
minimum five characters and maximum eight characters:
<xs:minLength value="5"/>
<xs:maxLength value="8"/>
</xs:restriction>
• There are also other constrain types for Datatypes like: fractionDigits, totalDigits, maxExclusive,
maxInclusive and so on.

XSD Complex element
28
• A complex element is an XML element that contains other elements and/or attributes.
• There are four kinds of complex elements:
• empty elements
• elements that contain only other elements
• elements that contain only text
• elements that contain both other elements and text
• Each of these elements may contain attributes as well.

XSD Complex element
29
• A complex XML element, "product", which is empty:
<product pid="1345"/>
• A complex XML element, "employee", which contains only other elements:
<employee>
<firstname>John</firstname>
<lastname>Smith</lastname>
</employee>
• A complex XML element, "food", which contains only text:
<food type="dessert">Ice cream</food>
• A complex XML element, "description", which contains both elements and text:
<description>
It happened on <date lang="norwegian">03.03.99</date> ....
</description>

XSD Complex element
30
• We can define a complex element in an XSD in two ways:
• The “employee” element can be declares directly by naming the element, like this:
<xs:element name="employee">
<xs:complexType>
<xs:sequence>
<xs:element name="firstname" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
• If you use the method described above, several elements can refer to the same complex type, like this:
<xs:element name="employee"
type="personinfo"/>
<xs:element name="student"
type="personinfo"/>
<xs:element name="member"
type="personinfo"/>

XSD Complex element
31
• You can also base a complex element on an existing complex element and add some elements,
like this:
<xs:element name="employee" type="fullpersoninfo"/>
<xs:complexType name="personinfo">
<xs:sequence>
</xs:sequence>
</xs:complexType>
<xs:complexType name="fullpersoninfo">
<xs:complexContent>
<xs:extension base="personinfo">
<xs:sequence>
<xs:element name="address" type="xs:string"/>
<xs:element name="city" type="xs:string"/>
<xs:element name="country" type="xs:string"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>

XSD Empty Complex element
32
• An empty XML element:
<xs:element name="product">
<xs:complexType>
<xs:complexContent>
<xs:attribute name="prodid"
type="xs:positiveInteger"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
• The "product" element above has no content at all. To define a type with no content, we must
define a type that allows elements in its content, but we do not actually declare any elements, like
this:
<product prodid="1345" />
• In the example above, we define a complex type with a complex content. The complexContent
element signals that we intend to restrict or extend the content model of a complex type, and the
restriction of integer declares one attribute but does not introduce any element content.

XSD Empty Complex element
33
• It is possible to declare the "product" element more compactly, like this:
<xs:element name="product" type="prodtype"/>
<xs:complexType name="prodtype">
<xs:attribute name="prodid" type="xs:positiveInteger"/>
</xs:complexType>
• Or you can give the complexType element a name, and let the "product" element have a type
attribute that refers to the name of the complexType (if you use this method, several elements
can refer to the same complex type):
<xs:element name="product">
<xs:complexType>
<xs:attribute name="prodid" type="xs:positiveInteger"/>
</xs:complexType>
</xs:element>

XSD Complex Types with Elements Only
34
• You can define the "person" element in a schema, like this:
• Notice the <xs:sequence> tag. It means that the elements defined ("firstname" and "lastname") must
appear in that order inside a "person" element.
• Or you can give the complexType element a name, and let the "person" element have a type attribute
that refers to the name of the complexType (if you use this method, several elements can refer to the
same complex type):
<xs:element name="person">
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>

XSD Complex Types with Text Only
35
• This type contains only simple content (text and attributes), therefore we add a simpleContent
element around the content. When using simple content, you must define an extension OR a
restriction within the simpleContent element:
• The following example declares a complexType, "shoesize". The content is defined as an integer
value, and the "shoesize" element also contains an attribute named "country":
<xs:element name="shoesize">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:integer">
<xs:attribute name="country" type="xs:string" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>

XSD Complex Types with Mixed Content
36
• The following schema declares the "letter" element that contain attributes, elements, and text:
<xs:element name="letter">
<xs:complexType mixed="true">
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="orderid" type="xs:positiveInteger"/>
<xs:element name="shipdate" type="xs:date"/>
</xs:sequence>
</xs:complexType>
</xs:element>
• We could also give the complexType element a name, and let the "letter" element have a type
attribute that refers to the name of the complexType (if you use this method, several elements
can refer to the same complex type):
<xs:element name="letter" type="lettertype"/>
<xs:complexType name="lettertype" mixed="true">
…..
…..

XSD Indicators
37
• We can control HOW elements are to be used in documents with indicators.
• There are seven indicators:
• Order indicators:
• All
• Choice
• Sequence
• Occurrence indicators:
• maxOccurs
• minOccurs
• Group indicators:
• Group name
• attributeGroup name

XSD Order Indicators
38
• Order indicators are used to define the order of the elements.
• The <all> indicator specifies that the child elements can appear in any order, and that each child
element must occur only once:
<xs:complexType>
<xs:all>
</xs:all>
</xs:complexType>
</xs:element>
• When using the <all> indicator you can set the <minOccurs> indicator to 0 or 1 and the
<maxOccurs> indicator can only be set to 1 (the <minOccurs> and <maxOccurs> are described
later).

XSD Order Indicators
39
• The <choice> indicator specifies that either one child element or another can occur:
<xs:complexType>
<xs:choice>
<xs:element name="employee" type="employee"/>
<xs:element name="member" type="member"/>
</xs:choice>
</xs:complexType>
</xs:element>
• The <sequence> indicator specifies that the child elements must appear in a specific order:
<xs:complexType>
<xs:sequence>
</xs:sequence>
</xs:complexType>
</xs:element>

XSD Occurrence Indicators
40
• Occurrence indicators are used to define how often an element can occur.
• The <maxOccurs> indicator specifies the maximum number of times an element can occur:
<xs:complexType>
<xs:sequence>
<xs:element name="full_name" type="xs:string"/>
<xs:element name="child_name" type="xs:string" maxOccurs="10"/>
</xs:sequence>
</xs:complexType>
</xs:element>
• The <minOccurs> indicator specifies the minimum number of times an element can occur:
<xs:complexType>
<xs:sequence>
<xs:element name="full_name" type="xs:string"/>
<xs:element name="child_name" type="xs:string"
maxOccurs="10" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>

XSD Group Indicators
41
• Group indicators are used to define related sets of elements.
• The following example defines a group named "persongroup", that defines a group of elements
that must occur in an exact sequence:
<xs:group name="persongroup">
<xs:sequence>
<xs:element name="birthday" type="xs:date"/>
</xs:sequence>
</xs:group>
• Attribute groups are defined with the attributeGroup declaration, like this:
<xs:attributeGroup name="groupname">
...
</xs:attributeGroup>

XSD The <any> Element
42
• The <any> element enables us to extend the XML document with elements not specified by the
schema.
• The following example is a fragment from an XML schema called "family.xsd". It shows a
declaration for the "person" element. By using the <any> element we can extend (after
<lastname>) the content of "person" with any element:
<xs:complexType>
<xs:sequence>
<xs:any minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
• The <any> and <anyAttribute> elements are used to make EXTENSIBLE documents! They allow
documents to contain additional elements that are not declared in the main XML schema.

XSD The <anyAttribute> Element
43
• The <anyAttribute> element enables us to extend the XML document with attributes not specified
by the schema.
• The following example is a fragment from an XML schema called "family.xsd". It shows a
declaration for the "person" element. By using the <anyAttribute> element we can add any
number of attributes to the "person" element
<xs:complexType>
<xs:sequence>
</xs:sequence>
<xs:anyAttribute/>
</xs:complexType>
</xs:element>

XSD String Data Types
44
• String data types are used for values that contains character strings.
• The string data type can contain characters, line feeds, carriage returns, and tab characters.
• The following is an example of a string declaration in a schema:
<xs:element name="customer" type="xs:string"/>
• An element in your document might look like this:
<customer>John Smith</customer>
• The normalizedString data type also contains characters, but the XML processor will remove line
feeds, carriage returns, and tab characters.
• The token data type also contains characters, but the XML processor will remove line feeds,
carriage returns, tabs, leading and trailing spaces, and multiple spaces.
<xs:element name="customer" type="xs:normalizedString"/>
<xs:element name="customer" type="xs:token"/>

XSD String Data Types
45
• Other data types below derive from the String data type.
• ENTITIES, ENTITY, ID, IDREF, IDREFS
• Language, Name, NCName
• NMTOKEN, NMTOKENS
• Qname
• Restrictions that can be used with String data types:
• enumeration
• length
• maxLength
• minLength
• pattern (NMTOKENS, IDREFS, and ENTITIES cannot use this constraint)
• whiteSpace

XSD Date and Time Data Types
46
• The date data type is used to specify a date.
• The date is specified in the following form "YYYY-MM-DD“.
<xs:element name="start" type="xs:date"/>
• To specify a time zone, you can either enter a date in UTC time by adding a "Z" behind the date or
you can specify an offset from the UTC time by adding a positive or negative time behind the date
• The time is specified in the following form "hh:mm:ss"
<xs:element name="start" type="xs:time"/>
• The dateTime is specified in the following form "YYYY-MM-DDThh:mm:ss“.
<xs:element name="startdate" type="xs:dateTime"/>
• The dateTime is specified in the following form "YYYY-MM-DDThh:mm:ss“.
<xs:element name="startdate" type="xs:dateTime"/>

XSD Date and Time Data Types
47
• Duration data type is used to specify a time interval in the following form "PnYnMnDTnHnMnS“
• P indicates the period (required)
• T indicates the start of a time section
<xs:element name="period" type="xs:duration"/>
• Other date and time date types used:
• gDay, gMonth, gMonthDay, gYear, gYearMonth
• Restrictions that can be used with Date data types:
• enumeration
• maxExclusive
• maxInclusive
• minExclusive
• minInclusive
• pattern
• whiteSpace

XSD Numeric Data Types
48
• The decimal data type is used to specify a numeric value (maximum of 18 digits).
<xs:element name="prize" type="xs:decimal"/>
• The integer data type is used to specify a numeric value without a fractional component.
<xs:element name="prize" type="xs:integer"/>
• Data types below derive from the Decimal data type and can be used:
• Byte
• Int
• Long
• negativeInteger, nonNegativeInteger, nonPositiveInteger, positiveInteger
• Short
• unsignedLong, unsignedInt, unsignedShort, unsignedByte
• Restrictions that can be used with Numeric data types

XSD Miscellaneous Data Types
49
• Other miscellaneous data types are boolean, base64Binary, hexBinary, float, double, anyURI,
QName, and NOTATION
• The boolean data type is used to specify a true or false value.
<xs:attribute name="disabled" type="xs:boolean"/>
• Binary data types are used to express binary-formatted data: base64Binary or hexBinary.
<xs:element name="blobsrc" type="xs:hexBinary"/>
• The anyURI data type is used to specify a URI.
• Restrictions that can be used with the other data types:
• enumeration (a Boolean data type cannot use this constraint)
• length (a Boolean data type cannot use this constraint)
• maxLength (a Boolean data type cannot use this constraint)
• minLength (a Boolean data type cannot use this constraint)
• pattern
• whiteSpace
<xs:attribute name="src" type="xs:anyURI"/>

XSD Schema – Business application
50
•One of the best applications for the XSD schemas is “Business rules”
•Define the entities upon which you write business rules
• Before you write business rules, you must first set up the model on which they rely. You define this model as a
business object model (BOM).
• For example a simple purchase order:
• Need to purchase an electric Lawnmower and a baby monitor from a merchant site
• The price for the mower is $148.95
• The price for the baby monitor is $39.98
• The billing should be done to Robert Smith with address: 8 Oak Avenue, 95819 Old Town, PA, USA
• The shipping should be done to Alice Smith with address: 123 Maple Street, 90952 Mill Valley, CA,
USA

XSD Schema – Business appliance
51
<purchaseOrder orderDate="1999-10-20">
<comment>Hurry, my lawn is going wild!</comment>
<shipTo country="US">
<name>Alice Smith</name>
<street>123 Maple Street</street>
<city>Mill Valley</city>
<state>CA</state>
<zip>90952</zip>
</shipTo>
<billTo country="US">
<name>Robert Smith</name>
<street>8 Oak Avenue</street>
<city>Old Town</city>
<state>PA</state>
<zip>95819</zip>
</billTo>
<items>
<item partNum="872-AA">
<productName>Lawnmower</productName>
<quantity>1</quantity>
<USPrice>148.95</USPrice>
<comment>Confirm this is electric</comment>
</item>
<item partNum="926-AA">
<productName>Baby Monitor</productName>
<quantity>1</quantity>
<USPrice>39.98</USPrice>
<shipDate>1999-05-21</shipDate>
</item>
</items>
</purchaseOrder>

XSD Schema – Business application
52
•Implement a physical model upon which the rules execute
• The BOM must be mapped to a physical data model. This data model is called an
execution object model (XOM)
• Every BOM element used in a rule must have a corresponding XOM implementation, but it does not have to be a simple
one-to-one mapping. You can create more complex BOM to XOM mappings, such as combining information from multiple
XOM properties into one BOM element.
• You can implement the XOM as a Java object model or as an XML schema (XSD).
• JAVA:
• Comment Class
Comment is a public interface that extends javax.xml.bind.Element.
Content in instantiations of this class binds to the XML schema element named comment.
The getValue() and setValue() methods are used to get and set strings representing XML comment elements in the Java
content tree.
• Items Class
The class provides public interfaces for Items and ItemType.
Content in instantiations of this class binds to the XML ComplexTypes Items and its child element ItemType.
Item provides the getItem() method.
ItemType provides setter and getter methods for each child object: PartNum, Comment, USPrice, ProductName, ShipDate,
Quantity

53
• PurchaseOrder Class
PurchaseOrder is a public interface that extends javax.xml.bind.Element and
PurchaseOrderType.
Content in instantiations of this class binds to the XML schema element named
purchaseOrder.
• PurchaseOrderType Class
Content in instantiations of this class binds to the XML schema child element named
PurchaseOrderType.
PurchaseOrderType is a public interface that provides setter and getter methods for each child
object: Items, OrderDate, Comment, BillTo, ShipTo
• USAddress Class
Content in instantiations of this class binds to the XML schema element named USAddress.
USAddress is a public interface that provides setter and getter methods for each child object:
State, Zip, Country, City, Street, Name

54
•XSD Schema corresponding to provided basic purchase order XML.
• The mapping of business objects to schema objects with their according restrictions
Business rule: The maximum quantity of ordered items in a simple order should be an integer value not greater
than 100.
maps to
<xsd:element name="quantity">
<xsd:simpleType>
<xsd:restriction base="xsd:positiveInteger">
<xsd:maxExclusive value="100"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
Business rule: The stock identifier for the product should contain only alphanumeric values and have a form of 3
digits – 2 upper case letters.
maps to
<xsd:simpleType name="SKU">
<xsd:restriction base="xsd:string">
<xsd:pattern value="d{3}-[A-Z]{2}"/>
</xsd:restriction>
</xsd:simpleType>

55
•XSD Schema corresponding to provided basic purchase order XML.
Business rule: The address should contain the following details: name of the recipient, street, city, state (all string
based) and zip code (a decimal value) and for USA the country should be implicitly set
maps to
<xsd:complexType name="USAddress">
<xsd:sequence>
<xsd:element name="name" type="xsd:string"/>
<xsd:element name="street" type="xsd:string"/>
<xsd:element name="city" type="xsd:string"/>
<xsd:element name="state" type="xsd:string"/>
<xsd:element name="zip" type="xsd:decimal"/>
</xsd:sequence>
<xsd:attribute name="country" type="xsd:NMTOKEN" fixed="US"/>
</xsd:complexType>

56
• The complete schema with all the elements
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="purchaseOrder" type="PurchaseOrderType"/>
<xsd:element name="comment" type="xsd:string"/>
<xsd:complexType name="PurchaseOrderType">
<xsd:sequence>
<xsd:element name="shipTo" type="USAddress"/>
<xsd:element name="billTo" type="USAddress"/>
<xsd:element ref="comment" minOccurs="0"/>
<xsd:element name="items" type="Items"/>
</xsd:sequence>
<xsd:attribute name="orderDate" type="xsd:date"/>
</xsd:complexType>
<xsd:complexType name="USAddress">
<xsd:sequence>
<xsd:element name="name" type="xsd:string"/>
<xsd:element name="street" type="xsd:string"/>
<xsd:element name="city" type="xsd:string"/>
<xsd:element name="state" type="xsd:string"/>
<xsd:element name="zip" type="xsd:decimal"/>
</xsd:sequence>
<xsd:attribute name="country" type="xsd:NMTOKEN" fixed="US"/>
</xsd:complexType>

57
<xsd:complexType name="Items">
<xsd:sequence>
<xsd:element name="item" minOccurs="1" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="productName" type="xsd:string"/>
<xsd:element name="quantity">
<xsd:simpleType>
<xsd:restriction base="xsd:positiveInteger">
<xsd:maxExclusive value="100"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
<xsd:element name="USPrice" type="xsd:decimal"/>
<xsd:element ref="comment" minOccurs="0"/>
<xsd:element name="shipDate" type="xsd:date" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="partNum" type="SKU" use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>

58

<xsd:simpleType name="SKU">
<xsd:restriction base="xsd:string">
<xsd:pattern value="d{3}-[A-Z]{2}"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>

What is a Web Service
60
• A Web Service is a method of communication between two electronic devices over the World Wide Web.
• A Web Service is a software function provided at a network address over the web or the cloud, it is a service
that is "always on“.
• A Web Service can convert your applications into Web-applications
• A Web Service is a XML-based information exchange system that use the Internet for direct application-to-
application interaction.

Web Service components
61
• The basic Web services platform is XML + HTTP.
• All the standard Web Services works using following components
• SOAP (Simple Object Access Protocol)
• UDDI (Universal Description, Discovery and Integration)
• WSDL (Web Services Description Language)

What is SOAP
62
• It is a simple XML-based protocol to let applications exchange information over HTTP.
• SOAP is a protocol for accessing a Web Service.
• SOAP stands for Simple Object Access Protocol
• SOAP is platform independent
• SOAP is language independent

SOAP Building Blocks
63
• A SOAP message is an ordinary XML document containing the following elements:
• An Envelope element that identifies the XML document as a SOAP message
• A Header element that contains header information
• A Body element that contains call and response information
• A Fault element containing errors and status information

SOAP Syntax Rules
64
• Here are some important syntax rules:
• A SOAP message MUST be encoded using XML
• A SOAP message MUST use the SOAP Envelope namespace
• A SOAP message MUST use the SOAP Encoding namespace
• A SOAP message must NOT contain a DTD reference
• A SOAP message must NOT contain XML Processing Instructions

SOAP Message example
65
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Header>
...
</soap:Header>
<soap:Body>
...
<soap:Fault>
...
</soap:Fault>
</soap:Body>
</soap:Envelope>

SOAP Envelope Element
66
• The required SOAP Envelope element is the root element of a SOAP message. This element
defines the XML document as a SOAP message:
<soap:Envelope
...
Message information goes here
...
</soap:Envelope>
• The xmlns:soap namespace in the example above it should always have the value of:
"http://www.w3.org/2001/12/soap-envelope". The namespace defines the Envelope as a SOAP
Envelope.
• The encodingStyle attribute is used to define the data types used in the document. This attribute
may appear on any SOAP element, and applies to the element's contents and all child elements.

SOAP Header Element
67
• The optional SOAP Header element contains application-specific information (like
authentication, payment, etc) about the SOAP message.
• If the Header element is present, it must be the first child element of the Envelope element.
<soap:Header>
<m:Trans xmlns:m="http://www.w3schools.com/transaction/"
soap:mustUnderstand="1">234
</m:Trans>
</soap:Header>
• The example above contains a header with a "Trans" element, a "mustUnderstand" attribute
with a value of 1, and a value of 234.
• SOAP defines three attributes in the default namespace. These attributes are: mustUnderstand,
actor, and encodingStyle.
• The attributes defined in the SOAP Header defines how a recipient should process the SOAP
message.

SOAP Header Attributes
68
• The SOAP mustUnderstand attribute can be used to indicate whether a header entry is
mandatory or optional for the recipient to process.
• If you add mustUnderstand="1" to a child element of the Header element it indicates that the
receiver processing the Header must recognize the element. If the receiver does not recognize
the element it will fail when processing the Header.
• A SOAP message may travel from a sender to a receiver by passing different endpoints along the
message path. However, not all parts of a SOAP message may be intended for the ultimate
endpoint, instead, it may be intended for one or more of the endpoints on the message path.
• The SOAP actor attribute is used to address the Header element to a specific endpoint.
• The encodingStyle attribute is used to define the data types used in the document. This attribute
may appear on any SOAP element, and it will apply to that element's contents and all child
elements.
• A SOAP message has no default encoding.

SOAP Body Element
69
• The required SOAP Body element contains the actual SOAP message intended for the ultimate
endpoint of the message.
• Immediate child elements of the SOAP Body element may be namespace-qualified.
<soap:Envelope
<soap:Body>
<m:GetPriceResponse xmlns:m="http://www.w3schools.com/prices">
<m:Price>1.90</m:Price>
</m:GetPriceResponse>
</soap:Body>
</soap:Envelope>

SOAP Fault Element
70
• The SOAP Fault element holds errors and status information for a SOAP message.
• The optional SOAP Fault element is used to indicate error messages.
• If a Fault element is present, it must appear as a child element of the Body element. A Fault
element can only appear once in a SOAP message.
• The SOAP Fault element has the following sub elements:
Sub Element Description
<faultcode> A code for identifying the fault
<faultstring> A human readable explanation of the fault
<faultactor> Information about who caused the fault to
happen
<detail> Holds application specific error information
related to the Body element

SOAP Fault Element
71
• The faultcode values defined below must be used in the faultcode element when describing
faults:
Error Description
VersionMismatch Found an invalid namespace for the SOAP
Envelope element
MustUnderstand An immediate child element of the Header
element, with the mustUnderstand attribute set
to "1", was not understood
Client The message was incorrectly formed or
contained incorrect information
Server There was a problem with the server so the
message could not proceed

SOAP Example
72
• In the example below, a GetStockPrice request is sent to a server. The request has a StockName
parameter, and a Price parameter that will be returned in the response. The namespace for the
function is defined in http://www.example.org/stock
• A SOAP Request:
<soap:Envelope
<soap:Body xmlns:m="http://www.example.org/stock">
<m:GetStockPrice>
<m:StockName>IBM</m:StockName>
</m:GetStockPrice>
</soap:Body>
</soap:Envelope>

SOAP Example
73
• A SOAP Response:
<soap:Envelope
<soap:Body xmlns:m="http://www.example.org/stock">
<m:GetStockPriceResponse>
<m:Price>34.5</m:Price>
</m:GetStockPriceResponse>
</soap:Body>
</soap:Envelope>

What is WSDL
74
• WSDL stands for Web Services Description Language
• WSDL is an XML based protocol for information exchange in decentralized and distributed
environments.
• WSDL is a language for describing how to interface with XML-based services.
• WSDL is an XML language used to describe and locate web services

WSDL Elements
75
• WSDL breaks down Web services into three specific, identifiable elements that can be combined
or reused once defined.
• Following are the elements of WSDL document. Within these elements are further sub elements
or parts:
• Definitions
• Data Types
• Message
• Operation
• Port Type
• Binding
• Port
• Service

WSDL example
76
<definitions>
<types>
definition of types........
</types>
<message>
definition of a message....
</message>
<portType>
<operation>
definition of a operation.......
</operation>
</portType>
<binding>
definition of a binding....
</binding>
<service>
definition of a service....
</service>
</definitions>

WSDL example
77
<definitions name="HelloService"
targetNamespace="http://www.examples.com/wsdl/HelloService.wsdl"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.examples.com/wsdl/HelloService.wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<message name="SayHelloRequest">
<part name="firstName" type="xsd:string"/>
</message>
<message name="SayHelloResponse">
<part name="greeting" type="xsd:string"/>
</message>
<portType name="Hello_PortType">
<operation name="sayHello">
<input message="tns:SayHelloRequest"/>
<output message="tns:SayHelloResponse"/>
</operation>
</portType>

WSDL example
78
<binding name="Hello_Binding" type="tns:Hello_PortType">
<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<soap:operation soapAction="sayHello"/>
<input>
<soap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:examples:helloservice"
use="encoded"/>
</input>
<output>
<soap:body
use="encoded"/>
</output>
</operation>
</binding>
<service name="Hello_Service">
<documentation>WSDL File for HelloService</documentation>
<port binding="tns:Hello_Binding" name="Hello_Port">
<soap:address
location="http://www.examples.com/SayHello/">
</port>
</service>
</definitions>

WSDL Definition Element
79
• The <definition> element must be the root element of all WSDL documents. It defines the name
of the web service.
• Here is the example piece of code from last session which uses definition element.
<definitions name="HelloService"
targetNamespace="http://www.examples.com/wsdl/HelloService.
wsdl"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.examples.com/wsdl/HelloService.wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
................................................
</definitions>
• The namespace specification does not require that the document actually exist at the given
location. The important point is that you specify a value that is unique, different from all other
namespaces that are defined

WSDL Types Element
80
• A Web service needs to define its inputs and outputs and how they are mapped into and out of
services. WSDL <types> element take care of defining the data types that are used by the web
service. Types are XML documents or document parts.
<types>
<schema
targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>

WSDL Message Element
81
• The <message> element describes the data being exchanged between the Web service providers
and consumers.
• Each message contains zero or more <part> parameters, one for each parameter of the Web
Service's function.
• Each <part> parameter associates with a concrete type defined in the <types> container
element.
<message name="SayHelloRequest">
<part name="firstName"
type="xsd:string"/>
</message>
<message name="SayHelloResponse">
<part name="greeting"
type="xsd:string"/>
</message>

WSDL portType Element
82
• The <portType> element combines multiple message elements to form a complete oneway or
round-trip operation.
• For example, a <portType> can combine one request and one response message into a single
request/response operation. This is most commonly used in SOAP services. A portType can
define multiple operations.
<portType name="Hello_PortType">
<input
message="tns:SayHelloRequest"/>
<output
message="tns:SayHelloResponse"/>
</operation>
</portType>

WSDL portType Element
83
• WSDL has four transmission primitives that an endpoint can support:
• One-way. The endpoint receives a message.
• Request-response. The endpoint receives a message, and sends a correlated message.
• Solicit-response. The endpoint sends a message, and receives a correlated message.
• Notification. The endpoint sends a message.

WSDL Binding Element
84
• The <binding> element provides specific details on how a portType operation will actually be
transmitted over the wire.
• The bindings can be made available via multiple transports, including HTTP GET, HTTP POST, or
SOAP.
• The bindings provide concrete information on what protocol is being used to transfer
portType operations
• The bindings provide information where the service is located.
• You can specify multiple bindings for a single portType.
• For SOAP protocol, the binding is <soap:binding>, and the transport is SOAP messages on top of
HTTP protocol.
• The binding element has two attributes - the name attribute and the type attribute.

WSDL Binding Element
85
<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<soap:operation soapAction="sayHello"/>
<input>
<soap:body
use="encoded"/>
</input>
<output>
<soap:body
use="encoded"/>
</output>
</operation>
</binding>
• Here is the piece of code from Example section:

WSDL Ports Element
86
• A <port> element defines an individual endpoint by specifying a single address for a binding.
• The port element has two attributes - the name attribute and the binding attribute.
• A port MUST NOT specify more than one address.
• A port MUST NOT specify any binding information other than address information.
<documentation>WSDL File for
HelloService</documentation>
<soap:address
</port>
</service>

WSDL Service Element
87
• The <service> element defines the ports supported by the Web service. For each of the
supported protocols, there is one port element. The service element is a collection of ports.
• The service element includes a documentation element to provide human-readable
documentation.
• The name attribute provides a unique name among all services defined within in the enclosing
WSDL document.
• Here is a piece of code from Example:
<documentation>WSDL File for
HelloService</documentation>
<soap:address
</port>
</service>

WSDL Summary
88
• WSDL is an XML format for describing network services as a set of endpoints operating on
messages containing either document-oriented or procedure-oriented information.
• A WSDL document is simply a set of definitions.
• A WSDL is composed from several elements, each one with a specific role.

What is JSON
89
• JSON stands for JavaScript Object Notation
• JSON is a text format that is completely language independent but uses conventions that are
familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl,
Python, and many others.
• JSON is smaller than XML, and faster and easier to parse.
• The following example is an array of 3 employee records (objects):
{
"employees": [
{ "firstName":"John" , "lastName":"Doe"
},
{ "firstName":"Anna" ,
"lastName":"Smith" },
{ "firstName":"Peter" ,
"lastName":"Jones" }
]
}

JSON Structure
90
• JSON is built on two structures:
• A collection of name/value pairs. In various languages, this is realized as an object, record,
struct, dictionary, hash table, keyed list, or associative array.
• An ordered list of values. In most languages, this is realized as an array, vector, list, or
sequence.
• An object is an unordered set of name/value pairs. An object begins with { (left brace) and ends
with } (right brace). Each name is followed by : (colon) and the name/value pairs are separated
by , (comma).
},

JSON Structure
91
• An array is an ordered collection of values. An array begins with [ (left bracket) and ends
with ] (right bracket). Values are separated by , (comma).
• A value can be a string in double quotes, or a number, or true or false or null, or an object or
an array. These structures can be nested.
{
"employees": [
},
{ "firstName":"Anna" ,
"lastName":"Smith" },
{ "firstName":"Peter" ,
"lastName":"Jones" }
]
}

JSON vs XML
92
• Below is a direct comparison between JSON and XML structures.
{
"employees": [
{ "firstName":"John" , "lastName":"Doe" },
{ "firstName":"Anna" , "lastName":"Smith" },
{ "firstName":"Peter" , "lastName":"Jones" }
]
}
<employees>
<firstName>John</firstName>
<lastName>Doe</lastName>
</employees>
<employees>
<firstName>Anna</firstName>
<lastName>Smith</lastName>
</employees>
<employees>
<firstName>Peter</firstName>
<lastName>Jones</lastName>
</employees>

JSON vs XML
93
• Simple corresponding conversion patterns between XML and JSON.
Patter
n
XML JSON Access
1 <tag/> "tag": null o.tag
2 <tag>text</tag> "tag": "text" o.tag
3 <tag name="value" /> "tag":{"@name": "value"}
o.tag["@name"
]
4
<tag
name="value">text</tag>
"tag": { "@name": "value",
"#text": "text" }
o.tag["@name"
] o.tag["#text"]
5
<tag> <a>text</a>
<b>text</b> </tag>
"tag": { "a": "text", "b":
"text" }
o.tag.a o.tag.b
6
<tag> <a>text</a>
<a>text</a> </tag>
"tag": { "a": ["text", "text"] }
o.tag.a[0]
o.tag.a[1]
7
<tag> text <a>text</a>
</tag>
"tag": { "#text": "text", "a":
"text" }
o.tag["#text"]
o.tag.a

What is REST
94
•Is an architecture style for designing networked applications focused on a system's
resources (including how resource states are addressed and transferred)
•REST stands for Representational State Transfer
•REST relies on a stateless, client-server, cacheable communications protocol (HTTP is
used)
•REST is platform independent
•REST is language independent

REST as Lightweight Web Services
95
•REST is a lightweight alternative to mechanisms like RPC (Remote Procedure Calls)
and Web Services (SOAP, WSDL, etc.)
•REST uses HTTP uniform interface (POST, GET, PUT, DELETE) for all four CRUD
(Create/Read/Update/Delete) operations
• E.g. GET to retrieve (read) simple information
 GET /employees/John HTTP/1.1
 Host: myserver.com
 Accept: application/xml
•A REST Web Service can be very intuitive (easy to guess, self-documenting) when
addressing resources by exposing ‘directory structure’-like URIs

96
• Examples of CRUD operations made on a RESTful API
• Create with HTTP POST
 POST /employee HTTP/1.1
 Content-Type:application/xml
<employee>
</employee>
• Read with HTTP GET
 GET /employee/John HTTP/1.1
 Content-Type: application/xml
• Output
• A new employee entry is created with
firstName = John and lastName = Doe
• Reads the employee entry
<employee>
</employee>

97
• Examples of CRUD operations made on a RESTful API
• Update over HTTP PUT
 PUT /employee/John HTTP/1.1
 Content-Type: application/xml
<employee>
<firstName>Bob</firstName>
</employee>
• Delete with HTTP DELETE
 DELETE /employee HTTP/1.1
 Content-Type:application/xml
<employee>
</employee>
• Output
• Updates the John Doe employee with
firstName to be Bob => the new entry will
be
<employee>
<firstName>Bob</firstName>
</employee>
• Deletes the John Doe employee

REST vs SOAP
98
• REST
• The RESTful Web services are completely stateless. This can be tested by restarting the server and
checking if the interactions are able to survive.
• Restful services provide a good caching infrastructure over HTTP GET method (for most servers).
This can improve the performance, if the data the Web service returns is not altered frequently
and not dynamic in nature.
• The service producer and service consumer need to have a common understanding of the context
as well as the content being passed along as there is no standard set of rules to describe the REST
Web services interface.
• REST is particularly useful for restricted-profile devices such as mobile and PDAs for which the
overhead of additional parameters like headers and other SOAP elements are less.
• REST services are easy to integrate with the existing websites and are exposed with XML so the
HTML pages can consume the same with ease. There is hardly any need to refactor the existing
website architecture. This makes developers more productive and comfortable as they will not
have to rewrite everything from scratch and just need to add on the existing functionality.
• REST-based implementation is simple compared to SOAP.

REST vs SOAP
99
•SOAP
• The Web Services Description Language (WSDL) contains and describes the common
set of rules to define the messages, bindings, operations and location of the Web
service. WSDL is a sort of formal contract to define the interface that the Web service
offers.
• SOAP requires less plumbing code than REST services design (e.g. transactions,
security, coordination, addressing, trust, etc.). Most real-world applications are not
simple and support complex operations, which require conversational state and
contextual information to be maintained. With the SOAP approach, developers need
not worry about writing this plumbing code into the application layer themselves.
• SOAP Web services (such as JAX-WS) are useful in handling asynchronous processing
and invocation.
• SOAP supports several protocols and technologies, including WSDL, XSDs, SOAP, WS-
Addressing

What is WADL
100
• WADL stands for Web Application Description Language
• WADL is a machine-readable XML description of HTTP-based (typically REST) web applications
• WADL is intended to simplify the reuse of web services that are based on the existing HTTP
architecture of the Web
• WADL is the REST equivalent of SOAP's WSDL, which can also be used to describe REST web
services
• WADL was submitted to W3 consortium for standardization but is not yet recognized, nor widely
supported
WADL

WADL Elements
101
• WSDL The service is described using a set of resource elements.
• Each resource contains param elements to describe the inputs, and method elements which
describe the request and response of a resource
• The request element specifies how to represent the input, what types are required and any
specific HTTP headers that are required
• The response describes the representation of the service's response, as well as any fault
information, to deal with errors.

WADL application element
102
•The application element forms the root of a WADL description and contains the following:
• Zero or more doc elements
• An optional grammars element
• Zero or more resources elements
• Zero or more of the following:
• resource_type elements
• method elements
• representation elements
• param elements

WADL documentation element (doc)
103
•Each WADL-defined element can have one or more child doc elements that can be used
to document that element. The doc element has the following attributes:
• xml:lang Defines the language for the title attribute value and the contents of the doc
element. If an element contains more than one doc element then they MUST have
distinct values for their xml:lang attribute.
• title A short plain text description of the element being documented, the value
SHOULD be suitable for use as a title for the contained documentation. The doc
element has mixed content and may contain text and zero or more child elements that
form the body of the documentation. It is RECOMMENDED that the child elements be
members of the text, list or table modules of XHTML

WADL grammars element
104
•The grammars element acts as a container for definitions of the format of data
exchanged during execution of the protocol described by the WADL document. Such
definitions may be included inline or by reference using the include element
•It is permissible to include multiple definitions of a particular format: such definitions are
assumed to be equivalent and consumers of a WADL description are free to choose
amongst the alternatives or even combine them if they support that capability.
• Include
• The include element allows the definitions of one or more data format descriptions to be
included by reference. The href attribute provides a URI for the referenced definitions and is of
type xsd:anyURI. Use of the include element is logically equivalent to in-lining the referenced
document within the WADL grammars element.

WADL resource element
105
•A resource element contains the following child elements:
• Zero or more doc elements
• Zero or more param elements with one of the following values for its style attribute:
• Template, Query, Matrix , Header
• Zero or more method elements
• Zero or more resource elements that describe sub-resources

WADL method element
106
•A method element describes the input to and output from an HTTP protocol method that
may be applied to a resource. A method element can either be a method definition or a
reference to a method defined elsewhere.
• Method Reference
• A method reference element is a child of a resource element that has an href attribute whose type is
xsd:anyURI. The value of the href attribute is a cross reference (see section 2.1 ) to a method definition
element. A method reference element MUST NOT have any other WADL-defined attributes or contain any
WADL-defined child elements.

WADL method element
107
• Method Definition
• A method definition element is a child of a resource or application element and has the following attributes:
• name - Indicates the HTTP method used.
• id - An identifier for the method, required for globally defined methods, not allowed on
locally embedded methods. Methods are identified by an XML ID and are referred to using
a URI reference.
It is permissible to have multiple child method elements that have the same value of the name
attribute for a given resource; such siblings represent distinct variations of the same HTTP method
and will typically have different input data.
• A method element has the following child elements:
• doc - Zero or more doc elements
• request - Describes the input to the method as a collection of parameters and an optional resource
representation
• response - Zero or more response elements that describe the possible outputs of the method

WADL Example (Yahoo News Search)
108
<application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://wadl.dev.java.net/2009/02 wadl.xsd"
xmlns:tns="urn:yahoo:yn"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:yn="urn:yahoo:yn"
xmlns:ya="urn:yahoo:api"
xmlns="http://wadl.dev.java.net/2009/02">
<grammars>
<include href="NewsSearchResponse.xsd"/>
<include href="Error.xsd"/>
</grammars>
<resources base="http://api.search.yahoo.com/NewsSearchService/V1/">
<resource path="newsSearch">
<method name="GET" id="search">
<request>
<param name="appid" type="xsd:string" style="query" required="true"/>
<param name="query" type="xsd:string" style="query" required="true"/>
<param name="type" style="query" default="all">
<option value="all"/>
<option value="any"/>
<option value="phrase"/>
</param>

WADL Example (Yahoo News Search)
109
<param name="results" style="query" type="xsd:int" default="10"/>
<param name="start" style="query" type="xsd:int" default="1"/>
<param name="sort" style="query" default="rank">
<option value="rank"/>
<option value="date"/>
</param>
<param name="language" style="query" type="xsd:string"/>
</request>
<response status="200">
<representation mediaType="application/xml" element="yn:ResultSet"/>
</response>
<response status="400">
<representation mediaType="application/xml" element="ya:Error"/>
</response>
</method>
</resource>
</resources>
</application>

Testing with SoapUI
110
• Create a SoapUI Project
• Right click on the project node and select New SoapUI Project.

Functional Testing
111
• In the New SoapUI Project dialog enter a project name (i.e. Country_info) and click OK.
• Right click on the project node and select Add WSDL.

Functional Testing
112
• The Add WSDL dialog is now open
• Enter http://webservices.oorsprong.org/websamples.countryinfo/CountryInfoService.wso?WSDL.
• Click OK.

Functional Testing
113
• Now see that the WSDL was successfully added to the
project by seeing the operations in the Web Service in
the navigatorEnter

Functional Testing
114
• Create a request from your WSDL
• Click on the plus sign next to the web service in the navigator to expand.
• Double click on the request.
• You now have to enter your data manually in the code editor as shown below. Replace “?” with “RO” (without
quotes)

Functional Testing
115
• Run a request to the Web Service
• Click on the green arrow head sign to submit the request.

Functional Testing
116
• Receive response
• On the right side of the window the response will be displayed.

Functional Testing
117
• Run an invalid request to the Web Service.
• Introduce a wrong country code (like “ZZ”).
• Click on the green arrow head sign to submit the request.
• The response of the Web Service will indicate that the country was not found.
• After seeing the result, correct the input data.

Functional Testing
118
• Create a Test Case from a request.
• In the request editor, select Add This Request to TestCase.

Functional Testing
119
• Next step:
• Adding a request to a TestCase will open the Create TestSuite dialog box. Enter a name for your TestSuite
and click OK.
• After clicking OK, you will be asked to create a TestCase. In the Create TestCase dialog, enter a name for your
TestCase and click OK.

Functional Testing
120
• Next step:
• The dialog box Add Request to TestCase will appear. Click OK.

Functional Testing
121
• Final step:
• SoapUI will now generate a TestSuite and TestCase for you while the request will be added as a TestRequest.
Below is a copy of the request that appears in the interface. A TestCase editor will also open with your new
TestRequest.
• The next step is to validate the response in your test by adding an Assertion.

Functional Testing
122
• Add an Assertion to the test:
• Now that we've created and run our first test, we are going to add a validation of the response. In SoapUI,
this is called adding an assertion.
• Examples of assertions that is possible in SoapUI are:
• Schema Compliance
• Simple Contains
• Simple Not Contains
• SOAP Faults
• Response SLA
• XPath Match
• XQuery Match
• WS Security Status
• WS-Addressing Request/Response Assertion
• Script Assertion

Functional Testing
123
• Close all windows you have open in SoapUI before starting:
• Double Click on your Test Request as shown below. This will open the request editor.
• After clicking OK, you will be asked to create a TestCase. In the Create TestCase dialog, enter a name for your
TestCase and click OK.

Functional Testing
124
• Next step:
• Select Response SLA from the Add Assertion menu.
• In the Configure Response SLA Assertion dialog box, write 500 and click OK. This will validate that the
response of the SLA is under 500.

Functional Testing
125
• Next step:
• Now that you've added the assertion, you are going to run the request to validate the response. If all
assertions are successful, the SOAP icon should turn green in three places as shown below.

Functional Testing
126
• Validate response with XPath Match:
• Select XPath Match from the Add Assertion menu.

Functional Testing
127
• Validate response with XPath Match:
• In the XPath Match Configuration press Declare button and write below “//m:CapitalCityResult”
• Click “Select from current” and you should see the word Bucharest appearing in the Expected Results field.
• Click Save

Functional Testing
128
• Final step:
• Now that you've added a new assertion, you are going to run the test again. If all assertions are successful,
the SOAP icon should turn green in three places as shown below.

Service Mocking
129
• “Service Mocking, or simulation, is the practice of creating a facsimile environment that works similar to the
environment you’re facsimileing”.
• When to use it: You should use mocks when you can’t use the real thing
• Advantages:
• You can create tests in advance.
• Teams can work in parallel.
• You can create proof of concepts or demos.
• You can isolate systems.
• You can write test for resource not accessible.
• Mock can be delivered to the customer.
• Disadvantages:
• You have to do Double work.
• Deployment constraints.
• It’s not live is it?

Service Mocking
130
• Start a new SoapUI project using the following wsdl:
http://www.webservicex.net/CurrencyConvertor.asmx?WSDL
• Click OK button.

Service Mocking
131
• Right-click on one of the SOAP interfaces and select Generate MockService.

Service Mocking
132
• In the dialog Generate Mock Service you can specify the local port/path for the service you're creating but for
the moment just click OK

Service Mocking
133
• Enter the name of your Mock Service in the Name dialog and click OK. For example: Mock convertor
• After creating the MockService, you should get a MockService with one operation and one request.
• As you can see, the Icons are Grey and inactive. This is an indication that the MockService is not yet running. We
have successfully created our first MockService.

Service Mocking
134
• Now, double click on the MockService to see the MockService editor. In the editor we can see a list of all
operations for the service, as well as a request and response log which logs all incoming requests that have
been handled by the MockService.
• Double Click on the Conversion Rate Operation to see the MockResponses we have in the MockService

Service Mocking
135
• As you can see we do only have one, Let's edit it, double click on it to open the Response Editor
• The MockResponse editor is very similar to the standard SoapUI Request editor , but instead of requests, we'll
edit responses. The Incoming Request view is still very useful; it shows the last received request to the
operation which is useful for debugging client calls, including attachments and HTTP headers.
• Edit the ConversionRateResult to be something else than the default empty value "?“. For example: 2.5

Service Mocking
136
• First we must start the MockService. Click the Start button in the MockService editor, the green arrow head ,
this will start the service on the configured port and path
• To the Top Right of the Editor you should see that it's running, and the port it's responding on. The play Button
is greyed out and if you would like to stop the MockService, just click the stop button.

Service Mocking
137
• Now in the MockResponse editor, Click the Button Create Request.
• This will prompt you to open one of the existing requests for its operation in your project.
• You will also need to give it a name.

Service Mocking
138
• When you open the request, SoapUI will automatically change its endpoint to the endpoint of the locally
running MockService instead of the endpoint that the WSDL is using. Submit the opened request by clicking the
Run Button
• As you can see the MockService returned the values we entered earlier as the response.

Service Mocking
139
• Let's continue by making the created MockResponse a bit more dynamic by changing the dispatch and
by Groovy scripting.
• First we’ll create a second MockResponse.
• Give it a Groovy Name

Service Mocking
140
• Let's write a script for the response. Click the Script tab in the Response and enter the following Groovy Script,
context.setProperty( "rate", Math.random() )
It will look like this:
• This script sets a property called rate to a random number. As you might have noticed we do not use the
property rate anywhere, so let's add it.

Service Mocking
141
• In the ConversionRateResult element enter the following: ${rate}
This is called a Property expansion and it's a very powerful feature in SoapUI. By inserting a property expansion
in any element you can then fill the element programmatically. Basically it tells SoapUI to use the current value
of property rate.
• Now that we have written a script and the random results will be inserted into the response.

Web Service Workshop - 3 days

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (18)

Similaire à Web Service Workshop - 3 days

Similaire à Web Service Workshop - 3 days (20)

Dernier

Dernier (20)

Web Service Workshop - 3 days