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

I agree with Mike.

But I think the narrow definition is missing three important points.

First of all, we have some intuitive idea of what it is we want to 
achieve and I think we should capture it, and I don't think using 
SOAP/WSDL (or similar specs) is what our intuition is all about.

Second of all, we are devising an architecture that is supposedly a 
solution to the problem. But what is the problem? We need to accept that 
there are other possible architectures, just not good ones we would 
advocate (e.g. using A.I. is one architecture that does not require WSDL 
or SOAP). Stating that the architecture requires a language for defining 
services is good, but if you marry that to the requirement that service 
requires a definition language, you end up with a circular definition. 
You have not explained the why.

Third, there are more specifications out there that are elemental to the 
WS architecture and possibly more that will be proposed soon. Is there 
some generic principle that we can use to decide whether these 
specifications are part of the WS architecture or just nice to have? 
What about security and RM: why do we need specifications to address 
these areas?

Granted, this is not the best text in the world. We can put it to rest 
or decide to refine it. I don't think I can alone propose good text, so 
if there's no interest lets just drop it and move on.

arkin


Dave Hollander wrote:

>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 23:18:32 UTC