Service Oriented Architecture:

(Semantic) Web Services,

(Business) Process Modeling,
Software Engineering
- Lecture Notes -
Yuhong Yan
Harold Boley
Bruce Spencer
NRC-IIT Fredericton
Internet Logic

ICEC 2006 Tutorial

13 Aug 2006
 Agenda

Introduction (20 minutes)

– Service and Service oriented architecture
– XML

Web Services (30 minutes)
– Web Services as middleware

Formal Methods for Web Services Process
Modeling (30 minutes)
– Automata, Process Algebra and Petri Nets

Break

Semantic Web Services (75 minutes)
– RDF, Description Logic, OWL, RuleML, OWL-S, WSMO

Wrap-up (10 minutes)
1 ICEC 2006 Tutorial on SOA 13-Aug-06
 Introduction to Service and Service Oriented
Architecture

2 ICEC 2006 Tutorial on SOA 13-Aug-06

 Service and Service Science

Service (from IBM):

A service is a provider/client interaction that creates and
captures value.

Service sector is important in post-manufacturing countries
– 80% of economic activities in US (from National Academy of
Engineering 2003)
– 70% of the Organization for Economic Cooperation and
Development (OECD) countries

Service Science
– An new emerging discipline in business schools
– Marketing, customer relation, operations research, business,
macroeconomics

3 ICEC 2006 Tutorial on SOA 13-Aug-06

 Service Computing

The role of Computing in Services

– Facilitating the communication, storage, and processing
of information
– Decreasing the cost of customization and marketing to
small segments
– Giving the customer a broader range of selection

In this tutorial
– Automated services enabled by Internet techniques
– Communicating among services
– Composing services into a process
– Semantic-based service searching and matching

4 ICEC 2006 Tutorial on SOA 13-Aug-06

 Service Oriented Architecture (SOA)

The OASIS SOA Reference Model group defines

Service Oriented Architecture is a paradigm for
organizing and utilizing distributed capabilities that
may be under the control of different ownership
domains. It provides a uniform means to offer,
discover, interact with and use capabilities to
produce desired effects consistent with
measurable preconditions and expectations.

5 ICEC 2006 Tutorial on SOA 13-Aug-06

 Web Services

W3C Web Services Architecture:

“A Web service is a software system designed to
support interoperable machine-to-machine
interaction over a network. It has an interface
described in a machine-processable format.”

6 ICEC 2006 Tutorial on SOA 13-Aug-06

 Web Services vs. SOA

Two opinions:
– SOA typically refers to Web Services –W3C

Web service reference architecture is on the foundation of SOAP
and WSDL
– SOA is not the same as Web Services (in this tutorial too)

Web services are an instantiation of SOA with SOAP and WSDL

SOA is a concept not bound to any specific technology

What people agree
– The roles and operations in the SOA/WS triangle
– The principles of SOA/WS
– There are many ways to implement messaging and service
description language, but ought to use internet protocols

7 ICEC 2006 Tutorial on SOA 13-Aug-06

 SOA/Web Service triangle

From “Web Services Architecture W3C Working Draft”

http://www.w3.org/TR/2002/WD-ws-arch-20021114/

8 ICEC 2006 Tutorial on SOA 13-Aug-06

 SOA/WS Principles

Service Encapsulation

Service Loose coupling - Services maintain a relationship that minimizes
dependencies and only requires that they maintain an awareness of each
other

Service contract - Services adhere to a communications agreement, as
defined collectively by one or more service description documents

Service abstraction - Beyond what is described in the service contract,
services hide logic from the outside world

Service reusability - Logic is divided into services with the intention of
promoting reuse

Service composability - Collections of services can be coordinated and
assembled to form composite services

Service autonomy – Services have control over the logic they encapsulate

Service statelessness – Services minimize retaining information specific to
an activity

Service discoverability – Services are designed to be outwardly descriptive
so that they can be found and assessed via available discovery mechanism

http://en.wikipedia.org/wiki/Service-oriented_architecture
9 ICEC 2006 Tutorial on SOA 13-Aug-06
 Web Service Stack

