- From: James M Snell <jasnell@us.ibm.com>
- Date: Mon, 4 Mar 2002 12:17:30 -0500 (EST)
- To: "Gaertner, Dietmar" <Dietmar.Gaertner@softwareag.com>
- Cc: www-ws-arch-request@w3.org
Personally, I would argue that both an HTML page and a FTP site are both legitimate *types* of Web services for exactly the reasons you give. What this group SHOULD do is first define the domain and range of what Web services are in general, and THEN distinguish that range of service types that are most interesting. In other words, speaking in mathematical terms, now that we've defined f(n), let's now find the domain of n that is most interesting to us as a group and work from there. Let's walk through it. Given the definition: "A web service is a software application or component identified by a URI that, through an application programming interface capable of being described, supports direct interactions with other software applications or components via internet-based protocols, where said interactions do not require direct human involvement." By finding the most interesting answers to the following questions, we narrow down our scope to something that is more "useful". 1. How is the interface described? 2. How is "direct interaction" via "internet-based protocols" achieved? 3. What "internet-protocols" are used? 4. What exactly qualifies as "direct human involvement"? The answers to these questions will provide the foundation for the definition of what the "Web Services Architecture" will become. In other words, we're basically saying that "While the general definition of what a Web service is is extremely broad, for the purposes of defining the Web Services Architecture, we wish to constrain the definition to a limited subset of possible Web service types determined by the protocols used for interaction and description". - James M Snell/Fresno/IBM Web services architecture and strategy Internet Emerging Technologies, IBM 544.9035 TIE line 559.587.1233 Office 919.486.0077 Voice Mail jasnell@us.ibm.com Programming Web Services With SOAP, O'reilly & Associates, ISBN 0596000952 == Have I not commanded you? Be strong and courageous. Do not be terrified, do not be discouraged, for the Lord your God will be with you wherever you go. - Joshua 1:9 To: James M Snell/Fresno/IBM@IBMUS cc: "'www-ws-arch@w3.org'" <www-ws-arch@w3.org> Subject: RE: Web Service Definition [Was "Some Thoughts ..."] I don't want to be negative, but this "definition" is IMHO useless for the pupose of serving as a start to define a sound web services architecture. I may be taken for some high level marketing material, but it does not capture at all what we all would like to see web services as. Take for example the stockquote "service", which we all know and love returning, a plain HTML page. It can be implemented as an application or component, identified by an URI (e.g. http://www.stockquote.org/quotes?symbol=xzy), can be described (the URI is enough of a description, if you wish), can be accessed by software via internet-based protocols, and the interaction does not necessarily require human interaction (the client could scrape the HTML). I could describe a similar scenario with an FTP site providing some files with stock quotes. I guess this is *not* what we would like to capture with a definition for web services! Having followed for a while the desperate discussion on this thread how to define web services, I came to the conclusion that it will simply not be possible to come up with a formal definition because there is nothing formal on which this definition could be based. Is there a definition for the web? Or a service? What is the definition for internet-based protocols? What can and what can not be described? I suggest to narrow down the scope and define an architecture for the type of services which we (informally) have in mind and then it will be possible to define what a service is relative to this architecture. Regards, Dietmar Gaertner Software AG -----Original Message----- From: "James M Snell" <jasnell@us.ibm.com> To: "Vinoski, Stephen" <steve.vinoski@iona.com> Cc: www-ws-arch@w3.org Message-ID: <OFBE8B0EFB.C1F76B5B-ON88256B70.000755AA@boulder.ibm.com> Date: Fri, 1 Mar 2002 18:25:18 -0700 Subject: RE: Web Service Definition [Was "Some Thoughts ..."] I'd say that this is definitely close enough to move foward. If there are any further refinements that could be made, I'm not thinking of any at the moment. - James M Snell/Fresno/IBM Web services architecture and strategy Internet Emerging Technologies, IBM 544.9035 TIE line 559.587.1233 Office 919.486.0077 Voice Mail jasnell@us.ibm.com Programming Web Services With SOAP, O'reilly & Associates, ISBN 0596000952 == Have I not commanded you? Be strong and courageous. Do not be terrified, do not be discouraged, for the Lord your God will be with you wherever you go. - Joshua 1:9 Sent by: www-ws-arch-request@w3.org To: James M Snell/Fresno/IBM@IBMUS cc: <www-ws-arch@w3.org> Subject: RE: Web Service Definition [Was "Some Thoughts ..."] OK, James, if we take your inputs along with those of Heather, Mark, and others, and apply them to my original strawman definition including Mark's amendment, we get: "A web service is a software application or component identified by a URI that, through an application programming interface capable of being described, supports direct interactions with other software applications or components via internet-based protocols, where said interactions do not require direct human involvement." Are we there? :-) --steve > -----Original Message----- > From: James M Snell [mailto:jasnell@us.ibm.com] > Sent: Friday, March 01, 2002 6:21 PM > To: Vinoski, Stephen > Cc: www-ws-arch@w3.org > Subject: RE: Web Service Definition [Was "Some Thoughts ..."] > > > Stephen, > > We actually are on the same page here. We both seem to agree > that yes, > Web services can be described and discovered, but we disagree > whether or > not those properties need to be called out explicitly in the > definition. > You seem to be saying no, I'm saying yes they do. The reason > is the same > as why we explicitly define Web resources as having unique URI > identifiers. Of course Web resources have identifiers, > they're objects > and all objects have identifiers -- of what use is it to > explicitly call > out that point? The answer is that by stating the fact, we lay the > groundwork for standardizing how those identifiers are created, > represented, communicated, etc. We're basically stating that Web > resources need to have a standardized method of > identification. For Web > Services, explicitly calling out description and discovery as > properties > of a Web service indicate that there needs to be standardized > mechanisms > for description and discovery -- regardless of whether or not > every Web > service actually implements those standards. Because a Web > Service can be > described and discovered, the overall Web Services > Architecture needs to > take into account standardized mechanisms for description and > discovery. > I'm not saying we have to create such standards here, just > acknowledge > their existence and role. Make sense? > > - James M Snell/Fresno/IBM > Web services architecture and strategy > Internet Emerging Technologies, IBM > 544.9035 TIE line > 559.587.1233 Office > 919.486.0077 Voice Mail > jasnell@us.ibm.com > Programming Web Services With SOAP, O'reilly & Associates, ISBN > 0596000952 > > == > Have I not commanded you? Be strong and courageous. Do not > be terrified, > > do not be discouraged, for the Lord your God will be with you > wherever you > go. > - Joshua 1:9 > > To: James M Snell/Fresno/IBM@IBMUS > cc: > Subject: RE: Web Service Definition [Was "Some Thoughts ..."] > > > > Given that you won't be able to prove it, let's look at it in a > practical manner. Everything in the universe is both describable and > discoverable. Therefore, speaking about D&D generally does not add any > clarity to the definition. On the other hand, if you're speaking > specifically about discovery services like UDDI and > description services > like WSDL, then that too is wrong, as I know of several web services > already in production that use neither WSDL nor anything like UDDI. > > --steve > > > -----Original Message----- > > From: James M Snell [mailto:jasnell@us.ibm.com] > > Sent: Friday, March 01, 2002 3:57 PM > > To: Vinoski, Stephen > > Subject: RE: Web Service Definition [Was "Some Thoughts ..."] > > > > > > 100% of all Web resources, including Web Services CAN be > > described and > > discovered. The differentiating factor is HOW. Every Web > > service CAN be > > discovered regardless of whether or not the Web service explicitly > > supports a specific discovery mechanism. Every Web service CAN be > > decribed regardless of whether or not the Web service > > explicity supports a > > specific description mechanism. You are right in that > decription and > > discovery alone do not distinguish Web services from other > > types of web > > resources, but that does not mean that the properties of > > discoverability > > and description are not part of the formal definition of a > > Web service. > > > > - James M Snell/Fresno/IBM > > Web services architecture and strategy > > Internet Emerging Technologies, IBM > > 544.9035 TIE line > > 559.587.1233 Office > > 919.486.0077 Voice Mail > > jasnell@us.ibm.com > > Programming Web Services With SOAP, O'reilly & Associates, ISBN > > 0596000952 > > > > == > > Have I not commanded you? Be strong and courageous. Do not > > be terrified, > > > > do not be discouraged, for the Lord your God will be with you > > wherever you > > go. > > - Joshua 1:9 > > > > To: James M Snell/Fresno/IBM@IBMUS, "Joseph Hui" > > <jhui@digisle.net> > > cc: <www-ws-arch@w3.org> > > Subject: RE: Web Service Definition [Was "Some Thoughts ..."] > > > > > > > > > -----Original Message----- > > > From: James M Snell [mailto:jasnell@us.ibm.com] > > > Sent: Friday, March 01, 2002 1:21 PM > > > To: Joseph Hui > > > Cc: www-ws-arch@w3.org > > > Subject: RE: Web Service Definition [Was "Some Thoughts ..."] > > > > > > > > > A Web Service must be defined as having the properties that
Received on Monday, 4 March 2002 18:02:03 UTC