Using RPC-Style Web Services with J2EE - Web Service Overview (Page 2 of 15 )
This first section provides the underlying information and concepts required to successfully implement Web Services. Before employing Web Services, you should understand which problems they are designed to solve and the motivation behind them. This should ensure that you apply Web Services in appropriate places in your application.
What Is a Web Service?
A Web Service is essentially an application component that can be accessed using Web protocols and data encoding mechanisms—primarily HTTP and XML. In some cases, this is a third-party service hosted remotely. A Web Service differs from a traditional component in several ways, not only in the protocols used to access it. Under the component model, a currency conversion component could bring with it a file containing a fixed set of currency conversion rates that must be updated regularly. However, it would be up to you (the component user) to ensure that this information is updated. On the other hand, a Web Service is (or should be) a "living" entity, such that it brings with it any data and "back-end" functionality it requires. Unlike the component, a currency conversion Web Service takes responsibility for any updating of data or functionality. Your application simply uses the conversion service and leaves the details of obtaining the latest data and subsidiary services to those who implement and host the service.
Similarly, a Web Service can represent a courier service or a credit-card processing service. Again, you do not need to concern yourself with how the service is implemented, simply the results of using the service. Many types of Web Services are appearing that provide a sliding scale of functionality from low-level infrastructure to high-level business services.
Applications can be built from services in a similar way to building applications from components. You will combine standard services (such as credit-card authorization) with custom code to create your desired application.
As a software developer, you might write Web Services for others to use. In this case you would
Decide what functionality you wish to expose as a service.
Implement the service being offered.
Describe the service being offered.
Publish the description.
Inform direct consumers of your Web Service that it is available (or wait for them to discover it).
Alternatively, you may use Web Services as part of your application as follows:
Discover an interesting service.
Retrieve the description.
Plug it into your application.
Use the service as the application executes.
This all sounds very easy, but you need a ubiquitous framework for Web Services to stop this from sliding into chaos. The key factor in delivering such a framework is the widespread agreement to use common, Web-based protocols. In the first instance, this comes down to the use of the Simple Object Access Protocol (SOAP), under which XML-encoded messages are sent over some form of transport mechanism—usually HTTP. SOAP is the way in which Web Services communicate. Other protocols are also required to deliver the full framework, and you will encounter these protocols over the course of the next two days.
Why Use Web Services?
Web Services bring similar advantages to the use of components. Using a service allows you to take advantage of another organization's expertise in, say, credit-card processing, without you having to become a specialist in it yourself. The service model enables you to use the most powerful and up-to-date functionality by connecting to a remote running service.
Although a service-based approach to application development is not a new concept, it has traditionally presented difficult challenges:
Interoperability between different distribution mechanisms, such as CORBA, RMI, and DCOM.
Application integration, including legacy systems, cross-vendor, and cross-version.
Web-based business requires cross-organization development and high flexibility to accommodate a rapid rate of change, and safe operation through company firewalls.
Web Services can provide a consistent, cross-organization, cross-vendor framework that will speed up the integration of applications and application components. By selecting existing, widely-used standards, the Web Service framework removes many barriers to integration that existed when using other frameworks. The Web Service model is language- and platform-neutral, so developers anywhere can potentially build and consume Web Services.
Probably the most important factor of all is that all the major application, platform, and technology vendors have adopted the Web Service concept and the associated protocols. This means that Web Services will form a large part of application development over the next few years.
 This chapteris fromTeach Yourself J2EE in 21 Days, second edition, byMartin Bond et. al.(Sams, 2004, ISBN: 0-672-32558-6). Check it out at your favorite bookstore today. Buy this book now.
|
Next: Web Service Technologies and Protocols >>
More Java Articles
More By Sams Publishing
/ 11 
