W3C home > Mailing lists > Public > www-ws-arch@w3.org > April 2003

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

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Thu, 17 Apr 2003 08:02:11 -0400
To: www-ws-arch@w3.org
Message-ID: <OFE4ED19C3.233BB927-ON85256D0B.0041B781-85256D0B.00421C43@us.ibm.com>
I agree that we don't want the architecture to necessarily restrict or 
constrain
to use of SOAP+WSDL. We rather need to define the constraints such that 
they
yield the properties we seek, and then we should map that onto a 
realization
layer (if you wish) that demonstrates how SOAP and WSDL meet the specified
constraints, etc.

I think that I agree with the point that I believe Mike made, while we 
don't want
to preclude the case where programmer A calls up programmer B and asks
her to describe her Web service, we probably have little motivation to 
explicitly
call out that particular use case, except to demonstrate which properties 
of the
architecture might be absent.

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

www-ws-arch-request@w3.org wrote on 04/16/2003 11:16:50 PM:

> 
> 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 Thursday, 17 April 2003 08:02:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:17 GMT