- From: Cutler, Roger (RogerCutler) <RogerCutler@ChevronTexaco.com>
- Date: Tue, 15 Apr 2003 20:10:03 -0500
- To: "Doug Bunting" <Doug.Bunting@sun.com>, Richard.Chennault@kp.org
- cc: jim.webber@arjuna.com, www-ws-arch@w3.org, www-ws-arch-request@w3.org
I may be wrong, but it seems to me that the situation in ebXML where you have profiles belonging to the participants in the transaction and then an agreement which specifies what subset of the intersection of the profiles are going to be used for the transaction is not describable in WSDL. I agree that if a definition will include a GET of a page intended for humans it is too broad. However, please note that the HTTP GET that I described was NOT intended for humans, it was intended for use by an application. It is a real case, and that interface will not be changed in a way that is not backwards compatible, since there is at least one application that depends on it. That is, there is a defined interface that has been agreed on by the participants. This still smells to me like a Web service, albeit a very simple one. Looks a lot like one of David Booth's diagrams to me. I don't think it's a good idea to define a Web service in terms of current specifications that implement them. I agree that these may be the best way at this time to implement Web services, but I think it would be better to define the concept itself in such a way that the implementing protocols can be improved. Thus, a bare HTTP GET can be improved greatly by using SOAP, and the description of that interface can be improved greatly by using WSDL or ebXML specs. Perhaps SOAP and WSDL can, in the future, be improved greatly by some semantic technology. The keys to being a Web service, as far as I can see, are in the app-to-app nature of the interaction, the fact that the interfaces are well defined, and the fact that the interaction occurs over the Web (perhaps broadly interpreted). -----Original Message----- From: Doug Bunting [mailto:Doug.Bunting@sun.com] Sent: Tuesday, April 15, 2003 5:29 PM To: Richard.Chennault@kp.org Cc: jim.webber@arjuna.com; www-ws-arch@w3.org; www-ws-arch-request@w3.org Subject: Re: Is This a Web Service? I'm thinking this portion of the many thread splinters occurring over the last 24 hours may be the most important. Richard and Jim are describing important additional use cases and requirements for a Web service definition. I find any Web service definition that includes straightforward, legacy CGI scripts to be overly inclusive and unhelpful when discussing the emerging architecture of interest to this WG. I also believe "must be describable using WSDL" is almost a tautology (excludes almost nothing) and is, when used alone, similarly unhelpful. To some points on this thread and other portions of the web we're spinning, any definition so abstract as to include HTTP GET of an HTML page intended for humans (for example) will not satisfy our requirements. We need a definition that (to Roger's original point) at least answers "no" once in a while when used to answer "is this a web service?". We need to find a definition more concrete than what's in the current Architecture and Requirements documents to inform later decisions about the actual architecture and to be useful. Going the other way, we need to avoid counter proposals that either delve below a line where we can reach consensus or which ignore ignore important considerations others in the group have raised. As Jim described, marginalisation may arise from attempting to make our definition too concrete and specific. That said, I can see an architectural nicety to some of the taxonomies described elsewhere. Subsets of the one definition we find may be interesting in specific areas of the architecture. However, let's focus on the single definition and getting it at a useful level before we start splitting it up. thanx, doug On 2003-04-15 09:57, Richard.Chennault@kp.org wrote: > > +1 to what Jim states. > > To me a Web Service requires WSDL and XML. If WSDL and XML are not > involved then one could theorize that we have always had web-services > once CGI's were born. > > Rregards, > > _________________________________________________ > Richard D. Chennault > > Kaiser Permanente > > > > *"Jim Webber" <jim.webber@arjuna.com>* > Sent by: www-ws-arch-request@w3.org > > 04/15/2003 08:23 AM > > > To: <www-ws-arch@w3.org>, <www-ws-arch-request@w3.org> > cc: > Subject: RE: Is This a Web Service? > > > > > > Roger: > > > Do other people think that if it doesn't use WSDL it's not a > Web > service? I personally don't like this at all. > > Nor do I, but then I have the seemingly contrarian view that SOAP is > implicitly involved :-) (and not necessarily anything to do with the > Web). > > While I can appreciate that this group does not necessarily have to > have a commercially-facing outlook, we are at risk of marginalisation > if the architecture fragments into X different flavours of Web > services. > > Jim > > >
Received on Tuesday, 15 April 2003 21:10:19 UTC