RE: To be a Web service, or not to be a Web service ...

I am sorry...I do not see a simple statement of constraints here.
the closest I could find was:

"So the constraint is first to define the Web as an ever changing 
collection of nodes. It's in constant flux, you can say what it looks 
right now but you can't predict what it will look like tomorrow. You can 
participate in that Web if you can do it today, tomorrow and the day 
after, in spite the constantly changing nature of the Web. And that means 
you need some level of independence and interoperability. Otherwise, if 
you can only connect to a few members (perhaps all those you know today) 
you may be part of a very exclusive and coveted group - but you can't be 
part of a larger Web."

I have now idea how to define a web service or describe which services are
web services by a general statement of the dynamic nature of networked
systems.

We are trying to get a work product done and need to be sure we agree
on some foundational terminology. Constraints and scoping statements
are good ways of finding agreement, hence that is why I asked for a 
constraint.  Now that Mike has posted alternative text, lets just
focus on getting that right. If his definitions seem off base, help us
understand why in terms of constraints or example services that are in 
scope that shouldn't be or vice versa.

Lets get the document moving!

daveh
-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Wednesday, April 16, 2003 3:43 PM
To: Dave Hollander
Cc: www-ws-arch@w3.org
Subject: Re: To be a Web service, or not to be a Web service ...


Dave Hollander wrote:

>This sounds like it is proposing composability as a key constraint.
>Is that what you had in mind? If not, could you propose a simple
>statement of what the constraint is?
>
>daveh
>  
>
Composition may be too narrow of a definition. When I compose A and B to 
form C I definitely worry about interoperability. But I can take it one 
piece at a time, and I would be satisfied using technologies like IIOP 
and DCOM.

I am thinking of a Web as being a collective of nodes that is always in 
flux. You can't really say who is part of the Web because once you're 
done listing them some new nodes join and some old nodes leave. Just 
like the World Wide Web it's ever changing and never stable. Your 
ability to participate is your ability to be independent of the current 
formation of the Web.

Just like a Web server in the traditional sense. It has nothing to do 
with using HTML and JPEG per se - we have better multimedia 
technologies. And it has nothing to do with using GET vs POST- it uses 
both and it's not about to crash down any time soon. It's about any site 
being able to become part of this large hypertext system by simply 
plugging in the network cable and turning the power on. Once you're up 
and running and have some end-point that others can find you become part 
of the Web - browsers and search engines can instantly connect to you 
and use your service. You don't have to "reprogram" all of them to 
accomodate your needs, and you don't have to "reprogram" new browsers 
and search engines that are not here today but will be turned on tomorrow.

So the constraint is first to define the Web as an ever changing 
collection of nodes. It's in constant flux, you can say what it looks 
right now but you can't predict what it will look like tomorrow. You can 
participate in that Web if you can do it today, tomorrow and the day 
after, inspite the constantly changing nature of the Web. And that means 
you need some level of independence and interoperability. Otherwise, if 
you can only connect to a few members (perhaps all those you know today) 
you may be part of a very exclusive and coveted group - but you can't be 
part of a larger Web.

So the idea is that some service doesn't depend on which nodes are out 
there that can provide it with a certain services, and doesn't depend on 
which nodes are out there that can consume the service it provides. All 
that it cares about is being able to participate in that Web that keeps 
changing. Whatever technology you have that can let you adapt to the 
ever changing Web is applicable. A.I. is one way to go. SOAP and WSDL 
may be more practical in the short term.

arkin

