'''Web service: an Internet-accessible software component that is:''' * self-contained * self-describing "see WsdlForRest" * 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) ---- 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 http://www.service-architecture.com/images/architecture.jpg ''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 ''' WebServices 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 (read StructureAndInterpretationOfComputerPrograms). 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:''' * XML Schemas http://www.w3.org/TR/xmlschema-0/ * UDDI (Universal Discovery, Description, and Integration) http://www.uddi.org * WSDL ( WebServicesDescriptionLanguage) http://www.ibm.com/developerworks/library/w-wsdl.html ** see also OwlForServices * SOAP (The SimpleObjectAccessProtocol, 1.1) http://www.w3.org/TR/SOAP/ * XML-RPC (XmlRpc) - the lightweight alternative to (or offspring from) SOAP * ebXML http://www.ebXML.org (which leverages SOAP - http://www.ebxml.org/news/pr_20010222.htm) ''' ''I do not know much about the subject matter. However more than one article has stated that there are only three common implementations'' ''' * ''' ''SimpleObjectAccessProtocol (SOAP) - most widely known. Think of it as Windows for messaging'' ''' * ''' ''XmlRpc (XML-RPC) - performance is its strength. Think of it as Linux for messaging'' ''' * ''' ''RepresentationalStateTransfer (REST) - most widely used if available. Think of it as Mac for messaging'' ''' ''' ''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?''' '' * See also KissWebServices -- DavidLiu ''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 at http://www.service-architecture.com/web-services/articles/organizations.html ---- '''SecurityManagement concerns''' ZapThink 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 http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1083614,00.html ---- '''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 engines are: * J2EE's JAX-packs: JAXR, JAXB, JAX-RPC, JAXM, JAXP. http://java.sun.com/xml/ * Microsoft DotNetRemoting / AspDotNet Web Services http://msdn.microsoft.com/ * ApacheAxis (Java) http://xml.apache.org/axis/ * Open source packages for other languages are emerging The competing implementations of tools, frameworks, and systems that support WebServices are: * SunMicrosystems' JavaEnterpriseSystem (JES) - http://wwws.sun.com/software/javaenterprisesystem/ * Microsoft VisualStudioDotNet - http://msdn.microsoft.com/vstudio/ * IBM's WebSphere Architecture (which uses Apache SOAP) ** http://www-3.ibm.com/software/webservers/appserv/appserv_v5.html ** http://www-3.ibm.com/software/ad/studioappdev/ * Oracle's Dynamic Services - http://technet.oracle.com/tech/webservices/content.html * BEA's WeblogicWorkshop - http://bea.com/products/weblogic/workshop/index.shtml * The Mind Electric's GLUE (Java) - http://www.themindelectric.com/ * Systinet - http://www.systinet.com/ ---- '''WebServices without HTTP''' Examples maybe those transported using MessageOrientedMiddleware like BigBlue MQSeries, or via SMTP. Source: article listed in PublicKeyInfrastructure SSL subsection. ---- '''Examples''' http://www.eaves.org/google/howcool ''Completely useless (or is it?) application using Google's WebServices API'' ---- '''QuickQuestions''' '''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'' '''A''' '''Q''' Any experiences related to WebServicesTesting? -- RaghuHavaldar '''A''' ---- '''Interoperability aspects''' BusinessProcessExecutionLanguage''''''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/ UniversalBusinessLanguage (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 activities. ---- '''Learning Resources''' * Oreilly sample chapter shows example of tinkering needed for Perl to communicate with DotNet. See http://www.oreilly.com/catalog/progwebsoap/chapter/ch03.html ---- '''WebServices UserStories''' * ''Lessons from companies that have embraced ServiceOrientedArchitecture'' http://www.computerworld.com/printthis/2004/0,4814,95207,00.html * ''standardisation efforts for WebServices'' http://searchwebservices.techtarget.com/tip/1,289483,sid26_gci965479,00.html * ''Users getting confused by different standards bodies '' http://www.zdnet.com.au/insight/software/print.htm?TYPE=story&AT=39151273-39023769t-10000102c ---- (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..'' -- StuCharlton ---- * 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 ---- A WebServicesRoadMap has been created where you can find topics about WebServices organized by categories. ---- '''Reading material''' * ''WhosWHO in WebServices 2002'' http://www.pcmag.com/print_article/0,1761,a=27538,00.asp * ''ClayShirky to spoil it again (share context problem not solved)'' at http://webservices.xml.com/lpt/a/ws/2001/10/03/webservices.html * ''WebServices as realization of SOA'' at http://searchwebservices.techtarget.com/searchWebServices/downloads/Weer_CH03.pdf ''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 * Will ServiceOrientedArchitecture be much the same three years hence? ---- See also: WebServicesDiscussion, WebServicesDescriptionLanguage (WSDL), ServiceOrientedArchitecture, WhatIsSoa ---- CategoryXml CategoryMessagingServices