RE: Web Service Definition [Was "Some Thoughts ..."]

I believe that our charter specifies that XML must be used. [1]


Regards,

D-

[1] http://www.w3.org/2002/01/ws-arch-charter#arch

> -----Original Message-----
> From: David Orchard [mailto:david.orchard@bea.com]
> Sent: Thursday, February 21, 2002 3:51 PM
> To: www-ws-arch@w3.org
> Subject: RE: Web Service Definition [Was "Some Thoughts ..."]
> 
> 
> If URIs, XML, HTTP, HTML, SOAP are not required for web 
> services, why are we
> doing this at the world-wide web consortium?  There's nothing 
> left of "the
> web" in web services.   We should just call it software services or
> something else without "web".  Also, I'm not sure how the 
> Director would
> treat a requirements document that says URIs, XML, HTTP, HTML 
> are optional
> and not required but WSDL is required.  I have a suspicion 
> there would be
> some pushback.
> 
> Our charter is very clear that web services architecture most 
> hold to "web
> principles".   Now sadly, we don't have an official web 
> principles document,
> though it is in progress at the TAG.  However, we do have a number of
> quasi-normative documents for defining web principles, such as Roy
> Fielding's thesis and the various TimBL design notes.  I 
> argue that URIs and
> markup are the minimum required to be part of the web and web 
> services.  I
> do think that binary formats like SSL are included in the 
> web, because the
> binary format is simply a transformation of markup.  If it's not-uri
> addressable and has a binary format that isn't derived from 
> markup, that's
> cool and fine, but it's not part of the web, imho.
> 
> 
> Cheers,
> Dave
> 
> > -----Original Message-----
> > From: Heather Kreger [mailto:kreger@us.ibm.com]
> > Sent: Thursday, February 21, 2002 1:10 PM
> > To: David Orchard
> > Cc: www-ws-arch@w3.org
> > Subject: RE: Web Service Definition [Was "Some Thoughts ..."]
> >
> >
> > WSDL defines the location (access point) for a web service.
> > That location
> > is not restricted to be
> > a URI, although there is no doubt that this will be the most
> > common usage.
> > It could also be
> > a set of properties required to set up the access.  I have
> > seen examples of
> > this approach
> > when addressing messaging systems. One could always argue
> > that the set of
> > properties
> > could be represented as a URI convention.
> >
> > WSDL does not force you to use a XML protocol. Binary
> > protocols can be used
> > and may be
> > popular within enterprises. Of course, your potential client
> > base may be
> > reduced.
> >
> > Heather
> >
> > "David Orchard" <david.orchard@bea.com>@w3.org on 02/21/2002
> > 03:43:07 PM
> >
> > Sent by:    www-ws-arch-request@w3.org
> >
> >
> > To:    <www-ws-arch@w3.org>
> > cc:
> > Subject:    RE: Web Service Definition [Was "Some Thoughts ..."]
> >
> >
> >
> > 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 Friday, 22 February 2002 18:00:21 UTC