Process BPEL4WS, WSCI, WS-CDL

Discovery UDDI

Description WSDL

XML messaging XML-RPC, SOAP, XML

Transport HTTP, SMTP, FTP, BEEP

10 ICEC 2006 Tutorial on SOA 13-Aug-06

 Extensible Markup Language

11 ICEC 2006 Tutorial on SOA 13-Aug-06

 General Advantages of XML

XML offers new general possibilities, from which

SOA can profit:

(1) Definition of self-describing data in worldwide

standardized, non-proprietary format

(2) Structured data and knowledge exchange for

enterprises in various industries

(3) Integration of information from different sources

(into uniform documents)

12 ICEC 2006 Tutorial on SOA 13-Aug-06

 Address Example: External to HTML

External Presentation:
Xaver M. Linde
Wikingerufer 7
10555 Berlin HTML tags are still
presentation-oriented
HTML Markup:
<em>Xaver M. Linde</em>
<br>
Wikingerufer 7
<br>
<strong>10555 Berlin</strong>
13 ICEC 2006 Tutorial on SOA 13-Aug-06
 Address Example: HTML to XML

HTML Markup: While not conveying

<em>Xaver M. Linde</em> any formal semantics:
<br>
Wikingerufer 7 XML tags are chosen for
<br> content-structuring needs
<strong>10555 Berlin</strong>
XML Markup:
<address>
<name>Xaver M. Linde</name>
<street>Wikingerufer 7</street>
<town>10555 Berlin</town>
</address>
14 ICEC 2006 Tutorial on SOA 13-Aug-06
 Address Example: XML to External

XML Markup:
<address>
<name>Xaver M. Linde</name>
<street>Wikingerufer 7</street>
<town>10555 Berlin</town>
</address>
XML stylesheets are,
e.g., usable to generate
External Presentations: different presentations
Xaver M. Linde Xaver M. Linde
Wikingerufer 7 Wikingerufer 7
10555 Berlin ... 10555 Berlin
15 ICEC 2006 Tutorial on SOA 13-Aug-06
 Address Example: XML to XML

XML Markup 1:
<address>
<name>Xaver M. Linde</name>
<street>Wikingerufer 7</street>
<town>10555 Berlin</town>
</address> XML stylesheets are
XML Markup 2: also usable to transform
<address> XML representations
<name>Xaver M. Linde</name>
<place>
<street>Wikingerufer 7</street>
<town>10555 Berlin</town>
</place>
</address>
16 ICEC 2006 Tutorial on SOA 13-Aug-06
 Address Example: Some Stylesheets Will
Contain Term-(Tree-)Rewriting Rules

address

name street town

N S T

address

name place

N street town

S T
17 ICEC 2006 Tutorial on SOA 13-Aug-06
 Address Example: The Element Tree

XML Markup: Prolog Term:

e <address> subelements
s
s address( substructuress
l t
e <name>Xaver M. Linde</name> r name("Xaver M. Linde"),
u
m <street>Wikingerufer 7</street> c street("Wikingerufer 7"),
e t
n
<town>10555 Berlin</town> u town("10555 Berlin")
r
t </address> e )
Node-Labeled, (Left-to-Right-)Ordered Element Tree:
tree
address

s
u
b name street town
t
r
e
e
s Xaver M. Linde Wikingerufer 7 10555 Berlin
18 ICEC 2006 Tutorial on SOA 13-Aug-06
 Address Example:
Document Type Definition and Tree (1)

Document Type Definition (DTD): Extended Backus-Naur Form (EBNF):

