- From: David Orchard <david.orchard@bea.com>
- Date: Thu, 21 Feb 2002 12:43:07 -0800
- To: <www-ws-arch@w3.org>
If we think of the web as URIs, HTML, HTTP, we probably should touch on how web services are similar/different from the web. A definition that I tend to like for web is "The web consists of resources identified by URIs that send/receive markup formatted messages, typically XML or HTML, and accessed via network protocols such as HTTP". I lobbied for this kind of definition in the upcoming TAG Web architecture document. The TAG discussed this at the F2F [1], though we have't formally captured this yet. From the core 3 web protocols, it seems that web services loosen the html definition into markup of either html or xml and further loosens the HTTP definition into network protocols. I firmly believe that the web services definition should completely fit inside the web definition. I'm struggling with the fact that the IBM definition does not mention URIs nor does it require markup. Further, it allows an HTML page (with WSDL) to classify as a web service. A different wording might be "Web services are web resources that are described by WSDL". Another wording might be "Web services are web resources that are accessed using SOAP and possibly defined by WSDL". Yet another definition is "Web services are web resources that are either accessed using SOAP or defined by WSDL". I think it's important for us to distinguish between the web and web services in a very clear manner, and that web services definition should be completely contained (ie a refinement) of the web definition. Cheers, Dave [1] http://www.w3.org/2002/02/12-tagmem-irc.html > -----Original Message----- > From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On > Behalf Of Heather Kreger > Sent: Thursday, February 21, 2002 12:18 PM > To: www-ws-arch@w3.org > Subject: RE: Web Service Definition [Was "Some Thoughts ..."] > > > As long as we are offering up definitions, > Here is a definition of a Web service that we actually agreed > upon within > IBM. > > 'Web services are software components described via WSDL > which are capable > of > being accessed via standard network protocols such as SOAP over HTTP" > > Please note that it is important that SOAP not be REQUIRED in order to > qualify > as a Web services. It is also important to note that the > network protocol > not be restrictive - > i.e. HTTP or 'Web Protocols'. Even the term 'internet' > protocol needs to > be > interpreted correctly... is that anything over TCP/IP? Or only things > defined by > the IETF? > > We recognize that SOAP and HTTP are critical to > interoperability between > vendors, > but the internal application integration application of Web > services do not > require it. > The way we are phrasing this is that SOAP and HTTP are > important and the > fact > that they are the only bindings in use today is a function of > the maturity > of this > emerging industry, not an indicator that they are the only > ones that we > need. > > > Heather Kreger > IBM Web Services Lead Architect > > "Cutler, Roger (RogerCutler)" > <RogerCutler@chevrontexaco.com>@w3.org on > 02/17/2002 03:17:14 PM > > Sent by: www-ws-arch-request@w3.org > > > To: "'Champion, Mike'" <Mike.Champion@softwareag-usa.com>, > www-ws-arch@w3.org > cc: > Subject: RE: Web Service Definition [Was "Some Thoughts ..."] > > > > > I thought that web services were supposed to include entire > processes that > might involve a number of data transmissions and provision > of services > from a number of sites??? If that is true, doesn't your > definition of a > web service actually describe a component of a web service? > > Another thing -- I don't think that the resolution of a web service > necessarily has to be done entirely via software. That is, > one could have > a process where some of the components occur via human actions (e.g. > expenditure approvals). > > I'm not good at crafting these phrases, but in the spirit of not just > being critical let me take a wild stab ... > > A web service is a process in which the communication > between the service > providers and requesters takes place over the web via XML. > > Yeah, well, I told you I wasn't good at this ... > > -----Original Message----- > From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com] > Sent: Saturday, February 16, 2002 12:31 PM > To: www-ws-arch@w3.org > Subject: RE: Some Thoughts about Goals > > > I think I agree with most of these points. I'd phrase my > position as: > > a) we need at least a fuzzy definition of "web services" up > front so that > we can make sure that we're all on more or less the same page when > defining an architecture for them. > > b) that definition should in principle be general enough to include > multiple message exchange patters including the "RPC over > HTTP" model that > is currently dominant, the more traditional "EDI using XML and the > Internet", and the emerging "Next generation web services > based on REST > principles" (see http://www.xml.com/pub/a/2002/02/06/rest.html) > > > c) Ideally, this group would take the time to make sure that the > architecture is "right" before releasing it. I believe that > the history > of the internet and software industry shows clearly that > "the best is the > enemy of the good." That is, those who take time to do it > "right" are > left in the dust because a barely adequate solution beats no solution > every time, and technology (and business reality) changes rapidly > and unpredictably, so multi-year projects almost always look much > different at the end than anticipated at the beginning. So, some > meta-requirements are: > > The work must proceed by successive refinement, starting > crude, and > iteratively fleshing out details based on feedback from > the "customers" > and the experience of web services projects and products > in the real > world. > The architecture must be modular and relatively decoupled > (or perhaps > "must employ best practices to help ensure that it can evolve > gracefully as conditions and requirements change"). > Time to market is indeed critical; if the architecture this group > defines diverges sharply from common practice, it will > not have much > impact (the OSI 7-layer networking reference architecture is often > cited as a bad example here). > Simplicity (in the sense of being understandable and > implementable) is > also critical, partly because it supports the "time to market" > requirement, and partly so that it can be communicated to > interested > parties as efficiently as possible. > > > > d) Bare minimum requirements for the architecture itself are: > > Provide for rigorous definition of web service invocation mechanisms > (URIs, SOAP, and something like WSDL) to ensure interoperability > Support platform/vendor/language neutrality > Suitability to real-world business needs (not just adding numbers or > checking stocks!) > Cover both synchronous and asynchronous message exchange patterns > Define components that can ensure reliable messaging. > Define components that guarantee secure and auditable/nonrepudiable > messaging > Support ork flow (== orchestration?) efinition [not sure > if this is an > absolute requirement for v 1.0) > > Finally, "what is a web service". FWIW, I typed that string > (and some > variants) into Google and got the following useful URLs: > http://www.oreillynet.com/pub/a/webservices/2002/02/12/webserv > icefaqs.html > http://www.xml.com/pub/a/2001/04/04/webservices/ > http://www.gotdotnet.com/playground/services/ > http://www.zdnet.com/anchordesk/stories/story/0,10738,2847589,00.html > http://iwsun4.infoworld.com/articles/hn/xml/01/03/12/010312hnw > ebserv.xml > http://www.devx.com/dotnet/articles/cp0901/cp0901-1/waws.asp > > My best shot at a "strawman" definition that is consistent > with the goals > and meta-goals I described above is: > > "A web service is is a software application or component that can be > accessed over the Internet using a > vendor/platform/language-neutral data > interchange format to invoke the service and supply the > response, using a > rigorously defined message exchange pattern, and producing a > result that > is sufficiently well-defined to be processed by a software > application." > > Some discussion points for this definition: > > "Web" in my mind implies HTTP; I would assert that a 'web > service' could > be accessed via BEEP, SMTP, raw sockets, UDP, or any other protocol > that uses IP as an underpinning. So, "web services" are > really "internet > services" IMHO. > > I'd be happy to put substitute "XML" for "a > vendor/platform/language-neutral data interchange format" , > but I'm not at > all sure that XML is *really* a requirement for what we're doing. My > thought is that SOAP 1.2 is defined on the XML InfoSet > rather than syntax > and some other format that can map to the infoset (e.g., a > URI-encoded > string representing an infoset) could in principle be used. > I'm not sure > we want to split this hair, and "XML" is obviously a good > shorthand for > "some syntax that can be mapped into the XML Infoset". > > I don't currently believe that SOAP is integral to the > *definition* of a > web service, but I might be persuaded otherwise ... > > The "result that is sufficiently well-defined" bit is an attempt to > distinguish a 'web service' from any random page on the Web. > > I have avoided the whole issue of discovery; as far as I can > see a "web > service" that is only discovered by human interaction is still a "web > service." That doesn't mean we shouldn't address discovery in the > architecture ... > > I avoided the security/reliability issues in the definition; > an insecure > web service over an unreliable protocol is still a 'web > service", albeit a > lousy one. > > Again, this is a strawman definition, whack away! > > > > -----Original Message----- > From: Cutler, Roger (RogerCutler) > [mailto:RogerCutler@chevrontexaco.com] > Sent: Saturday, February 16, 2002 12:00 PM > To: www-ws-arch@w3.org > Subject: Some Thoughts about Goals > > > > I'd like to talk about goals for a minute from a slightly different > perspective. Please forgive me if I dwell on the painfully > obvious or > ramble a bit. My objective here is not to substitute > different goals for > the ones being discussed, but perhaps to find out if there > is something > missing from them. > > It seems that there is a slight level of discomfort in the > group because > we do not have a clear definition of what a "web service" is. I am > personally quite willing to discover this during the process, > but I do > admit that there is a certain odd aspect to the situation. > On the other > hand, the discomfort level really does seem to be quite low. > Why is this? > Well, I think that most people sort of feel, "I'm not sure I > can define > it, but I know it when I see it". Now why would this be? > Well, it seems > to me that most people have the feeling that web services > should end up > with at least some reasonable subset of the functions of > systems that they > already know about -- like CORBA and Grid. So why not just use these > systems that are already there? Probably because we want to have a > standards-based solution on the web that is used by a wider > cross-section > of end users and/or is less costly than current solutions. > So one goal -- > and this one is certainly painfully obvious but perhaps worth stating > anyway -- is that the architecture be accepted by as many as the > stakeholders as possible. We want .Net-ers and Java-ers, > creators of open > source and proprietary masterpieces, all to say, "Yup, I can > work in that > framework". > > So, are all the stakeholders at the table? > > I am a little concerned that I am getting the impression > that systems like > CORBA and Grid are being used as models for goals but > perhaps not EDI??? > I don't know the people in this group very well -- are there any EDI > people here? I myself am hardly an EDI expert but I have > access to them. > I could imagine that EDI might be under-represented because > at least some > of these folks seem to want to close their eyes until XML > goes away. I > have heard, in this community, the phrase "flavor of the > month" used with > the implication that if you just wait a bit there will be some other > enthusiasm that will replace XML solutions. I think we > understand that > this is a bad call, and I think the EDI people are beginning > to realize > that too, but at least among those I know there is still not a lot of > active participation. > > Now I personally think that the EDI model is very important. > One of the > things that we want web services to do -- a "goal" perhaps > in a different > sense -- is to be capable of handling business transactions EDI is a > mature, functioning system that does just that. Web services should > support at least some subset of EDI functions. > > As I said, I'm not an EDI expert, but let me guess some of > the things that > are important in EDI that web services should probably also support: > > Reliable messaging. > Audit trails > The usual security suspects - e.g. authorization, nonrepudiation, > secure transmission, etc > Ability to transmit large volumes of data efficiently (?) > Work flow definition > Contingency processing (or something like that) > ??? Probably a bunch of important stuff I don't know about at the > moment ???? > > Soooo -- I guess I'm asking you folks: Do you agree with > these concerns? > If so, do the goals as presently articulated address them? > > > >
Received on Thursday, 21 February 2002 15:44:13 UTC