>-----Original Message-----
>From: Assaf Arkin [mailto:arkin@intalio.com]
>Sent: Wednesday, April 16, 2003 11:58 AM
>To: Champion, Mike
>Cc: www-ws-arch@w3.org
>Subject: Re: To be a Web service, or not to be a Web service ...
>
>
>
>Champion, Mike wrote:
>
>  
>
>>Good point ... that post was a "brain dump before bed", which I should
>>probably try harder to resist the temptation to do. 
>>
>>But here's an attempt to rework them:
>>
>>    
>>
>These are exactly the sort of questions that led me to conclude that the 
>definition of 'is this a Web service' depends not on the behavior of the 
>service itself, or the behavior of a particular client, but the Web 
>itself. We can find some scenarios where these examples could be 
>rationalized as Web services if all clients/services decide to operate 
>in the same way. On the other hand, we intuitively know that some of 
>these scenarios would not allow such a Web to grow indefinitely, and so 
>would consider these particular services/clients as hindering that 
>growth and therefore not being Web services.
>
>I don't think it has anything to do with what the client does. Consider 
>example #1:
>
>1) The "service" is an ordinary HTML Web page whose structure appears to
>follow a predictable pattern but the underlying code/stylesheets are not
>publicly available; a client agent "screen scrapes" the HTML to extract
>information into a data structure for further processing.
>
>
>Perhaps there is a lot of demand for a service that returns some HTML 
>page for the purpose of displaying it or printing it. Maybe it's a CSS 
>conformance Web page that clients extract and test. In such a Web of 
>clients and servers you will definitely perceive this to be a Web 
>service. You can add more servers to this Web as fast as you can make 
>them discoverable.
>
>On the other hand, perhaps there is a lot of demand for information in a 
>particular domain, and this service like others return that information. 
>However, instead of standardizing on some known schema to represent that 
>information, each service picks up some schema it wants to use. Each 
>client must be programmed to the peculiarities of each particular 
>service. Such a Web cannot grow organically by simply adding new service 
>to it.
>
>So now you have a client and a service and they both operate with each 
>other seamlessly. But you may have a larger Web of services and clients 
>in that domain that all agree to use some common schema so the Web can 
>grow as fast as you can discover new services. This service cannot 
>easily participate in that Web, and as far as the Web is concerned will 
>not be considered a Web service.
>
>The only citeria I can see as usable for determining whether or not this 
>is a Web service is the definition of the Web in which this service 
>intends to take part. If it can be addmitted to the Web it's a Web 
>service. If it cannot be addmited to the Web, it's not. I wouldn't use a 
>specific client as the litmus test.
>
>5) The "service" is some executable software accessed by a SOAP interface
>whose only description is the Java code that actually implements it; the
>client agent is hand-coded after a telephone conversation with the
developer
>of the "service."
>
>How would you define the first few services put in place before there 
>was reason to exchange WSDL definitions? What about a deployment cycle 
>where at some point (usually in the early life) exchanging Java code 
>definitions or hard-coding them is just as usable and applicable as 
>using WSDL? What if everyone is satisfied with using the same piece of 
>Java code to write their clients and servers?
>
>If the nature of the Web is such that all service consumers and 
>providers can leverage that definition, regardless of how you write it 
>or communicate it, then it's a Web service. It may be a Web that is 
>limited in scope to a single domain, say one company, because no one 
>else in the world has any use for its services. Nothing wrong with that. 
>On the contrary, if we are thinking of B2B collaboration on a larger 
>scale we can't construct such a Web. If such a Web did exist this will 
>not be one of its participants.
>
>3) The "service" is a RESTful hypermedia application (e.g. an online travel
>agency) designed to be used by either human agents or software agents and
>the returned data is XHTML; the client agent was programmed after
>consultation with the "service" developers to simulate the sequence of GETs
>and POSTS -- checking the HTTP return codes and parsing the result data to
>find the appropriate URI to go to the next state.
>
>4) Same as 3) but there is no human-usability requirement and the syntax of
>the returned data is XML that conforms to an agreed upon schema and the
>rules for interpreting the results and moving to the next state are
>well-defined in an XML-based format.
>
>As above. But this time we feel more comfortable that this is a Web 
>service and the reason for that is that we can easily imagine how this 
>particular selection does allow such a Web to grow as easily as we can 
>discover new Web services. There is no precise point at which we can say 
>"this is a Web service, but #1 and #2 are not". The only difference here 
>is that if we imagine a Web that happens to traverse network and 
>platform boundaries that we can incorpoate such services into that Web.
>
>I definitely agree with Roger that David's use cases are one way to 
>indicate whether or not a service is a Web service. But David's use 
>cases are looking at a Web of services that traverses across domains of 
>control. And that means they need better mechanism to standardize on the 
>exchange of information, such as SOAP and WSDL. I don't see how such 
>Webs can be esatblished easily without using such technologies.
>
>On the other hand, there are other valid uses for Web services. I may 
>build two Web services that I intend to use in my application and are of 
>no interest to the world. I can have more flexibility in electing which 
>protocols/languages to use, while still retaining the notion of a Web. 
>Perhaps all these Web services use DIME and not SOAP, but I can add more 
>DIME services to the mix as easily as I can discover them. So it is a 
>Web after all.
>
>Comments?
>
>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 Wednesday, 16 April 2003 20:12:10 UTC