Web service: an Internet-accessible software component that is:
- self-describing "see WsdlForRest"
- 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)
For the benefit of novices like myself, could someone please explain the above attributes, preferably with an example? In particular, 'dynamically composable'.
Discuss the attributes here: WebServicesAttributes
See a nice picture from http://www.service-architecture.com/index.html
Comparisons with a SoaImplementationFramework inspired implementation?
In summary, Web services are effectively another attempt at solving the "holy grail" of DistributedComputing
: a platform that will finally enable ubiquitous distributed components and composable systems to be written by average developers. 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
WebServices under the influence of the dreaded Xml
are different in that the common data representation is XML, or more specifically, the XmlInfoSet
. 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 XmlInfoSet
The effect of XML is to enable what is effectively a semantic data stream
for all messages. SDS is a concept coined by OliverSims
, but one that has a heritage in the LispLanguage
). 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 WebServices
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 WebServices
is the simplicity
of its architecture compared to former models. XmlSchema
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 XmlInfoSet
will enable high-performance WebServices
The current specifications to enable Web services are:
I do not know much about the subject matter. However more than one article has stated that there are only three common implementations
see for example: http://www.hebig.org/blogs/archives/main/000046.php
Assuming what I have here is ok, can someone in the know merge this with the above?
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 WebServices
analyst said "XML and Web services cut through existing firewalls and email-based spam and virus filters like a hot knife through butter"
WebServices for the REST of us
The most common transport protocol used will be HTTP, since it is ubiquitous and "firewall safe". Of course, the RealWorld
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 RestArchitecturalStyle
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 WebServices
The competing implementations of tools, frameworks, and systems that support WebServices
WebServices without HTTP
Examples maybe those transported using MessageOrientedMiddleware
MQSeries, or via SMTP. Source: article listed in PublicKeyInfrastructure
Completely useless (or is it?) application using Google's WebServices API
Q Looking for a simplge way to wrap BigBlue functionality into RestArchitecturalStyle WebServices without using SoapProtocol offered in CiCs 2.2. We have DbTwo version 6
Any experiences related to WebServicesTesting?
? -- RaghuHavaldar?
forWebServices (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 http://www.theregister.co.uk/2004/03/24/ibm_moots_bpeljava_fusion/
(UBL) is another ExtensibleMarkupLanguage
based specification intended to reduce communication barrier between applications through due to semantic variances. See http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci970231,00.html
Both can be considered to be higher level WorkFlow
(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..
- 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 UncleBob
's principles - the InterfaceSegregationPrinciple
. 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. -- StuCharlton
- Anyone used a non HTTP based transport? Why and did it work well? -- dl
I've used WebLogic
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. -- StuCharlton
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. -- DavidAllsopp
I think this is partly because of an unwritten assumption that web services are stateless. This obviously isn't always the case. WebLogic
9 (and Workshop 8.1) introduced some WSDL extensions to indicate conversation-based message exchange patterns (start/continue/finish). I believe the WebLogic
9 ones are based on WsAddressing?
so are more standards-base (though the 8.1 conversation header has pretty easy to hookup with non-WebLogic
services). -- StuCharlton
has been created where you can find topics about WebServices
organized by categories.
Old (3 years or more) material can still be interesting
2002 "Web Services Enters a Critical Phase" at http://www.entmag.com/news/print.asp?EditorialsID=5394
See also: WebServicesDiscussion