A Seminar Report on:

Prepared by: Jay Patel Roll. No. Class Year : U09CO237 : B.Tech IV (Computer Engineering) 7th Semester : 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 wellsuited 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 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 | i

Index

Abstract ....................................................................................................................................... i Index ..........................................................................................................................................ii Table of Figures ........................................................................................................................iii List of Abbreviations ................................................................................................................ iv 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 | ii

Table of Figures
Figure 1 Upgradation in IT Industry .......................................................................................... 2 Figure 2 SOA Standards ............................................................................................................ 3 Figure 3 Web Services Example ............................................................................................... 4 Figure 4 Overview of SOA ........................................................................................................ 6 Figure 5 Web Services Standard Stack .................................................................................... 11 Figure 6 Web Services in Action with Core Standards ........................................................... 13 Figure 7 SOAP Request and Response Message Example...................................................... 20 Figure 8 UDDI Example .......................................................................................................... 21 Figure 9 WSDL Document ...................................................................................................... 22

Page | iii

List of Abbreviations

Page | iv

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, service provider send a message to the service consumer. In this case a service provider can also be a service consumer.
Page | 5

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

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

Page | 7

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 tightlycoupled 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 tightlycoupled 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 loosely-coupled, document-based, asynchronous nature of services in an SOA allows applications to be flexible, and easy to evolve with changing requirements.

Page | 8

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 applicationdefined 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 interapplication 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, whats 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 Description, Discovery and Integration (UDDI), and SPARQL are the elements of Web Services.
Page | 18

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 before it. This shortcoming has been resolved in new technologies includes ActiveX, Java, JavaScript and cookies.

Page | 19

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 service that manages information about service providers, service implementations, and service metadata for Web services and for other electronic and non-electronic services.

Page | 20

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 serviceoriented 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 bachelors 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