Web services can implement a
service-oriented architecture. They make functional building-blocks accessible
over standard Internet protocols independent of platforms and programming
languages. These services can represent either new applications or just
wrappers around existing legacy systems to make them network-enabled.
Each SOA building block can play one or both of two roles:
Each SOA building block can play one or both of two roles:
Service provider
The service provider creates a web
service and possibly publishes its interface and access information to the
service registry. Each provider must decide which services to expose, how to
make trade-offs between security and easy availability, how to price the
services, or (if no charges apply) how/whether to exploit them for other value.
The provider also has to decide what category the service should be listed in for
a given broker service and what sort of trading partner agreements are required
to use the service.
It registers what services are available within it, and lists all the potential service recipients. The implementer of the broker then decides the scope of the broker. Public brokers are available through the Internet, while private brokers are only accessible to a limited audience, for example, users of a company intranet.
It registers what services are available within it, and lists all the potential service recipients. The implementer of the broker then decides the scope of the broker. Public brokers are available through the Internet, while private brokers are only accessible to a limited audience, for example, users of a company intranet.
Furthermore, the amount of
the offered information has to be decided. Some brokers specialize in many
listings. Others offer high levels of trust in the listed services. Some cover
a broad landscape of services and others focus within an industry. Some brokers
catalog other brokers. Depending on the business model, brokers can
attempt to maximize look-up requests, number of listings or accuracy of the
listings.
The Universal Description Discovery and
Integration (UDDI) specification defines a way to publish and discover
information about Web services. Other service broker technologies include (for
example) ebXML (Electronic
Business using eXtensible Markup Language) and those based on the ISO/IEC 11179 Metadata Registry(MDR)
standard.
Service
consumer:
The service consumer or web service
client locates entries in the broker registry using various find operations and
then binds to the service provider in order to invoke one of its web services.
Whichever service the service-consumers need, they have to take it into the
brokers, bind it with respective service and then use it. They can access
multiple services if the service provides multiple services.
There are three aspects of web service development:
Creating the web service
Creating a proxy
Consuming the web service
Creating the Web Service:
A web service is an web application which is basically a class
consisting of methods that could be used by other applications. It also follows
a code-behind architecture like the ASP.Net web pages, although it does not
have an user interface.
Creating the Proxy:
A proxy is a stand-in for the web service codes. Before using the web
service, a proxy must be created. The proxy is registered with the client
application. Then the client application makes the calls to the web service as
it were using a local method.
The proxy takes the calls, wraps it in proper format and sends it as a
SOAP request to the server. SOAP stands for Simple Object Access Protocol. This
protocol is used for exchanging web service data.When the server returns the SOAP package to the client, the proxy
decodes everything and presents it to the client application.
Consuming the web service:
We are adding the web service as service reference in the application and using the web service
Implementation of Web Service
No comments:
Post a Comment