WebServices (ideally) have several attributes. Here are some more detailed discussions of these attributes (as claimed on the parent page), particularly how they're realized today.
WebServices are encapsulated, that is, they separate their interface from their implementation, and the only way to interact with a service is through its interface. You cannot use a "back door" to get at a service's underlying data or implementation.
WebServices rely on TaggedData
?. Tagged data is self-describing, in that it associates symbols with values. Traditional distributed computing technologies had mandatory extrinsic interface definitions -- flat files needed field layouts, CORBA RPC's required interface description languages, etc. It was jibberish without them. With
WebServices, you can pretty much interpret an XML stream however you'd like.
In practice,
WebServices do rely on extrinsic definitions to supplement the tags as a way to ease the integration effort. XML Schemas and WSDL are examples of this. Self-description is "not enough", there also needs to be facilities to "ask questions" about what the web services support. Thus, most web service stacks provide ways of discovering these capabilities, conventions to ask for a WSDL file, or WsPolicy
? and WS-PolicyAssertions
? to determine reliability, security, and other non-functional capabilities.
Web services are really just network endpoints transferring XML documents. A web service can be statically composed of other web services (i.e. mash-ups), or it can be dynamically composed by intermediaries (which determines what the "next hop" in an invocation chain should be, and does the necessary data transformations). The
EnterpriseServiceBus architecture is gaining traction as the way to "dynamically compose" web services out of other web services.
- universally interoperable (platform, language, and protocol)
XML is something that all platforms can read, languages can parse, and transport protocols can carry.
- potentially configurable at run-time (in quality of service and security, for instance)
The WsPolicy
? family of specifications seek to achieve this today. For example, a service that supports reliable messaging can be told to use exactly once reliability or best effort, or a service that supports WS Security can be asked to use Kerberos tickets instead of an x509 certificate, or can be asked to digitally sign all of its messages.
- bound, published, and located through distributed registries (which are themselves services)
Sometimes being queryable is "not enough" to understand service capabilities, as it requires you to have a priori knowledge of the service's existence. Hence the need for centralized registries that contain some level of metadata & extrinsic descriptions of the service's capabilities. UDDI registries are perhaps the best example of this, but any website with a directory of web services, documentation about how to use them, and a REST-like interface is "good enough".
I wrote the original WebServices page back in late Summer of 2000, if I recall correctly. The definition above was idealistic and abstract, because all we had back then was wishful thinking. Today, I still think it holds up, and a lot of the dreams are now reality (to some degree). Though I'd also note that most of these attributes are applicable to ServiceOrientedArchitecture in general. --StuCharlton
See also SoaIsPeace
Web Services Attributes