Interoperability of Web Services - Essay Example

Interoperability of Web Services Essay 1 Tourism is the biggest field of application in the Internet today. Experts estimate that about 30% of transactions on the Internet today relates to travel and tourism. Fiercer global competition is likely to call for application of new web technologies that sets in a change in the intermediation services of the industry. The market today is increasingly growing short of patience with divergent standards camps. Lack of direction has raised the issue of when it is judicious for businesses to adopt a new technology specification. This transformation is enforced by changed consumer needs. In Web services there is a need for language and platform independent communication between computers. This means that Web service components should be interoperability. Platform-independent specifications that form the core Web services protocols like SOAP, WSDL, UDDI are powerful. The Web Services Interoperability Organization (WS-I) is an open industry organization that promotes interoperability among Web services across platforms, applications, and programming languages 1. Success of Web services makes it essential that the interoperability between various implementations be guaranteed. The first step in this direction came about with the setting up of the so-called SOAPBuilders Interop Lab that was a virtual lab for builders of SOAP stacks 2. However, with the advent of WSDL and UDDI respectively interoperability testing became noticeably harder. This led to the formation of the Web Services Interoperability Organization. The Web Services Interoperability Organization serves to work out common scenarios and a list of do's and dont's for three areas of interest in Web services 3 – messages, descriptions, and registry data. The best practices have been assembles into a document called the Basic Profile 1.1 that addresses issues of future compatibility with SOAP 1.2 messages etc. Web services being component-based services are likely to involve the service provider, broker and the consumer, SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) and UDDI (Universal Description, Discovery and Integration) are important for business. Web services are based on the service oriented architecture. The service collaboration can happen in several ways . Profiles of the WS-I BP add constraints and guidance on the interoperable usage of the WS-I BP 4. These constrains and guidance are organised around base specifications and are based on implementation experience. Creation of electronic catalogue formats based on EDI/XML standards is likely to open up a new world for buyers and sellers alike. In the future, visitors to virtual stores need not be human. Purchasing Web agents will to roam XML/EDI sites, gathering pricing information and may report information back to their human user 5. These agents may also have embedded discretionary e-cash buying power based on business rules that are defined by their creators. The business (EDI) community stands to benefit from this in many ways. EDI can use technological barriers and help the website to shorten its list of suppliers. EDI is arcane as it has age old cobol like structures, is costly because of high development and support costs, and also requires Value Added Network (VAN). EDI is also error prone as it requires manual data collection and data entry. Technologies competing against EDI are RosettaNet and ebXML. It is expected that RosettaNet will continue to a niche player. ebXML is a complex set of standards and it is trying to solve too many challenges and it can be broken down into modules like ebMS (Messaging services), ebBPSS (Business process Definitions), and ebCPPA (Collaborative protocol for Partner Agreement) 6. There is also the possibility that extensible mark-up language (XML) and the Internet will dramatically reshape the electronic data interchange (EDI) landscape. EDI can drive down the costs and complexity and become a truly ubiquitous technology that will reshape businesses. Traditional EDI is outdated since it is based on fixed transaction sets defined by standard bodies 7 such as the UN Standard Messages Directory for Electronic Data Interchange for Administration among others. Today, EDI is implemented in a one-to-one manner between exchange partners (trading partners). These partnerships can be extended through the tiers to create a supply chain and the new paradigm, the Supply Web. Specifically, various efforts have lead to the creation of a variety of EDI standards. The best known standards are EDIFACT and ANSI X12. The initiative to bring EDI and XML together while retaining the best features will result in XML being used as the data interchange format and as the presentation format. Moreover, XML and EDI can be converted to traditional EDI formats such as EDIFACT and viceversa. XML and EDI can also run across the Web and will be able to use standard TCP/IP and HTTP protocols 8. The travel information services are currently provided by Global Distribution Systems (GDS). A GDS is a sort of hub that provides its subscribers pricing and availability information for multiple travel products. Travel agents, corporate travel departments etc. subscribe to one or more commercial GDSs to check for availability of flights and prices for their customers. Additionally GDS provides hardware, software and technical support to customers although GDSs suffer from problems like relying on own private networks which, being legacy systems, are difficult to interoperate with other systems and data. GDS companies are facing challenges since their system architectures are based on a mainframe TPF (transaction processing facility) framework that even while being very reliable, and capable of tremendous I/O throughput has relatively little CPU power. Moreover, they are exorbitantly expensive to maintain and enhance. GDS companies are trying to catch up in the technology arena and all big GDS companies today have a browser-based system – Sabre, Amadeus and Worldspan. Businesses in the travel sector can look up for partners with the help of the UDDI, much like the way search engines operate in the WWW. Moreover the UDDI can also for finding a run-time naming service for finding a partner just like the DNS 9. The latest UDDI version supports XML signature. The services that are registered with XML signature in UDDI are very reliable. For a suitable interface between systems, one can use the services of WSDL. Apart from WDSL, the business processes or protocols may also be required for smooth collaboration of systems. Bibliography: 1. http://xml.coverpages.org/WS-I-Announce-20020206.html 2. http://www.xmethods.com 3. http://www.ws-i.org/Documents.aspx 4. http://www.ws-i.org/docs/presentations/wsi_netsec_preso_final.ppt 5. http://isoc.org/isoc/conferences/inet/99/proceedings/1i/1i_1.htm 6. http://www.aalayance.com/presentations/ediwebservicepresentation.ppt 7. http://swws.semanticweb.org/public_doc/D1.1.pdf 8. http://www.isoc.org/inet99/proceedings/1i/1i_1.htm 9. http://www.ebi.iao.fraunhofer.de/Web%20Services%20Juli%202003.pdf Essay 2 Most often people believe that there are only two implementations, Document or RPC. In reality, the choices are between what combo of Style and Use to implement such as RPC/ENCODING, RPC/LITERAL and DOCUMENT/LITERAL 1. When people refer to RPC they usually indicate the style. The document versus the RPC style is talked of in the parlance of the SOAP message. Both these ways represent two ways to structure a SOAP message. Early versions of SOAP were designed to support only the RPC style. When SOAP 1.0 spec was published, it expanded to support both RPCs and unstructured messages – the document. While using the Document style, one can structure the contents of the SOAP Body in any way. However, when using RPC style, the contents of SOAP Body need to conform to a structure indicating method name and contain a set of parameters 1. The bigger difference between Document and RPC style is in the encoding of messages 2. Usually literal encoding with Document style and SOAP encoding with RPC style is used. Literal encoding means that Body contents conform to a specific XML Schema. SOAP encoding uses a set of rules based on the XML Schema datatypes to encode the data, although the message does not conform to a particular schema. SOAP encoding is especially useful when passing cyclic object graphs. For instance, for a single element referenced repeatedly within the object graph, the element is required to be specified only once and then referenced as needed. However, when using literal encoding, the element has to be repeated each time it's referenced. Thus it appears to be a good idea to use SOAP encoding, although in doing so one can't validate the message with an XML Schema not transform the message using XSLT. In RPC style Web Services, the complete method is specified in WSDL file and in SOAP body 3. This method includes sent parameters and return values and so a tight coupling with this style is possible. RPC style has several strengths. First, definition of the WSDL file can be formatted in a well-known remote-procedure-call style. Second, operation name appears in message and enables the receiver to easily dispatch message for implementation. This is the only style possible when using data graphs or polymorphism in the service. Finally, most early Java implementations use only RPC style. RPC style, however, has weaknesses. First, SOAP message includes type-encoding information that is an overhead. Second, one cannot validate using a schema because type information is stored in the message and not a schema. Third, any change to interface breaks the contract between service and client because there is a tight coupling between the service provider and client. Finally, RPC style is not supported by WSI conformance standard. In RPC/Literal Style, style remains RPC but WSDL has 'use' setting changed from 'encoded' to 'literal' in soap:body 4. This means that data is serialized according to given schema. The strengths include a straightforward WSDL, appearance of operation name in SOAP message, and a higher throughput performance since type encoding is removed from message. There are some weaknesses here, such as break in contract between service and client with any changes to interface, schema insufficient in describing an RPC/Literal message, and non-support by the WSI conformance standard. In Document style Web Services, client sends standard XML document to server where server application is responsible for mapping server objects as well as values in XML documents. Here protocol places no constraint on how the document can be structured. The style has several strengths like non-requirement of type encoding information in SOAP message, possibility of validating message with an XML Schema, and less rigid rules providing for enhancements and changes to the XML schema without breaking the interface 5. The weaknesses, however, includes loss of operation name in SOAP message that makes dispatching difficult. The Document/Literal is a Microsoft proposal and even though there is no specification in the WSDL 1.1 standard for this style, many current SOAP toolkits support it 5. The strengths are that it contains all the strengths of Document/Literal style and the method name appears in the SOAP message. The weaknesses for this style includes inability to use this style if there is are overloaded operations in the Web Service. After a toe-to-toe match it is usually a win for the document style. The WS-I Basic profile 1.1 discourages use of RPC/Encoded approach and motivates Document/Literal 5 and RPC/Literal as the only allowed style/use combination. Industry leaders believe that RPC/Literal will disappear future versions of the WSI profile. Today several standards of web services have emerged. Several technologies combine to make up ‘Web Services’, the main standard being XML. XML is a popular portable technology developed by the World Wide Web Consortium. It is a meta-language for describing data and creating additional markup languages and XML tags. XML documents are text-based and are made up of XML tags. XML serves as the basis for several core Web services standards like SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) and the UDDI (Universal Description, Discovery and Integration Specification). SOAP enables programs on separate computers to interact across any network. It is a simple markup language for describing messages between applications. Developers use SOAP to integrate applications and business processes across the Web or intranet, through platform and programming languages 6. WSDL is another XML vocabulary standard created specifically for Web Services. WSDL allows developers to describe Web Services and their capabilities and also helps expose Web Services of various businesses for public access. UDDI is a framework that defines XML-based registries where businesses can upload information about themselves and the services they offer. XML-based registry contains names of organizations, services provided, as well as the descriptions about the capabilities of the services. There are several other web services like .NET Web Services that includes Visual Basic.NET, Java Web Services, and DIME 7. The .NET platform is one of the most complete environments for building, deploying and accessing Web Services. It supports multiple programming languages and tools for reusing code. Using Visual Basic.NET is one way of implementing Web Services. Java Web Services is ideal for building Internet applications, including applications based on Web services. The DIME (Direct Internet Message Encapsulation) is a lightweight binary message format that is used for moving data into the SOAP message packets 7. Bibliography: 1. http://www-128.ibm.com/developerworks/webservices/library/ws-soapenc/ 2. http://searchwebservices.techtarget.com/ateQuestionNResponse/0,289625,sid26_cid494324_tax289201 3. http://www.c-sharpcorner.com/UploadFile/martinkropp/DesigningInteroperableWebService11232005044847AM/DesigningInteroperableWebService.aspx?ArticleID=b70e7c59-9357-4908-9114-fcc928869e69 4. http://www.c-sharpcorner.com/Code/2005/March/InteroperableWS.asp 5. http://www.eherenow.com/soapfight.htm 6. http://www.hitmill.com/webservices/main.asp 7. http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci934542,00.html Read More