1. Web Service Ahmed Gamal Ahmed Nile University Bioinformatics Group
Web Service Over View
Web Service
Note Test
Ahmed Gamal Ahmed
Nile University
Bioinformatics Group

2. Web Service Over View
Agenda
Web Service Over View
SOAP
WSDL
UDDI

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

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

5. Web Service Over View Basic Architecture
The basic architecture includes Web services technologies capable of:
Exchanging messages
Describing Web services
Publishing and discovering Web service descriptions

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

7. Web Service Over View Web Service Over View
For example, XML messages compliant with the SOAP specification are exchanged between the requester and provider. The provider publishes a WSDL file that contains a description of the message and endpoint information to allow the requester to generate the SOAP message and send it to the correct destination.

8. It exists to be invoked by or to interact with a service requestor.
Web Service Over View
Web Service Over View
Components
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.

9. Web Service Over View Components 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.

10. Web Service Over View Roles 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.

11. Web Service Over View Roles 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.

12. Web Service Over View Roles 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.
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. For statically bound service requestors, the service discovery agent is in fact an optional role in the architecture, as a service provider can send the description directly to service requestors. Likewise, service requestors can obtain a service description from other sources besides a service registry, such as a local filesystem, FTP site, URL, or WSIL document

13. Web Service Over View Operations 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.

14. Web Service Over View Operations 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:
At design time in order to retrieve the service's interface description for program development
At runtime in order to retrieve the service's binding and location description for invocation.

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

16. Web Service Over View Web Service Over View
For example, XML messages compliant with the SOAP specification are exchanged between the requester and provider. The provider publishes a WSDL file that contains a description of the message and endpoint information to allow the requester to generate the SOAP message and send it to the correct destination.

17. XML—The Backbone of Web Services
Web Service Over View
XML—The Backbone of Web Services

18. XML—The Backbone of Web Services
Web Service Over View
XML—The Backbone of Web Services

19. XML—The Backbone of Web Services
Web Service Over View
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).

20. XML—The Backbone of Web Services
Web Service Over View
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.

21. XML—The Backbone of Web Services
Web Service Over View
XML—The Backbone of Web Services
This XML carries HTML table information:
This XML carries information about a table (a piece of furniture):

22. XML—The Backbone of Web Services
Web Service Over View
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.

23. XML—The Backbone of Web Services
Web Service Over View
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".

24. XML—The Backbone of Web Services
Web Service Over View
XML—The Backbone of Web Services
The namespace URI is NOT used by the parser to look up information.

25. Web Service Over View
Web Service Stack

26. Basic Web Service Usage Scenario
Web Service Over View
Basic Web Service Usage Scenario

27. Web Services Implementation
Web Service Over View
Web Services Implementation
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

28. SOAP – Simple Object Access Protocol
Web Service Over View
SOAP – Simple Object Access Protocol
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 defines the protocol by which web services can be invoked. It supports both
simple messaging (as in message queuing approaches) and RPC-style
communication. It can be used over any transport protocol layer (such as HTTP,
SMTP). SOAP defines the basic structure of messages and encoding rules for data
types (used as parameters in procedure/method calls) and the encoding of procedure
calls and responses. SOAP also defines bindings to specific transport protocols most
notably to HTTP and SMTP.
SOAP is designed to also allow the implementation of advanced message
processing models, in particular the use of intermediaries. Intermediaries both can
just route messages, based on the content of the message, or do some additional
processing before routing the message.

29. SOAP – Simple Object Access Protocol SOAP Messages
Web Service Over View
SOAP – Simple Object Access Protocol SOAP Messages
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
– processed by recipient only
The basic structure of a SOAP message consists of a header and a body, both of which the
contents are application specific, i.e. not defined by SOAP. The differentiation is made to
distinguish information that is to be processed by all intermediaries (Header) and
information that is to be processed at the final destination (Body).

30. SOAP – Simple Object Access Protocol Example: SOAP Message
Web Service Over View
SOAP – Simple Object Access Protocol Example: SOAP Message
We highlight some specificities of the SOAP message model for this example. The
envelope is the mandatory top-level element of any SOAP message.
The header relates to information on authentication, transaction management,
payment etc. needed for processing the message and during transport. Elements in
the header contain SOAP-specific attributes (recognizable as belonging to the env
namespace) which are used to determine which type of processing is expected by
intermediaries and endpoints. This example shows of how the header is used in
order transmit certain transactional properties that are required for the service
invocation.
The body contains the request, which consists of a travel itinerary in this case. That
is, this message is not corresponding to a method invocation but to a simple
message transfer.

