Re: Is This a Web Service?

Cutler, Roger (RogerCutler) wrote:

>This definition of Web services may have deep philosophical merit, but
>it is far too general and hard to understand in a specific way for my
>tastes.  If we are to adopt such language I think that it should be in
>addition to a definition of Web services that I can easily understand
>and, if given a particular situation ask myself, "Is this thing a Web
>services"?
>  
>
Metaphysical ;-)

I agree with you, it's not precise enough. We need a litmus test. We 
need some very simple checklist so we can look at some entity and easily 
determine whether or not it's a Web service.

But I think that protocol X, description language Y and discovery 
mechanism Z is a very narrow checklist. Either you exclude other 
interesting technologies that exist or are yet to come, or you need to 
constantly revise the definition and write permutations for all the 
possible combinations of specifications. So I think we need to start 
looking at very broad and generic principles based on our objectives - 
what we want WS to achieve - and then construct a checklist from that.


Why do we care to answer the question "is this a Web service"? If the 
answer is yes, what does it tell you? If the answer is no, how does that 
impact you? What's the benefit of being a Web service?

We're spending a lot of time and effort on building an architecture for 
Web services that covers a large spectrum of specifications, contains a 
lot of new technologies and requires building an array of solutions. If 
a Web service has to support all of that, we're not going to see a lot 
of Web services in existence. It's just that some technologies are not 
interesting for all business problems. On the other hand, if you just 
need to conform to X,Y, then we're going to have a lot of Web services 
out there and a lot of services we can't use but still put a "WS" stamp on.

I think we need some deciding factor to express the properties of a Web 
service not based on what it does and which protocol it supports, but 
based on what we want it to do. If the answer is "yes, it is a Web 
service", then the question on my mind is "what did I expect it to do 
that made it pursue a career as a Web service?"

We have pre-empted the definition of requirements and terminology and 
started to create a set of specifications because our intuition led us 
to believe it's a move in the right direction. Why did our intuition led 
us to believe that SOAP and WSDL are worthy of our attention?

I guess a lot of people at this point would say "interoperability". Yes, 
interoperability is a good answer but what was the question? I have 
worked on a big project for a key solution that was designed to review 
and update millions of insurance policies on a daily basis. It needs to 
interoperate with the database, and that problem has been solved years 
ago. It solved a critical business problem and did it completely and 
efficiently and didn't care about all these WS technologies.

But that was one type of service. At the other hand we have the Web and 
the Web is all about connecting. It's not just about connecting A to B, 
it's about connection A to anything else out there. What you get in 
return is the benefit of the network effect. If you can connect to your 
five preferred suppliers, that's good, but you don't need new 
technologies to accomplish that. But if you can connect to all the 
suppliers out there, you can force your preferred suppliers to match 
them for price or quality. And if they don't, you just switch. That's 
the type of power that decision makers want to have.

It all boils down to connecting the dots by flipping bits. You want to 
be able to connect as many dots as possible to benefit from the network 
effect. If it takes you a week to connect two dots, there are so many 
you can connect within a fiscal year. It's something, but it's not as 
powerful. But if you can connect two dots at the flip of a bit, it 
becomes a whole new ball game.

You may have an appealing value proposition and if all it takes is the 
flip of a bit to connect you to your customers then you can tap into a 
vast market opportunity. You may want to reduce costs by buying goods 
for a cheaper price. If all it takes is the flip of a bit you can let 
your system scan thousands of business opportunities and select the best 
one. This bit flipping may be technical but it does have a significant 
effect on the bottom line.

In my opinion that's all we're here to do. It's very simple yet it's 
also very powerful.

So what we're trying to do is let businesses establish this vast 
structure of interconnected services that traverse corporate, 
geographical and language barriers. That makes me think of the Web in 
its more conceptual form, not married to a particular protocol or 
application. And it's not just about information or instant 
gratification. As a business you are interested in reaching out to more 
customers and addressing their needs, or in reverse leveraging a larger 
network of suppliers. It's all about providing and consuming services.


When the time comes to build a new service for my customer, I need to 
first determine whether that service is going to connect to anything. 
And does it need to connect to the same old service, or does it need to 
tap into a vast and ever expanding pool of resources. Sometimes, a COBOL 
program that uses SQL is more than enough to meet your business 
requirements.

