At this point you should have a taste for what a simple Web service is and how you can create
and use them with managed code. Later in this tutorial I will spend more time talking about
development details and infrastructure. For now, however, I would like to take a side-trip into
the topic of why Web services are important.
Web services are really nothing more than a fancy remote procedure call (RPC) technology.
However, the real value is in the fancy parts. Unlike other RPC mechanisms Web services
offer all of the following benefits.
? Performance – Web services use the SOAP protocol which stands for Simple Object
Access Protocol. SOAP runs on HTTP which is a stateless request response protocol.
This statelessness provides just the scalability necessary for an Internet distributed RPC
mechanism.
? Interoperability – Web services are based on SOAP. SOAP is based on HTTP and XML.
All of these standards are simple and well defined. Any platform can use them, and many
platforms already have existing libraries and code for dealing with these standards. The
net result is that web-services do not have any affinity to a platform, language,
environment, etc.
? Well defined – The Web Service Description Language or WSDL (also XML based) is an
important benefit of Web services. This is because WSDL is well defined. This means that
a tool can be used to parse WSDL and create a code or some other mechanism to connect
to a Web service. This potentially simplifies coding tasks relating to Web services.
Conversely, a service that knows enough about itself (such as a web-service written using
managed code, which enjoys the benefits of metadata) can be made to automatically
describe itself in terms of WSDL.
These benefits are not small ones; they mean that for a great many applications their network
communication can be simplified and executed in terms of object instantiation and method
calls. This is true while still retaining the necessary performance. The ability to perform
network communication on such simple terms will increase the agility of applications and
massively increase data sharing in the industry.
Let’s take a look at some scenarios.
3.1. The Theater Scenario (Free Data)
Many companies, especially retail and service oriented companies, have data that they want
the world to know. By have´what I mean is that somebody or some thing knows the
information. Let’s take for example a movie theater.
Theaters have information that they would like the general public to know. Primarily facts like
the price of admission, which movies are playing and at what times, which showing are
matinees, etc. It is in the theater’s best interests to distribute this information as widely as
possible.
Most theaters solve their distribution problem using a number of mechanisms including
? Phone numbers with recorded messages
? Newspaper listings
? Web sites
The phone and web-site solution share a problem in common. They both require the potential
customer to seek out the theater. This is not true of the newspaper listing; however, the
newspaper is inefficient and fairly static, as a source of information goes.
The ideal solution is a web site or application that collects listing from every theater in town
and displays them in a browsable fashion for the user. Such sites do exist today, but they
require one of two things to happen: manual entry of listings and coordinated data sharing.
The cost of these solutions may be acceptable for listings sites, because movies are popular
and listings generate traffic. But what about industries that are less popular or less well
organized, for example bag-pipe parts and services?
Now let’s look at the Web services solution. Each theater publishes their listings and other
theater information as a public Web service. Then each theater consumes their own Web
service to produce their dynamic web-site for the theater. The theater companies job is done.
Any site that wants to offer aggregate listings of theaters now needs only to know the
published URL of a theater’s Web service and the published URL for the Web services WSDL
document, and it will be a trivial thing to consume the theater’s data. This drastically reduces
the cost of consuming this data, because it requires no manual entry, and it requires no
agreement on data exchange format (except for SOAP). This reduced cost of consumption will
cause the information to be shared and aggregated in more ways. In fact, the local newspaper
would do well to consume the theater Web services, and automatically generate their listings
as well.
Now, the benefits of this approach apply to many industries. For example, if restaurants
commonly hosted Web services that produced menus and accepted reservations getting a
reservation would quickly become an automatable and searchable task. And not just with a
few restaurants that sponsor a reservation site, but with every restaurant in town.
Retail outfits would do well to publish their sales through a service. Why? Because
consumers want to know the information, and someone will make a sale-searcher website that
consumes all of the retail services in town hunting for sales. The possibilities are limitless.
3.2. Credit Card Purchase Scenario (Data that Costs Money)
Credit card purchases are automated through software today. There are companies that will
run a credit card transaction on behalf of a retailer, and they take a fee for the service. This is
an example of a service that already exists that would benefit from being moved over to Web
services, not because it isn’t already automated, but because it is not sufficiently simple.
If your transaction fulfillment service requires little more than an object instantiation and a
method call, then your service will be competitive over one that requires adherence to a
protocol.
3.3. Large Institution Scenario (Application Integration)
Most large institutions such as schools and corporations have a local area network on which
data is shared. It has become very common for various groups inside of a company to expose
information about their group via small web-sites and similar medium. Similarly departments
inside of an institution such as human resources or accounting will often expose tools via an
enterprise network.
These data sources and services are commonly implemented as web-sites and they represent
usable but largely isolated islands of data or business logic. The results of this is that it is
actually common for network and web site developers in an institution to develop HTML screen
scraper utilities that grovel over web sites in the company to aggregate data. This is efficient, and often the results are a less than optimal solution.
The Web service solution is this: every website that exists in a corporate or local network today
should be broken up into two pieces. The first is a Web service that exposes the data or
performs the processing that the old web site used to fulfill. Then a thin web site should be
created to expose the Web service to the browser.
As institutions begin to take this approach data and business logic will begin to be shared
much more readily. Now the functionality of each of these departments’ sites is no longer an
island, but a fully accessible channel for aggregation.
3.4. Why Web Services?
To summarize these scenarios, the whole goal is sharing of information and logic as objects on
the network. It is no longer acceptable to only use the Internet as a browsing tool. Data
sharing is not a new idea, however the key to the Web service solution is just how easy and
interoperable Web services are.
In the long run a technology like Web services will bring the computer industry into the world of
science fiction where every computer is not only connected, but can share any information with
ease.
and use them with managed code. Later in this tutorial I will spend more time talking about
development details and infrastructure. For now, however, I would like to take a side-trip into
the topic of why Web services are important.
Web services are really nothing more than a fancy remote procedure call (RPC) technology.
However, the real value is in the fancy parts. Unlike other RPC mechanisms Web services
offer all of the following benefits.
? Performance – Web services use the SOAP protocol which stands for Simple Object
Access Protocol. SOAP runs on HTTP which is a stateless request response protocol.
This statelessness provides just the scalability necessary for an Internet distributed RPC
mechanism.
? Interoperability – Web services are based on SOAP. SOAP is based on HTTP and XML.
All of these standards are simple and well defined. Any platform can use them, and many
platforms already have existing libraries and code for dealing with these standards. The
net result is that web-services do not have any affinity to a platform, language,
environment, etc.
? Well defined – The Web Service Description Language or WSDL (also XML based) is an
important benefit of Web services. This is because WSDL is well defined. This means that
a tool can be used to parse WSDL and create a code or some other mechanism to connect
to a Web service. This potentially simplifies coding tasks relating to Web services.
Conversely, a service that knows enough about itself (such as a web-service written using
managed code, which enjoys the benefits of metadata) can be made to automatically
describe itself in terms of WSDL.
These benefits are not small ones; they mean that for a great many applications their network
communication can be simplified and executed in terms of object instantiation and method
calls. This is true while still retaining the necessary performance. The ability to perform
network communication on such simple terms will increase the agility of applications and
massively increase data sharing in the industry.
Let’s take a look at some scenarios.
3.1. The Theater Scenario (Free Data)
Many companies, especially retail and service oriented companies, have data that they want
the world to know. By have´what I mean is that somebody or some thing knows the
information. Let’s take for example a movie theater.
Theaters have information that they would like the general public to know. Primarily facts like
the price of admission, which movies are playing and at what times, which showing are
matinees, etc. It is in the theater’s best interests to distribute this information as widely as
possible.
Most theaters solve their distribution problem using a number of mechanisms including
? Phone numbers with recorded messages
? Newspaper listings
? Web sites
The phone and web-site solution share a problem in common. They both require the potential
customer to seek out the theater. This is not true of the newspaper listing; however, the
newspaper is inefficient and fairly static, as a source of information goes.
The ideal solution is a web site or application that collects listing from every theater in town
and displays them in a browsable fashion for the user. Such sites do exist today, but they
require one of two things to happen: manual entry of listings and coordinated data sharing.
The cost of these solutions may be acceptable for listings sites, because movies are popular
and listings generate traffic. But what about industries that are less popular or less well
organized, for example bag-pipe parts and services?
Now let’s look at the Web services solution. Each theater publishes their listings and other
theater information as a public Web service. Then each theater consumes their own Web
service to produce their dynamic web-site for the theater. The theater companies job is done.
Any site that wants to offer aggregate listings of theaters now needs only to know the
published URL of a theater’s Web service and the published URL for the Web services WSDL
document, and it will be a trivial thing to consume the theater’s data. This drastically reduces
the cost of consuming this data, because it requires no manual entry, and it requires no
agreement on data exchange format (except for SOAP). This reduced cost of consumption will
cause the information to be shared and aggregated in more ways. In fact, the local newspaper
would do well to consume the theater Web services, and automatically generate their listings
as well.
Now, the benefits of this approach apply to many industries. For example, if restaurants
commonly hosted Web services that produced menus and accepted reservations getting a
reservation would quickly become an automatable and searchable task. And not just with a
few restaurants that sponsor a reservation site, but with every restaurant in town.
Retail outfits would do well to publish their sales through a service. Why? Because
consumers want to know the information, and someone will make a sale-searcher website that
consumes all of the retail services in town hunting for sales. The possibilities are limitless.
3.2. Credit Card Purchase Scenario (Data that Costs Money)
Credit card purchases are automated through software today. There are companies that will
run a credit card transaction on behalf of a retailer, and they take a fee for the service. This is
an example of a service that already exists that would benefit from being moved over to Web
services, not because it isn’t already automated, but because it is not sufficiently simple.
If your transaction fulfillment service requires little more than an object instantiation and a
method call, then your service will be competitive over one that requires adherence to a
protocol.
3.3. Large Institution Scenario (Application Integration)
Most large institutions such as schools and corporations have a local area network on which
data is shared. It has become very common for various groups inside of a company to expose
information about their group via small web-sites and similar medium. Similarly departments
inside of an institution such as human resources or accounting will often expose tools via an
enterprise network.
These data sources and services are commonly implemented as web-sites and they represent
usable but largely isolated islands of data or business logic. The results of this is that it is
actually common for network and web site developers in an institution to develop HTML screen
scraper utilities that grovel over web sites in the company to aggregate data. This is efficient, and often the results are a less than optimal solution.
The Web service solution is this: every website that exists in a corporate or local network today
should be broken up into two pieces. The first is a Web service that exposes the data or
performs the processing that the old web site used to fulfill. Then a thin web site should be
created to expose the Web service to the browser.
As institutions begin to take this approach data and business logic will begin to be shared
much more readily. Now the functionality of each of these departments’ sites is no longer an
island, but a fully accessible channel for aggregation.
3.4. Why Web Services?
To summarize these scenarios, the whole goal is sharing of information and logic as objects on
the network. It is no longer acceptable to only use the Internet as a browsing tool. Data
sharing is not a new idea, however the key to the Web service solution is just how easy and
interoperable Web services are.
In the long run a technology like Web services will bring the computer industry into the world of
science fiction where every computer is not only connected, but can share any information with
ease.
No comments:
Post a Comment