Building Web Services in Java
- Web Services Architecture
- Java Building Blocks
- The Future of Java Web Services
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
In Chapters 2 and 3, "The Internet and Web Services Changing Business" and "Becoming a Web Services Provider," you should have gained a better appreciation of just what Web services are all about and why they are they so popular. But now you might just be wondering why you would want to use Java to build Web services. After all, other options do exist; you could use Perl, Python, or Microsoft .NET.
The simple answer is that Java provides the perfect complement to XML: one provides a portable data format, the other a portable language format. With Java you have a wide range of Enterprise APIs (Application Programming Interfaces) that enable you to easily connect to databases, interact with messaging services, or connect to legacy systems.
The Java approach is to provide the developer with maximum power and flexibility. You can select the best virtual machine that satisfies your needs, the best JDBC driver implementation, the best J2EE server, the best Web server, or even the best hardware and operating system. If you later change your mind, you can easily modify your application, often without any code changes.
This chapter looks in more detail at some of the Java building blocks that can be used to build Web services.
Web Services Architecture
Before jumping into the specific Java tools that you can use to build Web services, you need to examine the different types of Web service architectures that you might utilize. This chapter explores two categories. You use the first category of architecture to build new applications that are exposed, at least in part, via a Web service. The other option involves exposing existing applications via a Web service.
By all accounts, business-to-business communications will be one of the dominant application areas for the deployment of Web services. This should be especially true early on in the growth of Web services, because it is easier to make two applications communicate successfully than it is to do the same with a server and a myriad of clients. As an example, a company might want to join an online market. Part of the entrance requirement might be to implement a Web service that provides a product listing. This sort of application would follow a server-to-server communication path, as shown in Figure 4.1.
){kind=link}
Figure 4.1 A server-to-server communication example for a Web service architecture. In this model, the Web service is a new application.
A particular business might want to extend this application to enable individuals to connect to the product listing Web service directly. In this case, the client server architecture provides business-to-consumer communication. In this model, unlike a HTML application, the server isn't able to control how the service appears to the client. Instead, the service would need to follow an industry-standard approach that enables a client to "shop" at different online markets, as demonstrated in Figure 4.2.
){kind=link}
Figure 4.2 A client-to-server communication example for a Web service architecture. In this model, the Web service is a new application, but the client can now change services by utilizing industry standards.
If a business doesn't want to follow the two-tier model laid out in the previous example, the other option is to employ a middle tier, which sits between the new Web service—for example, the product listing service—and the client. Although this introduces extra complexity, it does enable the Web service to be customized for different types of clients. For example, a wireless client might want to utilize WML, whereas a high-bandwidth client might prefer a Swing application, as demonstrated in Figure 4.3.
){kind=link}
Figure 4.3 A client-to-server communication example that utilizes a middle tier to customize the Web service to the client's needs and capabilities.
At the other end of the spectrum are the vast quantities of existing services that are written in everything from COBOL to C to C++ and even Java. Businesses will not want to, and may not be able to, abandon these legacy applications. Instead, they will want to wrap them in a Web service blanket that enables them to be exposed to a myriad of new clients. This model applies in all three of the previous cases as well, as shown in Figure 4.4.
){kind=link}
Figure 4.4 Existing legacy applications can be wrapped into Web services, allowing corporations to leverage existing services as they migrate to an online communication model.
No matter which the fundamental architecture is employed to build your Web service, however, Java is the perfect language to use. From the wide support for Enterprise requirements to the rich interactive user interfaces, Java has something for everyone. With the widespread adoption of Java among the software community, and the competition between vendors to satisfy the needs of the developer, you couldn't ask for a better solution.