But if you can benefit from the network effect than you want to become 
one of the dots that can easily be connected. You want to be part of the 
matrix (no pun intended). So the determining factor here is that you 
want to become part of a larger and ever growing structure of 
interconnected services. So you build a Web service.


So what makes a something a Web service, and can we write it down as a 
checklist? My partial, still a bit abstract, looks at the principles 
that a Web service adheres to:

1. A Web service is something you can connect to.

Duh.

Anyway you can connect to it is acceptable if it can also meet 
principles 2-4. Connecting using the phone is just as good. We talk a 
lot about manual vs automatic. But we do have the technology to 
automatically phone-based communication from the annoying voice response 
systems to the even more annoying predictive dialers. On the other hand, 
when it's time to test your service you may feed it a SOAP message 
manually. There important factor is that you can connect to a Web service.

That doesn't mean SOAP is redundant. On the contrary. Principles 2-4 
explain the important role it plays. They just don't exclude using other 
forms of communication alongside or alternative to SOAP.


2. A Web service is something you can talk about.

Without requirements 3-4 that may also define movie stars and heads of 
state. But seriously, this is more interesting than the current two 
requirements:

- A Web service is something that can be discovered. Ok, but that's too 
broad to say anything useful: physical phenomena are also discovered. 
And there's no principle here that tells me what a good discovery 
mechanism looks like. Why is UDDI better than the Yellow pages?

- A Web service is identifiable. So are ice cream flavors and anything 
that has a bar-code stuck to it. And what is a good identification 
mechanism? Is URI good enough why do we see new specifications emerging 
to solve issues related to identification?

If you want to use a Web service you need to know about it. That's 
simple. If you want to use a lot of Web services you need to know about 
all of them. That's not practical. So you want to find someone that will 
catalog them and then tell you about them. Just like the Yellow pages. 
It's more interesting if that someone is a service in itself, but that's 
optional. What is imporant is that you need some way to exchange 
information about a Web service: the fact that it exists, what it does, 
and how to contact it.

That simple requirement spawns a lot of other requirements. To talk 
about something you need to identify it, so you need some naming scheme. 
URI is a good choice, but QNames and UUID also work. You need to tell 
what it is so you need some ability to decribe it or at least reference 
it. WSDL gives you the ability to describe it, and you may need to 
supplemen that with other meta languages like WS Choreography or 
WS-Policy. WS-Addressing gives you the ability to describe it as the 
difference form all other services of the same kind. But using WSDL is 
not a requirement it's a choice - it's a choice you may want to take 
based on principle 4, but other options should not be excluded.

You don't necessarily need a discovery mechanism, though that may become 
very useful. With all due respect to UDDI, you may find that being 
listed in the Fortune 500 or having your end-point scribbled on the 
restroom wall may be more effective. What you need is the ability to be 
able to communicate that information. Whatever it is that identifies the 
Web service or describe it for the purpose of connecting to it must be 
communicable.


3. A Web service is self-descriptive.

You can't connect at the flip of a bit without self-descriptive 
services. If you don't know what the service is going to do then you're 
going to think twice before using it. For all you know if may be taking 
your information and adding it to a spam list. But if you can determine 
what it does then you can automate the decision to use it.

Self-describing doesn't mean you need to contact the service to 
determine what it does. It just requires that "who I am" be associated 
with "what I do". There are many ways to do that. If you find my name in 
the Yellow pages under the category Plumber you can assume I can fix an 
overflowing toilet but probably can't fix a broken TV.

A framework where you put WSDL definitions inside a UDDI directory is 
one way to do this. Or you may just list services under some category 
and fetch their definition from a WSIL document. Or perhaps you can send 
a requirement for a fulfilled service and have someone send you back a 
list of end-points you can talk to. And you can validate the association 
between the service and it's description by them to sign using the same 
private key.


4. A Web service is able to participate in a Web of services.

You can only establish a large and constantly expanding network of 
services if you can force them all to talk the same language. Language 
is the biggest barrier to communication, and if you have a variety of 
independent languages you create disconnected islands and can't 
establish a Web of services.

You're looking for homogeny but at the same time you don't want to force 
a common denominator. That would be a way to stifle technology. Let's 
say that all Web services are designed to support SOAP 1.1 and WSDL 1.1. 
They all speak the same language. Great. But now we can't leverage all 
the capabilities of SOAP 1.2 or WSDL 1.2. You want to allow room for 
maneuver and some degree flexibilty.

