Ahmed Gamal Ahmed Nile University Bioinformatics Group

architectgroundhogInternet and Web Development

Dec 4, 2013 (3 years and 8 months ago)

71 views

Ahmed Gamal Ahmed

Nile University

Bioinformatics Group

Agenda


Web Service Over View


SOAP


WSDL


UDDI


Web Service Over View


What are Web services?


a standardized way of integrating Web
-
based
applications using the
XML, SOAP, WSDL
and
UDDI

open standards over an Internet protocol backbone.



XML is used to tag the data


SOAP is used to transfer the data



WSDL is used for describing the services available


UDDI is used for listing what services are available.



Web Service Over View


Why there is a need for Web services?


Web services' distributed computing model allows
application
-
to
-
application communication.



Web services allow different applications from different
sources to communicate with each other without time
-
consuming custom coding, and because all communication
is in XML, Web services are not tied to any one operating
system or programming language.



Because of this level of application integration, Web
services have grown in popularity and are beginning to
improve business processes. In fact, some even call Web
services the next evolution of the Web.



Basic Architecture


The basic architecture includes Web services
technologies capable of:


Exchanging messages


Describing Web services


Publishing and discovering Web service descriptions


Web Service Over View


Service
-
Oriented Architecture


SOA is a specific architectural style that is concerned
with loose coupling and dynamic binding between
services. Some critically important factors at the heart
of SOA are necessary to make it work effectively.


Web Service Over View

Web Service Over View


Components

1.
The Service:


A service is a software module deployed on
network accessible platforms provided by the
service provider.


It exists to be invoked by or to interact with a
service requestor.


It may also function as a requestor, using other
web services in its implementation.


Web Service Over View


Components

2.
The Service Description:


The service description contains the details of the
interface and implementation of the service.


This includes its data types, operations, binding
information, and network location.


It could also include categorization and other meta
data to facilitate discovery and utilization by
requestors.



The service description may be published to a
requestor directly or to a discovery agency.


Web Service Over View


Roles

1.
Service Provider:



From a business perspective, this is the owner of the
service.



From an architectural perspective, this is the platform
that hosts access to the service.



It has also been referred to as a service execution
environment or a service container.



Its role in the client
-
server message exchange patterns
is that of a server.


Web Service Over View


Roles

2.
Service Requestor:


From a business perspective, this is the business that
requires certain function to be satisfied.



From an architectural perspective, this is the
application that is looking for and invoking or
initiating an interaction with a service.



The requestor role can be played by a browser driven
by a person or a program without a user interface,
e.g. another web service.


Its role in the client
-
server message exchange patters
is that of a client.


Web Service Over View


Roles

2.
Discovery Agency:


This is a searchable set of service descriptions where
service providers publish their service descriptions.


The service discovery agency can be centralized or
distributed.


A discovery agency can support both the pattern where it
has descriptions sent to it and where the agency actively
inspects public providers for descriptions.


Service requestors may find services and obtain binding
information (in the service descriptions) during
development for static binding, or during execution for
dynamic binding.

Web Service Over View


Operations

1.
Publish:


In order to be accessible, a service needs to publish
its description such that the requestor can
subsequently find it.


Where it is published can vary depending upon the
requirements of the application.

Web Service Over View


Operations

2.
Find:


The service requestor retrieves a service description
directly or queries the registry for the type of service
required .


The find operation may be involved in two different
lifecycle phases for the service requestor:

i.
At design time in order to retrieve the service's
interface description for program development

ii.
At runtime in order to retrieve the service's binding
and location description for invocation.

Web Service Over View


Operations


Interact: Eventually, a service needs to be invoked. In
the interact operation the service requestor invokes or
initiates an interaction with the service at runtime
using the binding details in the service description to
locate, contact, and invoke the service. Examples of
the interaction include: single message one way,
broadcast from requester to many services, a multi
message conversation, or a business process. Any of
these types of interactions can be synchronous or
asynchronous.

Web Service Over View

Web Service Over View


XML

The Backbone of Web Services


XML

The Backbone of Web Services


XML

The Backbone of Web Services


