Scribd
Upload
9 views

Lesson 8 It Sia01

as

Uploaded by

Joey De la Cruz
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
9 views

Lesson 8 It Sia01

as

Uploaded by

Joey De la Cruz
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 34

Lesson 8

SERVICE-ORIENTED
ARCHITECTURE AND
WEB SERVICES
LESSON OBJECTIVES

AT THE END OF THE LESSON,


THE STUDENTS MUST BE ABLE
TO

1. DEFINE SERVICE-ORIENTED
ARCHITECTURE AND WEB
SERVICES;
2. KNOW THE DIFFERENT KINDS
OF WEB SERVICES AND
APPLICATIONS.
3

SERVICE ORIENTED
ARCHITECTURE

• SOA is a design pattern for


creating software applications that
make use of services offered
through a network, such as the
internet.
LEVELS OF FLEXIBILITY OF 4

SOA
1. Services are implementation-
independent software
components having well defined
interfaces.
2. Services are self-contained (they
execute specific activities) and
loosely linked (for independence)
3. Services can be found in real
time.
4. Aggregates of different services
5
SOA’S FIND-BIND-EXECUTE
PARADIGM
6

SUPPORTING INTERACTIONS
• Human to Human
Interactions
• Human to Machine
(Applications) Interactions,
• Machine (Application) to
Machine Interactions.
CONSTRUCTS NECESSARY TO 7

SUPPORT INTERACTIONS
Different things are necessary to support
interactions such as:

1. Language (English, ASP.Net, Java)


2. Vocabulary (Meaning of words,
meaning of code).
3. Context (Conversation context).
4. Medium (Communication channel,
ability to speak, and ability to listen).
5. Situation awareness (Recognizing
where you are, role of the person).
NEW FRONTIER: SERVICE COMPUTING 8
9

WEB SERVICES
• Application-to-application
communication is supported
through web services. It allows
for integration that is "loosely
linked." It reduces the amount
of time and effort needed to
create interconnected apps.
10

THREE MAIN PARTS OF WEB SERVICES


1.Data is presented and shared using XML
2.Applications find services and share information
and data across diverse systems environments
using shared, open, emerging technology
standards – SOAP, UDDI, WSDI, etc.
3.How communications take place over a common
network (the Internet) using HTTP protocol as
the transport.
11

THREE BASIC PARTICIPANTS

1.Service provider – develops an


application and converts into a service.
2.Service registry
3.Service requestor – Needs a service for
specific tasks/purpose.
12

THREE BASIC OPERATIONS

1. Publishing services
2. Discovering services
3. Binding services
13

KEY WEB SERVICE STANDARDS


1. SOAP – Simple Object Access Protocol
a. Submitted to W3C in 2000
b. SOAP 1.1 became standard in July 2003
c. SOAP 1.2 became standard in April 2007 (current)
d. XML-based messaging format established a transmission
framework for inter-application (or inter-service) communication
via HTTP
e. SOAP specification is vendor neutral technology; therefore, it
was an attractive alternative to proprietary protocols such as
COBRA and DCOM
14

KEY WEB SERVICE STANDARDS


2. WSDL – Web Service Description Language
a. XML-based language for describing the interface of
web services
b. WSDL 1.1 became standard in March 2001
c. WSDL 2.0 became standard in June 2007 (current)
15

KEY WEB SERVICE STANDARDS


3. UDDI – Universal Description, Discovery and
Implementation (UDDI)
a. Mechanism for the dynamic discovery of
service descriptions
b. UDDI 2 became standard in April 2003
c. UDDI 3 became standard in February 2005
(current)
16

RELATIONSHIP BETWEEN KEY WEB


SERVICES STANDARDS
1. Use UDDI to search for services. Use SOAP to access
UDDI. Search using key words
2. Download WSDL document from UDDI for selected
service
3. Use URI information from WSDL document to invoke the
service using SOAP
4. After the services accepts the request, then the
application and the service can exchange data using SOAP.
17
Relationship between key Web Services Standards
CLIENT SERVER AND PEER-TO-PEER 18

ARCHITECTURE
WEB-BASED APPLICATION 19

DEVELOPMENT ARCHITECTURE
20

APPLICATION INTEGRATION
21
APPLICATION INTEGRATION AS
SERVICES
A LOGICAL REPRESENTATION OF A WEB
22

SERVICE BASED ON INTEGRATION


WSDL DOCUMENTS REPRESENTING
23

WEB SERVICES TO APPLICATIONS


24
WEB SERVICE DESCRIPTION LANGUAGE
(WSDL)
25

1. Abstract – the description of a web service


interface, independent of implementation
details.
2. Concrete – specifies location and
implementation information about a web
service. Concrete interface definition is made
up of binding, endpoint, and service elements.
26
WSDL DEFINITION ELEMENTS –
ABSTRACT INTERFACE DEFINITION
1.Interface – contain a group of logically
related operations
2. Operations – represents a single action or
function performed by an application (i.e.,
method in an application).
3. Message element can contain one or more
input or output parameter that belong to an
operation.
27
WSDL DEFINITION ELEMENTS –
CONCRETE (IMPLEMENTATION)
DEFINITION
1. Service – represents one or more endpoints at
which the web service can be accessed.
2. Endpoint – consist of location (URI) and
protocol information
3. Binding – defines invocation requirements of
each of its operation. Associate’s protocol and
message format information to operations.
28

SOAP MESSAGE STRUCTURE


The root Envelope element frames the message document consist of a
mandatory Body element and an optional Header element.
Header element is used for
a. Including implementation of SOAP extensions (advanced web service
standards)
b. Identification of target SOAP intermediaries
c. Processing information for SOAP intermediaries
d. Providing supplementary Meta information about the SOAP message.

Within the Body element, data being delivered by the SOAP message is
included. Fault element can be used host exception information. Embedded
within Body element.
29

EXAMPLE SOAP DOCUMENT


30

UNIVERSAL DESCRIPTION, DISCOVERY,


AND IMPLEMENTATION (UDDI)

• Fundamental of SOA is a mechanism for


service descriptions to be discovered by
potential requestors. UDDI is a central
directory that hosts service descriptions
(including WSDL).
31

UDDI REGISTRY ELEMENTS


1. Business Entities (businessEntity element) - Provides profile
information about the registered business, including its name, a
description, and a unique identifier.

2. Business Services (businessServices element) - Records of


the actual services offered by the registered business are
nested within the businessEntity element

3. Specification Pointers (bindingTemplate element) - Provides


address linking the businessService to implementation
information. Developer can learn how and where to physical
bind to a web service.
4. Service Types (iModel element) Points
to location of service interface definitions
(WSDL), message formats, as well as
message and security protocols.

5. Business Relationships
(publisherAssertion element) Provides a
means of establishing the relationship of
the current businessEntity with another.

6. Subscriptions (subscription element)


Allows subscribers to be notified when
business entity profile information is
updated.
ACCESSING UDDI
REGISTRY
UDDI provides inquiry
and publishing APIs
allowing applications to
interface
programmatically with
a registry. Registries
are expected to provide
interface for humans as
THANK
YOU!

You might also like