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