Web Services Building Blocks

WEB SERVICES
BUILDING
BLOCKS
TRANSPORT PROTOCOLS FOR
WEB SERVICES
►Transportsuch as HTTP and TCP are
becoming common for SOAP traffic
►However UDP and SMTP are also used for
SOAP Messaging
►Anyway SOAP is designed to be transport
independent
TRANSPORT PROTOCOLS FOR
WEB SERVICES
►TCP – More traffic in world runs over TCP/IP
stack and this is most popular networking
stack.
Tcp code …
TcpClient tcpClient=new TcpClient();
tcpClient.Connect(txtServer.Text,55);
txtServer.Text is to access text from
txtServer textbox
NetworkStream stream=tcpClient.GetStream();
If(stream.CanWrite && stream.CanRead)
Used to make sure stream can be written

over and read from
Byte[] buffer=Encoding.ASCII.GetBytes(txtWords.txt);
stream.Write(buffer,0,buffer.Length);
TcpListener listener=new TcpListener(55);
listener.Start();
TcpClient client=listener.AcceptTcpClient();
Tcp code …
udp code…
IPAddress multicastAddress=IPAddress.Parse(“244.0.0.1”);
UdpClient client=new UdpClient(555);
Client.JoinMulticastGroup(multicastAddress,100);
while(true){
IPEndPoint endpoint=null;
Byte[] buffer=client.Receive(ref,endpoint);
String message=Encoding.ASCII.GetString(buffer);
MessageBox.Show(message);
}
Client.DropMulticastgroup(multicastAddress);
IPAddress multicastAddress=IPAddress.Parse(“244.0.0.1”);
IPEndPoint m_RemoteEP=new IPEndPoint(multicastAddress,555);
UdpClient client=new UdpClient(555);
Client.JoinMulticastGroup(multicastAddress,100);
Byte[] buffer=new Byte[txtWords,Text.ength+1);