The XML markup, in much the same way as HTML, is
in the form of tags(e.g., <tag>, <name>, <price>,
<wife>, and so forth).




XML

The Backbone of Web Services


XML namespaces


Name Conflicts


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.


XML

The Backbone of Web Services


This XML carries HTML table information:






This XML carries information about a table (a piece of
furniture):




XML

The Backbone of Web Services


Solving the Name Conflict Using a Prefix


Name conflicts in XML can easily be avoided using a
name prefix.



XML

The Backbone of Web Services


XML Namespaces
-

The
xmlns

Attribute


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
".



XML

The Backbone of Web Services











The namespace URI is
NOT

used by the parser to look up
information.








Web Service Stack








Basic Web Service Usage Scenario











Application Server (web service
-
enabled)




provides implementation of services and exposes it through WSDL/SOAP




implementation in Java, as EJB, as .NET (C#) etc.



SOAP server




implements the SOAP protocol



HTTP server




standard Web server



SOAP client




implements the SOAP protocol on the client site

Web Services Implementation


SOAP consists of



Envelope construct: defines the overall structure of messages



Encoding rules: define the serialization of application data types



SOAP RPC: defines representation of remote procedure calls
and responses



Binding framework: binding to protocols such as HTTP, SMTP



Fault handling



Soap supports advanced message processing:



forwarding intermediaries: route messages based on the semantics of
message



active intermediaries: do additional processing before forwarding
messages, may modify message

SOAP


Simple Object Access Protocol


SOAP messages consist of



Envelope: top element of XML message (required)



Header: general information on message such as security (optional)



Body: data exchanged (required)



Header



elements are application
-
specific



may be processed and changed by


intermediaries or recipient


Body



elements are application
-
specific



processed by recipient only

SOAP


Simple Object Access Protocol

SOAP Messages

SOAP


Simple Object Access Protocol

Example: SOAP Message



Bindings to different protocols possible: HTTP, SMTP


Different HTTP bindings: HTTP POST, HTTP GET





standard HTPP POST for request
-
response

SOAP


Simple Object Access Protocol

Protocol Binding



Description of Web services in XML format



abstract description of operations and their parameters (messages)



binding to a concrete network protocol (e.g. SOAP)



specification of endpoints for accessing the service


Structure of a WSDL document


WSDL


Web Service Description Language

1.
Define in XML Schema the message types used when invoking the
service: MT1, MT2 etc.

2.

Define (named) messages by using these types, e.g.


message m1 has type MT1


message m2 has type MT2 etc.

3.

Define Services that consist of one or more operations; each
operation is implemented by the exchange of messages


service S offers operation O1; for executing O1 first send a request
message m1, then a response message m2 is returned

4.
Define a Binding B to a specific protocol, e.g. SOAP


service S is implemented in SOAP; the SOAP messages are
constructed from the abstract messages m1 and m2 by, e.g.
inlining

the message as body of SOAP messages

5.
Service S is provided with binding B at the following URI's (called
ports)


WSDL


Web Service Description Language


Overview of Defining WSDL Services




WSDL


Web Service Description Language


Example: Overall Document Structure




WSDL


Web Service Description Language


Example: Definition of Types




WSDL


Web Service Description Language


Example: Definition of Messages and
PortType




WSDL


Web Service Description Language


Example: Definition of Binding and Service


WSDL supports 4 message patterns that an endpoint (=service provider!) can
support for an operation


one
-
way: message is sent to service provider without expecting response



request
-
response: request is sent to service provider expecting response


solicit
-
response: provider sends a message and expects response


notification: message is sent by service provider


Message patterns are distinguished by the use of input/output elements



one way:




request/response:


WSDL


Web Service Description Language

PortTypes


Universal Description and Discovery and Integration


UDDI consists of


A specification for how to build a registry of business,
services and how to connect to them


A standards committee that is working on revising and
improving the specification


Agreement to operate solutions that conform to the
specification



UDDI


Universal Description Discovery and
Integration


UDDI Business Registry consist of


White pages


general information regarding business


Yellow pages


arranged by geography or industry code


Green pages


list protocols supported by each business


Information stored in XML format



UDDI


Universal Description Discovery and
Integration