Codenotes for Web Services in Java and .Net

Chapter 1 INTRODUCTION What Are Web Services? If you search the Internet, you will find an astounding variety of answers to the question "What is a web service?" The only common consensus is that web services share the following characteristics: 1. Web services use XML-based standards. As you will see in this book, web services are built on numerous APIs, standards, and protocols. Almost all of these systems use XML as a core component. 2. Web services use the Internet. In truth, most web services use standard Internet protocols, including HTTP and TCP/IP. However, web service technologies can also be deployed over messaging systems and other transport protocols. 3. Web services are platform- and language-neutral. You can build and deploy web services on almost any platform, using almost any language. Assuming you use the same version(s) of the same standard(s), a client developed in Java could easily use a web service developed in C# and hosted on Microsoft's Internet Information Services. The next obvious question is "How can I use web services?" The answer to this question varies, depending on your specific need: 1. Linking legacy systems. If you work in a large corporation, you may want to take advantage of web services to provide cross-language and cross-platform compatibility. Why spend the time and money to rewrite your perfectly functional COBOL system in Java when you can develop a web service layer that allows your COBOL system to communicate with your new Java web portal? 2. Business to Business (B2B). The long-standing dream of simple, workable B2B communication can take a giant step forward with web services. Because web services work on open protocols, using XML you can develop B2B systems that actually work. No longer do you have to struggle with shared platforms or open large holes in your corporate firewall. Simply create straightforward web services that let your B2B partner build his own client using his own technology choices. Each side maintains control of the important pieces (technology choice, infrastructure, security, etc.), but both sides share a common, easy-to-understand set of services. 3. Service-based software. Web services open the door for many different types of service-based software. In the future, you may find small shell client programs that connect to a wide variety of web services on a subscription basis. The companies that host the web services can monitor your connections and charge you for each use. This approach may help prevent the ever-increasing bloat in common software packages. A TYPICAL WEB SERVICE A typical web service involves three distinct components. First, you need a contract that defines the service. Second, you need a producer, or host, for the service. Finally, you need a consumer, or client, to use, or consume, the service. The Contract The web service contract defines the name of the service, the service's input and output parameters, and how to communicate with the service. With some APIs the contract may also include information related to publication and discovery. In any case, the contract is always an XML document that follows a rigidly defined XML Schema (or dTD in some cases). The contract does not specify which software you have to use for either the server or client, nor does it specify security or transactional control. The Producer The producer generates the web service and hosts it. In most cases, the producer is a combination of a small-footprint web server with additional back end systems. The back end can be anything from a few simple stand-alone programs all the way up to enterprise systems using EJB. The real power of web services is that the contract isolates the producer from the client. The producer can use almost any back end system to host the service and provide the functionality,Brill, Gregory is the author of 'Codenotes for Web Services in Java and .Net' with ISBN 9780812966398 and ISBN 0812966392.