Introduction To Web Services A brief Introduction to Web Services

[andrewsmithy 1]

FORENOTE: I did this as my research paper for an English class, and I thought I would post it here. It's quite long (6 pages), but may be helpful for you here. I don't know. Reply if you like it.Andrew SmithMrs. Kim BaumgaertelHigh School Composition19 April 2005Introduction to Web Services Technology continues to advance, sometimes in revolutionary breakthroughs or in seemingly minor evolutions. The creation of the internet in the 1990s allowed people to access information from a wealth of resources, and allowed businesses to create their identity. This new technology matured, as did several demands. Gone are the days of technological ?toys? and innovation; they have been replaced with standards of function and use. Because businesses found it difficult to communicate with each other and themselves due to different systems, servers, operating systems, or applications, a standard way of communication was needed to keep together the seemingly fragile environments. In 2000, a technology known as Web services was created to keep business connections from falling apart, and provide better communication. ?Web services started as a vision of ?web applications? that could find each other on the Internet, establish communication channels, and exchange information and services without human intervention.? (Nakhimovsky/Myers 3) There are many definitions for a Web service, but generally speaking, a Web service is technically defined as a software application that can be accessed remotely using different XML-based languages. A Web service is normally identified by a URL (Uniform Resource Locator), a lot like a website. The difference lies in the content. Web service servers and clients send an XML document that complies to the rules of the SOAP specification, where a standard website sends a regular HTML document. A SOAP message can contain a call to a method along with any parameters that might be needed. A SOAP message can also contain a header in which extra processing parameters can be sent to the service. Web services are not a completely new technology, but rather an association of components that work together to accomplish the task of communication. It doesn?t matter what kind of computer is sending the message or what operating system it is running. It doesn?t matter where in the world the client is sending the message from, what language the software is written in. It also doesn?t matter what type of SOAP processor is running on the server. In essence, Web services are the ultimate answer in computing. Every software application can potentially talk to every other software application in the world, regardless of the old boundaries of location, operating system, language, protocol, and so on. Web services still have a long way to go. ?Web Services are still more like a movement than a mature technology.? (Nakhimovsky/Myers xix) Web services are a faster approach to system communication development. Instead of re-writing a whole new system, Web services allow the developer to use existing components. The components, known as legacy systems, are simply code that has already been written, tested, and has been found reliable. Web service systems can be developed faster by using a wide variety of programming and rapid development tools. Since any programming language can be used, current programmers can easily adopt the Web service approach by using previously learned skills or legacy systems. Entirely different systems can communicate seamlessly. Web services also offer a cheaper way to offer services. Because Web services can be created in any programming language, and because they are reusable, new developers do not have to be hired to build Web services. Web services provide businesses with lower operational costs in many ways. First, web services use the Internet, which is much cheaper that a LAN (Local Area Network) based network. Web services can be used for remote system management; being able to fix problems without having to be at the computer with problems. However this is just the beginning of the glory of Web services. Web services fit perfectly into today?s business world. Because Web services are so universally adaptive, businesses can interconnect with other businesses without having to make significant changes to either system. Web services integrate better with customers as well. Web services allow customers to access business information, order and ship products because the Web Service architecture is inter-woven into their systems. For example, if a store ran out of carrots, the store could easily order more carrots through the Web services of the carrot business. Web services provide low-cost electronic data interchange between customers and vendors. Web services can allow for remote status reports on shipping or progress from any organization, night or day. Also, Web services are being expanded onto PDAs (Personal Digital Assistant), which can allow for service people to be dispatched using Just-in-time planning instead of site-to-site. A client can request a physical service, and the workers can immediately see that a new job has been added to their list, instead of having a planned workday. Web services seem like the best technology ever, but many inter-communication issues still exist, and not all businesses have migrated to the Web service approach. After looking at the advantages of Web services, one must also look at the disadvantages of Web services. As mentioned before, Web services are more of a movement than a mature technology. ?Because web services are a relatively young technology, the standards are evolving rapidly. Applications built on one version of the specification can quickly be outdated. There is a general lack of standards in several areas such as authentication, security, and billing/contracts. Authentication is not yet implemented in the Web service standards, and is left to the web services to handle. Security and privacy are poor in the Web service architecture. There are several security measures that may be taken by the Web service, such as data transfer over SSL (Secure Sockets Layer) which encrypts all the data, secure and insecure. HTTP is insecure, allowing anyone to intercept requests from the client and responses from the server. However, security is not the only problem. Because Web services communicate over internet, this presents several problems. First, no site is available 100% of the time, and without the ability to contact the Web service on the site, Web services cannot interact. HTTP, with all its advantages, still has faults that affect Web services. It is very transactional in nature, and time is wasted creating and terminating connections, causing it to be slow. It is built to handle hundreds of request per second, instead of a longer, meaningful connection with a Web service. HTTP is not a reliable protocol, and can?t guarantee a request or response. There is no ?rock-solid? evidence that a transaction has taken place. There are performance issues as the data has to be decrypted (if encrypted), parsed (read), processed, and encoded to send to the client. Sometimes a Web service will not always match a specific client, because different clients need specialized information. Also Web service methods must stay the same, as clients rely on these methods. Beyond all of these pitfalls and disadvantages, Web services provide a very universal way to communicate. Web services offer some advantages when compared to three types of current systems: stub/skeleton systems, screen scrapers, and HTTP transactional systems. Stub/Skeleton based systems are communication systems that are ?meant to provide programmatic access to some form of remote service as though it was a local entity.? (Potts/Kopack 44) The ?stub? is the code on the client side, and the ?skeleton? is the code on the server?s side. They typically can handle a higher number of requests because the connection is persistent; however, interoperability is much less between these systems. Some popular solutions that use this architecture are CORBA, RMI, and DCOM. Web services offer a greater amount of interoperability than stub/skeleton based systems. Screen scrapers are client-side applications that make use of an existing interface such as a Web browsers or mainframe terminal. They push data into an interface, and then read (or scrape) the returned data off of the interface and convert it into something that the client application needs. ?Screen scrapers aren?t pretty.? (Potts/Kopack 53) They rely on an interface, and if it changes, they have to be re-written. Lastly, are HTTP transactional based systems. These run today?s main web applications. They are based on a client/server architecture with a typically larger client to server ratio. They communicate over standard ports (TCP 80, 81), which most networks leave open. Some common HTTP transactional systems are CGI (Common Gateway Interface), Servlets/JSP (Java Server Pages), ASP (Active Server Pages), and PHP (Hypertext Pre-Processor). With the advantages of HTTP transactional systems, there are several issues including, performance issues, lack of a directory service, and no true error handling.The amazing part is that these systems can be converted to Web services fairly easily. After looking at what Web services are, how they compare to other technologies, it is time to look at the components that make up Web services. As stated before, Web services are individual technologies that work together to effectively communicate between each other. The major components of the Web service architecture are HTTP/1.1, Cookies, SOAP 1.1, UDDI 2.04, WSDL 1.1, XML 1.0, and XML Schema. Most of these technologies, including the Web service specification, are maintained by the World Wide Web Consortium (W3C). The W3C looks for the best in standards, not vendor-specific ideas. Each of these components plays a vital and different part in the Web service architecture. To communicate over the internet, several different protocols may be used. Near the base of all communication is TCP/IP (Transmission Control Protocol / Internet Protocol). TCP/IP is a lower level set of protocols for the transmission of data across a network. TCP/IP has more overhead information than other protocols such as UDP (User Datagram Protocol), but has more reliable delivery. Built upon TCP/IP are other protocols such as HTTP, SMTP, FTP, Jabber, etc. HTTP, or Hypertext Transfer Protocol, was built in the early 1990?s, and is the workhorse of the web. HTTP facilitates the transfer of requests for a browser to a Web server. In HTTP, communications are established through a simple ?handshake? mechanism. The client makes a connection to the server, the server sends the socket to connect on, the client requests data, the server processes the request and sends the result back, the client acknowledges the data, and the server closes the connection. SOAP makes great use of HTTP; however, HTTP is not required for SOAP and Web services. HTTP is by far the largest used protocol for Web services. Web services can also use FTP, or File Transfer Protocol, which is designed for moving files from one computer to another. Another protocol that is used for Web services is SMTP (Simple Mail Transport Protocol) which is used for sending email. SMTP works by checking if the message that is being sent, is being sent to an address on its server. If the address is not on it, SMTP simply sends it on to another server which does the same thing, until the message reaches the right server. SMTP takes much longer than HTTP or FTP, and the messages may not even reach their destination. Furthermore, it is easy to eavesdrop on the messages along the way. However, SMTP is perfect for sending a message to a client that is not available all the time, or publish/subscribe types of Web services. Jabber is a protocol that is made for instant messaging, and communicates with most instant messaging services and programs. Jabber is the newest protocol of the protocols looked at. All of these protocols have strengths and weaknesses, but Web services can use any of the afore mentioned protocols. It is up to the Web service developer to choose the protocol that would work the best for the Web service. Another key component and cornerstone of Web services is XML. XML stands for Extensible Markup Language and is more of a meta-language in that it is a language that is used to create grammars such as WSDL and SOAP. XML describes data in a way that is human and computer readable. It is a tag-oriented language, much like HTML or SGML. XML documents must be written according to the xml grammar rules, or the XML parser will give an error. A document that follows these rules is considered to be ?well-formed.? There are several components to XML. There is the XML document, the XML Parser, DTDs, XML schemas, and namespaces. The XML parser produces a program-readable version of the document. The XML schemas provide a powerful way to describe the structure of XML documents; they are more powerful than DTDs (Document Type Definition), and have made DTDs obsolete. Schemas specify elements, their attributes, their range of values, and their data types. The namespaces are a prefix to the tag name separated by a colon, and a declaration of that namespace?s unique identifier, which is typically a URL. They prevent a XML document from having two different tags with the same names. All of these components work together through the document?s usage. XML provides a powerful way to describe and use data. This makes it ideal for data transfer between Web services. XML is not enough to accurately describe a message for transfer between Web services. In 2000, the SOAP specification became a standard. It is not a product that was created by a vendor, but rather a document that describes the characteristics of a piece of software. SOAP used to stand for Simple Object Access Protocol, but is now considered a name. It is a XML-based language, with a tighter specification for the contents. SOAP is much less than other alternatives such as DCOM or CORBA, but it has a higher level of abstraction so it can be used on any operating system and any programming language. ?SOAP does not specify what data can be moved or what function calls can take place over it.? (Potts/Kopack 126) It is simply an XML grammar that defines how to send and receive messages. A SOAP message consists of an envelope that contains an optional header and a body. The header contains instructions on how to process the message, and the body is a payload that contains the method call. SOAP is used by Web services to send data and method call between the client and the server. It is a universal way to communicate with any Web service, making the Web service approach much more appealing. In all this Web services are still missing a component. It is easy to communicate with a Web service through the protocols and data formats mentioned above, but not if the client has no knowledge of the Web service. The question is posed. How does a potential client learn about the Web service? Up to this point, the answer might be through HTML documentation or other. However there is a much better standard known as WSDL, or Web Service Description Language. WSDL is an xml-based language that describes items such as what methods may be called, parameters for these methods, response types, protocols used to connect and receive data from the Web service, the URL of the Web service, etc. A programmer can write a client solely off of this document. Now, programs and IDEs (Integrated Development Environments) can automatically generate a WSDL document for a Web Service, and some can even generate a simple client from the WSDL descriptor. WSDL answers the question of how to communicate with the Web service, and is another advantage to Web services. Lastly, there is a need to find a Web service on the Internet. Instead of searching for hours, trying to find the types of Web services needed, there is a solution called UDDI. UDDI, or Universal Description, Discovery, and Integration, is a special type of registry that lists web services that a client might potentially be interested in. The potential customer can search the registry, browse the results, find a potential service, look at its description and WSDL, and use that Web service. Developers publish their Web service information to the registries, and then receive customers. There are three types of registries: public, private, and restricted. Public registries are available to everyone. Private registries exist behind a firewall, and usually are a company?s registry of web services. Restricted registries are only accessible to certain organizations, such as partnerships. UDDI completes the Web service puzzle by allowing clients to find Web services that they can consume, or use. Web services will be the answer to many of today?s communication and computing problems. They offer ease of use, universal information exchange, new business models, and more. As the technologies that drive Web services are molded into a more interoperable system, all the prior barriers will be removed. Web services are still not a mature technology. Even now, in 2005, standard are being revised and built to further enhance the Web service architecture. However, the technology still advances. New ideas as well as solutions to common Web service problems are being created. Web services, although not as much of a revolution as the creation of the Internet, are still a very limitless and powerful innovation. The future of Web services is bright.

[nonon 0]

Hi, that's what i call a HUGE post Well i'm know learning Web Services that i will have to use with Servlets/JSP/XML in my college project, i've read your post, i must say it's a good intro to the subject. Now i need some practicle examples in order to get my first one's :lol:Besides W3C do you know any good sites on this matter ? Regards

[csmith 0]

Some sites which you may wish to look at are:

 

http://forums.xisto.com/no_longer_exists/ (a tutorial)

 

http://www.oracle.com/technetwork/java/index.html (web services code examples)

 

http://www.onjava.com/pub/a/onjava/2002/06/05/axis.html (good for a beginning web services code example)

 

http://shop.oreilly.com/product/9780596002695.do (more web services code examples)

 

http://www.jguru.com/ (running web servcies on Apache Axis)