Web service: an Internet-accessible software component that is: - self-contained - self-describing "see Wsdl For Rest" - queryable - dynamically composable - universally interoperable (platform, language, and protocol) - potentially configurable at run-time (in quality of service and security, for instance) - bound, published, and located through distributed registries (which are themselves services)
In summary, Web services are effectively another attempt at solving the "holy grail" of Distributed Computing: a platform that will finally enable ubiquitous distributed components and composable systems to be written by average developers - c2.com 
Prior attempts have met with mixed results (some of which are Sun RPC, DCE RPC, DCOM, CORBA, and RMI)
> "Many have tried." "They tried and failed?" "They tried and died." > > Reverend Mother Helen Moah'im, ''Dune''
---
Early Discussion from C2.com: - Web Services Discussion - Web Services Attributes
# Dicussion below form c2.com
See a nice picture from www.service-architecture.com
www.service-architecture.com
Comparisons with a Soa Implementation Framework inspired implementation?
Web Services under the influence of the dreaded Xml
Web Services are different in that the common data representation is XML, or more specifically, the Xml Info Set. XML provides a standardized information set for specifying messages between software services, one that is independent of processing model. The text-based extensible markup language is the 'least common denominator' encoding method Xml Info Set.
The effect of XML is to enable what is effectively a semantic data stream for all messages. SDS is a concept coined by Oliver Sims, but one that has a heritage in the Lisp Language (read Structure And Interpretation Of Computer Programs). SDS implies carrying the structure of the message (its metadata) along with the message, as opposed to completely relying on extrinsic definition of interface or data structure.
Carrying along this "metadata" is crucial to allow for loose coupling, dynamic binding and run-time interoperability. This is the key difference between the Web Services approach and previous approaches, which relied heavily on immutable interfaces, early binding, and/or high coupling to a particular platform or object model.
The other key aspect to Web Services is the simplicity of its architecture compared to former models. Xml Schema throws a fair amount of complexity into the mix, so this simplicity isn't guaranteed to last. In the short term, the higher bandwidth consumption of XML versus binary data representations is the primary trade-off made to achieve this simplicity. In the long term, binary encodings of the Xml Info Set will enable high-performance Web Services.
The current specifications to enable Web services are:
XML Schemas www.w3.org
UDDI (Universal Discovery, Description, and Integration) www.uddi.org
see also Owl For Services
SOAP (The Simple Object Access Protocol, 1.1) www.w3.org
XML-RPC (Xml Rpc) - the lightweight alternative to (or offspring from) SOAP
ebXML www.ebXML.org (which leverages SOAP - www.ebxml.org )
I do not know much about the subject matter. However more than one article has stated that there are only three common implementations
Simple Object Access Protocol (SOAP) - most widely known. Think of it as Windows for messaging
Xml Rpc (XML-RPC) - performance is its strength. Think of it as Linux for messaging
Representational State Transfer (REST) - most widely used if available. Think of it as Mac for messaging
see for example: www.hebig.org
Assuming what I have here is ok, can someone in the know merge this with the above?
See also Kiss Web Services -- David Liu
SOAP implies XML Schemas or Relax-NG, WSDL, and UDDI. There are also the whole boatload of WS-* specifications coming from IBM, Microsoft, and BEA. ebXML is another kind of web service, though more niche. Those articles you've read are talking in broad strokes.
Check out the list of organizations and consortia involved in Web Services at www.service-architecture.com
Security Management concerns
Zap Think analyst said "XML and Web services cut through existing firewalls and email-based spam and virus filters like a hot knife through butter"
more at "XML viruses threaten Web services security" article at searchwebservices.techtarget.com
Web Services for the REST of us
The most common transport protocol used will be HTTP, since it is ubiquitous and "firewall safe". Of course, the Real World will require differing levels of service or security, hence the perceived need for protocol independence.
An emerging debate about the shape of Web services is whether all these extra XML protocols and interfaces provide enough value in exchange for their complexity. The Rest Architectural Style is an alternative way of building Web services. Their premise is that HTTP in and of itself has the set of "verbs" (GET, POST, etc) we need to implement Web services. All we need new are lots of "nouns" (URIs).
A lot of big guys are making noise about Web services; currently the grassroots are doing the work of implementing real-world services.
The main competing implementations of XML Web Services engines are:
J2EE's JAX-packs: JAXR, JAXB, JAX-RPC, JAXM, JAXP. java.sun.com
Microsoft Dot Net Remoting / Asp Dot Net Web Services msdn.microsoft.com
Apache Axis (Java) xml.apache.org
Open source packages for other languages are emerging
The competing implementations of tools, frameworks, and systems that support Web Services are:
Microsoft Visual Studio Dot Net - msdn.microsoft.com
IBM's Web Sphere Architecture (which uses Apache SOAP)
Oracle's Dynamic Services - technet.oracle.com
BEA's Weblogic Workshop - bea.com
The Mind Electric's GLUE (Java) - www.themindelectric.com
Systinet - www.systinet.com
Web Services without HTTP
Examples maybe those transported using Message Oriented Middleware like Big Blue MQSeries, or via SMTP. Source: article listed in Public Key Infrastructure SSL subsection.
Examples
www.eaves.org
Completely useless (or is it?) application using Google's Web Services API
Q Looking for a simplge way to wrap Big Blue functionality into Rest Architectural Style Web Services without using Soap Protocol offered in Ci Cs 2.2. We have Db Two version 6
A
Q Any experiences related to Web Services Testing? -- Raghu Havaldar
A
Interoperability aspects
Business Process Execution LanguageforWebServices (BPEL4WS or just BPEL) is meant to be an execution environment independent mechanism for long running conversions between organizations. However there are efforts to have language specific extensions (e.g. BPELJ) that diminishs interoperability. See www.theregister.co.uk
Universal Business Language (UBL) is another Extensible Markup Language based specification intended to reduce communication barrier between applications through due to semantic variances. See searchwebservices.techtarget.com
Both can be considered to be higher level Work Flow activities.
Learning Resources
Oreilly sample chapter shows example of tinkering needed for Perl to communicate with Dot Net. See www.oreilly.com
Lessons from companies that have embraced Service Oriented Architecture www.computerworld.com
standardisation efforts for Web Services searchwebservices.techtarget.com
Users getting confused by different standards bodies www.zdnet.com.au
(Dru here - and yes, Web Services will die too. This technology completely ignores certain _unwritten_truths_ about internet technologies, and will end up being a huge, performance sucking monster. Lets see how long this stays here.)
All technologies die. The question is whether they provided value and paid the bills while they were alive. Thus far, WS are doing okay.. -- Stu Charlton
What use is a dynamic schema if the receiving party does not know about a change?
The whole point is that new extensions to the schema may be applicable to some receivers, but not others. That I can ignore those extensions the benefit. This is actually a distributed systems application of one of Uncle Bob's principles - the Interface Segregation Principle. You pay attention to the smallest amount XML that matters to you. Prior approaches were "strong typed first", and only had secondary facilities for this kind of flexibility - Corba DII, COM Automation, etc. -- Stu Charlton
Anyone used a non HTTP based transport? Why and did it work well? -- dl
I've used Web Logic JMS, MQSeries, and plain-old TCP. HTTP really isn't necessary sometimes, and if you're doing asynchronous callbacks to a client, it doesn't make sense for that client to implement an HTTP server. Anyway, It works fine. Just have to be aware of what functionality of HTTP you might have assumed you were getting for free - SSL+HTTP authentication, for example. -- Stu Charlton
Incidentally, asynchronous message patterns are a weakness of current web service specifications (WSDL) which assume that everything is a query-response or invoke-acknowledge one-shot interaction, rather than a two-way conversation. Agent-based systems have dealt with more complex conversation protocols for a long time now. -- David Allsopp
I think this is partly because of an unwritten assumption that web services are stateless. This obviously isn't always the case. Web Logic 9 (and Workshop 8.1) introduced some WSDL extensions to indicate conversation-based message exchange patterns (start/continue/finish). I believe the Web Logic 9 ones are based on Ws Addressing so are more standards-base (though the 8.1 conversation header has pretty easy to hookup with non-Web Logic services). -- Stu Charlton
A Web Services Road Map has been created where you can find topics about Web Services organized by categories.
Reading material
WhosWHO in Web Services 2002 www.pcmag.com
Clay Shirky to spoil it again (share context problem not solved) at webservices.xml.com
Web Services as realization of SOA at searchwebservices.techtarget.com
Old (3 years or more) material can still be interesting
2002 "Web Services Enters a Critical Phase" at www.entmag.com
Will Service Oriented Architecture be much the same three years hence?
See also: Web Services Discussion, Web Services Description Language (WSDL), Service Oriented Architecture, What Is Soa
See original on c2.com