So now we face apparently two conflicting requirements. One way to 
resolve the issue without forcing adherence to a particular technology 
is to define a Web service as something that is able to participate in a 
Web of services. Perhaps the Web today consists of a thousand services 
that use SOAP 1.1 and tomorrow it will consist of a million services 
that use SOAP 1.2. For the individual Web service it means that it must 
be able to connect to services it never heard of. Being a good citizen 
means not posing any obstacles, e.g. by being able to talk the language 
of the land.

If you write an HTTP server that gets a XML request and sends an XML 
response using SOAP 1.1 you don't have a Web service. You have a SOAP 
1.1 service. Once we all switch to SOAP 1.2 it's no longer able to 
participate in any Web. But if you build a service and expose it using 
some mechanism, so you can replace that mechanism tomorrow and use SOAP 
1.2 - that's a Web service. And if it's sole mission in life is to 
provide access to PNG images, then doing so while participating in the 
Web means it's a first-class citizen.


So looking at just these four principals, what role does the technology 
play in it?

SOAP is one mechanism that allows to connect to a service and allows the 
service to participate in a larger network by speaking the same 
language. It provides us the necessary level of abstraction to achieve 
that. But it doesn't preclude any set of services from talking DIME or 
VoIP if that something they are able to do collectively. They still 
connect to each other and they still participate in the Web. We just 
expect SOAP to be used for the larger more common Webs then other more 
specific protocols. Not all Webs are going to be big or grow 
exponentially, but Webs that do will opt to use SOAP.

WSDL is one mechanisms that allows us to talk about a service and allows 
a service to be self-describing. It's not the only mechanism, some 
services will need more descriptive capabilities because they perform 
more complicated functions. In some Webs we can get away with 
hard-coding all the services and won't use WSDL. In other Webs we'll 
need to use WSDL in combination with more expressive description 
languages (e.g. WS Choreography) or more concise forms of identification 
(e.g. WS-Addressing).

There are some technologies that are optional. In some Webs of fully 
connected services I may not care about security at all. The application 
may be exchanging the time of day and security is not a concern. In some 
Webs security becomes paramount and you can't participate unless you 
have the proper mechanisms in place. To make that possible we need 
common languages for security and we need different languages for 
different capabilities. Some Webs may settle for using SSL and SAML, 
other Webs may require XML-Sig and WS-Security.

It all depends on what the Web as the larger entity deems as important, 
and that dictates what a Web service as a member of that entity is 
required to do. Obviously, utilizing a generic WS stack lets one easily 
build a lot of services that can participate in a lot of Webs. So 
defining what a WS stack looks like and what combination of standards it 
supports would help speed up the creation of such Webs.

Fortunately for us, even though we need a lot of different languages to 
address very specific problems in a way that reduces the language 
barrier, the set of specifications is finite and in fact not that big. I 
can imagine that soon enough we'll have the core specifications out 
there so we can start building new and interesting Webs of services.

arkin

