A Seminar Report on:
“SERVICE ORIENTED ARCHITECTURE
USING WEB SERVICE”
Prepared by: Jay Patel
Roll. No. : U09CO237
Class : B.Tech –IV (Computer Engineering) 7th Semester
Year : 2012-13
Guided by : Prof. Dr. D. C. Jinwala
Department of Computer Engineering
Sardar Vallabhbhai National Institute of Technology,
Surat -395007 (Gujarat), India
Sardar Vallabhbhai National Institute of Technology,
Surat -395007 (Gujarat), India
CERTIFICATE
This is to certify that the seminar report
entitled Service Oriented Architecture Using
Web Service is prepared and presented by Mr.
Jay Patel bearing Roll No. : U09CO237, Final Year
of B. Tech (Computer Engineering) and his
work is satisfactory.
GUIDE JURY(s) HEAD OF DEPT.
(Prof Dr. D. C.
Jinwala)
(Prof. R. P. Gohil)
Abstract
“Service-Oriented Architecture (SOA) concepts and Web services technologies
have matured into highly attractive architecture and implementation
alternatives for building distributed systems. SOA concepts and Internet
protocol-based implementation stacks are a powerful combination that is well-
suited for crafting heterogeneous business-to-business and enterprise
application integration solutions. Web services is a technology that allows
applications to communicate with each other in a platform- and programming
language-independent manner. A web service is a software interface that
describes a collection of operations that can be accessed over the network
through standardized XML messaging. It uses protocols based on the XML
language to describe an operation to execute or data to exchange with another
Page | i
web service. A group of web services interacting together in this manner defines
a particular web service application in a Service-Oriented Architecture (SOA).”
Keywords: Service-Oriented Architecture (SOA), Web Service, XML, Distributed Systems.
Page | ii
Index
Abstract.......................................................................................................................................i
Index..........................................................................................................................................ii
Table of Figures........................................................................................................................iv
List of Abbreviations..................................................................................................................v
Chapter 1 Introduction...............................................................................................................1
1.1 Service Oriented Architecture (SOA)...............................................................................1
1.2 Web Services...................................................................................................................3
Chapter 2 Service Oriented Architecture (SOA)........................................................................5
2.1 What is SOA?...................................................................................................................5
2.2 Why SOA?........................................................................................................................6
2.3 Different Technologies Used for SOA:...........................................................................9
Chapter 3 Web Services...........................................................................................................10
3.1 What is a Web Service?..................................................................................................10
3.2. Web Service Standards..................................................................................................11
3.4 Implementing Web Services...........................................................................................12
3.5 Web Service Infrastructure.............................................................................................13
3.6 Web Services Technologies and Tools...........................................................................13
3.7 Why Web Services?........................................................................................................16
Chapter 4 Web Services Technologies.....................................................................................18
4.1 Definition........................................................................................................................18
4.2 The Elements of Web Services.......................................................................................18
4.3 Uses of Web Services.....................................................................................................22
Chapter 5 Conclusion...............................................................................................................25
References................................................................................................................................26
Acknowledgement....................................................................................................................27
Page | iii
Table of Figures
Figure 1 Upgradation in IT Industry..........................................................................................6
Figure 2 SOA Standards.............................................................................................................7
Figure 3 Web Services Example...............................................................................................8
Figure 4 Overview of SOA......................................................................................................10
Figure 5 Web Services Standard Stack....................................................................................15
Figure 6 Web Services in Action with Core Standards............................................................17
Figure 7 SOAP Request and Response Message Example......................................................23
Figure 8 UDDI Example..........................................................................................................24
Figure 9 WSDL Document......................................................................................................25
Page | iv
List of Abbreviations
Page | v
Chapter 1 Introduction
1.1 Service Oriented Architecture (SOA)
“A service-oriented architecture is a way of sharing functions (typically business
functions) in a widespread and flexible way.”
Service Oriented Architecture (SOA) is an architectural style that guides all aspects of
creating and using business processes, packaged as services, throughout their lifecycle, as
well as defining and provisioning the IT infrastructure that allows different applications to
exchange data and participate in business processes regardless of the operating systems or
programming languages underlying those applications. SOA represents a model in which
functionality is decomposed into small, distinct units (services), which can be distributed over
a network and can be combined together and reused to create business applications. These
services communicate with each other by passing data from one service to another, or by
coordinating an activity between one or more services. It is often seen as an evolution of
distributed computing and modular programming. SOA generally provides a way for
consumers of services, such as web-based applications, to be aware of available SOA-based
services. For example, several disparate departments within a company may develop and
deploy SOA services in different implementation languages; their respective clients will
benefit from a well-defined interface to access them. XML is often used for interfacing with
SOA services, though this is not required. JSON is also becoming increasingly common.
Page | 1
Figure 1 Upgradation in IT Industry
SOA defines how to integrate widely disparate applications for a Web-based environment
and uses multiple implementation platforms. Rather than defining an API, SOA defines the
interface in terms of protocols and functionality. An endpoint is the entry point for such a
SOA implementation.
Service-orientation requires loose coupling of services with operating systems and other
technologies that underlie applications. SOA separates functions into distinct units, or
services,[1] which developers make accessible over a network in order to allow users to
combine and reuse them in the production of applications. These services and their
corresponding consumers communicate with each other by passing data in a well-defined,
shared format, or by coordinating an activity between two or more services.[2]
SOA can be seen in a continuum, from older concepts of distributed computing[1][3] and
modular programming, through SOA, and on to current practices of web
services, mashups, SaaS,grid computing and cloud computing (which some see as the
offspring of SOA). Which is shown clearly in below Figure 1:
Page | 2
Figure 2 SOA Standards
1.2 Web Services
Web Services is one of the most active and widely adopted implementation of SOA. It is
based on an interoperable protocol called SOAP (Simple Object Access Protocol) and all
communication between the server to client, client to client or server to server and in general
application to application, uses the same protocol. Web Services technologies are being
continuously standardized to ensure interoperability and security. Due to this reason, Web
Services based SOA work from embedded systems to mainframes, from C to Java
programming languages. Web Services make calls to web methods exposed as a service by
sending and receiving SOAP messages. Web Services are regularly being considered as one
of the most advanced form of SOA implementation and usually one of the most matured as
well.
Page | 3
Figure 3 Web Services Example
Like SOA, Web Services do not limit any kind of transport for message delivery. It is merely
required for a web service to deliver the SOAP message to the target by any means (See
Figure 3). Therefore, web services may be operated over HTTP/HTTPS (the traditional
approach), or Java Messaging Service (a message based asynchronous approach), over FTP
(a file based approach), and just about any other transport protocols. Web Services are
discoverable by the clients by searching the UDDI (Universal Description, Discovery and
Integration) directories, which publishes the web services as standard contracts like WSDL
(Web Services Description Language). A WSDL is a contract document, which is merely an
XML document based on WSDL schema, which describes the messaging format of the
exposed services. It is this WSDL, which clients are interested in. The client fetches the
WSDL and interprets the XML grammar then either builds stubs and proxies or makes
dynamic invocation of services. In most cases, WSDL documents are static and do not
change very often. Therefore, most programming languages generate stubs and proxies for
the client from WSDL. If the WSDL document changes from one version to another, most
vendors keep the old bindings and just add new bindings. Therefore, the older clients
continue to work.
Page | 4
Chapter 2 Service Oriented Architecture (SOA)
2.1 What is SOA?
Service Oriented Architecture or SOA for short is a new architecture for the development of
loosely coupled distributed applications. In fact service-oriented architecture is collection of
many services in the network. These services communicate with each other and the
communications involves data exchange & even service coordination. Earlier SOA was based
on the DCOM or Object Request Brokers (ORBs). Nowadays SOA is based on the Web
Services.
Broadly SOA can be classified into two terms: Services and Connections.
Services:
A service is a function or some processing logic or business processing that is well-defined,
self-contained, and does not depend on the context or state of other services. Example of
Services areLoan Processing Services, which can be self-contained unit for process the
Loan Applications. Other example may be Weather Services, which can be used to get the
weather information. Any application on the network can use the service of the Weather
Service to get the weather information.
Connections:
Connections means the link connecting these self-contained distributed services with each
other, it enable client to Services communications. In case of Web services SOAP over HTTP
is used to communicate the between services.
The following figure is a typical example of the service-oriented architecture. It shows how a
service consumer sends a service request to a service provider. After accepting the request,
Page | 5
service provider send a message to the service consumer. In this case a service provider can
also be a service consumer.
Figure 4 Overview of SOA
2.2 Why SOA?
There are many reasons for an enterprise to take an SOA approach, and more specifically, a
web services based SOA approach. Some of the primary reasons are:
Reusability. What drives the move to SOA is reuse of business services. Developers within
an enterprise and across enterprises (particularly, in business partnerships) can take the code
developed for existing business applications, expose it as web services, and then reuse it to
meet new business requirements. Reusing functionality that already exists outside or inside
an enterprise instead of developing code that reproduces those functions can result in a huge
savings in application development cost and time. The benefit of reuse grows dramatically as
Page | 6
more and more business services get built, and incorporated into different applications. A
major obstacle in taking advantage of existing code is the uniqueness of specific applications
and systems. Typically, solutions developed in different enterprises, even different
departments within the same enterprise, have unique characteristics. They run in different
operating environments, they're coded in different languages, they use different programming
interfaces and protocols. You need to understand how and where these applications and
systems run to communicate with them. The work involved in doing this analysis and the
development effort in tying these pieces together can be very time consuming. Witness the
pain IT organizations generally encounter when they try to integrate their applications with
systems from business partners (or even with legacy systems from other parts of their own
company). In an SOA, the only characteristic of a service that a requesting application needs
to know about is the public interface. The functions of an application or system (including
legacy systems) can be dramatically easier to access as a service in an SOA than in some
other architecture. So integrating applications and systems can be much simpler.
Interoperability. The SOA vision of interaction between clients and loosely-coupled
services means widespread interoperability. In other words, the objective is for clients and
services to communicate and understand each other no matter what platform they run on.
This objective can be met only if clients and services have a standard way of communicating
with each other -- a way that's consistent across platforms, systems, and languages. In fact,
web services provide exactly that. Web services comprise a maturing set of protocols and
technologies that are widely accepted and used, and that are platform, system, and language
independent. In addition, these protocols and technologies work across firewalls, making it
easier for business partners to share vital services. Promising to make things even more
consistent is the WS-I basic profile, introduced by the Web Services Interoperability
Organization (an organization chartered to promote web services interoperability). The WS-I
basic profile identifies a core set of web services technologies that when implemented in
different platforms and systems, helps ensure that services on these different platforms and
Page | 7
systems, and written in different languages, can communicate with each other. The WS-I
basic profile has widespread backing in the computer industry, virtually guaranteeing
interoperability of services that conform to the profile.
Scalability. Because services in an SOA are loosely coupled, applications that use these
services tend to scale easily -- certainly more easily than applications in a more tightly-
coupled environment. That's because there are few dependencies between the requesting
application and the services it uses. The dependencies between client and service in a tightly-
coupled environment are compounded (and the development effort made significantly more
complex) as an application that uses these services scales up to handle more users. Services in
a web services-based SOA tend to be coarse-grained, document-oriented, and asynchronous.
As mentioned earlier, coarse-grained services offer a set of related business functions rather
than a single function. For example, a coarse-grained service might handle the processing of a
complete purchase order. By comparison, a fine-grained service might handle only one
operation in the purchase order process. Again, as mentioned earlier, a document-oriented
service accepts a document as input, as opposed to something more granular like a numeric
value or Java object. An example of a document-oriented service might be a travel agency
service that accepts as input a document that contains travel information for a specific trip
request. An asynchronous service performs its processing without forcing the client to wait
for the processing to finish. A synchronous service forces the client to wait. The relatively
limited interaction required for a client to communicate with a coarse-grained, asynchronous
service, especially a service that handles a document such as a purchase order, allows
applications that use these services to scale without putting a heavy
communication load on the network.
Flexibility. Loosely-coupled services are typically more flexible than more tightly-coupled
applications. In a tightly-coupled architecture, the different components of an application are
tightly bound to each other, sharing semantics, libraries, and often sharing state. This makes it
difficult to evolve the application to keep up with changing business requirements. The
Page | 8
loosely-coupled, document-based, asynchronous nature of services in an SOA allows
applications to be flexible, and easy to evolve with changing requirements.
Cost Efficiency. Other approaches that integrate disparate business resources such as legacy
systems, business partner applications, and department-specific solutions are expensive
because they tend to tie these components together in a customized way. Customized
solutions are costly to build because they require extensive analysis, development time, and
effort. They're also costly to maintain and extend because they're
typically tightly-coupled, so that changes in one component of the integrated solution require
changes in other components. A standards-based approach such as a web services-based SOA
should result in less costly solutions because the integration of clients and services doesn't
require the in-depth analysis and unique code of customized solutions. Also, because services
in an SOA are loosely-coupled, applications that use these services should be less costly to
maintain and easier to extend than customized solutions. In addition, a lot of the Web-based
infrastructure for a web services-based SOA is already in place in many enterprises, further
limiting the cost. Last, but not least, SOA is about reuse of business functions exposed as
coarse-grained services. This is potentially the biggest cost saving of all.
2.3 Different Technologies Used for SOA:
SOA is much different from point-to-point architectures. SOA comprise loosely coupled,
highly interoperable application services. These services can be developed in different
development technologies (such as Java, .NET, C++, PERL, PHP), the software components
become very reusable i.e. the same C# (C Sharp) service may be used by a Java application
and / or any other programming language. WSDL defines an standard, which encapsulates /
hides the vendor / language specific implementation from the calling client / service.
Page | 9
Chapter 3 Web Services
The next generation of distributed computing has arrived. A Web service is a unit of managed
code that can be remotely invoked using HTTP, that is, it can be activated using HTTP
requests.
Historically speaking, remote access to binary units required platform-specific and sometimes
language-specific protocols. For example, DCOM clients access remote COM types using
tightly coupled RPC calls. CORBA requires the use of tightly coupled protocol referred to
as Internet Inter-ORB Protocol (IIOP), to activate remote types. Enterprise JavaBeans
(EJBs) requires a Remote Method Invocation (RMI) Protocol and by and large a specific
language (Java). Thus each of these remote invocation architectures needs proprietary
protocols, which typically require a tight connection to the remote source.
One can access Web services using nothing but HTTP. Of all the protocols in existence
today, HTTP is the one specific wire protocol that all platforms tend to agree on. Thus , using
Web services, a Web service developer can use any language he wish and a Web service
consumer can use standard HTTP to invoke methods a Web service provides. The bottom
line is that we have true language and platform integration . Simple Object Access Protocol
(SOAP) and XML are also two key pieces of the Web services architecture.
3.1 What is a Web Service?
Web services constitute a distributed computer architecture made up of many different
computers trying to communicate over the network to form one system. They consist of a set
of standards that allow developers to implement distributed applications - using radically
different tools provided by many different vendors - to create applications that use a
combination of software modules called from systems in disparate departments or from other
companies.
Page | 10
A Web service contains some number of classes, interfaces, enumerations and structures that
provide black box functionality to remote clients. Web services typically define business
objects that execute a unit of work (e.g., perform a calculation, read a data source, etc.) for
the consumer and wait for the next request. Web service consumer does not necessarily need
to be a browser-based client. Console-baed and Windows Forms-based clients can consume a
Web service. In each case, the client indirectly interacts with the Web service through an
intervening proxy. The proxy looks and feels like the real remote type and exposes the same
set of methods. Under the hood, the proxy code really forwards the request to the Web
service using standard HTTP or optionally SOAP messages.
3.2. Web Service Standards
Figure 5 Web Services Standard Stack
Web services are registered and announced using the following services and protocols. Many
of these and other standards are being worked out by the UDDI project, a group of industry
leaders that is spearheading the early creation and design efforts.
Page | 11
Universal Description, Discovery, and Integration (UDDI) is a protocol for describing
available Web services components. This standard allows businesses to register with an
Internet directory that will help them advertise their services, so companies can find one
another and conduct transactions over the Web. This registration and lookup task is done
using XML and HTTP(S)-based mechanisms.
Simple Object Access Protocol (SOAP) is a protocol for initiating conversations with
a UDDI Service.SOAP makes object access simple by allowing applications to invoke object
methods or functions, residing on remote servers. A SOAP application creates a request block
in XML, supplying the data needed by the remote method as well as the location of the
remote object itself.
Web Service Description Language (WSDL), the proposed standard for how a Web service
is described, is an XML-based service IDL (Interface Definitition Language) that defines the
service interface and its implementation characteristics. WSDL is referenced by UDDI entries
and describes the SOAP messages that define a particular Web service.
ebXML (e-business XML) defines core components, business processes, registry and
repository, messaging services, trading partner agreements, and security.
3.4 Implementing Web Services
Here comes a brief step-by-step on how a Web service is implemented.
A service provider creates a Web service
The service provider uses WSDL to describe the service to a UDDI registry
The service provider registers the service in a UDDI registry and/or ebXML
registry/repository.
Another service or consumer locates and requests the registered service by
querying UDDI and/or ebXML registries.
The requesting service or user writes an application to bind the registered service
using SOAP in the case of UDDI and/or ebXML
Page | 12
Data and messages are exchanged as XML over HTTP
3.5 Web Service Infrastructure
Even though Web services are being built using existing infrastructure, there exists a strong
necessity for a number of innovative infrastructures. The core architectural foundation of
Web services are XML,XML namespaces, and XML
schema. UDDI, SOAP, WSDL, ebXML and security standards are being developed in
parallel by different vendors
Figure 6 Web Services in Action with Core Standards
3.6 Web Services Technologies and Tools
There are a number of mechanisms for constructing Web services. Microsoft has come out
with a new object-oriented language C# as the development language for Web services
and .NET framework. Microsoft has an exciting tool called Visual Studio .NET in this regard.
The back end database can be Microsoft SQL Server 2000 in Windows 2000 Professional.
Page | 13
Sun Microsystems has its own set of technologies and tools for facilitating Web services
development. Java Servlets, Java Server Pages (JSPs), Enterprise JavaBeans (EJB)
architecture and other Java 2 Enterprise Edition (J2EE) technologies play a very critical role
in developing Web services.
There are a number of tools for developing Web services. They are Forte Java IDE, Oracle
JDeveloper, and WebGain Studio.
Sun Microsystems has taken an initiative called Sun ONE (Open Network Environment) and
is planning to push Java forward as a platform for Web services. It is developing Java APIs
for XML-based remote procedure calls and for looking up services in XML registries - two
more JAX family APIs: JAX/RPC (Java API for XML Remote Procedure Calls) and JAXR
(Java API for XML Registries). These will wrap up implementations of Web services
standards, such as SOAP and UDDI.
IBM also for its part has already developed a suite of early-access tools for Web services
development. They are Web Services Toolkit (WSTK), WSDL Toolkit, and Web Services
Development Environment (WSDE).
Apache Axis is an implementation of the SOAP ("Simple Object Access
Protocol") submission to W3C.
From the draft W3C specification: SOAP is a lightweight protocol for exchanging structured
information in a decentralized, distributed environment. It is an XML based protocol that
consists of three parts: an envelope that defines a framework for describing what is in a
message and how to process it, a set of encoding rules for expressing instances of application-
defined datatypes, and a convention for representing remote procedure calls and responses.
Apache Axis is an Open Source SOAP server and client. SOAP is a mechanism for inter-
application communication between systems written in arbitrary languages, across the
Internet. SOAP usually exchanges messages over HTTP: the client POSTs a SOAP request,
and receives either an HTTP success code and a SOAP response or an HTTP error code.
Page | 14
Page | 15
3.7 Why Web Services?
In this section of WebServices tutorials series we will understand why Web Services are
developed and what are the benefits of using Web Services for the development of
Enterprise applications.
Here are the benefits of using Web Services:
Exposing the function on to network: A Web service is a unit of managed code that can be
remotely invoked using HTTP, that is, it can be activated using HTTP requests. So, Web
Services allows you to expose the functionality of your existing code over the network. Once
it is exposed on the network, other application can use the functionality of your program.
onnecting Different Applications: Web Services allows different applications to talk to each
other and share data and services among themselves. Other applications can also use the
services of the web services. For example VB or .NET application can talk to java web
services and vice versa. So, Web services is used to make the application platform and
technology independent.
Standardized Protocol: Web Services uses standardized industry standard protocol for the
communication. All the four layers (Service Transport, XML Messaging, Service Description
and Service Discovery layers) uses the well defined protocol in the Web Services protocol
stack. This standardization of protocol stack gives the business many advantages like wide
range of choices, reduction in the cost due to competition and increase in the quality.
Low Cost of communication: Web Services uses SOAP over HTTP protocol for the
communication, so you can use your existing low cost internet for implementing Web
Services. This solution is much less costly compared to proprietary solutions like EDI/B2B.
Support for Other communication means: Beside SOAP over HTTP, Web Services can also
be implemented on other reliable transport mechanisms. So, it gives flexibility use the
Page | 16
communication means of your requirement and choice. For example Web Services can also
be implemented using ftp protocol (Web services over FTP).
Loosely Coupled Applications: Web Services are self-describing software modules which
encapsulates discrete functionality. Web Services are accessible via standard Internet
communication protocols like XML and SOAP. These Web Services can be developed in any
technologies (like c++, Java, .NET, PHP, Perl etc.) and any application or Web Services can
access these services. So, the Web Services are loosely coupled application and can be used
by applications developed in any technologies. For example, I have heard of people
developing Web Services using Java technologies and using the Web Services in VB or .NET
applications.
Web Services Sharing: These days due to complexness of the business, organizations are
using different technologies like EAI, EDI, B2B, Portals etc. for distributing computing. Web
Services supports all these technologies, thus helping the business to use existing investments
in other technologies.
Web Services are Self Describing: Web Services are self describing applications, which
reduces the software development time. This helps the other business partners to quickly
develop application and start doing business. This helps business to save time and money by
cutting development time.
Automatic Discovery: Web Services automatic discovery mechanism helps the business to
easy find the Service Providers. This also helps your customer to find your services easily.
With the help of Web Services your business can also increase revenue by exposing their
own Web Services available to others.
Business Opportunity: Web Services has opened the door to new business opportunities by
making it easy to connect with partners
Page | 17
Chapter 4 Web Services Technologies
Before understanding why web services are popular or so important, you should first assess
‘What is Web Services, what’s its use and how does it work?’ The nature and functionality of
web services have made it very popular. Nowadays, our business systems have matured,
transparent and more logical and high tech, and all for these are because of web services.
4.1 Definition
Web services are the amalgamation of eXtensible Markup Language (XML) and HyperText
Transfer Protocol HTTP that can convert your application into a Web-application, which
publish its function or message to the rest of the world.
In other words, we can say, web services are just Internet Application Programming
Interfaces (API) that can be accessed over a network, such as Internet and intranet, and
executed on a remote system hosting the requested services.
Web-applications are simple applications that run on the web. Web services are browsers and
operating system independent service, which means it can run on any browser without the
need of making any changes. Web Services take Web-applications to the Next Level.
The World Wide Web Consortium (W3C) has defined the web services. According to W3C,
“Web Services are the message-based design frequently found on the Web and in enterprise
software. The Web of Services is based on technologies such as HTTP, XML, SOAP,
WSDL, SPARQL, and others.”
4.2 The Elements of Web Services
Web services use XML to code and to decode data, and SOAP to transport it (using open
protocols). Besides these, HTTP, Web Services Description Language (WSDL), Universal
Page | 18
Description, Discovery and Integration (UDDI), and SPARQL are the elements of Web
Services.
To understand clearly about Web Services, it is mandatory to have some brief knowledge of
web services elements.
XML
eXtensible Markup Language (XML) has become the de facto standard for describing data to
be exchangedmon the Web. As it's name indicates, XML is a markup language. It involves
the use of tags that "mark up" the contents of a document, and in doing so, describe the
contents of a document. An XML tag identifies information in a document, and also identifies
the structure of the information. At its core XML is text formatted in the form of tags and text
that follow a well-defined set of rules.
This text may be stored/represented in:
- A normal file stored on disk
- A message being sent over HTTP
- A character string in a programming language
- A CLOB (character large object) in a database
- Any other way textual data can be used
HTTP
HyperText Transfer Protocol in short HTTP is the most widely used protocol by World Wide
Web. It defines how messages are formatted and transmitted, and what actions Web servers
and browsers should take in response to various commands.
One of the shortcomings of HTTP is that it is a stateless protocol, which means each
command is executed independently, without any knowledge of the commands that came
Page | 19
before it. This shortcoming has been resolved in new technologies includes ActiveX, Java,
JavaScript and cookies.
Simple Object Access Protocol (SOAP)
SOAP is a simple XML-based protocol that allows to communicate applications information
over HTTP without the dependency of OS platform. SOAP uses HTTP and XML as the
mechanisms for information exchange.
Figure 7 SOAP Request and Response Message Example
Universal Description, Discovery and Integration (UDDI)
Universal Description, Discovery and Integration in short UDDI is a web based distributed
directory like traditional phone book's yellow and white pages that enables businesses to list
themselves on the Internet and discover each other. It defines a registry service – a Web
Page | 20
service that manages information about service providers, service implementations, and
service metadata – for Web services and for other electronic and non-electronic services.
Figure 8 UDDI Example
The service providers can use UDDI to advertise the services they offer while service
consumers can use UDDI to discover services.
Web Services Description Language (WSDL)
The WSDL refers to Web Services Description Language, is an XML based protocol used for
sending and receiving the information through decentralized and distributed environments.
WSDL is an integral part of UDDI that was developed jointly by Microsoft and IBM.
Page | 21
Figure 9 WSDL Document
It defines what services are available in its Web service and also defines the methods,
parameter names, parameter data types, and return data types for the Web service. The
WSDL document is quite reliable and applications that use web services accept it
SPARQL
SPARQL refers to SPARQL Protocol and RDF Query Language is an RDF query language
that defines a standard query language and data access protocol for use with the Resource
Description Framework (RDF) data model. It works for any data source that can be mapped
to RDF. SPARQL allows a query to be consisted of triple patterns, conjunctions,
disjunctions, and optional patterns. It is standardized by the RDF Data Access Working
Group (DAWG) of the W3C, and is considered a key semantic web technology.
4.3 Uses of Web Services
Page | 22
Web services are a set of tools that can be used in a number of ways most commonly in three
styles:
Remote Procedure Calls
Service-oriented architecture
Representational state transfer
Moreover, it is also used as Reusable application-components and Connect existing
software.
Remote procedure calls (RPC)
The Remote procedure calls Web services present a distributed function call interface, which
is familiar to many developers. Typically, the basic unit of RPC Web services is the WSDL
operation.
Service-oriented architecture (SOA)
Under Service-oriented architecture (SOA) Web services is used to implement an architecture
in which the basic unit of communication is a message, rather than an operation. This is often
referred to as "message-oriented" services. Major software vendors and industry analysts
support the SOA Web Services.
Representational state transfer (REST)
The Representational State Transfer (REST) Web Services attempts to describe architectures
based on REST can use WSDL to describe SOAP messaging over HTTP, which defines the
operations. REST describes operations, can be implemented as an abstraction purely on top
of SOAP or can be created without using SOAP at all.
In Reusable application-components uses Web Services offers most frequently used services
like currency conversion, weather reports, language translation and much more.
Page | 23
In Connect existing software, Web Services offers you to exchange data between different
applications and different platforms. In this type of uses, you can solve the interoperability
problem by giving different applications a way to link their data.
Page | 24
Chapter 5 Conclusion
Conceptually, SOA dates back to over 20 years, when green screen terminals were popular.
SOA evolved over time and Web Services specification were proposed. Then gradually new
terms started to muddle up the basic concept. Each company add slight variation of SOA and
call it by a different name in order to market and position their products. As SOA starts to
mature, you will hear more new and confusing terms, new acronyms, buzzwords, but do not
forget that the seed of all those jargons were derived from Service Oriented Architecture, the
most general concept upon which all service based software design is approached. A service-
oriented architecture is essentially a collection of services. These services communicate with
each other. The communication can involve either simple data passing or it could involve two
or more services coordinating some activity. Some means of connecting services to each
other is needed. The combination of services - internal and external to an organization -
makes up a service-oriented architecture.
If a service-oriented architecture is to be effective, we need a clear understanding of the term
service. A service is a function that is well-defined, self-contained, and does not depend on
the context or state of other services. Services are what you connect together using Web
Services. A service is the endpoint of a connection. Also, a service has some type of
underlying computer system that supports the connection offered.
The technology of Web Services is the most likely connection technology of service-oriented
architectures. Web services essentially use XML to create a robust connection.
Page | 25
References
Page | 26
Acknowledgement
I wish to express sincere gratitude, regards and thanks to my seminar guide Prof. Dr.
D. C. Jinwala for constantly motivating and encouraging me, and also for invaluable advice
during the course of our bachelor’s studies. I would like to express my gratitude, regards and
thanks to Prof. R.P.Gohil , Head of Department, Computer Engineering, to provide
unrestrained access to project lab.
I am extremely grateful to my institute for giving me the encouragement and freedom
to explore new avenues, and for the excellent computing and library facilities.
Last but not least, my sincere gratitude to my parents and friends whose blessings and
wishes were always with me.
Page | 27