int length=Encoding.ASCII.GetBytes(txtWords.Text.ToCharArray(),0, txtWords.Text.Length,buffer,0);
client.Send(buffer,length,m_RemoteEP);
►SOAP in Email – SMTP
►HTTP – On top of TCP/IP the most popular
transport protocol in the world HTTP which
is connection oriented protocol that is based
on request and response messages
►This is a request
GET/CRWeb/CRService.html HTTP/1.1
►This is a reponse for the request we used
HTTP/1.1 200 OK
Content-Type:text/xml; charset=utf-8
Content-Length:nnn
<HTML>
<BODY>
This is an HTML Page
</BODY>
</HTML>
MESSAGING WITH WEB
SERVICES - PROTOCOLS - SOAP
► SOAP's place in the web services technology stack
is as a standardized packaging protocol for
the messages shared by applications. The
specification defines nothing more than a simple
XML-based envelope for the information being
transferred, and a set of rules for translating
application and platform-specific data types into
XML representations. SOAP's design makes
it suitable for a wide variety of application
messaging and integration patterns. This, for the
most part, contributes to its growing popularity.
MESSAGING WITH WEB
SOAP ENVELOPE
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://w
ww.w3.org/2001/12/s
oap-envelope"
soap:encodingStyle="h
ttp://www.w3.org/200
1/12/soap-encoding">
... Message information
goes here ...
</soap:Envelope>
MESSAGING WITH WEB
SOAP HEADER SOAP BODY
<?xml version="1.0"?> <?xml version="1.0"?>
<soap:Envelope <soap:Envelope
xmlns:soap="http://www.w3.org/ xmlns:soap="http://www.
2001/12/soap-envelope" w3.org/2001/12/soap-
soap:encodingStyle="http://www. envelope"
w3.org/2001/12/soap-encoding"> soap:encodingStyle="http:/
<soap:Header> /www.w3.org/2001/12/soa
<m:Trans p-encoding">
xmlns:m="http://www.w3schools <soap:Body>
.com/transaction/" <m:GetPrice
soap:mustUnderstand="1">234 xmlns:m="http://www.w3s
</m:Trans> chools.com/prices">
</soap:Header>... <m:Item>Apples</m:Item>
</soap:Envelope> </m:GetPrice>
</soap:Body>
</soap:Envelope>
MESSAGING WITH WEB
SOAP RESPONSE
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-
envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-
encoding">
<soap:Body>
<m:GetPriceResponse
xmlns:m="http://www.w3schools.com/prices">
<m:Price>1.90</m:Price>
</m:GetPriceResponse>
</soap:Body>
</soap:Envelope>
MESSAGING WITH WEB
SOAP FAULT
DESCRIBING WEB SERVICES –
WSDL
The SOAP specification does not address description. The de facto standard specification
used to make web services self-describing is the Web Services Description Language
(WSDL). Using WSDL, a web service can describe everything about what it does, how it
does it, and how consumers of that web service can go about using it.
There are several advantages to using WSDL:
1. WSDL makes it easier to write and maintain services by providing a more structured
approach to defining web service interfaces.
2. WSDL makes it easier to consume web services by reducing the amount of code (and
potential errors) that a client application must implement.
3. WSDL makes it easier to implement changes that will be less likely to "break" SOAP
client applications. Dynamic discovery of WSDL descriptions allows such changes to
be pushed down automatically to clients using WSDL so that potentially expensive
modifications to the client code don't have to be made every time a change occurs.
ANATOMY OF WSDL
ANATOMY OF WSDL
It does so by defining four types of things:
Data
Messages
Interfaces
Services.
► A service (HelloWorldService in our example) is a collection of ports (addresses
► implementing the service; see HelloWorldPort in the example).
► A port has both an abstract definition (the port type) and a concrete definition
(the binding).
► Port types function as the specification of the software interface
(HelloWorldInterface in this example), and are composed of collections of
operations (the individual method signatures) that define the ordered
exchanges of messages (sayHello_IN and sayHello_OUT in the example).
► Bindings say which protocols are used by the port, including the packaging
protocol (SOAP in this case). A message is a logical collection of named parts
(data values) of a particular type.
► The type of part is defined using some standard data typing mechanism such
as the XML Schema specification.
ANATOMY OF WSDL [ example
WSDL with embedded schema ]
<?xml version="1.0" encoding="UTF-8"?> <xsd:pattern value="\d{3}"/>
<wsdl:definitions name="HelloWorldDescription" restriction>
targetNamespace="urn:HelloWorld" </xsd:simpleType>
xmlns:tns="urn:HelloWorld" </xsd:element>
xmlns:types="urn:MyDataTypes" <xsd:element name="exchange">
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" <xsd:simpleType>
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> <xsd:restriction base="xsd:string">
<wsdl:types> <xsd:pattern value="\d{3}"/>
<xsd:schema </xsd:restriction>
xmlns:xsd="http://www.w3.org/2000/10/XMLSchema" </xsd:simpleType>
targetNamespace="urn:MyDataTypes" </xsd:element>
elementFormDefault="qualified"> <xsd:element name="number">
<xsd:complexType name="telephoneNumberEx"> <xsd:simpleType>
<xsd:complexContent> <xsd:restriction base="xsd:string">
<xsd:restriction base="telephoneNumber"> <xsd:pattern value="\d{4}"/>
<xsd:sequence> </xsd:restriction>
<xsd:element name="countryCode"> </xsd:simpleType>
<xsd:simpleType> </xsd:element>
<xsd:restriction base="xsd:string"> </xsd:sequence>
<xsd:pattern value="\d{2}"/> </xsd:restriction>
</xsd:restriction> </xsd:complexContent>
</xsd:simpleType> </xsd:complexType>
</xsd:element> </xsd:schema>
<xsd:element name="area"> </wsdl:types>
<xsd:simpleType> </wsdl:definitions>
<xsd:restriction base="xsd:string">
MANIPULATING WSDL
► Writing WSDL
Use 2001 recommendations of XML Schema
Use the <types> section
Break WSDL to several pieces
Start your design with a WSDL (auto generate code
where ever possible)
► Reading WSDL
Reading and writing can be done with API in
System.Web.Services.Description
XML Serialization
MANIPULATING WSDL
► Extending WSDL eg2
We can extend wsdl <sec:SecurityPolicy
beyond the specification xmlns:sec=http:// keith
describes and the
current state of art
ba.com/SecurityPolicie
eg1
s>
<sp:servicePolicy <sec:Encyption
xmlns:sp=http://keithb level=“128”
a.com/Policies type=“DES3”>
location=http://localhos </sec:SecurityPolicy>
t/policy
/>
WEB SERVICE POLICY
► Web services are being successfully used for interoperable solutions
across various industries. One of the key reasons for interest and
investment in Web services is that they are well-suited to enable service-
oriented systems. XML-based technologies such as SOAP, XML Schema
and WSDL provide a broadly-adopted foundation on which to build
interoperable Web services. The WS-Policy and WS-PolicyAttachment
specifications extend this foundation and offer mechanisms to represent
the capabilities and requirements of Web services as Policies.
► Web Services Policy is a machine-readable language for representing the
capabilities and requirements of a Web service. These are called 'policies'.
Web Services Policy offers mechanisms to represent consistent
combinations of capabilities and requirements, to determine the
compatibility of policies, to name and reference policies and to associate
policies with Web service metadata constructs such as service, endpoint
and operation. Web Services Policy is a simple language that has four
elements - Policy, All, ExactlyOne and PolicyReference - and one
attribute - wsp:Optional.
WEB SERVICE POLICY
Policy Expression
<Policy>
<wsap:UsingAddressing />
</Policy>
► The policy expression in the above example consists of a Policy main element and a child
element wsap:UsingAddressing. Child elements of the Policy element are policy
assertions. Contoso attaches the above policy expression to a WSDL binding description.
► The wsap:UsingAddressing element is a policy assertion. (The prefix wsap is used here
to denote the Web Services Addressing – WSDL Binding XML Namespace.) This assertion
identifies the use of Web Services Addressing information headers. A policy-aware client
can recognize this policy assertion, engage addressing automatically, and use headers
such as wsa:To and wsa:Action in SOAP Envelopes.
► It is important to understand the association between the SOAP message and policy
expression in the above example. As you can see by careful examination of the message,
there is no reference to any policy expression. Just as WSDL does not require a message
to reference WSDL constructs (such as port, binding and portType), Web Services Policy
does not require a message to reference a policy expression though the policy
expression describes the message.
DISCOVERING WEB SERVICES -
UDDI
► The UDDI project is an industry effort to define a
searchable registry of services and their
descriptions so that consumers can automatically
discover the services they need.
► UDDI has two parts: a registry of all a web
service's metadata (including a pointer to the
WSDL description of a service), and a set of WSDL
port type definitions for manipulating
and searching that registry.
ANATOMY OF UDDI
UDDI defines entities to describe
businesses and their services - I
► businessEntity
provides information, including identifiers, contact
information etc…
[white-pages information]
includes one or more businessService (service entity)
elements that represents the services it provides
specifies a categoryBag to categorize the business
[yellow-pages information]
a unique key identifies each businessEntity
businessEntity Business Key
<businessEntity businessKey=
“A687FG00-56NM-EFT1-3456-098765432124”>
<name>Acme Travel Incorporated</name>
<description xml:lang=“en”>
Acme is a world leader in online travel services
</description>
<contacts>
<contact useType=“US general”>
<personName>Acme Inc.</personName>
<phone>1 800 CALL ACME</phone>
<email useType=““>acme@acme-travel.com</email>
<address>….</address>
</contact>
</contacts>
<businessServices>
...
….
</businessServices>
<identifierBag> ...
</identifierBag>
<categoryBag> ...
<keyedReference tModelKey=
“UUID:DB77450D-9FA8-45D4-A7BC-04411D14E384”
keyName=“Electronic check-in”
keyValue=“84121801”/>
</categoryBag>
</businessEntity>
UDDI defines entities to describe
businesses and their services - II
► businessService (service entity)
includes information such as name, description.
[white-pages information]
uniquely identified by a service key
specifies a categoryBag to categorize the service
[yellow-pages information]
contains a list of bindingTemplates which in turn
contains tModelInstanceDetails encoding the technical
service information [green-pages information]
includes reference to its host with a businessKey
A simple businessService structure
Service Key
<businessService serviceKey=
“894B5100-3AAF-11D5-80DC-002035229C64”
businessKey=“D2033110-3AAF-11D5-80DC-002035229C64”>
<name>ElectronicTravelService</name>
<description xml:lang=“en”>Electronic Travel Service</description>
<bindingTemplates>
<bindingTemplate bindingKey=
“6D665B10-3AAF-11D5-80DC-002035229C64”
serviceKey=“89470B40-3AAF-11D5-80DC-002035229C64”>
<description>
SOAP-based e-checkin and flight info
</description>
<accesssPoint URLType=“http”>
http://www.acme-travel.com/travelservice
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey=“D2033110-3BGF-1KJH-234C-09873909802”>
...
</tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>
</bindingTemplates>
<categoryBag>
...
</categoryBag>
</businessService>
UDDI Information Model
Rompothong, Senivongse 03
UDDI Query
► UDDI Search API allows users to query for service providers that
provide particular service.
► A UDDI query may be for
A business entity
► Using business name, business key or business category (i.e. find_business())
A list of publisher assertions
► Using business key (i.e. find_relatedBusiness())
A business service
► Using the business key of service key and service name (i.e. find_service())
Service key of a bussiness entity
► Using a binding template (i.e. find_binding())
A set of business entities and business services adopting same tModel
► Using a tModel (i.e. find_tModel())
► After finding the requited UDDI entry, a set of API is used to get details
of those entries from UDDI
get_businessDetail(), get_serviceDetail(), get_bindingDetail(), get_tModelDetail()
UDDI and WSDL relationship
Adams, Boeyen 02
tModel
► A WSDL document is registered as a tModel into UDDI
registry
In order to describe a service in more expressive way, an
external information is referenced where the type and format of
this information should be arbitrary.
UDDI Specs. leaves the responsibility of defining such
arbitrary information types and formats to programmers.
► tModel is a UDDI construct to refer an interface
describing WSDL document.
► The tModel idea:
to better describe a service we tend to reference information
such information type or format should not be anticipated
replacing such information about a service with a unique key
provides a reference to arbitrary information types
tModels for Categorization
► Using categorization, UDDI directory can be
queried for specific type of services.
► Each classification in a taxonomical system is
registered as a tModel.
► Three standard taxonomies cited by UDDI are
North American Industry Classification System (NAICS)
taxonomy – an industry classification
The Universal Standard Products and Services Code
System (UNSPSC) taxonomy – a classification of
products and services
The International Organization for Standardization
Geographic taxonomy (ISO 3166)
A simplified tModel definition
<tModel tModelKey=““>
<name>http://www.travel.org/e-checkin-interface</name>
Standard service interface definition for travel services
</description>
<overviewDoc>
WSDL Service Interface Document
</description>
<overviewURL>
http://www.travel.org/services/e-checkin.wsdl
</overviewURL>
</overviewDoc>
<categoryBag> ...
</categoryBag>
</tModel>
WEB SERVICE INSPECTION
► While UDDI is the best-known mechanism for service
discovery, it is neither the only mechanism nor always the
best tool for the job. In many cases, the complexity and
scope of UDDI is overkill if all that is needed is a simple
pointer to a WSDL document or a services
URL endpoint. Recognizing this, IBM and Microsoft got
together and worked out a proposal for a new Web Service
Inspection Language that can be used to create a simple
index of service descriptions at a given network location.
► An example WS-Inspection document is illustrated in
Example 6-38. It contains a reference to a single service
(Hello World) with two descriptions—one WSDL-based
description and one UDDI-based description.
WEB SERVICE INSPECTION
<inspection
xmlns="http://schemas.xmlsoap.org/ws/2001/10/inspection/"
xmlns:uddi="http://schemas.xmlsoap.org/ws/2001/10/inspection/uddi/">
<service>
<abstract>The Hello World Service</abstract>
<description
referencedNamespace="http://schemas.xmlsoap.org/wsdl/"
location="http://example.com/helloworld.wsdl"/>
<description referencedNamespace="urn:uddi-org:api">
<uddi:serviceDescription
location="http://www.example.com/uddi/inquiryapi">
<uddi:serviceKey>
4FA28580-5C39-11D5-9FCF-BB3200333F79
</uddi:serviceKey>
</uddi:serviceDescription>
</description>
</service>
<link
referencedNamespace="http://schemas.xmlsoap.org/ws/2001/10/inspection/"
location="http://example.com/moreservices.wsil"/>
</inspection>
WEB SERVICE INSPECTION -
SYNTAX
► The syntax of a WS-Inspection document is simple. The root inspection
element contains a collection of
abstract
link
service elements.
► The abstract element provides for simple documentation throughout
the WS-Inspection document.
► The link element allows the inspection document to link to other
external inspection documents or even other discoverymechanisms
(such as a UDDI registry) where additional information can be found.
► The Programming Web Services with SOAP service element represents
a web service being offered by the publisher of the inspection
document.
► The service element itself is a collection of abstract and description
elements. You can describe a service in several ways.
AD-HOC DISCOVERY
►Discovery for Client is about finding services
►From service’s point of view ,discovery is
about publishing location and other
information about the service and the
information needed are as below
Description Information
Service Location
Contact and Service API Documentation
Service Classification
SECURING WEB SERVICES
► Securing is all about
Authentication
Confidentiality
Integrity
► This can be either performed as
Public Key Encryption
Private Key Encryption
► The namespace where we can find the definition
of the security features is
using System.Security.Cryptography;
► XML ENCRYPTION ► Encrypting a portion of the
source file
Source file
►Encrypting the entire document
► Encrypting SSN Number
►Preservation of Integrity is performed as
follows
This figure
shows a
xml
signature
►Web Service Security Protocols
The following are components
►Claim
►Subject
►Policy
WS-Security
►This specification tells of a single SOAP header
named <security> with each actor.
► Here is a WS-Security namespace and the protocols usage
►Security Tokens
A WS-Security Message is as below
►UserName Token is shown below
Integrity and Encryption – The following is an
example of Using X509 Certificates and
Signatures
THE END

Web Services Building Blocks

Uploaded by

Copyright:

Available Formats

You might also like

Web Services Building Blocks

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Web Services Building Blocks

Uploaded by

Copyright:

Available Formats

WEB SERVICES

Used to make sure stream can be written

Byte[] buffer=new Byte[txtWords,Text.ength+1);

You might also like