>-----Original Message-----
>From: Assaf Arkin [mailto:arkin@intalio.com] 
>Sent: Tuesday, April 15, 2003 2:17 PM
>To: www-ws-arch@w3.org
>Cc: www-ws-arch@w3.org
>Subject: Re: Is This a Web Service?
>
>
>
>I feel obliged to throw my $0.02 and an alternative definition
>
>A Web service - A service that can be incorporated into a larger 
>interconnected structure (a web) or services that can grow infinitely 
>unlimited by the capabilities of a particular communication mechanism.
>
>
>An OO language adds a lot of capabilities to procedural languags. 
>Abstraction, encapsulation, etc. But OO languages do not flat out reject
>
>procedural languages - they extend them with new capabilities but do not
>
>reject any existing capabilities. A SOAP-based Web services that 
>supports XML content, enveloping of transaction context in the header, 
>and WSDL-based end-point definition is a novel use of Web service 
>technologies. This is something we could not have done a few years back.
>
>But the legacy CGI's of yore are also Web services. They don't take 
>advantage of all the new capabilities, surely they can be extended, but 
>they are still Web services.
>
>A Web service doesn't change its skin because it decides to offer a 
>service with less "XML" in it. A Web service may provide you with the 
>latest XML qoute, or just stream back an MPEG file, or give you access 
>to a PDF document. If it offers the service you request it should be 
>considered a Web service. We can't ignore useful services that return 
>data just because the data is not XML. And in fact, an XML document may 
>just as well be purely binary content (see XML Schema 1.0). So when does
>
>it stop becoming XML?
>
>
>Interoperability is key. But interoperability is more about semantics 
>and common languages that it is about medium. If I talk about a new 
>business opportunity for Wi-Fi and you expect me to talke about the 
>chemical makeup of a new miracle drug - we're not talking the same 
>language. We're not communicating.
>
>On the other hand, if we're both exploring the same business opportunity
>
>I may call you from my CDMA cell-phone and you may be using a land-line 
>phone. Or I may use VoIP on my end and you may be using GSM on your end.
>
>All I need is a rudimentary medium adapter to allow the both of use to 
>converse over any number of topics. We don't need a specific adapter for
>
>each and every topic of discussion. And that's when interoperability is 
>realized - because we distinguish between the information that is 
>communicated and the mediums of communication.
>
>So let's carry that analogy back to Web services. Let's say we both 
>agree on the semantics of our exchange - what information we exchange 
>and what is the outcome of that exchange. We can use any number of 
>protocols at the same time. Perhaps on my end I send a SOAP/HTTP message
>
>and on your end you find it easier to do DIME/TCP and we have some very 
>generic and dumb adapter in the middle. But we agreed on the semantics 
>we use in our discussion. We can interoperate, can't we?
>
>
>WSDL and SOAP are just means to represent information. They have a lot 
>of utility and I expect them to be widely used. But what we care about 
>is not the particular representation - it's the information. We can pick
>
>other representations, maybe DIME or an alternative to WSDL, but if we 
>must dissociate representation from model.
>
>If there's anything we should have learned from XML is to stop depending
>
>on a particular presentation. XSLT gives us one of the most powerful 
>tools to transform information to any number of alternative 
>representations. It's time we learn that it's not about representation 
>but about the information model.
>
>I think the power of Web services will be fully realized when we define 
>Web services as a SOA that is not dependent on the limitations of a 
>particular syntax, language, implementation or protocol. They are not 
>just for Interent use, neither are they limited to just Intranet use. 
>They do B2B with the same level of success as A2A. They can support XML 
>content as well as MIME content.
>
>
>And what is the Web? When I first started using HTML/HTTP I frowned upon
>
>any non-techie who failed to understand that the Web is the Interent and
>
>not just two connected computers, it's HTTP and not SMTP, it's Web 
>servers and not just file servers. But over time I realized that the 
>pure techie point of view may be too narrow to capture the essence of 
>the Web. I began to recognize that perhaps the people who best 
>understand the nature of the Web are my non-techie friends and 
>relatives. That ones who can't read the HTTP specification if their life
>
>dependent on it. It took a shift in perspective, but I've finally 
>accepted their utilitarian non-techie perception of the Web.
>
>People I know would say "I'm on the Web" when they're using e-mail or 
>IM. The perceive the Web in its most basic sense - a complex 
>interconnected structure of things you can touch electronically.  They 
>care less about protocols. With the click of a mouse they can easily 
>traverse from an e-mail to an HTML page to an IM conversation. They can 
>use all three to get information and services. They don't use VoIP, they
>
>use Web phones. To them that's what the Web is all about and damn the 
>protocols.
>
>
>I would define a Web service as nothing more than a service that, having
>
>selected from a variety of available protocols and encodings, can be 
>incorporated into a larger web of services. It is not a Web service if 
>for any particular reason that has nothing to do with the nature of the 
>service itself - and by that I mean artificial issues like limited 
>protocol selection - cannot be incorporated into a lager web of
>services.
>
>If I can make it part of a larger interconnected structure of services, 
>maybe by using SOAP or by using DIME or other protocols, then I perceive
>
>it as a Web service. And if I am limited to using one protocol, be it 
>IIOP or DCOM, and can only fit it with other same-protocol services, 
>then it's not a Web service. It's a service of limited utility.
>
>The Web service revolution is not about using XML and SOAP and WSDL. The
>
>Web service revolution is about utilizing all these technologies to 
>create an interconnect of services that can grow infinitely across the 
>boundaries of businesses, countries and communication networks.
>
>arkin
>
>
>
>
>  
>


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.

Received on Tuesday, 15 April 2003 22:49:26 UTC