<!ELEMENT address (name, street, town) > address ::= name street town
<!ELEMENT name (#PCDATA) > name ::= PCDATA
<!ELEMENT street (#PCDATA) > street ::= PCDATA
<!ELEMENT town (#PCDATA) > town ::= PCDATA

Document Type Tree:

address

name street town

PCDATA PCDATA PCDATA

19 ICEC 2006 Tutorial on SOA 13-Aug-06
 Address Example:
Document Type Definition and Tree (2)
Document Type Definition (DTD):
<!ELEMENT address (name, place) >
<!ELEMENT place (street, town) >
<!ELEMENT name (#PCDATA) >
<!ELEMENT street (#PCDATA) >
<!ELEMENT town (#PCDATA) >
Document Type Tree:
address

name place

PCDATA street town

PCDATA PCDATA
20 ICEC 2006 Tutorial on SOA 13-Aug-06
 Well-Formedness and Validity

XML principles for XML principle for

a document being a document being valid
well-formed: with respect to (w.r.t.) a DTD :

Open and close all tags
Match the constraints listed

Empty tags end with /> in the DTD (or, generate

There is a unique root from DTD as linearized
element derivation tree, as shown

Elements may not overlap later)

Attribute values are quoted

< and & are only used to
Checked by
start tags and entities validators such as

Only the five predefined http://www.stg.brown.edu/
entity references are used service/xmlvalid/
21 ICEC 2006 Tutorial on SOA 13-Aug-06
 Mail-Box Example: Address Variant

XML Markup: Prolog Term:

<address> address(
<name>Xaver M. Linde</name> name("Xaver M. Linde"),
<box>2001</box> box("2001"),
<town>10555 Berlin</town> town("10555 Berlin")
</address> )
Node-Labeled, (Left-to-Right-)Ordered Element Tree:

address

name box town

Xaver M. Linde 2001 10555 Berlin

22 ICEC 2006 Tutorial on SOA 13-Aug-06
 "|"-Disjoined Street/Mail-Box Example:
Document Type Definition and Tree

Document Type Definition (DTD):

<!ELEMENT address (name, (street | box), town) >
<!ELEMENT name (#PCDATA) >
<!ELEMENT street (#PCDATA) >
<!ELEMENT box (#PCDATA) > "|": Choice
<!ELEMENT town (#PCDATA) > The above box address
and the original street
Document Type Tree: address are valid w.r.t.
address this "|"-DTD

name street box town

PCDATA PCDATA PCDATA PCDATA

23 ICEC 2006 Tutorial on SOA 13-Aug-06
 Phone & Fax Example: Address Variant

XML Markup: Prolog Term:

<address> address(
<name>Xaver M. Linde</name> name("Xaver M. Linde"),
<street>Wikingerufer 7</street> street("Wikingerufer 7"),
<town>10555 Berlin</town> town("10555 Berlin"),
<phone>030/1234567</phone> phone("030/1234567"),
<phone>030/1234568</phone> phone("030/1234568"),
<fax>030/1234569</fax> fax("030/1234569")
</address> )
Node-Labeled, (Left-to-Right-)Ordered Element Tree:
address

name street town phone phone fax

Xaver M. Linde Wikingerufer 7 10555 Berlin 030/1234567 030/1234568 030/1234569

24 ICEC 2006 Tutorial on SOA 13-Aug-06
 "+"/"*"-Repetitive-Phone & -Fax Example:
Document Type Definition and Tree
Document Type Definition (DTD):
<!ELEMENT address (name, street, town, phone+, fax*) >
<!ELEMENT name (#PCDATA) >
<!ELEMENT street (#PCDATA) > "+"/"*": One/Zero or More
<!ELEMENT town (#PCDATA) > The above two-phone/one-fax
<!ELEMENT phone (#PCDATA) > address is valid w.r.t. this
<!ELEMENT fax (#PCDATA) >
"+"/"*"-DTD but the
Document Type Tree: original no-phone/no-fax
address address is not (≥1 phone!)

name street town phone fax

PCDATA PCDATA PCDATA PCDATA PCDATA

25 ICEC 2006 Tutorial on SOA 13-Aug-06
 Country Example: Address Variant

XML Markup: Prolog Term:

<address> address(
<name>Xaver M. Linde</name> name("Xaver M. Linde"),
<street>Wikingerufer 7</street> street("Wikingerufer 7"),
<town>10555 Berlin</town> town("10555 Berlin"),
<country>Germany</country> country("Germany")
</address> )

Node-Labeled, (Left-to-Right-)Ordered Element Tree:

address

name street town country

Xaver M. Linde Wikingerufer 7 10555 Berlin Germany

26 ICEC 2006 Tutorial on SOA 13-Aug-06
 "?"-Optional-Country Example:
Document Type Definition and Tree

Document Type Definition (DTD):

<!ELEMENT address (name, street, town, country?) >
<!ELEMENT name (#PCDATA) >
<!ELEMENT street (#PCDATA) > "?": One or Zero
<!ELEMENT town (#PCDATA) > The above country
<!ELEMENT country (#PCDATA) > address and the
original countriless
Document Type Tree: address are valid w.r.t.
address this "?"-DTD

name street town country

PCDATA PCDATA PCDATA PCDATA

27 ICEC 2006 Tutorial on SOA 13-Aug-06
 Country Address: A Complete XML
Document Referring to an External DTD
XML Document (just ASCII, e.g. stored in a file):
<?xml version="1.0" standalone="no"?>
<!DOCTYPE address SYSTEM "country-address.dtd">
<address>
<name>Xaver M. Linde</name>
<street>Wikingerufer 7</street>
<town>10555 Berlin</town>
<country>Germany</country>
</address>
The XML declaration uses standalone attribute with "no" value: DTD import
The DOCument TYPE declaration names the root element address and, after
the SYSTEM keyword, refers to an external DTD "country-address.dtd"
(or, at some absolute URL, to an "http://www.test.org/country-address.dtd")
28 ICEC 2006 Tutorial on SOA 13-Aug-06
 XML Namespaces

29 ICEC 2006 Tutorial on SOA 13-Aug-06

 XML Namespaces and
Programming-Language Modules

XML namespaces are akin to namespaces,
packages, and modules in programming languages

Disambiguation of tag–and attribute–names from
different XML applications (“spaces”) through
different prefixes

A prefix is separated from the local name by a “:”,
obtaining prefix:name tags

Namespaces constitute a layer on top of XML 1.0,
since prefix:name is again a valid tag name and
namespace bindings are ignored by some tools

30 ICEC 2006 Tutorial on SOA 13-Aug-06

 Namespace Bindings

Prefixes are bound to namespace URIs by attaching

an xmlns:prefix attribute to the prefixed element or
one of its ancestors, prefix:name1 ,..., prefix:namen

The value of the xmlns:prefix attribute is a URI,
which may or (unlike for DTDs!) may not point to a
description of the namespace’s syntax

An element can use bindings for multiple name-
spaces via attributes xmlns:prefix1 ,..., xmlns:prefixm

31 ICEC 2006 Tutorial on SOA 13-Aug-06

 Namespaceless Example:
Address Variant
Namespaceless XML Markup:
<address>
<name>Xaver M. Linde</name>
<street>Wikingerufer 7</street>
<town>10555 Berlin</town>
<bill>12.50</bill> bill is ambiguous
<phone>030/1234567</phone> tag (name clash
<phone>030/1234568</phone>
from two XML
<fax>030/1234569</fax>
<bill>76.20</bill> applications)
</ address>

32 ICEC 2006 Tutorial on SOA 13-Aug-06

 Two-Namespace Example:
Snail-Mail and Telecoms Address Parts
Namespace XML Markup:
<mail:address xmlns:mail="http://www.deutschepost.de/"
xmlns:tele="http://www.telekom.de/">
<mail:name>Xaver M. Linde</mail:name>
<mail:street>Wikingerufer 7</mail:street>
<mail:town>10555 Berlin</mail:town>
<mail:bill>12.50</mail:bill>
<tele:phone>030/1234567</tele:phone> bill disambiguation
<tele:phone>030/1234568</tele:phone> through mail and
<tele:fax>030/1234569</tele:fax> tele prefixes
<tele:bill>76.20</tele:bill>
</ mail:address>
• The root element, mail:address, as well as the children mail:name, mail:street,
mail:town, and mail:bill, use the mail prefix, bound to a deutschepost URI
• The tele:phone, tele:fax, and tele:bill children use the tele prefix, bound to a telekom
URI
33 ICEC 2006 Tutorial on SOA 13-Aug-06