31. SOAP – Simple Object Access Protocol Protocol Binding
Web Service Over View
SOAP – Simple Object Access Protocol Protocol Binding
Bindings to different protocols possible: HTTP, SMTP
Different HTTP bindings: HTTP POST, HTTP GET
– standard HTPP POST for request-response
SOAP also standardizes the binding of SOAP messages to specific transport protocols, in
particular to HTTP. Essentially it prescribes of how the transport protocols are to be used to
perform SOAP message exchanges. A possible way of how such a binding looks like for
HTTP is given in the example. Specifically this type of binding requires the use of HTTP
POST to transmit a request and to use the corresponding HTTP response to transmit the
response associated with the request.

32. WSDL – Web Service Description Language
Web Service Over View
WSDL – Web Service Description Language
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 describes web services in terms of the services offered and the endpoints
that offer the services. Using the WSDL specification of a web service a client is
able to construct the necessary SOAP messages in order to access the service, to
send the message to the required network location, as well as to correctly interpret
the responses.
WSDL distinguishes the abstract and concrete specification of a service. The
abstract part specifies the type of data used in the parameters, the types of messages
exchanged during an operation, and the operations themselves, which might require
the exchange of multiple messages. Since a Web service might consists of a set of
operations supported (e.g. a travel reservation service might offer operations to
check itineraries, book flights and payment) multiple operations can be bundled in
so-called portTypes.
The concrete specification of the service concerns the transport protocol used and
the necessary binding (e.g. to SOAP) and the network addresses where the service is
offered (called ports). Again the same service may be offered at multiple physical
sites, therefore a set of ports can be specified to define the service.
This organization is also reflected in the structure of a WSDL document. The
vertical arrows in the figure correspond to references made within a WSDL
document through a "name" attribute (thus they are "refersTo" relationship) whereas
the horizontal arrows correspond to sub-element relationships in the WSDL
document.

33. Web Service Over View
WSDL – Web Service Description Language Overview of Defining WSDL Services
Define in XML Schema the message types used when invoking the service: MT1, MT2 etc.
Define (named) messages by using these types, e.g.
message m1 has type MT1
message m2 has type MT2 etc.
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
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
Service S is provided with binding B at the following URI's (called ports)

34. Web Service Over View
WSDL – Web Service Description Language Example: Overall Document Structure
This is an overview of the syntactical representation of a service in WSDL. For each of the
main parts (data, messages, portTypes, Service) a separate top element is used (outer boxes).
Within this subelements represent collections of specifications, such as the set of operations
belonging to a portType. These are indicated by the inner boxes.

35. WSDL – Web Service Description Language Example: Definition of Types
Web Service Over View
WSDL – Web Service Description Language Example: Definition of Types
This example shows the type definition of a WSDL specification. The types are
defined using the XML Schema language. In this example two data types are
defined as complex types. XML document (fragments) corresponding to these types
will be used as parameters of the web service.

36. Web Service Over View
WSDL – Web Service Description Language Example: Definition of Messages and PortType
This (fragment of a) WSDL specification refers to the type definitions before. Two
messages are defined. The part elements of a message allow to associate with the
message one or more types that have been defined before in the type specification.
Each part obtains an individual name and refers to a type.
A portType consists of one or more operations. Each operation requires two
messages, one for the request (input) and one for the response. The messages are
referred to by their names.
This example illustrates of how a WSDL definition can be decomposed into
multiple documents: the type definitions from the previous slides are imported into
the document using the import element (rather directly inlined into the document,
which also would be possible).
Note that all element and attribute names in this example are WSDL-specific, i.e.
defined in the WSDL schema (which is given as an XML Schema)

37. Web Service Over View
WSDL – Web Service Description Language Example: Definition of Binding and Service
This WSDL specification completes the example. It refers to the specification on the
previous slide. In the binding element it binds the port type GetLastTradePrice
(which is the abstract service) to a concrete protocol, namely the SOAP protocol and
thus defines the message format. In the service part the binding StockQuoteBinding
(which is the abstract service definition together with a concrete transport protocol)
is bound to a specific access point, given as URL, resulting in a port. This single
port then constitutes the concrete service.
We do not detail the rules of how the binding between the abstract operation
specification and its corresponding SOAP operations is established. Essentially
using the syntax given above the input/output messages are mapped to SOAP
request/response messages, and the SOAP message body is derived from the XML
types associated with the messages in the abstract specification.

38. WSDL – Web Service Description Language PortTypes
Web Service Over View
WSDL – Web Service Description Language PortTypes
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 foresees four different types of operations, corresponding to different message
exchange patterns. These patterns are considered as being the most frequently used in
practice. These different patterns are distinguished in the specification of the operation by
the different use of the input/output elements, as illustrated in the example.

39. UDDI – Universal Description Discovery and Integration
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

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